Product Discovery Phase: Why It Comes Before Design and Development

Most founders want to start with screens. Screens feel like progress. You can show them to investors, to friends, to your team.

The problem is that design is expensive to change once it is built. The most costly mistake in a first product is not bad design. It is good design of the wrong thing.

That is what a discovery phase is for.

What is a product discovery phase?

Product discovery is the short stage before design and development where you decide what to build first, and why. You take everything the founders believe about the product and check it against real data: competitors, user reviews, market differences, technical effort.

The output is not a report for the drawer. It is a scope. A clear first version, what waits for version two, and what you are not building at all.

Discovery does not replace user research, design or development. It makes sure they start from the right place.

What discovery actually produces

A good discovery phase ends with a small set of things the whole team can act on:

• A competitor map. Not every app in the category. The few that matter, what they do well, and where users complain.

• The voice of the user. App store reviews, forum threads, support complaints. Real words from real people, tagged by problem.

• A feature matrix. Your candidate features against the competition, so you can see where you are copying and where you are different.

• Checked assumptions. Every claim in the pitch deck and the feature list, marked as supported, unsupported or unknown.

• A versioned scope. V1, V2 and V3, with the reason each feature sits where it does.

• A list of risks. What could break the plan and what would tell you early.

A real example: from ten features to one clear first release

We recently ran discovery for a pre-seed consumer AI app. Two founders, no engineers yet, a three-screen mockup they already considered outdated, and investor materials due in a few months.

They came with ten candidate features. Several internal documents described the MVP, and they did not agree with each other. One put a style profile first. Another built the MVP around daily AI recommendations. The founders were honest about it: none of these documents was an approved spec. They were research.

So on the third call we reframed the goal. Not “design all ten features”. Instead: find the one to three things that make someone download the app, and the one thing that makes them invite a friend.

The founders gave us two hard filters for every decision. Setup has to be short. The app has to earn use at least once or twice a week. Everything we found went through those two filters.

What we did

The founders asked for a light competitor review, not an exhaustive one. They were not on the market yet, and depth would not change the decision. So we focused on signal:

• the handful of apps that define the category, one slide each;

• a wider scan of the category across two regional markets: availability, ratings, pricing, local language support;

• hundreds of app store reviews and forum threads, each tagged by type of complaint;

• hands-on tests of the leading apps, including a stopwatch on onboarding;

• every claim in the founders’ documents checked against the data.

We deliberately did not run large-scale user interviews. The sample this audience needs is too big for a discovery sprint. That is a separate phase, and it should be planned as one.

What changed

The headline AI feature left V1. Daily AI recommendations were at the center of one version of the MVP. The data did not support them as a first reason to download. They moved to a later version, in a simpler form.

The real barrier turned out to be setup, not intelligence. One complaint appeared again and again, even in five-star reviews: getting your own data into the app by hand. It was the only complaint that survived a five-star rating. So V1 got a fast import path instead of another AI feature.

A top-priority feature was based on one opinion. One of the most complex features on the list was ranked high because a single potential user asked for it. The founders’ own technical notes rated it among the hardest to build. Our recommendation: keep it out of the MVP and license an existing solution later.

“The AI learns you” was not true anywhere. Several competitors promise that their assistant learns your taste. In our tests, none of them did. So the V1 chat was scoped honestly, as search over your own data, not as a system that learns.

The second market was a different market. Two of the key competitors were not available there at all. The biggest app in the category there was a different kind of product. And local language requests appeared only in that market’s reviews. If that market had been chosen first, half of the benchmark would have been irrelevant.

One convincing number was wrong. Early analysis showed that more than half of the complaints in one market were about subscriptions. On a second look, two apps produced almost all of them. Without those two, the picture was bugs and missing features. We showed both versions openly in the deck.

None of this required design. All of it would have changed the design.

Why discovery pays for itself

Every item above is a decision that would otherwise be made in Figma or in code. And then made again.

A feature designed and built for V1, then removed after launch, costs the design, the development, the testing and the time. A market chosen on assumptions costs a launch. A number that looks convincing in a pitch deck and falls apart in due diligence costs trust.

Discovery moves those decisions to the cheapest point in the project: before anything is built.

Signs your project needs discovery first

• You have more than five “must-have” features for the first version.

• Your documents describe the MVP differently.

• A feature is on the list because one person asked for it.

• The concept includes hardware, a marketplace or a second audience from day one.

• You are choosing between markets and have not compared them.

• You need to show investors a clear plan, not just a vision.

If two or more of these sound familiar, start with discovery.

What discovery is not

• It is not design. There are no screens at the end, and there should not be.

• It is not a full research program. Deep interviews with a large sample are a separate phase.

• It is not a way to delay. A focused discovery is short. It exists to make the next phases faster.

How to prepare as a founder

Bring everything you have, even if it contradicts itself. Pitch decks, feature lists, old mockups, notes from calls with users. Contradictions are useful. They show where the decisions are still open.

Decide your filters before the work starts. How long can setup take? How often must people use the product for it to work as a business? These two answers will cut more features than any debate.

And agree on what “start” means. For us, starting a project with a new product idea means starting with discovery, not with design.

FAQ

What is a product discovery phase?

It is the stage before design and development where you decide what to build first. You check the founders’ assumptions against competitors, user reviews and market data, and end with a versioned scope for V1, V2 and V3.

How long does product discovery take?

It depends on the product and the number of markets. A focused discovery for an early-stage product is usually counted in weeks, not months. Large-scale user interviews, if needed, are planned as a separate phase.

What is the difference between discovery and design?

Discovery decides what to build and why. Design decides how it looks and works. Discovery ends with a scope and a list of risks. Design starts from that scope.

Do early-stage startups need a discovery phase?

Especially early-stage startups. Before the first release, every feature decision is still cheap to change. After design and development, it is not.

What should a founder bring to discovery?

Every document you have about the product, even if they disagree. Plus two filters: how long setup can take, and how often people must use the product.

Related reading: MVP design: 10 steps to build a successful MVP · Four ways a first MVP goes wrong

Planning a new product? We run discovery as the first stage of our SaaS and MVP product design work. Book a free intro call and we will tell you whether your project needs it.