🎨Working with Design
The PM-designer relationship is the single most leveraged partnership for a PM. Get it right and the team flies.
Most PM-designer friction is unnecessary and comes from PMs not understanding the design craft. Investing in this relationship pays out for years — and the patterns are surprisingly learnable.
Bring the designer in early with a problem (not a solution), give them creative latitude, respect the craft, and partner on trade-offs. Treating design as 'make this pretty' is the fastest way to ruin the relationship and produce mediocre product.
The four PM-designer modes
- Spec-and-handoff. PM hands designer a PRD; designer comes back with pixel-perfect designs. Worst mode — slow, low-trust, mediocre output.
- Design-led, PM-supports. Designer drives the experience; PM provides context and unblocks. Common at design-led companies (Airbnb early, Stripe).
- PM-led with designer-support. PM is sketching, designer polishes. Common at execution-heavy teams. Risky — usually means the PM is over-designing.
- True trio collaboration. PM, designer, tech lead jointly own the problem and meet 2-3x per week. Best mode by far.
Aim for #4. If you can't, aim for #2.
How to bring a designer in
- Bring a problem, not a solution. "Users are abandoning checkout at step 3, we don't know why." Beats "let's add a progress bar."
- Bring the research. Customer interview clips, data, support tickets. Designers want context.
- Show the constraint, not the spec. "We have 4 weeks. Mobile-first. Must integrate with existing X." Lets the designer make trade-offs.
- Reserve judgment until v1. Don't critique sketch #1; the designer is exploring.
Working through design reviews
A good design review (60 min):
- PM frames the problem and the constraint. (5 min)
- Designer walks through the design. (15 min)
- Team asks questions. What about [edge case]? Why this not that? (15 min)
- Decisions and trade-offs. What are we committing to? What's still open? (15 min)
- Next steps. Who's doing what by when? (10 min)
The bad design review: PM critiques the design without engaging with the rationale. Designers feel marginalized; the team learns to avoid showing work early. Don't do this.
When you disagree with a designer
Two principles:
- Bring data, not preference. "I think users won't get this" → 'I tested with 5 users and 3 missed the call to action."
- Decide who has the call. Usually the designer has the design call; you have the product call (what problem we're solving, what scope). Negotiate at the seam.
The right escalation when you genuinely disagree: bring it to the tech lead or your manager. Don't go silent and then ship a watered-down version.
Real-world examples
Airbnb is famously design-led — co-founder Brian Chesky and CEO is a designer. PMs at Airbnb are explicitly expected to bring problems to designers, not solutions. The design org has more decision authority than at most companies; PMs who don't adapt struggle.
Linear's product trios — PM, designer, engineer — work in tight three-person cells with shared ownership. The PM is not 'above' the others; they're peers. The product reflects it: Linear is one of the most coherent products in dev tools.
Go deeper — recommended reading
Interview questions (1)
Q1Tell me about a time you disagreed with a designer. How did you resolve it?behavioralmid▼
Situation: We were redesigning the onboarding flow. The designer wanted a 4-step wizard; I thought users would abandon at step 2.
Task: Resolve the disagreement and ship something better than either of our defaults.
Action: I avoided just asserting my opinion. Instead I asked: 'what's our hypothesis with the 4-step flow?' We surfaced that the designer's hypothesis was 'progressive disclosure reduces overwhelm' and mine was 'every additional step compounds drop-off.' Both are defensible. So we tested: a clickable prototype with 5 users on each version. 3 of 5 users on the 4-step version dropped at step 2 because the value prop wasn't clear yet. We landed on a 2-step version with progressive disclosure inside step 1 — combining both of our intuitions.
Result: D1 activation moved from 38% to 46%. More importantly, the designer and I built a habit: every disagreement, surface the underlying hypothesis, then design a test. We never had a real fight after that.
Reflection: The mistake junior PMs make is asserting opinion. The senior PM move is surfacing the hypotheses behind each opinion and testing them.