PM Gym

Product Discovery 101

Make sure you're building the right thing — before building it right

Delivery answers "are we building it right?" Discovery answers the more dangerous question: "are we building the right thing at all?" This guide covers how to shrink risk cheaply, before you commit a team of engineers to the wrong idea.

Step-by-step lessons

Discover Before You Build

Four short lessons: discovery vs. delivery, the four big risks, testing your riskiest assumption, and making discovery continuous.

1

Discovery vs. Delivery

Product work has two distinct jobs. Confusing them is why teams flawlessly build things nobody wants.

Everyday example — measure twice, cut once

A carpenter who measures twice before cutting wastes almost no wood. One who cuts first and measures after throws away expensive planks. Discovery is the measuring — cheap, quick, done before you commit. Delivery is the cutting — costly and hard to undo. Teams that skip straight to cutting (building) look busy and fast, but they burn months producing beautifully-made things nobody asked for.

Right thing?

Discovery

Reducing uncertainty about what to build. Fast, cheap experiments and research to decide whether an idea is worth building at all.

Thing right?

Delivery

Building the chosen thing well: engineering, quality, shipping. Expensive and slow — which is exactly why discovery should come first.

The whole point of discovery is to fail cheaply on paper, so you don't fail expensively in code.

Quick check

A team spends six months beautifully building a feature, ships it, and almost no one uses it. Which job did they skip?

2

The Four Big Risks

Marty Cagan frames discovery as tackling four risks. Any one of them can sink a feature, so good discovery checks all four — not just the one you find easiest to answer.

Everyday example — opening a food truck

Before you buy the truck, four questions decide whether it works. Value: will people actually want to buy this food? Usability: can they find you, read the menu, and order without confusion? Feasibility: can you actually cook each dish fast enough during a lunch rush? Viability: do the numbers work for you — ingredients cheaper than the price, permits legal, a good spot to park? A truck can nail three and still fail on the fourth. Every product feature faces the same four.

Value

Will they want it?

Does it solve a real need people care about enough to use or pay for? The most common killer.

Usability

Can they use it?

Can people actually figure out how to use it without a manual?

Feasibility

Can we build it?

Can engineering deliver it with the tech, time, and skills available?

Viability

Should our business?

Does it work for the business — legal, cost, sales, brand, strategy?

Quick check

Users love a proposed feature and it's easy to use, but every unit would cost more to deliver than customers will ever pay. Which risk failed?

3

Assumptions & the Riskiest One

Every idea rests on a stack of assumptions. Discovery is the art of finding the one most likely to be wrong and most damaging if it is — and testing that one first.

Everyday example — crossing a frozen lake

You wouldn't test the ice by the shore, where it's obviously thick and safe. You'd check the spot in the middle that's most likely to be thin — because that's the one that can kill you. Your riskiest assumption is that thin patch: the belief that, if it's wrong, sinks the whole idea. Don't spend your energy confirming the things you're already fairly sure of. Go straight for the scary unknown, and test it with the smallest, cheapest step you can.

1

List the assumptions

Everything that must be true for the idea to work. "Users will trust us with their bank login."

2

Find the riskiest

The one that is both most uncertain and most fatal if false. That's your riskiest assumption.

3

Test it cheaply

Design the smallest experiment that could prove it wrong — before building anything real.

Quick check

You're building a feature that only works if users will connect their bank account. Which assumption should you test first?

4

Continuous & Dual-Track

Discovery isn't a one-time phase before a project — the best teams do it continuously, in parallel with delivery.

Everyday example — GPS vs. a printed map

An old printed map is planned once and never updates — if a road closes, you're stuck. A GPS keeps checking traffic and re-routes you as things change. One-time discovery is the printed map: you decide everything on day one and hope the world holds still for a year. Continuous discovery is the GPS: you keep checking in with real users and adjust course while it's still cheap. The road always changes — so keep looking at it.

Dual-track, not two phases

In dual-track work, a discovery track and a delivery track run at the same time. While engineers build what's already validated, the PM, designer, and a tech lead keep talking to users and testing what's next.

Teresa Torres' rule of thumb: touch base with real users every week. Discovery is a steady habit, not a gate you pass through once.

Quick check

A team does one month of "discovery," then eleven months of heads-down building with no further user contact. What's the risk?

Review the concepts

Discovery Flashcards

6 cards covering the essentials. Click a card to flip it.

Core Card 1 of 6

Product Discovery

Click to flip

Tip: say the answer out loud before flipping.

Explanation

In practice

1 / 6
Apply what you learned

Practice Scenarios

15 situations that test whether you can spot the right risk, pick the riskiest assumption, choose a cheap test, and keep discovery alive. Choose the strongest move, then read why the rest miss.

Scenario 1

A stakeholder is certain a new AI assistant feature will be a hit and wants engineering to start a three-month build tomorrow.

What's the discovery-minded response?

Scenario 2

Your proposed feature scores well on value (users want it) and usability (easy to use), but legal flags that it may violate data-privacy rules in your biggest market.

Which risk is unresolved, and what does it mean?

Scenario 3

Your team ran a thorough discovery phase before the project and hasn't spoken to a user in the four months of building since.

What should change?

Scenario 4

Your riskiest assumption is "small businesses will pay $50/month for this." To test it, a teammate proposes fully building the product, then launching to see if anyone subscribes.

What's wrong with that test?

Scenario 5

In a usability test, five of five users can't find the "share" button, even though every one of them said they wanted a share feature.

Which risk did this surface, and which did it clear?

Scenario 6

A feature depends on three assumptions: (1) users want it, (2) it can be built in our current stack, (3) the button should be top-right. You have time to test only one this week.

Which do you test first?

Scenario 7

To gauge demand for a feature that doesn't exist yet, a PM adds a button for it in the live app. Clicking it shows "Coming soon — want this? Leave your email." They measure click-through.

What is this technique, and what's the one caution?

Scenario 8

Engineering says a proposed feature is technically impossible with the current architecture and would need a year-long rebuild. Users, however, love the concept.

Which risk is the blocker, and what's the discovery move?

Scenario 9

A PM runs a survey: "Would you use a feature that saves you time?" 92% say yes. They cite this as proof the feature will succeed.

Why is this weak discovery evidence?

Scenario 10

A designer wants to test a new checkout flow. She proposes building a clickable prototype in a design tool and watching five users attempt to buy, rather than shipping code first.

Is this good discovery practice?

Scenario 11

Leadership treats "discovery" as a two-week phase on the Gantt chart, after which the design is frozen and cannot change no matter what building reveals.

What's the flawed assumption?

Scenario 12

A feature clears value, usability, and feasibility — but shipping it would cannibalize your highest-margin existing product and confuse the sales team's pitch.

Which risk is unresolved?

Scenario 13

You have three feature ideas and limited discovery time. One is a tiny tweak everyone agrees on; one is a bold bet the whole roadmap depends on; one is a nice-to-have.

Where should discovery effort concentrate?

Scenario 14

A test of your riskiest assumption comes back negative: users clearly won't do the key behavior the feature depends on. The team is disappointed and wants to ignore the result and build anyway.

What's the right framing?

Scenario 15

Your CEO says: "We already know what customers want — we've been in this industry 20 years. Discovery is just slowing us down."

What's the strongest, respectful reframe?

Lock it in

Guess the Term

Read the clues and name the concept. The fewer clues you need, the more points you score.

Round 1 Score 0
Keep it handy

Discovery Quick Reference

The whole topic on one screen.

Discovery vs. Delivery

Discovery

Are we building the right thing? Cheap, fast, reduces uncertainty.

Delivery

Are we building the thing right? Expensive — so de-risk first.

Dual-track

Run both in parallel; talk to users every week.

The Four Big Risks

Any one can sink a feature. Check all four.

Value

Will they want it?

Real, cared-about need.

Usability

Can they use it?

Understandable without a manual.

Feasibility

Can we build it?

Tech, time, skills.

Viability

Should our business?

Cost, legal, strategy.

Cheap Ways to Test

Learn before you build. Roughly cheapest → richest.

Customer interviews

Talk to real users about real past behavior — not hypotheticals.

Fake-door test

A button/landing page for a feature that doesn't exist yet. Measure real clicks.

Pre-sale / paid pilot

The strongest value signal: will they actually pay before it's built?

Clickable prototype

~5 users on a mockup catches most usability problems, no code needed.

Technical spike

Time-boxed engineering experiment to test feasibility.

Riskiest-Assumption Test

Where to point your limited discovery time.

1

List every assumption

All the things that must be true for the idea to work.

2

Find the riskiest

Most uncertain and most fatal if false — the thin ice.

3

Test it small

Smallest experiment that could prove it wrong. Fail on paper, not in code.

A "no" is a win

A negative result cheaply killed a doomed build. Celebrate it.

Notification