Discovery phase or MVP: which one your startup needs first

Two different questions

"Should we start with a discovery phase or go straight to the MVP?" is one of the first things founders ask us, and it hides two separate questions. The first is what you know: about your users, the problem, the competition, the constraints. The second is what you need to learn next, and whether learning it is cheaper with research or with a working product in people's hands. A discovery phase answers the first. An MVP answers the second. Which one comes first depends on where you stand.

What a discovery phase actually produces

A discovery phase is the work that turns an idea into something a team can build with confidence. At the end of it you have a written goal, a description of the people the product is for, the flows the first version needs, the list of what it will not do and why, the risks you have decided to accept, and a backlog with priorities. Done well, it also settles the technical shape: what the product talks to, what it stores, what it has to comply with.

Most agencies run discovery as a separate paid engagement of several weeks, with a team of specialists attached for the duration. That is a serious investment, and for some products it is the right one. For a startup with a clear idea and a small budget, it is often more discovery than the decision needs.

What an MVP is, and what it is not

A minimum viable product is a working product that real users can use to get real value, built with the smallest scope that makes that possible. It is not a proof of concept, which proves that something technical can be done. It is not a prototype, which shows what the product would look like without working code. And it is not the final product; it is the first version of one, built to learn from.

That distinction matters because the MVP is the only one of the three that produces the evidence founders and investors actually want: do people use it, do they come back, will they pay. Everything before it is preparation.

When discovery comes first

Run a discovery phase before committing to a build when:

• You are entering a market you do not know from the inside, and you cannot describe your first ten customers by name.
• There are several ideas on the table and no agreed way to choose between them.
• The product touches regulation, payments, health data or another domain where a wrong early decision is expensive to unwind.
• Nobody on the founding team has shipped a digital product before and there is no product person to make the daily calls.
• The budget for the first version is fixed and you cannot afford to spend it on the wrong thing.

In each of these cases the cost of a few weeks of research is small next to the cost of building the wrong first version.

When you can go straight to the MVP

Skip the separate discovery phase, and fold the essential parts into the MVP project, when:

• The founder is a domain expert who has lived the problem and knows the users personally.
• Demand is already visible: a waiting list, a manual version of the service, paying customers on a spreadsheet.
• The first version is genuinely small, one core flow and the minimum around it.
• You can reach real users quickly enough that their behavior will teach you more than a research report would.

Here the fastest way to learn is to ship, and a long discovery phase mostly delays the moment the learning starts.

What skipping discovery really costs

The failure mode is well documented. In CB Insights' analysis of startup post-mortems, the most common reason cited is building something nobody needed. That is rarely a failure of engineering. It is a failure to find out, early and cheaply, whether the problem is real and whether the proposed solution is the one people want.

The other cost is quieter: decisions that should have taken an afternoon get taken in the middle of a sprint, when changing them means throwing work away. A backlog that nobody argued over before the build starts gets argued over during it, at engineering prices.

How we handle it

At WeaveLines the essential discovery work is part of every MVP project rather than a separate phase. We start with a few working sessions on the goal, the users and the scope, and the founder leaves with the same things a long discovery phase would give them: the flows the first version needs, a backlog with a reason next to every cut, and a plan. Then we prototype, so the founder can put something in front of customers and investors before any production code exists, and we build from there.

When a product needs more than that, because the market is unfamiliar or the domain is regulated, we say so and run a longer discovery with product management leading it. The point is to size the research to the decision, not to sell a phase.

A quick way to decide

Ask yourself three questions. Can you name your first ten users? Can you describe, in one sentence, what the first version must do for them? Do you know what you will measure to decide whether it worked? Three yeses: go build the MVP, with discovery folded in. Three noes: run discovery first. Anything in between is a conversation, and it is the one we have on the first call.