Discovery Craft

Discovery is a habit, not a phase. A team that talks to customers for two weeks before a build and then not again has done research. A team that talks to three customers every week has discovery.

Discover is the phase this sits inside, and the two split cleanly: Discover owns finding and defining the right problem, and this page owns getting the evidence that a problem definition is worth anything. Personas & Jobs is where the findings end up written down.

What follows is how to collect evidence worth decomposing in Structured Problem Solving, and how to avoid the kinds that feel convincing and are not.

Interview so they cannot mislead you#

People will tell you what you want to hear, and they are not lying. Asked about the future they guess, asked about your idea they are polite, and both answers feel like data. The fix is Rob Fitzpatrick’s, in The Mom Test: ask about their past behaviour, never about your idea, and never about what they would do.

Three rules carry most of the value:

Talk about their life, not your idea. “Walk me through the last time you closed payroll” beats any description of what you are planning to build.
Ask about specifics in the past, not generics in the future. “Would you use this?” is worthless. “What did you do last month when it broke?” is evidence.
Listen for what it cost them. Anything they already spent money, time, or reputation on is real. Anything they merely find annoying may be entirely survivable.

How to tell it worked: you learned something that made you less confident. An interview where everything confirmed the plan usually means you pitched rather than asked.

When it goes wrong: the classic tell is a compliment. “That sounds really useful” is the sound of an interview that has stopped producing information. Redirect to the last time the problem actually happened.

Keep a weekly cadence, with the trio#

The unit of discovery is a week, not a project. Teresa Torres’ Continuous Discovery Habits sets the bar we hold: at least one customer conversation a week, done by the trio together, PM and designer and engineer.

The trio part is not ceremony. When the engineer hears the customer describe the workaround directly, the solution space changes in the room. When they hear it second-hand in a written summary, it does not.

The organising artifact is the opportunity solution tree: the outcome at the root, opportunities (unmet needs, discovered in conversations) beneath it, candidate solutions beneath those, and the assumption tests beneath those. It keeps discovery tied to one outcome instead of drifting into a feature wishlist.

How to tell it worked: every opportunity on the tree traces to a specific conversation you could name, and every solution traces to an opportunity. An opportunity nobody said out loud is a feature idea wearing a costume.

Check which risk you are actually reducing#

Marty Cagan’s four risks are the fastest way to see whether a piece of research was worth doing:

Risk	The question	What settles it
Value	Will they choose it?	Interviews, past behaviour, willingness to pay
Usability	Can they figure it out?	Watching someone try, five users at a time
Feasibility	Can we build it?	An engineer spiking the hard part
Viability	Does it work for the business?	Pricing, cost, support load, compliance

Most teams over-invest in value and under-invest in viability, then discover at launch that the thing customers wanted is the thing we cannot afford to support.

How to tell: name which of the four a planned study reduces. If the answer is “all of them”, it reduces none of them.

Test the assumption that would hurt most#

Find the belief that, if wrong, makes everything downstream pointless, and test that first. List what has to be true for the bet to pay off, mark each as high or low confidence and high or low consequence, and the top-right corner is your next week of work.

The test should be the cheapest thing that could genuinely change your mind, which is usually not a prototype. It might be one conversation with the person who would have to approve the purchase.

When it goes wrong: teams test the assumption they know how to test rather than the one that matters. The guard is to write down, before building anything, what result would stop the project. If no result would stop it, the test is theatre.

Read a competitor who publishes nothing#

Most of the markets we work in are sales-led: no pricing page, no public roadmap, a demo gated behind a form. That is not a dead end, it just moves the evidence somewhere else. Ranked by yield:

Win/loss interviews. Every lost deal, interviewed within two weeks, by someone who is not the person who lost it. Nothing else comes close, and the reason it works is that the buyer has just finished comparing you to the alternative in detail.
Switching interviews. A customer migrating to us is a free audit of the product they left: what specifically broke, and what finally made it intolerable.
Their documentation. Sales-led vendors still publish help centres and API docs. That is their full feature surface and effectively their data model. Read it once end to end, then diff it quarterly.
App store reviews of their mobile apps, sorted worst first. Unfiltered pain, at volume, in the customer’s own language.
Job postings. Roles reveal roadmap, segment, and stack. A vendor hiring enterprise implementation consultants is telling you where it is going.
Published tender and procurement requirements. A requirement list somebody else paid a consultant to write, available free, already validated by a buyer.
Implementation partners and consultants. They have configured every vendor in the market and will usually talk.

On taking their demo: get it through a prospect or customer who already sat through one and will share the deck and the quote. That is normal and clean. Misrepresenting yourself to a competitor’s sales team trades credibility in a small market for information you could have obtained another way.

What does not count as discovery#

A survey standing in for conversations. Surveys measure things you already know how to ask about. They cannot surface the thing you did not know to ask.
A feature request treated as a finding. A request is a customer’s proposed solution. The finding is the problem underneath it, and it is your job to go get it.
Research the PM does alone and reports as conclusions. The team did not hear it, so the team does not believe it, and they are right not to.
Discovery run as a phase before a build. Then the next build starts from nothing again.

Where to learn it#

Rob Fitzpatrick, The Mom Test. Two hours, and it changes every interview you run afterwards. Read this one first.
Teresa Torres, Continuous Discovery Habits. The cadence, the trio, and the opportunity solution tree.
Marty Cagan, Inspired. The four risks and the product-team model around them.
David Bland and Alex Osterwalder, Testing Business Ideas. A catalogue of experiments ranked by evidence strength and cost, for when you know the assumption but not how to test it.
Bob Moesta, Demand-Side Sales, for switch interviews: reconstructing the timeline of a purchase decision and the forces on either side of it.

Discover and Define: where this sits in the build process.
Personas & Jobs: how findings get written down.
Pain Points & Winning: turning a finding into a reason someone switches.
Structured Problem Solving: what to do with the evidence once you have it.