Most product teams are excellent at building things and mediocre at deciding what to build. That's backwards, because the second problem is where the money is.
Shipping the wrong thing efficiently is still shipping the wrong thing. The research on this is old and consistent: a large share of shipped features see little or no use. Every one of those features had a backlog entry, a spec, a sprint, and a launch. What they didn't have was discovery.
Discovery is the work of reducing risk before you build. Here's how to do it in practice, without turning your team into a research department that never ships.
The Four Risks
Marty Cagan's framing is the cleanest one, so let's use it. Before building anything significant, you want some confidence on four questions:
- •Value risk: Will anyone want this?
- •Usability risk: Can people figure out how to use it?
- •Feasibility risk: Can we build it with the time and skills we have?
- •Viability risk: Does it work for the business (legal, financial, brand, support)?
Most teams over-rotate on feasibility, because engineers are in the room, and under-rotate on value, because users aren't. The most common postmortem for a failed feature is "we built it well and nobody cared." That's a value risk you never tested.
The discipline: for each meaningful initiative, ask which of the four risks is biggest, and attack that one first with the cheapest test available.
Discovery Is Not a Phase
The old model was: research phase, then spec, then build. That model fails because learning doesn't stop when building starts, and because "research phase" becomes a gate that either blocks delivery or gets skipped under pressure.
The better model is continuous discovery: a steady drumbeat of learning that runs alongside delivery. In practice, that looks like:
- •Regular customer contact. Teresa Torres's benchmark is weekly touchpoints with customers. Weekly might be ambitious for your team; the point is cadence. Interviews scheduled by default, not spun up per project.
- •A running stock of open questions. Every roadmap theme has assumptions. Keep a visible list of the riskiest ones and chip away.
- •Small tests woven into normal work. A prototype test here, a fake-door there, a pricing conversation with five customers. Days, not quarters.
Discovery as a habit beats discovery as a project. Habits survive deadline pressure. Projects get cut.
The Opportunity Space Comes First
The most common discovery mistake is starting with a solution and looking for evidence it's good. That's not discovery, that's a prosecution building its case.
Start instead with the opportunity space: what problems, needs, and desires exist for your users in the outcome area you care about? If your goal is improving retention, the opportunity space might include "users forget the product exists between monthly billing cycles" and "the second user on an account never gets onboarded." Different problems, different solutions, both discovered by talking to users rather than brainstorming in a conference room.
Only after you've mapped opportunities do you generate solutions, ideally several per opportunity. Comparing three candidate solutions against one problem produces much better decisions than asking "is this one idea good?" One idea in isolation always looks good. Its sponsor is in the room.
For the interviewing technique itself, including how to avoid leading questions that produce polite lies, see our guide on customer interviews.
Cheap Tests, Ranked by Cost
You almost never need to build the product to test the riskiest assumption. A rough menu, cheapest first:
Interviews and observation
Best for value risk and problem understanding. Five to eight conversations per round. Watch what people do today; the workarounds they've built are proof of demand no survey can match.
Prototype tests
Best for usability risk. Clickable mockups in front of five users will catch the majority of usability problems before a line of code exists. Your designer already knows how to run these; your job is making sure they happen before commitment, not after. (Related: working with designers.)
Fake doors and painted doors
Best for value risk at scale. A button or landing page for a thing that doesn't exist yet, measuring how many people try it. Use with care and respect for users: a "coming soon, want early access?" framing keeps it honest.
Concierge and Wizard of Oz tests
Best for testing a service before automating it. Deliver the value manually for a handful of customers. If people won't accept the thing when a human does it for free, software won't fix that.
Data analysis
Best for sizing and locating problems. Where's the drop-off? Who churns? What do power users do differently? Data tells you where to look; interviews tell you why. You need both, and our product metrics guide covers the first half.
The skill isn't knowing these techniques exist. It's matching the cheapest adequate test to the riskiest assumption. Spending three weeks prototyping when the real question was "will anyone pay?" is a category error.
How Much Discovery Is Enough?
The honest answer: enough to make the risk of building acceptable, and no more. Some calibration:
- •Small, reversible changes: minimal discovery. Ship and measure. This is what A/B testing is for.
- •Medium features: a round of interviews, a prototype test, a look at the data. One to three weeks of part-time effort.
- •Big bets (new products, pricing changes, platform migrations): serious discovery. Multiple rounds, real evidence on all four risks, and the willingness to kill the idea.
Discovery theater is real too: endless research as a way to avoid deciding. If your team has interviewed forty users and can't say what it would take to commit, the problem isn't insufficient data. It's an unclear decision. Write down what evidence would change your mind before gathering more of it.
A useful forcing function: before each round of discovery, write a one-line decision statement. "We will build X if we see Y; otherwise we'll do Z." It takes two minutes, it exposes fuzzy thinking immediately, and it turns the eventual readout from a debate into a check against something everyone already agreed to. Teams that adopt this stop arguing about what the research means, because they decided what it would mean in advance.
Making It Stick With Stakeholders
Discovery dies when leadership sees it as delay. Two moves prevent that:
Frame it as risk management, not research. "We're spending two weeks to avoid a two-quarter mistake" lands with executives in a way "we need more user research" doesn't. Bring the four risks language into your stakeholder conversations; it gives skeptics a structure they can argue inside of.
Show the kills. Every idea discovery kills before it consumed a sprint is money saved. Track and report them. "Discovery killed three of the seven candidates this quarter, here's what we built instead" is the most persuasive discovery advocacy there is.
The Bottom Line
Decide what the riskiest assumption is. Test it with the cheapest adequate method. Keep customer contact on a cadence so learning is continuous rather than episodic. Kill weak ideas early and brag about it.
Teams that do this ship less waste and win more often. PMs who can describe this process concretely, with real examples of ideas they killed and why, do noticeably well in product sense interviews.
When you're ready to bring discovery skills to a new team, browse open PM roles at productmanagerjobboard.com.