How to validate an MVP idea before you build it

Start with the user need, not the feature list#

GOV.UK's Service Manual recommends beginning by learning who likely users are, what they are trying to do, how they do it today and what frustrates them. That is a stronger starting point than asking people whether they like your app idea, because approval is cheap while behaviour is expensive.

Write the riskiest assumption down#

Most early products carry several assumptions at once: that the problem exists, that it is urgent, that the proposed workflow is understandable, that people will switch from the current workaround and that a viable acquisition channel exists. Pick the assumption that would kill the business fastest if it were false.

Use the cheapest test that can change your mind#

A landing page, concierge service, clickable flow, manual back office or spreadsheet can answer many product questions without a production build. The point is not to avoid engineering forever. It is to make sure engineering is aimed at the right unknown.

Interview for behaviour, not compliments#

Ask people to describe the last time the problem happened, what they did next, what it cost, who else was involved and what they have already tried. Treat solution suggestions as hypotheses, not requirements. GOV.UK explicitly advises teams to treat opinions not grounded in user evidence as assumptions to prove through research.

Decide what evidence is enough#

Define a threshold before the test. That could be ten qualified discovery calls with the same repeated pain, five businesses agreeing to pilot, a credible waitlist conversion rate, or a small number of people paying for a manual version. The threshold will vary, but it should be concrete enough to produce a go, change or stop decision.

Then define the MVP around one learning goal#

Once the problem is credible, the MVP should answer the next expensive question. Build the smallest end-to-end workflow that lets real users receive the promised value. Everything else should justify itself by improving that test, reducing material risk or making the product safe enough to operate.

Keep an evidence log#

Record who participated, how they were recruited, what they actually did and what would count against your idea. Separate a paid pilot from a free waitlist signup: both can be useful, but they demonstrate different levels of commitment. Small qualitative samples help find patterns; they do not establish a market-wide conversion rate.

After the test, write a short decision: continue with the same audience, change the offer, run a different test or stop. Document the uncertainty that remains. This makes the next build decision easier to explain and prevents a collection of positive comments from quietly turning into assumed demand.

Match the test to the uncertainty#

Choose the cheapest test capable of changing your decision. If the problem is buyer access, a beautiful prototype will not solve it. If customers want the outcome but cannot complete the flow, more interviews about general interest may miss the problem.

Write the decision before seeing the results#

An illustrative hypothesis could be: independent tutors who currently lose bookings during scheduling will commit to a paid assisted-booking pilot. State the segment, offer, outreach route, observation window and what would justify the next investment. Set the threshold using your economics and capacity; there is no universal conversion rate that validates a business.

Keep the denominator honest. Forty cold messages, eight qualified conversations and three paid pilots describe different stages. Record each rather than reporting “three customers from eight” without explaining where the eight came from. Note when a friend, discount or bespoke promise changes the meaning of the result.

Record negative outcomes with the same care: no response, wrong buyer, no priority, no budget, unsuitable timing or failure to deliver value. A rejection reason is a hypothesis until you have evidence; do not rewrite every “no” as proof that the customer misunderstood.

Know when to narrow, repeat or stop#

Repeat when a result may be explained by the execution of the test and a specific change can resolve that uncertainty. Narrow when one segment or use case has evidence that others lack. Stop or change direction when the key assumption fails and you cannot identify a credible next test within your budget.

A pilot that customers buy but need you to perform manually for hours can validate a problem while invalidating the current delivery economics. Preserve both findings. The next question may be whether the expensive step can be simplified, not whether you can attract another signup.

Put this guide to work#

Frequently asked questions#

Sources and methodology#

This guide combines editorial analysis with the linked primary sources. Decision frameworks, worksheets and worked examples are our own; examples are illustrative unless explicitly identified as supplier claims or published research. We have not conducted original interviews, comparative supplier testing or a controlled experiment for this article.

1. GOV.UK Service Manual: learning about users and their needs ↗

   Primary reference for the platform or practice discussed. Editorial examples and decision frameworks are our own.

   Accessed 16 October 2026
2. ONS Service Manual: identifying user needs ↗

   Primary reference for the platform or practice discussed. Editorial examples and decision frameworks are our own.

   Accessed 16 October 2026
3. ICO: data protection by design and by default ↗

   Primary reference for the platform or practice discussed. Editorial examples and decision frameworks are our own.

   Accessed 16 October 2026

Source check: 16 October 2026. Platform documentation can change. Published as part of our editorial collection.

Expanded 16 October 2026 with practical decision material, downloads and topic-specific answers. Supplier and platform claims are identified by their linked sources.