The phrase “minimum viable product” has been stretched until it means almost anything: a rough prototype, a cut-price app, or a first release with half the buttons greyed out. None of those definitions is especially helpful. A good MVP is the smallest credible product that can answer an important business question.
That distinction matters because your goal is not to build less for the sake of it. Your goal is to learn before the expensive decisions become hard to reverse. The GOV.UK discovery guidance puts it neatly: understand the problem, the users, and the constraints before committing to a solution. That is solid advice whether you are launching a public service, an internal operations tool, or a new commercial platform.
Start with the decision, not the feature list
Feature lists feel productive because they are concrete. They are also where early products get heavy. A list that says profiles, dashboards, notifications, permissions, exports, and integrations hides the more important question: what must become true for this product to be worth building further?
For a marketplace, the risk may be whether supply and demand can meet reliably. For an internal workflow, it may be whether a team will leave its spreadsheet behind. For a client portal, it may be whether customers can complete a task without support. The MVP should expose that risk quickly and honestly.
Write the decision in plain language: “If eight of ten pilot customers complete this journey without assistance and return within two weeks, we will fund the next release.” That sentence is more valuable than a backlog with 120 items because it gives the team a filter.
Build the three layers that make learning possible
The three layers of a useful first release
Keep the surface narrow, but make the experience credible enough that real behaviour means something.
- 01
Problem evidence
Talk to the people living with the current workaround. Map the cost, delay, risk, or frustration in the existing process.
- 02
One complete journey
Choose a thin end-to-end path. A small journey that actually finishes is more revealing than six disconnected screens.
- 03
A feedback loop
Instrument the important actions, schedule real conversations, and decide in advance how the evidence will change the roadmap.
What should stay out of the first release?
An MVP earns focus by saying no. Keep an item out when it does not affect the core decision, can be handled manually for a small pilot, or only becomes necessary at a scale you have not reached yet. Common candidates include:
- automating an edge case that will occur twice during the pilot
- supporting every user role before the primary role is proven
- a native mobile app when a responsive web journey can test the behaviour
- complex dashboards before anyone has agreed which decision the data supports
- premature integrations that can be simulated safely for the first cohort
Manual does not mean careless. If a team member performs a behind-the-scenes step during the pilot, document it and protect customer data. The point is to avoid paying to automate a process that may change next month.
If removing a feature does not change the decision your MVP is meant to unlock, it is probably not part of the MVP.
Keep quality high while the scope stays small
“Minimum” should describe scope, not care. A narrow product can still be secure, accessible, responsive, observable, and pleasant to use. In fact, poor quality contaminates your test: users may reject the execution even when the underlying idea is sound.
This is why our product engineering work starts with the business constraint and then protects the foundations that are expensive to retrofit. We would rather ship one polished journey that earns trust than a broad demo that collapses when the first customer uses it differently.
Budget for the next move, not only launch day
Reserve time and money for observation, fixes, and the first evidence-led iteration. Launch is the start of the useful part. If the entire budget disappears into version one, the team has created a test with no room to respond to the result.
A sensible plan includes a decision date, a small contingency for what the pilot reveals, and ownership after release. If you are still deciding what belongs in the first slice, our guide to custom software budgeting guide will help frame the conversation.
