Product discovery: how to decide what to build before you build it

Product discovery is the work a product team does to decide what to build before committing engineering time to it. You learn what customers need, come up with more than one way to meet that need, and test the assumptions each idea depends on until you have enough evidence to choose. The output is a decision. Often it is "build a smaller version of this," and sometimes it is "don't build it."

Discovery runs alongside delivery. Delivery is building and shipping; discovery is choosing what is worth building. Most product teams do some of both every week.

What discovery is trying to reduce

Marty Cagan of SVPG groups the risks in a new product idea into four types (The Four Big Risks):

• Value: will customers buy it, or will users choose to use it?
• Usability: can users figure out how to use it?
• Feasibility: can your engineers build it with the time, skills and technology you have?
• Business viability: does it work for the rest of the business, such as your sales channel, legal and contract constraints, the cost of acquiring customers and how you charge?

Cagan argues that value risk is usually the hardest, and that strong teams tackle value and business risk early rather than after launch. GOV.UK's service manual makes a related point about its own discovery phase: you should not start building during discovery, and stopping at the end is not a failure if the research shows that is the right call (How the discovery phase works).

A worked example

Suppose you run a small team building warehouse management software for regional distributors. A large customer asks for automatic pick-route suggestions so pickers walk less. This example is hypothetical, and we will follow it through each step.

The request is a solution. Discovery starts by asking what problem it solves, and who else has that problem.

1. Start from an outcome and real stories

Teresa Torres's opportunity solution tree is a common way to structure this work (Opportunity Solution Trees). At the top is the outcome your team is trying to move, ideally a product outcome such as a customer behavior in the product. Below it are opportunities: customer needs, pain points and desires. Below those are possible solutions, and below each solution are the assumption tests that will show whether it works.

In Torres's approach, opportunities emerge from the stories customers tell in interviews, not from the team's own guesses. She suggests three to four story-based interviews before drafting a first tree, and revisiting it every three to four interviews after that. A story-based interview asks about a specific past event, starting with a prompt like "Tell me about the last time…"

For the warehouse team, the outcome might be "more orders picked per labor hour at customer sites." Interviews with pick supervisors about their last busy shift might surface several opportunities: pickers walk to the wrong spot for items stored in two places, new temporary staff don't know the layout, and rush orders interrupt planned batches. Route suggestions might help with the first. They do nothing for the other two.

Torres offers a useful check: if there is only one way to address an "opportunity," it is a solution in disguise. "I want route suggestions" has one answer. "I waste time walking to the wrong aisle" has many.

Customer interviews covers how to plan and run these conversations, and problem interviews vs. solution interviews helps you tell which kind you are running.

2. Compare several solutions, not one

Choose one target opportunity and come up with more than one way to address it. Torres recommends taking three forward, because comparing options leads to better decisions than asking whether a single idea is good enough.

For "pickers walk to the wrong location," the team might consider route suggestions on the handheld scanner, a re-slotting report that recommends moving fast-selling items closer to packing, or showing an item's second storage location on the pick screen.

3. List the assumptions and test the riskiest

Every idea rests on things that must be true for it to work. Torres groups these assumptions into five types: desirability, viability, feasibility, usability and ethical (Assumption Testing). She describes four common kinds of test: prototype tests, one-question surveys, mining data you already have, and short engineering investigations she calls research spikes. She also recommends deciding what result would count as success before you run each test.

To choose which assumptions to test first, she points to David Bland's assumption mapping: rank each assumption by how important it is to the idea and how much evidence you already have. Test the important ones with the weakest evidence.

The route-suggestion idea may still win. The point is that you now know which assumption would sink each one, and you can often check it with a small test before any engineering work starts.

4. Know when to ask a domain expert instead of a user

Users are the right source for what they did and what went wrong. They are often the wrong source for constraints outside their job. A pick supervisor may not know who approves re-slotting across sites, how distributors evaluate add-on software modules, or what a labor agreement says about tracking pickers. Those are viability and feasibility questions.

That is when a conversation with someone who has worked across many sites, such as a former distribution center manager or someone who has implemented warehouse software, earns its place. Use them to check constraints and to sharpen the questions you ask users. Don't use them as a substitute for users: their picture of what pickers do minute to minute is secondhand. Expert interview covers how to run one, and market research interviews with customers, suppliers and operators covers whom to ask.

5. Decide, then keep going

After a round of tests you will usually have a mix: some assumptions held and some failed. Torres suggests asking what you learned about customers, not only which idea came out ahead. You might build a smaller version of one idea, redesign around what failed, or pick a different opportunity. GOV.UK frames the end of discovery the same way: decide whether there is something worth building and whether it is worth the cost.

Once you have chosen, usability testing checks whether people can use what you design. If the idea started as a customer request, how to test a feature request covers that path in more detail.

Your next step

Write your team's outcome at the top of a page. Under it, list the opportunities you have heard in real interviews, and circle one. Write three ways to address it, then the one assumption behind each that you have the least evidence for. Pick the cheapest test for each.

If the assumption you can't test from inside the company is about an industry constraint, Instant Expert can find people who match a description you write, such as "former distribution center operations managers." You review who it finds, it sends your invitations, and you pay only for calls that get booked. The operations professionals in warehousing directory page is one place to start.