Discovery Work as a Product Designer (Not Just Executing PM Specs)

You spent three days on a flow. You opened Figma at 9 a.m. on Monday and didn't really come up for air until Wednesday afternoon. You hand the PM one file. They glance at it, say "looks good, ship it," and move on. Nothing in their spec changed. Nothing in the roadmap shifted. You feel useful but invisible. And six months later your perf review says "executes well" instead of "shapes the roadmap."

I've watched designers blame the PM for this. The PM is busy. The PM doesn't get design. The PM has favorites. None of that is the actual problem. The actual problem is the artifact you handed over. One design means one decision: ship or don't ship. PMs don't reject single options. They rubber-stamp them. I call this the one-option trap, and almost every "execution-only" designer is stuck in it without realizing.

The fix isn't working harder. It's changing what lands on their desk.

Why this matters more than it did two years ago

Two trends collided in the last 18 months. First, discovery designers (the ones who shape what gets built, not just how it looks) earn meaningfully more than execution designers at the same level. From the latest public salary studies (Pencil & Paper's 2025 Product Design Salary Report, the Dribbble Salary Database, and the Read the Docs design salary thread), the gap runs roughly 18-30% at mid-level and widens past senior. A senior product designer at a Series B who shapes spec lands closer to $190K total comp. The same title, same company, same level, executing-only? Closer to $150K. That's not a small delta. That's a car.

Second, PMs are increasingly shipping without designers. Cursor, Linear, Lovable, v0, and the wave of AI design tooling means a PM with taste can ship a competent flow themselves. The designers who survive that shift are the ones contributing upstream, at the problem-definition layer, not the polish layer. If your only value-add is "makes the Figma file look nice," you're racing AI to the bottom.

This isn't doom. It's a clarification. The job is shifting toward discovery, and the designers who already operate that way are pulling further ahead. The mechanics of how they do it are learnable. That's what the rest of this playbook covers.

Discovery vs execution: the actual mindset split

Execution mode answers one question: "How should this look and behave?" You receive a problem, scope, and constraints. You make a thing. You hand it back.

Discovery mode answers a different question: "Is this even the right problem to solve?" You receive a brief and you push on it before you open Figma. You talk to customers. You sketch alternatives that don't match the spec. You bring evidence into the conversation.

Both modes matter. The mistake isn't doing execution work. Execution is most of any designer's week, even at staff level. The mistake is doing only execution work and being surprised when you're treated like a service desk.

Concrete behaviors per mode:

Execution-mode designer:

• Opens Figma the moment they get a spec
• Asks "what should the empty state look like?"
• Hands over one file
• Tracks shipped flows in their portfolio
• Reports up: "I shipped X, Y, Z this quarter"

Discovery-mode designer:

• Reads the spec, then closes the laptop and goes for a walk
• Asks "who are we building this for and what do we know about them?"
• Hands over three options with tradeoffs
• Tracks spec changes their work caused
• Reports up: "I changed how we approached X. Here's the customer evidence and the outcome."

Notice the executive verbs. Discovery designers say "changed," "shifted," "redirected." Execution designers say "shipped," "completed," "delivered." The first set sounds like ownership. The second set sounds like throughput.

The 3 paths rule

This is the single mechanical change that does the most work. Whenever you hand a design to a PM, hand them three options:

1. The safe path: closest to what the PM specced. Lowest risk, lowest reward. The thing they expected.
2. The stretch path: what you'd build if you had two more weeks and a bit more scope. Same problem, more ambitious solution.
3. The weird path: the option that solves a different problem, or solves the same problem in a way nobody's considered. Usually inspired by a customer interview or a competitor's flank attack.

Each path comes with three labels: time cost, risk, and upside. That's it. No 10-page Notion doc. A one-pager with three Figma frames and a small table.

Why three? Because of how PMs actually decide. With one option, the verdict is binary: ship or kill. PMs almost always ship, and that's the rubber-stamp loop. With two options, you've created a false binary. The PM picks the safer one and you've trained them to expect a safe-vs-risky choice every time. With three options, you've created a real conversation. The PM has to articulate why they prefer one. And once they articulate the why, you've moved from "executing a spec" to "co-deciding a strategy."

I've never had a PM reject a 3-paths handoff. I've had plenty pick the safe path. But the conversation is different. We're discussing tradeoffs instead of approving polish.

A working template I use:

Problem: [one sentence — what we're trying to do for the user]

Path A — Safe (1 week)
  What: [what the PM expected, designed cleanly]
  Risk: low
  Upside: ships on time, hits the OKR

Path B — Stretch (2 weeks)
  What: [more ambitious solution to same problem]
  Risk: medium — needs backend changes
  Upside: addresses the second-order problem we'll hit in Q3 anyway

Path C — Weird (3 weeks)
  What: [solves a different framing of the problem entirely]
  Risk: high — unclear if customers want this
  Upside: 10x the impact if right; learnings either way
  Customer evidence: [name a customer interview that pointed here]

That's a one-pager. Fifteen minutes to write once you've done the design thinking. Adopt it for every handoff for one quarter and watch what happens to your perf review.

Opportunity-solution tree, designer edition

Teresa Torres' opportunity-solution tree is the cleanest framework I've found for staying upstream of execution. The original version: outcome at the top, opportunities (customer pains and desires) in the middle, solutions branching from each opportunity at the bottom.

The designer adaptation: your job is to populate the middle layer, not just the bottom. Most designers live entirely at the solution layer (sketching, prototyping, polishing things that solve known opportunities). PMs live mostly at the outcome layer (quarterly OKRs, business metrics, executive narratives). The middle layer (the actual customer problems) is the contested territory. Whoever populates it well, owns the roadmap.

A real example. I worked on a checkout flow for a B2B SaaS that wanted to lift activation rates.

Outcome layer (PM territory): Increase 30-day activation from 38% to 50%.

Opportunity layer (the real fight):

• Users abandon during seat-assignment because they don't know who to invite yet
• Users skip the integrations step because they think it's optional
• Users complete signup but never return because the product feels empty until they invite teammates
• Users invite teammates but those teammates ignore the email because subject lines are generic

A junior designer would have been handed "redesign the seat-assignment screen" and made it pretty. The discovery move was to map all four opportunities, then run a quick interview round to figure out which was actually the binding constraint. (It was the third one, the empty-product feeling, and it was 4x the size of the other three combined. Nobody had specced for it because nobody had asked.)

The artifact for this is dirt simple. Open FigJam. Three rows: outcome, opportunities, solutions. Sticky notes. The rule is no solution gets attached to an opportunity that wasn't validated in at least one customer conversation. That rule alone separates discovery designers from execution designers.

Customer interview rhythm: 3+ per week is the floor

Designers tell me they "don't have access to customers." This is almost never true. It's usually one of three real problems:

1. They've never asked the CSM team for warm intros (5-minute Slack message away)
2. They think they need PM permission to schedule a chat (they don't)
3. They're worried about looking like they're stepping on the PM's toes (also a misconception, addressed below)

Three customer conversations a week is the floor. Not the ceiling. Pencil & Paper's 2025 designer survey put the median for senior+ designers at five interviews per week during active discovery. Three is the bare minimum to call yourself a discovery designer.

How to actually get there:

• Slack the CSMs once. "Hey, I'm trying to talk to 3 customers a week about [problem area]. Can you queue intros?" That one message produces interviews for the next 6-8 weeks. CSMs love it because their customers feel heard.
• Hijack existing calls. If sales does discovery calls or CS does QBRs, ask to silently shadow two a week. Half an interview is better than zero.
• DM 5 customers in the in-app messenger. "I'm a designer working on X. Got 15 minutes this week to tell me what's broken?" Reply rate runs 30-50% if the product has any kind of relationship with the user.
• Steal post-cancellation surveys. When churn happens, the cancellation form is gold. Read all of them weekly. Pull the 5 most articulate complaints into your tree.

A sample question bank, the one I keep in a Notion page and pull from for every interview:

1. Walk me through the last time you tried to do [task]. What happened?
2. Where did you get stuck?
3. What did you try before this product? Why didn't that work?
4. If I deleted this feature tomorrow, what would you do instead?
5. What would have to be true for you to use this every day?
6. Who else on your team touches this? What do they do differently?
7. What's the worst part of your week related to [problem area]?
8. Tell me about a time this product surprised you (good or bad).
9. If you had a magic wand, what would you change?
10. Is there anything I should have asked but didn't?

Notice what's missing: questions about your design. You're not asking "do you like this button color." You're asking about their world. The design questions come later, in prototype validation.

Prototype-driven validation: Tuesday prototype, Thursday insights

Once you have opportunities mapped and a few solution sketches, ship a prototype before the spec is finalized. I run a cadence I call Tuesday prototype, Thursday insights.

Monday-Tuesday: Build a Figma prototype of the most promising 1-2 paths. Not pixel-perfect. Functional enough to click through. 4-8 hours of work, max.

Wednesday: Send to 5 customers via Maze, UserTesting, or just plain Loom + a Slack DM that says "click around this for 5 minutes and tell me what you'd expect to happen." Five users is enough to surface the 80% pattern; Nielsen's classic study held up when Maze re-validated it in 2024.

Thursday: Synthesize. Three slides: what worked, what broke, what surprised us. Drop in PM channel.

Friday: Update the 3-paths doc with the prototype data. Now your handoff isn't "here are three options." It's "here are three options, and option B was tested with five customers. Three completed the task, two got stuck at the same step. Here's the recording."

That changes the conversation. PMs argue with opinion. They don't argue with five recordings of customers getting stuck. The prototype data shifts you from "the designer thinks" to "the customers said," and that's a different kind of authority.

Cheap tool stack for this:

• Maze: best for unmoderated quant prototype tests. ~$99/mo.
• UserTesting: best for moderated qualitative. Pricier but worth it for high-stakes flows.
• Loom + Slack DM to 5 customers: free, surprisingly effective, only requires that you actually press send.

The point isn't the tool. The point is you tested before the spec was final. That's discovery. Anything after the spec is locked is execution polish.

"But you're not the PM": the misconception that keeps designers small

Every time I coach designers on this stuff, someone surfaces the same fear: "won't my PM think I'm overstepping?"

Discovery work doesn't make you a PM. It makes you a better designer. The distinction is real and worth holding onto. PMs own the decision about what gets built. Designers own the input that shapes the decision. Bringing customer evidence, three options, and prototype data isn't taking the PM's job. It's doing yours competently.

Scripts that work, in my experience:

• Adversarial framing to avoid: "I don't think we should build what you specced." (You've made it about you vs them.)

• Discovery framing that lands: "I sketched three paths so we can pick together. Path C came out of a conversation with two customers who described a different problem than the brief. Worth a look?"

• Adversarial: "The spec is wrong."

• Discovery: "I tested the spec with five users on Tuesday. Three got stuck at step two. Here's the recording. What do you think?"

• Adversarial: "I should be in the roadmap meetings."

• Discovery: "I'd love to bring customer interview findings to roadmap planning. Want me to put together a 5-min summary for the next session?"

The pattern: turn opinions into artifacts, turn confrontation into invitations. PMs don't actually want to fight designers. They want fewer things to figure out alone. Show up with options, evidence, and a posture of "let's decide together," and you're the easiest collaborator they have. Show up with "I disagree," and you're the hardest. Same content, different framing, completely different reputation.

Track your discovery wins, or they don't exist

Here's the brutal truth about perf reviews at most product companies: influence that isn't documented didn't happen. You'll meet senior designers who quietly reshaped three roadmaps in a quarter, then watched a peer who shipped two flashy launches get promoted ahead of them. The peer told a story. The senior designer didn't.

Keep a discovery log. One row per win. Five columns:

Three columns are descriptive. Two are evidence. The "PM acknowledgment" column matters: it's a Slack screenshot, a Loom comment, a roadmap doc edit. Something dated and traceable. When perf review comes, you're not pleading "I think I added value." You're showing receipts.

This log takes 5 minutes a week to maintain. Most designers never start one. The ones who do walk into perf reviews with a different conversation than their peers.

The mechanical shift

Here's what I want you to take away. The shift from execution to discovery isn't a personality change. It isn't about being "more strategic," whatever that means. It's mechanical. You change four artifacts:

1. Hand over 3 paths, not 1 design
2. Maintain an opportunity-solution tree that you populated with interviews
3. Run 3+ customer interviews a week, every week
4. Run a Tuesday prototype, Thursday insights loop on every meaningful flow
5. Keep a discovery wins log and bring it to perf review

Five artifacts. None of them require a title change, a manager's permission, or a new job. You can start every one of them on Monday. The PM relationship shifts as a side effect — not because you talked to the PM about it, but because what you put on their desk changed.

That's the whole game.

Learn More

• Companion JD — Product Designer
• A Day in the Life of a Product Designer
• Your First 30/60/90 Days as a New Product Designer
• End-to-End Ownership: Problem to Ship to Learn
• Design Critique That Improves Work
• Path From Product Designer to Staff Designer