product-discovery: decide what to build before you build it

---
name: product-discovery
description: Decides, one customer problem at a time, what is worth building before it is built, by finding the outcome to move and the problem behind a request, comparing several ideas and testing the riskiest assumptions in days. Use when someone asks "should we build this", "is this feature worth it", "a customer asked for X", "what should we build for this goal" or "test this idea", or brings a feature request, a stakeholder's idea or a prototype to judge. Works with the product manager, designer and engineer together, keeps a weekly conversation with customers going, and writes each decision down with the evidence behind it.
license: MIT
metadata:
  source: https://alcoven.co/skills/product-discovery
  version: "2"
---

Product discovery: learn what is worth building, then build it

At least half of a team's ideas will not work, and the ones that do usually need several rounds before they pay off (Marty Cagan's two "inconvenient truths", 2013). Discovery tells the two apart before weeks go into building: find the problem, try several ideas against it, and test what must be true for each, in days. The person asking usually has a request in hand (a big customer wants an export) and a week at most. They fear a month spent on something nobody uses, and saying no to someone important without a reason. Keep the pass in proportion to the stakes, and end it with a decision and its evidence.

The strategy sets the outcomes this work serves (the product-strategy skill). Discovery works one problem at a time inside them.

What you need

• The outcome: a change in what customers do, with a measure and today's reading, from the strategy, the goals or the numbers. If there is none, ask: "If this works, what will customers do differently, and how would we see it?"
• The request or idea, in the words it arrived in, and who brought it.
• The evidence on record: interview notes, support tickets, sales notes, usage numbers, earlier discovery notes, in folders such as discovery/, research/ or feedback/, and decisions on record.
• The trio: a product manager, a designer and an engineer, working together from the start (Teresa Torres's term). If no engineer is named, ask who it is.
• The business's constraints: dates, money, legal limits, partners, what sales has promised.

Size the pass

The method

1. Start from the outcome, as a change in customer behaviour with its measure and today's reading: "bakeries taking 20 or more repeat pre-orders a week: 18 (numbers, 20 Oct)". Prefer what the team can move in weeks to what it can only hope to move, such as revenue. Output: the discovery note's first line.
2. Find the problem behind the request. Ask whoever brought it for the last time a customer hit the problem: what they were doing, what went wrong, what they did instead; then how many customers have it, and how often. Write it in the customer's words with source and date. With no real instance behind it, it is a hypothesis; mark it so. Output: the problem, who has it, how often, the evidence and its age.
3. Map the problems around the outcome. Outcome at the top; under it the needs, pains and wishes customers described in their stories (Torres's opportunity tree), grouped by the moment in their week where each happens. To catch an idea dressed as a problem, ask "is there more than one way to answer this?" Pick one target by how many people have it, how often, how much it hurts and how well it serves the strategy; leave effort out for now. Output: the tree, target marked.
4. Talk to customers every week. The trio holds at least one conversation a week about a specific recent time ("tell me about the last time you...") and writes a one-page snapshot straight after. Revisit the tree every three or four conversations. For running interviews, use the customer-interviews skill if the project has it. Output: a snapshot per conversation.
5. Generate at least three ideas for the target, with the engineer in the room: they know what has just become possible and what is costly. Include one that is not software (a message, a manual service). Output: the ideas, a line each.
6. List what must be true for each idea. Customers want it (value), can work out how to use it (usability), it can be built (feasibility), it works for the business (viability: cost, sales, legal, brand), it does no harm (ethics). Walk the idea step by step as a customer would to find them. Write each as something a person does ("regulars set up a standing order in their first week"), and mark how much it matters and how much evidence exists. Output: the assumption table; the riskiest matter most and have least evidence.
7. Test the riskiest few, across the ideas. The smallest test that answers each in hours or days: data already held, a one-question survey about past behaviour, a prototype in front of five customers, an engineer's spike, a working prototype on real data for a few customers. Write the pass line before the test runs. Run one test on several ideas where you can, so the result compares them. For experiment design and A/B tests, use the lean-experiments skill if the project has it. Output: each test with pass line, date and result.
8. Decide on the evidence, and write it down. Compare the ideas. Rate confidence by the kind of evidence (Itamar Gilad's confidence meter: opinions and a few requests count for little, tests with real customers for more, launch data for most). Decide: build, change and test again, park, or drop. Write the decision, the evidence, what was dropped and why. Output: the discovery note's decision; the chosen idea goes to the ux-designer skill for the experience, then to delivery.
9. After it ships, read the outcome on the date you set. Expect another round; take what you learned back to the tree.

A prototype is built to learn; the product is built to earn, by engineers, to the standard customers rely on (Cagan, 2025). Cheap AI-made prototypes make that line easy to cross by accident. Prototypes, tests and evidence levels: references/method.md.

Common mistakes

Name one when you see it, once, with the evidence and the fix.

Speaking up

• Once, with the evidence and the cheapest check. "This came from one customer (sales/notes.md, 14 Oct). Two calls with other bakeries this week would tell us whether it's common. Shall I draft the questions, or start the spec?"
• Credit what the team knows first. If they go ahead, do the work, and write the untested assumption once where the team will see it: the note, the task or the spec.
• Match their pace. On a deadline the check is one line. Never repeat a concern they have heard and decided on.

What you never do

• Refuse, delay or water down work because a step was skipped. The person decides.
• Invent customer quotes, findings, test results or rates. Missing evidence is said to be missing.
• Present an assumption as a finding, or five people as proof about everyone.
• Move a pass line after the result is in. If it was wrong, say so and set a new one for the next test.
• Contact customers or send anything outside the project without the person's yes.
• Keep more about interviewees than the team needs: a first name or a role is enough.

In Alcoven

Pass the project's slug and cite by § address.

1. open_project: the brief, the outcomes on the home with their readings, what is agreed (the strategy).
2. related with the request in a sentence: earlier interviews, notes and decisions on the same problem. grep for the customers' own words in discovery/; numbers for the outcome's reading and date.
3. add_document, after showing the person the text, for each snapshot (discovery/interviews/YYYY-MM-DD-<who>.md), the tree (discovery/opportunities.md) and each note (discovery/<slug>.md), with read set to the § addresses used.
4. task for the next conversation, for the trio member holding it, due on the day, standing on the tree; add the following week's when this one is done. add_note with to on the request, asking whoever brought it for the last time it happened.
5. hand_out the decided note (ask: read, with the person's own line on top) to those who asked, each with the passage that answers them. A decision that changes the strategy or a commitment goes on record (the decision-making skill).

To see when the habit stops, log each conversation with add_rows in discovery/touchpoints.csv, with a .source.md beside it that expects a row every week.

Elsewhere

Keep the same documents as plain files in discovery/. Read the strategy, research and decisions first, use git log for what changed, and cite file paths. With only the conversation, ask for the outcome and the evidence, and say what you could not see.

Files

• references/method.md: the four risks, the trio, outcomes, the opportunity tree, weekly conversations, assumptions and tests, prototypes, the confidence meter, what changed since 2023, sources.
• references/templates-and-example.md: the discovery note, snapshot, tree and assumption table, and a worked example.

Product discovery: the method in detail

The ideas behind each step of the method, with where they come from. Sources at the end, each read on 2026-10-22.

Discovery and delivery

A product team does two kinds of work at once. Discovery tests, cheaply, whether an idea is worth building. Delivery builds it to the standard customers rely on: reliable, secure, able to grow. Marty Cagan's shorthand is "build to learn" and "build to earn" (SVPG, 2025 and 2026).

Discovery exists because of two facts Cagan set out in 2013: at least half of a team's ideas will not work (customers want them less than hoped, they are too hard to use, or they cost far more to build), and the ideas that do work usually take several rounds before they deliver. A plan that assumes each idea works first time is wrong in ways nobody sees until after the release.

The four risks, and who owns them

Every idea carries four risks. Test them before building, and early, starting with value and business viability (Cagan, "The Four Big Risks", 2017; Inspired, 2nd edition, 2017).

Teresa Torres adds a fifth kind of assumption, ethics: whether offering it causes harm (who it serves, how data is used, trust and safety). Her five are desirability, viability, feasibility, usability and ethical (Product Talk, 2023).

The trio, and what the product manager brings

Discovery is done by the people who will build: a product manager, a designer and an engineer, jointly responsible for one outcome, together from the first interview to the decision (Torres, "Product Trio", 2021). Engineers who only receive written requirements can't say what has just become possible, and the team pays in rework.

The product manager brings four kinds of knowledge (Cagan, Inspired): the customers, the data (how the product is used), the business (how it makes money and sells, and what it must not break), and the market and industry. When one is thin, say so; that is the team's blind spot.

Outcomes over output

Teams in what Cagan calls the product model are given problems to solve and outcomes to reach, and they choose what to build; they are judged on whether it worked (Cagan, "The Product Operating Model", 2023; Cagan and Jones, 2020; Cagan, Transformed, 2024). An outcome is a change in what customers or the business do, with a measure.

Torres separates three kinds of measure (Product Talk, 2023):

• Business outcome: revenue, retention, cost. What the company needs, but slow to move and affected by much more than one team.
• Product outcome: a change in what customers do in the product ("regulars place a repeat pre-order each week"). The team can move it and see the effect within weeks. Prefer this.
• Traction metric: use of one feature ("people who click Export"). It assumes the feature is the answer, so it belongs after discovery has chosen the feature.

The opportunity tree

Torres's opportunity tree (Continuous Discovery Habits, 2021) is a map from one outcome down to the tests that decide what to build:

1. Outcome at the root: one product outcome per tree, one tree per team.
2. Opportunities under it: customer needs, pains and wishes, heard in stories about specific times, grouped under the moments of the customer's experience where they happen. Larger opportunities break down into smaller ones.
3. Ideas under one chosen target opportunity: at least three.
4. Assumption tests under each idea.

Rules that keep it honest:

• An opportunity comes from what customers said or did, with a source. Before drafting one, have a clear outcome and three or four story-based interviews behind you.
• "Is there more than one way to address this?" If not, it is an idea dressed as an opportunity ("I want a loyalty card" is an idea; "my regulars drift to the café next door" is a problem).
• Choose the target by how many customers have it, how often, how much it hurts, and how it serves the strategy and the company's strengths. Leave effort out until assumptions are tested; hard problems are often the valuable ones.
• Generate ideas only for the target opportunity.
• Revisit the tree every three or four interviews; one interview, sales call or support ticket is no reason to redraw it. Start a new tree only when the outcome changes.

Weekly conversations with customers

Torres defines continuous discovery as, at a minimum, weekly touchpoints with customers by the team building the product, running small research activities toward a desired outcome. The team that builds talks to customers itself (reports and personas don't replace it), and the activities are small enough to fit beside delivery.

Ask for stories. "Tell me about the last time you..." draws out what the person actually did. Questions about what they would do, or what they want, draw out guesses. Keep them on one specific time; when they drift to "usually", bring them back.

Write a snapshot straight after. One page per conversation, filled in while it is fresh: who it was with and quick facts about them, one memorable quote, a sketch of their story as steps, the opportunities heard (in their words), and any insights that are not opportunities. Torres suggests a 45-minute slot: about 20 to 30 minutes of interview, the rest to write the snapshot together.

Make recruiting automatic so the habit survives a busy week: a standing ask in the product, a list of customers who agreed to talk, a fixed weekly slot.

For how to run the conversation itself (questions, traps, synthesis), use the customer-interviews skill if the project has it.

Assumptions and how to test them

Testing a whole idea means building it, which is slow. Testing the assumptions it rests on is fast, and lets weak ideas drop early (Torres, "Assumption Testing", 2023).

1. Find them. Walk the idea step by step as the customer would use it: what must they notice, want, understand and do at each step? A story map (below) is one way. Add what the business and the build must make true.
2. Write each as a behaviour. "Regulars set up a standing order in their first week" can be tested; "customers will like standing orders" cannot.
3. Map them by importance (if it is false, does the idea fail?) and evidence (how much do we already know?). Torres takes this from David Bland's Testing Business Ideas (2019). Test first what is important and has least evidence.
4. Test small. Four common kinds: a one-question survey about past or current behaviour; a prototype test that puts a person in a moment and watches what they do; data mining in what the team already has (usage data, support tickets, sales notes); and a research spike, where an engineer tries the hard part.
5. Set the pass line first. Write what result would count as a pass, as a number, before the test runs: "at least 4 of 6 bakeries set up a standing order without help". A line set afterwards bends to the result.
6. Compare across ideas. Run the same test on two or three ideas where you can. Decide on the pattern across several tests, never on one result. Failed tests are normal and say what to change.

Prototypes

The kind of prototype follows the risk being tested (Cagan, "Flavors of Prototypes", 2014; Inspired, 2017; "The Purpose of Prototypes", 2025):

AI prototyping tools have made working prototypes cheap: a live-data prototype that took engineers weeks can now take days, and several ideas can be tried side by side (Cagan, 2025 and 2026). Its job is still to learn. Cagan is blunt that these tools are generally not for building actual products, and that a realistic prototype makes the gap to a real product look smaller than it is.

AI features need one more test. When the idea includes an AI model's output, quality varies from one answer to the next, so judge its quality early with evals (real cases the output is checked against), and keep tests with customers for whether it adds value (Cagan, "Experimentation, AI and the Product Model", 2026).

How much to trust the evidence

Itamar Gilad's confidence meter (Evidence-Guided, 2023) ranks evidence from weakest to strongest: your own conviction; the idea being fashionable in the industry; colleagues' and managers' opinions; estimates and plans; a handful of customers asking; market data such as surveys; customers using a prototype, or interviews; test results; data from a real launch. Opinions, however senior, add almost nothing. Use it to say plainly how sure the team is: "two bakeries asked for it" is low on the meter, whatever the bakeries' size.

Story mapping

Jeff Patton's story map (User Story Mapping, 2014) lays out a person's steps from left to right, with each step's details stacked below. In discovery it helps find assumptions and slice the smallest version that still gets the whole job done.

What changed, 2023 to 2026

• Building got cheap. Andrew Ng argued in January 2025 that as AI makes writing software cheaper, demand grows for people who decide what is worth building. Cagan's 2026 posts say the same from the product side: the hard part now is deciding what to build.
• Faster output can mean faster waste. Teams that use AI to speed up a feature roadmap ship more and see no better results. Cagan quotes Hilary Gridley: it has never been faster to build, so it has never been easier to run fast in the wrong direction ("The AI Productivity Paradox", 2026).
• More ideas can be tested in parallel. Cheap prototypes make it practical to try several approaches to one problem in the same week and keep the best (Cagan, "Build to Learn vs Build to Earn", 2026).
• AI helps with research; the trio still listens. AI can summarise interviews and scale qualitative work; hearing customers first-hand is what makes the findings believable to the team (Cagan, 2026; Torres).

Sources

• Marty Cagan, Inspired: How to Create Tech Products Customers Love, 2nd edition, Wiley, 2017. Publisher listing via O'Reilly, read 2026-10-22.
• Marty Cagan, "The Inconvenient Truth About Product", SVPG, 2013. https://www.svpg.com/the-inconvenient-truth-about-product/, read 2026-10-22.
• Marty Cagan, "The Four Big Risks", SVPG, 2017. https://www.svpg.com/four-big-risks/, read 2026-10-22.
• Marty Cagan, "Flavors of Prototypes", SVPG, 2014. https://svpg.com/flavors-of-prototypes/, read 2026-10-22.
• Marty Cagan, "The Purpose of Prototypes", SVPG, 2025. https://www.svpg.com/the-purpose-of-prototypes/, read 2026-10-22.
• Marty Cagan, "Prototypes vs Products", SVPG, 2025. https://www.svpg.com/prototypes-vs-products/, read 2026-10-22.
• Chris Jones and Marty Cagan, "Stakeholders and the Product Model", SVPG, 2025. https://www.svpg.com/stakeholders-and-the-product-model/, read 2026-10-22.
• Marty Cagan, "Build to Learn vs Build to Earn", SVPG, 2026. https://www.svpg.com/build-to-learn-vs-build-to-earn/, read 2026-10-22.
• Marty Cagan, "The AI Productivity Paradox", SVPG, 2026. https://www.svpg.com/the-ai-productivity-paradox/, read 2026-10-22.
• Marty Cagan, "Experimentation, AI and the Product Model", SVPG, 2026. https://www.svpg.com/experimentation-ai-and-the-product-model/, read 2026-10-22.
• Marty Cagan, "The Product Operating Model: An Introduction", SVPG, 2023. https://svpg.com/the-product-operating-model-an-introduction, read 2026-10-22.
• Marty Cagan and Chris Jones, Empowered, Wiley, 2020; Marty Cagan and others, Transformed, Wiley, 2024. https://www.svpg.com/TRANSFORMED, read 2026-10-22.
• Teresa Torres, Continuous Discovery Habits, Product Talk, 2021; "Continuous Discovery" glossary entry. https://www.producttalk.org/glossary-discovery-continuous-discovery/, read 2026-10-22.
• Teresa Torres, "Opportunity Solution Trees", her guide to the tree, Product Talk, 2023. https://www.producttalk.org/opportunity-solution-trees/, read 2026-10-22.
• Teresa Torres, "Product Trio", Product Talk, 2021. https://www.producttalk.org/product-trio/, read 2026-10-22.
• Teresa Torres, "The Interview Snapshot", Product Talk, 2024. https://www.producttalk.org/interview-snapshot/, read 2026-10-22.
• Teresa Torres, "Assumption Testing" and "Five Types of Assumptions", Product Talk, 2023. https://www.producttalk.org/assumption-testing/ and https://www.producttalk.org/five-types-of-assumptions/, read 2026-10-22.
• Itamar Gilad, Evidence-Guided, 2023; "The Tool That Will Help You Choose Better Product Ideas" (the confidence meter), https://itamargilad.com/the-tool-that-will-help-you-choose-better-product-ideas/; "From opinion-based to evidence-guided product development", Mind the Product, 2022. Read 2026-10-22.
• Jeff Patton, User Story Mapping, O'Reilly, 2014. https://www.jpattonassociates.com/story-mapping/, read 2026-10-22.
• David J. Bland and Alexander Osterwalder, Testing Business Ideas, Wiley, 2019 (assumption mapping, as cited by Torres).
• Andrew Ng, "AI Product Managers Will Be In-Demand", The Batch, 15 January 2025. https://www.deeplearning.ai/the-batch/ai-product-managers-will-be-in-demand/, read 2026-10-22.

Templates and a worked example

The shapes of the documents discovery leaves behind, then one problem taken from request to decision. Keep each document short; a reader should get the decision in a minute.

The discovery note

One per target problem, at discovery/<slug>.md. It holds the decision and the evidence for it.

# [The problem, in a few words]

- Status: exploring | testing | decided
- Outcome: [the measure], [today's reading] ([source], [date]); target [n] by [date]
- Trio: [product], [design], [engineering]
- Asked by: [who, where, date], if it started as a request

## The problem

[In the customer's words: who has it, how often, what they do today. Each claim with its source and date.]

## Why this problem

[Its place on the tree. How many customers have it, how often, how much it hurts, how it serves the strategy.]

## Ideas compared

| Idea | In one line | Riskiest assumption | Test | Pass line | Result |
|---|---|---|---|---|---|
| A | | | | | |
| B | | | | | |
| C | | | | | |

## Decision

[Build, change and test again, park, or drop. Why, in two or three sentences. How sure we are, and the kind of evidence behind it. What was dropped and why. What we will measure after release, and on what date.]

## Open risks

[Assumptions the team went ahead without testing, and who decided.]

The interview snapshot

One page per conversation, written straight after it, at discovery/interviews/YYYY-MM-DD-<who>.md. Use a first name or a role, never more personal detail than the team needs.

# [First name or role], [company or kind of customer], [date]

- Quick facts: [role, size, how long a customer, anything that sets context]
- Held by: [who from the trio]

> "[One memorable quote, word for word.]"

## The story

[The specific time they described, as steps: what happened first, then, then. What they did instead when it went wrong.]

## Opportunities heard

- [A need, pain or wish, in their words where possible.]

## Insights

- [Anything worth keeping that is not an opportunity.]

The opportunity tree

Kept as a nested list at discovery/opportunities.md. Each opportunity names the snapshots it came from, so anyone can check it.

# Opportunities: [the outcome]

Outcome: [measure], [today's reading] ([date]); target [n] by [date].
Last revisited: [date], after [n] conversations.

- [Moment in the customer's week]
  - [Opportunity] ([snapshot], [snapshot])
    - [Smaller opportunity] ([snapshot])
- [Moment]
  - [Opportunity] ([snapshot]) ← target, chosen [date]
    - Idea A, idea B, idea C: see discovery/[slug].md

The assumption table

| Assumption, as something a person does | Idea | Kind | Matters (high, low) | Evidence (strong, some, none) | Test |
|---|---|---|---|---|---|
| [Regulars set up a standing order in their first week] | B | value | high | none | [prototype test] |

Kinds: value, usability, feasibility, viability, ethics. Test first the rows that matter most and have least evidence.

A worked example (invented)

Crumb is an app independent bakeries use to take pre-orders from their regulars. Its trio is a product manager, a designer and an engineer. The first outcome in Crumb's strategy (strategy/2026-q4.md) is bakeries taking 20 or more repeat pre-orders a week: 18 of 140 bakeries on 20 October, with a target of 45 by 31 December. All names and numbers here are invented.

The request. On 14 October, a salesperson writes: "Rise & Co want loyalty points. They're our biggest bakery. Can we get it into next sprint?"

Step 1, the outcome. The product manager writes the outcome at the top of a new note, discovery/regulars-reorder.md, with the reading from the numbers.

Step 2, the problem. The product manager asks the salesperson for the last time Rise & Co hit the problem. The salesperson passes on the owner's words: "My Saturday regulars forget to order by Thursday, then they buy at the café next door." The problem is regulars missing the cut-off; points are one guess at a fix.

Step 3, the tree. The trio has seven snapshots from the last month. Under the outcome they group what they heard:

• Deciding to order
  • Ordering every week means remembering it and typing it all again ← target
    • "I forget until the cut-off has passed" (4 of 7)
    • "I order the same thing every week and type it all again" (5 of 7)
• Baking
  • "On Wednesday I can't tell how many loaves to bake for Saturday" (3 of 7)
• Collecting
  • "The pick-up queue is as long as the normal one" (2 of 7)

"Is there more than one way to answer this?" Yes, so the target is a real problem. They pick it because it came up in six of the seven snapshots, it happens every week, and it sits on the strategy's outcome.

Step 4, conversations. The designer books two more calls this week, one with a regular and one with a bakery owner, and the product manager adds a weekly task for the trio's next four conversations.

Step 5, ideas. With the engineer in the room:

• A. Loyalty points (the request).
• B. A standing order: set it once, it repeats every week until the customer skips or pauses.
• C. A Thursday reminder with "same as last week" in one tap.
• D. Without software: staff ask regulars at the till to sign up for a weekly order on a card, and enter it for them.

Step 6, assumptions. The riskiest, by how much they matter and how little evidence there is:

Step 7, tests. Over eight days: 41% of regulars had four identical orders in a row (pass). Five of six regulars set up the standing order unaided (pass). Four of five owners accept it if customers can skip by Wednesday (pass, with a condition). The hand-sent reminder brought 22% of each list to order (just under the line). Two of five regulars said a stamp card changed when they came (fail). The engineer's spike worked in a day (pass).

Step 8, decision. The product manager writes:

Build B, the standing order, with C's Thursday message reused as the skip-a-week notice. Park A: regulars collect stamps without changing when they come. Confidence: test results with real customers, short of launch data. Next: a working version with three bakeries for three weeks, pass line 15% of each bakery's regulars on a standing order. We read the outcome again on 31 December.

The product manager hands the note out to the salesperson and the head of sales to read, with the passage that answers Rise & Co, and the salesperson offers Rise & Co a place among the first three bakeries. The designer takes the standing order into the ux-designer skill for the experience.

What went right. The request was a fix; the problem behind it was regulars forgetting and retyping. The team compared four ideas in eight days, the requested one among them, and each test had its pass line before it ran.