Every product team eventually hits the same wall. The idea is clear, the enthusiasm is high, and the feature list has quietly grown to forty items — each one defended by someone who is certain it is essential. Six months later the product ships late, over budget, and users engage with roughly four of those forty features.
The MVP was supposed to prevent exactly this. In practice, “MVP” has become one of the most misused terms in product work — usually meaning “the full product, but rushed.”
This is about doing it properly: what a minimum viable product actually is, how to decide what belongs in it, and how to avoid the failure modes that turn a lean first release into an expensive false start.
What is an MVP?
A minimum viable product is the smallest version of your product that delivers real value to real users and generates evidence about whether your core assumption is correct.
Three words in that definition carry the weight:
- Minimum — the smallest scope that still works. Not the cheapest, not the fastest, the smallest that remains genuinely usable.
- Viable — it has to actually solve the problem. A product that is minimal but doesn't work isn't an MVP; it's a broken product.
- Product — something people can use unaided, not a demo that requires you in the room explaining it.
The purpose is learning. An MVP exists to answer a question you cannot answer any other way: will people actually use this, and does it deliver the value we think it does?
What an MVP is not
Most MVP failures trace back to a definitional mistake made at the start.
An MVP is not a prototype. A prototype tests a concept with a handful of users in a controlled setting. It can be clickable, it can look real, but it is not connected to anything and nobody relies on it. An MVP is live, and real people depend on it.
An MVP is not a proof of concept. A POC answers “is this technically possible?” An MVP answers “does anyone want this?” These are different questions and they need different work.
An MVP is not version 1.0 with features cut at random. Removing features until the timeline fits produces a product that does several things badly. A real MVP does one thing completely.
An MVP is not an excuse for poor quality. Minimum refers to scope, not craft. Users judge the thing in front of them; they don't grade on a curve because it's early. A rough MVP produces feedback about the roughness, not about the idea.
Why most MVPs fail
They're too big. The most common failure. Scope expands during definition because every stakeholder adds their essential item, and the “minimum” viable product takes nine months. By launch, the market has moved and the budget for iteration is gone.
They're too small to be viable. The opposite error. Scope is cut so aggressively that the product no longer solves the problem end to end. Users try it, hit the missing piece, and leave. The team concludes there's no demand, when what they actually proved is that half a solution isn't useful.
Nobody defined what success looks like. An MVP launches, gets some usage, and the team cannot agree whether that counts as validation. Without a threshold set before launch, results get interpreted to fit whatever people already believed.
No plan for what happens next. The MVP ships, data comes in, and there's no capacity reserved to act on it. Learning that never changes anything is expensive trivia.
It tests the wrong assumption. Teams often build an MVP to test whether they can deliver something, when the real risk is whether anyone wants it. The riskiest assumption should determine what you build.
How to define MVP scope
This is the actual work, and it is a product decision far more than a technical one.
Start with the riskiest assumption
Every product idea rests on a stack of assumptions. Some are safe; one or two would kill the product if wrong. List them, rank them by “how badly does this hurt if we're wrong,” and let the top item define what the MVP has to test.
If the risky assumption is will people pay for this, the MVP needs a payment flow. If it's can we get people to switch from their current tool, the MVP needs migration to work. Everything not serving that test is a candidate for cutting.
Map the core journey end to end
Identify the single path a user must complete to get value — from arrival to the moment the product has actually helped them. That path has to work completely. Everything off that path is negotiable.
This is what separates a viable MVP from a broken one. Breadth is optional. Depth on the critical path is not.
Sort features by necessity, not enthusiasm
For each proposed feature, ask: if this were missing, could a user still complete the core journey and get value? If yes, it isn't MVP scope. Enthusiasm is not a prioritisation criterion, and neither is “it's easy to add.”
Define success before you build
Set the threshold in advance. Not “we'll see how it goes” — an actual number, or an actual observable behaviour. What level of activation, retention, or completion would tell you the assumption holds? What result would tell you to stop?
Teams that skip this step reliably declare victory regardless of outcome.
Decide what you're deliberately not doing
The out-of-scope list is as important as the scope list, and it needs to be written down. It prevents the scope conversation from being reopened every week, and it gives stakeholders confidence that their item was considered rather than forgotten.
What MVP work actually involves
A well-run MVP definition and design phase produces:
- A prioritised feature set with explicit in-scope and out-of-scope lists, and the reasoning attached to each decision.
- The core user journey, mapped end to end, with edge cases identified and consciously deferred or handled.
- User flows covering the paths through the product, including the failure states — empty screens, errors, and interrupted sessions, which are where most MVPs quietly fall apart.
- Information architecture that won't need rebuilding when the product grows. Structural decisions are the expensive ones to reverse.
- Interface design for the screens in scope, at a quality level that doesn't undermine the test.
- A clickable prototype for validating the flow before development starts — the last cheap moment to change your mind.
- Developer-ready specifications — states, behaviours, and edge cases documented so the build doesn't stall on ambiguity.
- Success metrics and an instrumentation plan so the MVP actually generates the evidence it was built to generate.
That last point is routinely forgotten. An MVP that ships without analytics in place answers nothing.
MVP vs. prototype vs. proof of concept vs. pilot
These get conflated constantly, and buying the wrong one wastes a quarter.
- Prototype — answers “does this concept make sense?”, shown to a few test users, not live.
- Proof of concept — answers “is this technically possible?”, internal and technical, not live.
- MVP — answers “does anyone want this?”, used by real users, live.
- Pilot — answers “does this work at scale in context?”, run with a defined real segment, live.
The sequence isn't mandatory — plenty of products go straight to MVP. But knowing which question you're actually trying to answer determines what you should build, and it is worth being explicit about it before scoping anything.
How long does an MVP take?
The design and definition phase for an MVP typically runs four to eight weeks, with development timelines depending entirely on scope and team.
The variables that matter:
- Clarity of the problem. If discovery has already happened and the problem is well understood, definition moves quickly. If direction is still uncertain, that work has to happen first — and doing it during the build is the most expensive place to do it.
- Number of user roles. A single-user product is far smaller than one with an admin, a manager, and an end user, each needing their own flows.
- Integration surface. Every external system the MVP touches adds definition work, edge cases, and failure states.
- Decision-making speed. The most common cause of MVP delay is not complexity — it is stakeholders taking two weeks to approve each decision.
An MVP scoped to take more than six months is generally not an MVP. It is version one wearing a smaller label.
Common mistakes in MVP development
Building for the roadmap instead of the test. Adding architecture for features you might need in year two, before you've confirmed anyone wants year one.
Skipping the definition phase. Going straight from idea to development guarantees the scope conversation happens during the build, when changes are ten times more expensive.
Designing only the happy path. Real users arrive with empty accounts, poor connections, and mistyped inputs. Products that only work when everything goes right feel broken almost immediately.
Confusing “we launched” with “we learned.” Shipping is the start of the useful part, not the end of the project.
Not reserving budget for iteration. If the entire budget is consumed by the initial build, the MVP produces evidence you can't act on. Reserve for what comes after.
Treating user feedback as a mandate. Users report symptoms accurately and prescribe solutions badly. What they struggled with is data. What they suggest building usually isn't.
How we approach MVP work
Our core contribution is defining and designing the MVP — deciding what goes in, mapping how it works, and specifying it clearly enough that the build runs without ambiguity. How it gets built depends on what makes sense for your situation.
You already have a development team. We define and design the MVP and work alongside your engineers through the build, handling the design decisions and edge cases that surface once implementation starts. Most clients with in-house capacity land here.
You need a development partner. We bring in vetted partner studios and manage the handover, so you get a working product without having to assemble and brief a technical team yourself. You keep one point of contact throughout.
The product is simple enough to build with AI. For MVPs with contained scope — internal tools, single-flow products, focused validation builds — AI-assisted development can produce a working product in a fraction of the usual time and cost. Not every product suits this route, and we'll tell you plainly when it doesn't. But when it does, it collapses the gap between deciding what to build and having something real in front of users.
You only need the definition. Some clients need the scoping and design work and nothing else. That's a complete engagement in its own right.
The reason the definition work stays at the centre regardless of route: the hardest part of an MVP is almost never the code. It is the discipline to cut scope, the judgment to know which cuts break viability, and the willingness to defend those decisions when someone senior wants their feature added. Getting that wrong makes the build irrelevant, whoever does it.
Three principles shape the work.
Scope is decided by risk, not by preference. The riskiest assumption determines what gets built. Everything else is negotiable, and we make the reasoning visible so decisions can be challenged on merit rather than seniority.
The critical path is protected. Breadth gets cut before depth. A product that does one thing completely will always outperform one that does five things partially.
The MVP is specified to be measured. Success criteria and instrumentation are defined during scoping, not bolted on afterwards. An MVP that can't tell you whether it worked has failed at its only job.
The approach comes out of thirteen years in UX across agencies, startups, and corporate teams, and work spanning insurtech, fintech, health, education, enterprise, and transportation — sectors where getting the first release wrong is expensive and slow to recover from. It is grounded in formal certification from the Nielsen Norman Group, the institution behind modern UX as we know it, across information architecture, journey mapping, usability testing, UX leadership, and analytics.
Every engagement is run personally, start to finish. No account layer between you and the person making the decisions.
Frequently asked questions
What's the difference between an MVP and a prototype?
A prototype tests a concept with a small number of users and isn't connected to anything real. An MVP is live, used by actual users solving actual problems, and generates behavioural evidence rather than opinions. Prototypes are cheap and fast; MVPs are the real thing at minimum scope.
How much does MVP development cost?
Cost is driven almost entirely by scope, which is why the definition phase pays for itself. A well-scoped MVP with one user role and few integrations is a fraction of the cost of a poorly-scoped one that grew during the build. The most expensive MVP is the one that shipped without anyone deciding what to leave out.
Should we do UX discovery before the MVP?
If you're confident about the problem and the user, you can go straight to MVP definition. If there's genuine uncertainty about who you're building for or what problem you're solving, discovery first is considerably cheaper than finding out through a failed launch.
How do we know if our MVP succeeded?
By comparing results against criteria you defined before launching. If the threshold was set in advance, the answer is unambiguous. If it wasn't, the result gets interpreted to match whatever the team already believed — which is why the criteria matter more than the metrics.
What if the MVP shows the idea doesn't work?
Then it did exactly what it was built to do, at the smallest possible cost. An MVP that invalidates an idea in eight weeks has saved you the year you would have spent building the full version.
Can an MVP be built with AI?
For products with contained scope — internal tools, single-flow applications, focused validation builds — AI-assisted development can produce a working product substantially faster and cheaper than a conventional build. It suits MVPs where the goal is to get something real in front of users quickly rather than to lay foundations for a large platform.
It is not universal. Products with complex integrations, strict compliance requirements, unusual performance demands, or an expectation of heavy scaling still need conventional engineering. The honest answer for any given product depends on its scope, and it is worth asking early — the difference in time and cost is significant enough to change what's worth attempting.
Do you build the MVP, or just design it?
Both, depending on what you need. Some clients take the definition and design and build it with their own engineering team. Some need a development partner brought in and managed. Some have scope simple enough to build with AI assistance. And some need only the scoping work itself. The definition and design stays constant; the build route is chosen to fit the product.
Can we add features later?
That's the point. An MVP is the first release, not the final scope. What matters is that additions are driven by evidence from real usage rather than by the same assumptions that were meant to be tested.
Where to start
The useful diagnostic question is this: if you could only ship one thing, and it had to work perfectly, what would it be — and does everyone on your team give the same answer?
If the answers differ, that gap will surface during the build. It's considerably cheaper to resolve it now.