Why your product team doesn't respect design (and what to do about it)

The most comfortable version of this problem is that product teams don't appreciate design because they don't understand it. That's occasionally true. More often, they understand what design is providing and have made a rational decision that it's not worth much.

That's a harder diagnosis to sit with. It's also more useful, because it points at fixable things.

The problem is usually the work, not the perception

When designers say they don't get respect, they often mean their input doesn't change decisions. Product moves forward without waiting for design, or waits but then ignores the output. That can be a culture problem. It can also be a feedback loop telling you that the designs aren't answering the questions the product team is actually asking.

A lot of design work solves the wrong problem. A product manager is trying to figure out whether a feature is worth building. The designer brings back a high-fidelity mockup of how the feature would look if they built it. Those aren't the same thing, and the product manager can sense the mismatch even if they can't name it.

The version of design that earns consistent respect is the version that makes product decisions easier. It reduces uncertainty before engineering time gets committed. It surfaces failure modes before they're expensive to fix. It gives the team something to react to that's specific enough to be wrong about.

Designers often don't know the business well enough

This is the part designers usually don't want to hear. If you've been on a product team for six months and you can't tell me what the key conversion metric is, which user segment is being prioritized, or what the biggest complaint in support tickets is, your designs are probably not anchored to the problems that matter most.

Product managers spend most of their time thinking about these things. When a designer shows up with work that doesn't connect to them, it signals that the designer is solving a different problem. A design problem rather than a business problem. That's when design starts to feel like a tax on the process rather than a contributor to it.

The fix isn't to become a product manager. It's to understand the context well enough that your design decisions are legibly connected to what the product team cares about. "I went wide here because we don't know yet whether the heavy users or casual users are the ones who need this" is a sentence that connects design thinking to business questions. "I explored a few visual directions" doesn't.

The brief problem

Much of the friction between design and product comes from designs being evaluated against criteria that were never shared. Product says "this isn't quite right" and can't fully articulate what right would look like. Design interprets that as vague feedback and feels dismissed. What actually happened is that there was no shared definition of what the work was supposed to accomplish.

A brief, even a two-sentence one, changes this. "We're trying to reduce the number of steps to complete this action. Secondary goal is consistency with the new navigation pattern." That gives design something to solve against and gives the product team something to evaluate against. When the criteria are shared upfront, feedback stops being a personality contest and starts being about the work.

Product managers often don't write briefs because they think design can figure out the problem from context. Sometimes design can. When it can't, nobody figures that out until several rounds of review have already happened.

Review process failure modes

A lot of respect erodes in the review process. Specifically, in the review process where design shows up with a finished-looking artifact and the product team reacts to it.

Finished-looking artifacts invite a certain kind of feedback: nitpicking the surface. "The button label should be different. Can we try a darker color here." This is frustrating for designers because it feels like the feedback is about the wrong things. But it's partly a setup problem. When you present something that looks done, people react to what's in front of them.

The early-stage version of design work (rough sketches, flow diagrams, concept variations) invites a different kind of engagement. It signals that decisions are still open and that input can change the direction. Product teams are more useful early and more nitpicky late, which is the opposite of when most design teams involve them.

When it actually is a culture problem

Sometimes the problem is real organizational indifference to design. A product manager who has shipped products their whole career without significant design involvement is not going to immediately change that model. An engineering team that sees design handoffs as a bottleneck will work around them.

In these cases, the thing that changes perception is making design's value visible in terms the team cares about. Not "design makes things more beautiful" but "the last three flows we researched before building had a major structural change in them, which would have been expensive to fix in code." You build that case by actually doing the work and documenting what happened. It takes longer than you want it to.

What doesn't work is asking for respect before demonstrating the value. The seat at the table doesn't come from making an argument for having it.