MVP Design and Product Discovery

Most founders do not need a build team yet.

They need to know whether the idea is worth building — and if it is, what the first version actually has to do.

That is product discovery. The MVP is the smallest product that can answer it.

I help founders in that window: after the idea is real enough to talk about, before engineering has been paid to guess. Validation, prioritisation, user journeys, a prototype people can use. Then a decision. Build. Change. Or stop.

If you are searching for MVP design because you can feel the scope swelling, this is the work to do first.

Discovery is not a workshop that produces a backlog

Product discovery is often treated as a phase you complete so that build can begin. Sticky notes, a journey map, a ticket pile. Then six months of delivery against a list that was never tested.

That is planning dressed up as learning.

Discovery, done properly, has one job: reduce the most expensive uncertainty before you pay to encode it in software.

The questions are rarely mysterious:

• Do people actually have this problem, in the way you think they do?
• Do they understand the proposition without a founder in the room?
• Will they complete the journey you think is “simple”?
• Is the valuable part the interface — or a judgement, a workflow, an AI task?
• What would have to be true for v1 to be worth shipping?

Until those have evidence, a larger MVP is not ambition. It is untested risk with a launch date.

How I work is Find, Cut, Make, Test, Learn, Decide. This page is what that looks like before the build starts.

Validation: prove the risky thing, not the easy thing

Validation is not collecting compliments.

Friends will say it is interesting. Advisors will say it is big. A survey will say people “would use it.” None of that tells you whether someone will start, finish, and come back.

I look for the assumption that would hurt most if it were wrong — then I design the smallest experience that can put a crack in it.

That might be:

• Care — do they want this enough to try it without you selling it
• Comprehension — do they get it in the first thirty seconds
• The job — can they complete the one workflow that matters
• Trust — will they give you the data, the payment, the commitment
• The AI — can the model actually do the task you are hanging the product on

The output of validation is not “people liked it.” It is a clearer statement of what is known, what is still a bet, and what v1 is for.

If the evidence is weak, we change the product. If the idea is not strong enough, we stop. Stopping before a six-month build is not failure. It is the point of discovery.

Prioritisation: v1 is a proof, not a shrink-ray

MVP does not mean a smaller version of the entire product.

It means building enough to learn something important.

The wrong question is: what can we fit into version one?

The right question is: what does version one need to prove?

Everything in the scope should have a reason. Everything left out should have a reason too. Features that do not help you learn — extra roles, extra settings, extra “while we’re here” screens — are how overbuilding starts. They feel cheap individually. Together they become the product you cannot explain.

A useful prioritisation test:

• If we cut this, can we still answer the question?
• If we keep this, what extra journey, state, or exception does it create?
• Is this for the user, or for the pitch?

I will push for a focused first version you can put in front of real people. It will almost certainly be smaller than the one in your head. That is the design.

User journeys: one path that holds together

A journey map of the whole company is not an MVP.

Users do not experience your platform. They experience a path: arrive, understand, do the thing, know what happened, decide whether to return.

Before build, I design that path until it is coherent — and I refuse the side quests.

That usually means:

• One primary user, not five personas sharing a nav
• One job to complete, not a suite
• The states that make the job honest (empty, error, waiting, done)
• The moment of value, as early as it can honestly appear
• Nothing that requires a tutorial to justify itself

If the journey only works with you narrating it, it is not ready to build. It is a story. Make the story usable first.

A prototype is how we find out. Documents are useful for thinking. People react differently to something they can actually click, hesitate on, or abandon. Fidelity follows the question: a sharp flow to test understanding, a working slice to test the job, an agent doing a real task if that is the bet.

Pledge My Tree was a four-day prototype for that reason. The product decision — pledged is not planted, planted is not verified — had to be felt in the journey, not buried in a spec.

How overbuilding actually happens

Overbuilding rarely looks like a bad decision in the room. It looks like reasonable additions.

• A second user type “because we will need it”
• Admin, because someone has to configure it
• Notifications, because engagement
• AI, because the deck has AI
• Edge cases, because a lawyer asked
• Visual polish, because the prototype will be shown to investors

Each one is defensible. Together they delay the only thing that reduces risk: someone who does not work for you, using the product, without a walkthrough.

The cost is not only money. It is conviction spent on the wrong shape. Once the shape is in code and in the pitch, it is much harder to admit the journey was wrong.

Discovery is how you keep that option. A Product Sprint exists to find the product before you fund the build — typically two to four weeks: the problem, the cut scope, a prototype, a test. Then you know whether you are looking at an MVP Launch or a rewrite of the idea.

What you should have in your hands before engineering starts

You do not need a 40-page PRD.

You should be able to say, without sliding into features:

• Who this is for, in one sentence
• The job they are trying to finish
• The assumption v1 is there to test
• The journey they take to finish it
• What is explicitly out of scope, and why
• What you will watch for when a real person uses it

If you cannot say those yet, you are not late to build. You are early. That is a cheaper place to be.

Product design for startups is the wider picture — idea through Series B, including UX that has to scale later. This page is the gate in front of that: do not start the expensive work until the product has a question and a path.

If you are not ready to build yet

Good. That is the honest position.

Bring the messy version — the idea, the users you think you have, the thing you are afraid is wrong. Start a conversation. We will find the question, cut the scope, and make something you can put in front of people.

Then you can fund a build that already knows what it is for.