# Product discovery

Product discovery is the work of deciding what to build and for whom before committing to a build. It tests the riskiest assumptions with real people through interviews, prototypes, and prioritization, so the build starts from evidence.

Also called: Discovery, Discovery phase, Product discovery phase.

## In short

- Discovery decides what to build and for whom, before the expensive part starts.
- It works by naming your riskiest assumptions and testing them cheaply.
- For a small team, a few weeks is usually enough. Months of discovery is often a way of putting off a decision.
- Its output is a short set of decisions that becomes the [scope of work](https://www.choie.co/glossary/scope-of-work).

## What product discovery is

Building software is expensive, and the most expensive mistake is building the wrong thing well. Product discovery is the work that comes before the build, where a team figures out which problem is worth solving, for which people, and what the first version needs to do.

It is a set of activities, and most of them fall into a few groups that tend to run in roughly this order.

**Diagram: How discovery usually runs.**

1. Problem interviews (Learn how people cope today)
2. Assumptions (Write down what must be true)
3. Prototypes (Test the riskiest guesses)
4. Prioritization (Pick the first job to do)
5. Written scope (What is in and out of v1)

_The steps overlap and loop back. A failed test often sends you back to more interviews._

## The main activities

- **Problem interviews.** Conversations with people who might use the product, about how they handle the problem today. Ask what they did the last time it came up, not what they would do in theory, because past behavior is a far better guide.
- **Assumptions.** A written list of what must be true for the product to work, such as who has the problem, how often, what they use now, and whether they would pay. Rank each one by how risky it is and how little evidence you have.
- **Prototypes.** A [prototype](https://www.choie.co/glossary/prototype) puts the riskiest assumptions in front of a few real people. Use the cheapest form that can answer the question.
- **Prioritization.** Deciding what goes into the first release and what waits. For a small team, a simple ranking of value to the user against effort to build is usually enough.

Teams often add a quick look at what people already use to get the job done, from competing products to spreadsheets and email. Those habits are the real competition for anything new, and they show what a first release has to beat.

## How long discovery should take

For a small team with one product idea, two to four weeks of focused discovery is usually enough to make a confident first decision. It can be shorter when the founder knows the problem well from their own work. It runs longer when the product serves several kinds of user or sits in a regulated field.

Discovery that stretches into months is often a sign that the team is avoiding a decision. More research rarely removes every doubt. At some point the cheapest way to learn more is to build a small version and watch how people use it.

Choie's [prototype week](https://www.choie.co/services/coded-prototype) is built for that point. It takes one critical workflow with up to eight screens and states and turns it into a coded prototype within five days, so the founder has something real to put in front of their own users.

> **A useful stopping point.** Stop when you can name the primary user, the one job the first release does for them, and the evidence behind both.

## What discovery produces

Good discovery ends in a few pages, backed by the interview notes and prototypes behind them.

| Output | What it says |
| --- | --- |
| Problem statement | Who has the problem, how they handle it today, and why that falls short |
| Primary user | The one kind of person the first release is for |
| Assumption log | What was tested, what held up, and what is still a guess |
| Prototype findings | What people did when they tried it, and what changed as a result |
| First-release outline | The critical workflow, and what is left out on purpose |

## Common mistakes

- **Asking people if they like the idea.** Most will say yes to be polite. Ask about their past behavior instead.
- **Testing the easy assumptions.** It feels productive to confirm what you already believe. Test the ones that would sink the idea if they were wrong.
- **Writing a long requirements document.** Discovery should narrow the product. Forty pages of requirements usually means it did the opposite.
- **Treating discovery as a phase that ends for good.** The same habits keep paying off after launch, with real usage data to work from.

## From discovery to scope

The last step is turning decisions into a [scope of work](https://www.choie.co/glossary/scope-of-work), a written description of what the first build includes and excludes. This is where discovery pays for itself. A scope written from evidence is shorter, easier to price, and less likely to change halfway through the build.

The scope usually describes an [MVP](https://www.choie.co/glossary/mvp), the smallest release that does one job well for one kind of user. Anything discovery surfaced but did not prioritize goes on a later list, where much of it will look different once real users arrive.

At Choie, that prototype week costs a fixed $4,900, and the fee is credited in full against a build that starts within 60 days. Every project then gets a written scope with deliverables, dates, and a fixed price before work starts. See [pricing](https://www.choie.co/pricing) and [how a project runs](https://www.choie.co/process).

## Common questions

### Who should do product discovery?

The people who will make the product decisions, usually the founder and whoever will design the product. A developer should be involved early enough to flag what is hard or expensive to build. At Choie, the people who scope a project are the ones who design and build it, so anything hard to build is flagged while the scope is still being written.

### Is product discovery the same as market research?

No. Market research sizes a market and studies competitors. Discovery focuses on specific people and a specific problem, and ends in a decision about what to build first.

### Can I skip discovery and go straight to building?

You can when you know the problem from your own work and the first release is small. Even then, a few interviews and one prototype are cheap insurance against building the wrong workflow.

### What is the difference between discovery and delivery?

Discovery decides what to build, and delivery builds, tests, and ships it. In established teams the two run at the same time, with discovery working a few steps ahead of what is being built.

Related: [Minimum viable product (MVP)](https://www.choie.co/glossary/mvp), [User research](https://www.choie.co/glossary/user-research), [Product-market fit](https://www.choie.co/glossary/product-market-fit), [Prototype](https://www.choie.co/glossary/prototype), [Scope of work](https://www.choie.co/glossary/scope-of-work).

HTML: https://www.choie.co/glossary/product-discovery