The product discovery process, in days instead of months

Discovery has a reputation for drifting. Workshops turn into more workshops, and a month later there is a slide deck but no decision. A good product discovery process does the opposite. It is short, it ends on a date, and its output is a written answer to one question: what should we build first, and why?

What discovery is for

Discovery exists to reduce the risk of building the wrong thing. It is not research for its own sake, and it is not design. By the end, you should be able to answer four questions in plain words:

Who is the first user, specifically?
What problem do they have, and how do they handle it today?
Is it worth it? Is the market big enough, and do the numbers work?
What is the first release? What it will do, and what it will not do.

If your discovery output does not answer all four, it is not done. If it answers them in three days, it is done, even if there is more you could study.

Why a product discovery process drags

Discovery rarely runs long because the work is hard. It runs long for the same reasons most projects do. Our post on why software projects run late goes into this in more depth, but in discovery the usual causes are:

No end date. Without a deadline, there is always one more interview to run.
Too many decision makers. Each new voice reopens settled questions.
Research without a question. Teams collect data, then try to work out what it means.
Fear of cutting. Nobody wants to be the one who says a feature is out.

The fix for all four is the same: set the end date first, name one decision maker, and write the questions down on day one.

A product discovery process in five days

Here is a structure that works for most new products. It can stretch to ten days for complex domains, or compress to three when the founder already knows the users well.

Day	Focus	Output
1	Frame the problem	Problem statement, first user, assumption list
2	Users and market	Interview notes, competitor map
3	The numbers	Market size, pricing view, simple financial model
4	Shape the solution	Core journey, rough flows, feature list
5	Decide the scope	Written release plan and “not now” list

Day 1: Frame the problem

Write a one-paragraph problem statement and name the first user as precisely as you can. “Small businesses” is too broad. “Independent physiotherapy clinics with one to three staff” is something you can research.

Then list every assumption the idea depends on and mark the riskiest ones. Those set the agenda for the rest of the week.

Day 2: Users and market

Talk to people who have the problem. Even four or five short calls change the picture. Ask what they did the last time the problem came up, what it cost them, and what they tried before.

In parallel, map the competitors. Include the indirect ones: spreadsheets, email, a part-time assistant. Your real competition is often whatever the user does today.

Day 3: The numbers

A product can solve a real problem and still not be a business. Size the market from the bottom up: how many of your first users exist, and what would each pay? Sketch a simple model of costs and revenue for the first year. Rough numbers are fine. The point is to spot an idea that cannot work before you pay to build it.

Day 4: Shape the solution

Now turn to the product. Write the core journey, the single path a user takes to get value. Sketch the main flows on paper or in a quick wireframe. List every feature the journey touches.

This is not interface design. It is enough shape to estimate and to cut.

Day 5: Decide the scope

Sort the feature list into what is in release one and what waits. MVP feature prioritization covers the methods. Write the result down, including the “not now” list, and get the decision maker to agree to it.

Discovery ends when the scope is written down and someone with authority has said yes.

What you should hold at the end

A short set of documents, each one useful on its own:

A problem statement and a named first user
Interview notes and a competitor map
A market size, a pricing view, and a simple financial model
A product roadmap, with release one clearly marked
A written scope for release one, plus the list of what waits

That is enough to brief a design and engineering team, pitch an investor, or decide not to go ahead. All three are good outcomes.

How we run discovery at Batriders

Discovery and strategy is the first of four steps on every project we run, and it covers user research, market research, MVP planning, and a technical plan that can grow with the product. You can read more about it on our product design page.

For new products on a fixed clock, our two-week 2Sprint compresses the plan into days 1 to 3: we test the idea, size the market, map competitors, and model the numbers. You leave that phase with a market and competitor map, a financial model and pricing view, a roadmap, and an agreed scope for release one. Design and build start on day four.

Frequently asked questions

How long should a product discovery process take?

For most new products, three to ten working days is enough to answer the core questions. Longer discovery makes sense for regulated industries or products that depend on undocumented systems, but it should still have a fixed end date.

Who should take part in discovery?

One decision maker, someone who knows the users, and the people who will design and build the product. Keeping the builders involved means the scope is realistic from the start.

Is discovery worth it for a small MVP?

Yes, and it can be short. A three-day discovery that cuts two unneeded features usually pays for itself before the build starts.

What if discovery shows the idea will not work?

Then it did its job. Finding out in a week costs far less than finding out after launch. Often the result is not “stop” but “change the first user” or “change the offer”.

The best discovery is the one that ends on time with a decision, even an uncomfortable one.