What Is A Minimum Viable Product

A minimum viable product is the smallest coherent product that can test one value proposition with real users. Not the cheapest version of the platform you dream about, and not a demo with half the buttons painted on. It is a small, finished thing that does one job from start to finish, tells people plainly what it is for, works every time on the path that matters and measures whether anyone got value from it. Everything else is negotiable. Those four parts are not.

Most teams hear “minimum” and stop listening. They cut quality instead of scope, ship a slice of a future platform that nobody can finish a task in, and then call the silence “market feedback”. It isn’t feedback. It is a product that never got a fair test, paid for with money that is not coming back, plus the ad budget that brought in users who hit a dead end on day one.

We have scoped, designed and rescued MVPs for 15 years, and the plot never changes. Only the props do. A decade ago the excuse for a bloated first release was “the developers need six months anyway”. Today AI writes a login screen before the coffee is cold, and the same mistake simply got faster: teams now build twelve unvalidated features in the time it used to take to build three. Speed was never the bottleneck. Deciding was.

What is a minimum viable product

A minimum viable product is the first release of a product that is small enough to build quickly and complete enough for a real person to get real value from it, so the team can find out whether the value proposition holds before it spends the big money.

Read that sentence again and notice what it does not say. It does not say “cheap”. It does not say “rough”. It does not say “the first 20% of the roadmap”. An MVP is defined by the question it answers, not by the budget left over after everything else was paid for.

Picture two builders with the same money. The first pours the foundation slab for a twelve-room mansion, runs out of cash and invites the family to move in. There is a lot of concrete. Nobody can sleep on it. The second builds one small room with a roof, a door that locks, running water and a bed. It is tiny, and it is a house. The family moves in on Friday and by Monday you know whether they like the neighbourhood.

The foundation slab is what most “MVPs” we are asked to audit look like: a sign-in screen, a dashboard with empty charts, a settings page with fourteen toggles, and the one feature the product exists for half built behind a “coming soon” label. Each piece took real salaries. Together they answer nothing, because nobody can get from the front door to the value.

So the useful definition has three parts, one per word:

• Minimum limits the scope. One audience, one job, one path through the product. Everything that does not serve that path waits.
• Viable sets the quality bar. The path works, reliably, for a stranger who has never met your team. If a user needs you on a call to finish, it is not viable yet.
• Product means it is real. People find it, understand it, use it without supervision, and ideally pay for it. A slide, a clickable mock-up and a waitlist page are useful tools, but they test other questions.

A twisted proverb we use with founders: Rome wasn’t built in a day, but somebody had a room to sleep in by the first night.

Where the term comes from, and what it was meant to do

The phrase went mainstream through the lean startup movement. In a post published on 3 August 2009 on his blog Startup Lessons Learned, Eric Ries defined the minimum viable product as the version of a new product that lets a team collect the most validated learning about customers for the least effort. Note the direction of that definition: learning first, effort second. The whole point was to find out sooner whether you were building the right thing.

Somewhere between 2009 and your last board meeting, the term got flipped. “Minimum” started to mean “whatever we can afford” and “viable” started to mean “technically runs”. Founders now use MVP to describe everything from a landing page to a 40-screen platform, and investors nod at both. The word lost its edges, and a word without edges cannot protect a budget.

We keep the original intent and make it stricter. An MVP exists to test a specific value proposition with the least product that can test it fairly. “Fairly” is the part everyone skips. A test where users cannot finish the task tells you nothing about the idea. It only tells you the test was broken.

What an MVP is not: prototype, proof of concept, pilot, version one

Half the arguments about MVP scope are really arguments about which tool the team needs. Founders ask for an MVP when they need a prototype, and ask for a prototype when they need an MVP, and then everyone is surprised the answer does not fit the question.

Think of a street-food trader with an idea for a new dish. Handing out tasting spoons at a market answers “do people like the flavour?”. Cooking one batch in a borrowed kitchen answers “can we make it at all?”. A food truck with a three-dish menu and a card reader, parked where hungry people walk past, answers the only question that pays the rent: will strangers come back and pay for it? A restaurant with forty covers and a wine list is version one, and you only sign that lease after the truck has a queue.

The expensive confusion runs in two directions. Some teams build a proof of concept, see that the tech works, and call it an MVP. The tech working was never the question; nobody queues at a truck to admire the engine. Others build a prototype so polished it looks like a product, show it to investors, and skip the part where strangers use it unsupervised. Both end up with a deck full of optimism and no evidence.

A clickable prototype still has a place in almost every MVP we scope. It is cheap, it comes before the build, and it catches the flow problems that would otherwise cost engineering weeks. It just does not replace the MVP. It tests whether people understand the product. The MVP tests whether they want it.

Minimum is about scope. Viable is about quality.

Think of a new hospital. One version builds the reception, the car park, the gift shop, the staff canteen and half an operating theatre, then opens its doors. It cannot treat a single patient. The other version opens one small clinic room with one doctor and the right equipment, and treats patients on Monday. The first looks like more hospital. Only the second is one.

Software works the same way. A product has layers: getting people in, letting them set up, doing the core job, delivering the result, getting paid, and seeing that it worked. The platform in your head has all of those for twenty jobs. The MVP has all of them for one job. Engineers call the first approach a horizontal slice and the second a vertical slice.

The horizontal slice is seductive because it looks like progress on every front. The navigation is there, the dashboard is there, the settings are there, the team is busy. Every status meeting is green. And not one user can complete the task the product exists for. You have built a jack of all trades, master of none, except the trades are all half-learned.

The vertical slice feels uncomfortably small. One job. Maybe one type of user. No settings page worth mentioning. But a stranger can walk in, do the job and leave with the result, and that is the first moment your product can earn money or teach you anything.

Here is the uncomfortable consequence for quality. Because the scope is small, the quality inside it has nowhere to hide. On a horizontal slice, a broken payment step is “one of many things still in progress”. On a vertical slice, it is the whole product failing. That is exactly why the vertical slice is the honest test.

The four things an MVP cannot skip

Cut features, cut platforms, cut settings, cut the admin panel your cofounder keeps asking for. Four things stay, whatever the budget, because without them the release cannot answer its own question:

• A complete happy path, so a user can get from arrival to value without a dead end.
• Positioning people understand, so the right users recognise the product is for them.
• Core behaviour that works every time, so a failure is not mistaken for disinterest.
• A way to measure value, so the launch produces evidence instead of opinions.

Skip any one and the MVP still ships, still costs the same, and still gets “feedback”. The feedback just measures your screw-up instead of your idea. Our running example from here on is Quillbill, a fictional invoicing app for freelancers whose promise is “send an invoice from your phone in a minute and get paid by card”.

A complete happy path, from arrival to value

The happy path is the route a typical user takes when nothing goes wrong: they arrive, understand what the product is, do the core job and see the result. In an MVP it must be complete. Not mostly complete. Complete.

A bus route that stops one stop short of the station is not a slightly shorter bus route. It is a bus that drops everyone in a car park with their suitcases. Nobody praises the driver for covering 90% of the distance. They miss the train, and next time they take a taxi.

MVP happy paths usually break in the same places:

• At the handover to someone else. The freelancer sends the invoice, and the client receives a bare PDF with no way to pay. Half the value proposition lives on the client’s side, and nobody designed it.
• At the result. The job runs, but the user never sees that it worked. No confirmation, no status, no “paid” moment. They cannot tell success from silence.
• At the “we’ll do it manually for now” step that nobody told the user about. The team plans to handle something by hand behind the scenes, which is a perfectly good MVP tactic, but the interface shows a spinner and the user leaves before anyone on the team wakes up.
• At the edge nobody considered normal. The very first real user has two clients with the same name, or an invoice in a second currency, and the path forks into nowhere.

Look at the left screen and count what the “coming soon” costs. You paid to acquire that user. You built sign-up, onboarding, client records and an invoice editor. And then, one tap from value, the product hands the job back. The user does exactly what the screen says: goes back to the spreadsheet they were already using, and never returns. Every earlier screen was money spent on walking someone to a locked door.

Doing parts of the path by hand is not a sin. Plenty of good MVPs send the email, match the payment or review the result manually for the first few dozen customers. Think of it as a supper club before a restaurant: the cooking is real, the kitchen is improvised, and the guest still gets dinner. The rule is that the guest must never be left waiting at an empty table. If a person on your team completes a step, the interface still tells the user what happens next and when.

Positioning people understand in five seconds

An MVP has no brand awareness, no sales team and no second chance. The first screen, the store listing or the landing page has one job: make the right person think “that’s for me” and the wrong person leave quickly. If it cannot do that, the product never meets the users it was built for, and your launch data fills up with the wrong crowd.

Imagine a market stall with no sign, no prices and a table of unlabelled boxes. The goods might be excellent. People slow down, squint, and walk to the stall next door that says “Fresh bread, £2”. The stall owner goes home believing nobody wants what he sells. Nobody knew what he sold.

The usual MVP positioning mistake is ambition. The team is building a platform in their heads, so the first screen describes the platform: “the all-in-one financial workspace for modern teams”. The MVP delivers one thing. The promise and the product disagree, and the user notices within a minute. The people who came for “all-in-one” leave disappointed. The people who needed the one thing never recognised it.

Good MVP positioning names three things in words the user already uses: who it is for, the one job it does, and the result they get. No category invented last week, no “AI-powered” doing the work of a verb. If your team cannot write that sentence without arguing, you have found a missing product decision, and it is much cheaper to find it now than after the launch spend.

Positioning is also a filter for your data. When the promise is specific, the people who sign up are the people you built for, so their behaviour means something. When the promise is vague, your first hundred users are a random sample of the curious, and you will spend months trying to learn from people who were never your customers.

Core behaviour that works every time

“Minimum” gives you permission to do less. It never gives you permission to do it badly. The core job must work every time a user tries it, including on a patchy connection, with a typo in an email address, and on the second attempt after something went wrong.

A washing machine that finishes the cycle four times out of five is not 80% of a washing machine. The fifth time it floods the kitchen, and from then on you stand guard over every wash. You stop trusting it, and you tell everyone at dinner about it. Users treat an unreliable core exactly the same way, except they tell the app store.

Here is the trap, and it is expensive. When the core fails, users do not file bug reports. They leave. Your dashboard records a user who signed up and never came back, and the team reads it as “the market doesn’t want this”. The idea gets killed for a bug. You paid for the user, paid for the build, and then paid for a false conclusion that might send the company in the wrong direction.

Reliability in an MVP is narrower than in a mature product, which is the good news. You do not need five nines across the platform. You need the core path to be solid:

• The core job never corrupts data. No duplicate invoices, no lost drafts, no wrong totals. If money or someone’s work is involved, this is non-negotiable.
• Failures on the core path explain themselves. What happened, whether anything was lost and what to do next, in one short sentence each.
• The obvious unhappy paths are designed. Wrong input, no connection, a declined card, an expired link. Not every edge case in the universe; the five that real people will hit in the first week.
• Someone is watching. Errors on the core path reach a person on the team within the hour, not in the quarterly review.

Everything outside the core can be rough. The settings screen can be plain, the admin can be a spreadsheet, the reports can be an email. Users forgive plain. They do not forgive losing their work.

A way to measure value, decided before launch

An MVP that ships without measurement is a very expensive opinion. It will produce a launch, some sign-ups and a lot of Slack messages about “early traction”. It will not produce a decision, because nobody agreed what success looks like.

Imagine a football match with no scoreboard and no referee. Both teams play hard for ninety minutes, then retire to the pub and argue about who won. Everyone has evidence. Everyone saw the same game. Nobody can prove anything. That is a product review after an unmeasured MVP launch: the founder remembers the three enthusiastic emails, the CTO remembers the crash logs, and the investor remembers the chart that went up for a week.

Measuring an MVP does not mean a data warehouse. It means answering four questions before the first user arrives:

• What is the value moment? The event that proves a user got what the product promised. For Quillbill it is not “signed up” and not “created an invoice”. It is “a client paid an invoice through the link”.
• What shows they came back for more? One repeat behaviour that separates the curious from the converted. A second invoice within a month says more than a hundred page views.
• What will we count as enough? A threshold the team writes down before launch, so the result cannot be reinterpreted afterwards to fit the mood.
• Where do people drop? The few steps between arrival and the value moment, instrumented so you can see which one leaks.

Pair the numbers with a few conversations. The events tell you where people stopped; five short calls with users who stopped tell you why. Numbers alone make you guess at motives. Conversations alone make you generalise from the loudest person. Together they turn a launch into a decision.

Five or six core capabilities, at most

Here is the scope rule we hold founders to: an MVP gets five or six core capabilities at most. Not five or six screens, not five or six epics with forty stories each. Five or six things the user can do that together make the happy path work.

It sounds brutal. It is merciful. A pupil who hands in twelve half-written essays does not get twelve half-marks. He gets zero, twelve times, and a note home. A pupil who hands in one finished essay gets a grade and feedback he can use. An MVP with twelve half-built capabilities gets exactly the first result: nothing works well enough to be judged, so nothing can be learned.

Why five or six? Because that is roughly what one coherent job needs. For Quillbill: add a client, create an invoice with line items and VAT, send it by email with a pay link, let the client pay by card, show the status from sent to paid, and send an automatic reminder when it is overdue. Six. Every one of them sits on the happy path. Remove one and the promise breaks. Add a seventh and you are building for a second job before you have proven the first.

The capabilities that get cut are rarely bad ideas. Time tracking is useful. Multi-currency is useful. An AI assistant that writes invoice descriptions is certainly fashionable. They are cut because none of them is needed to answer the question “will freelancers use a phone app to send invoices and get paid faster?”. If the answer is no, time tracking will not save it. If the answer is yes, you will know which feature to add next, because users will tell you with their behaviour.

To decide what stays, we run every candidate capability through the same four questions:

• Is it on the happy path, or is it a detour?
• Does the value proposition break without it?
• Could we do it by hand for the first fifty customers instead?
• Does it change what we will learn from this release?

A capability that fails all four is out. A capability that passes only the third is a manual process for now. The ones that pass the first two are your five or six. If more than six survive, the job is too big: split it, and pick the half that carries the value.

This is the moment to cut your coat according to your cloth. The budget, the runway and the team you actually have set the size of the MVP, not the size of the vision. Every capability over six is borrowed against a future you have not proven yet.

An MVP with twelve half-built features is not twice as viable as one with six. It is not viable at all.

A fixed release boundary, not a moving target

Choosing six capabilities is the easy part. Keeping it six is where MVPs die. Every week of the build someone has a good idea, a potential customer asks for “just one thing”, an investor mentions a competitor, and the release date slides one reasonable request at a time.

Airlines solved this problem with a metal frame at the gate. The cabin-bag sizer does not negotiate, does not care how important your hairdryer is and does not accept the argument that the bag is “basically the same size”. Either it fits or it goes in the hold. An MVP needs the same frame: a written release boundary that decides what is in, what is out and what happens to every new idea.

The boundary is a one-page document the whole team signs up to. It names the audience and the job, lists the capabilities that are in, lists the ones that are explicitly out, defines what “done” means for each, sets the release date, and sets the rule for change. Our rule for change is simple: anything new that comes in swaps something of equal size out, and the swap is decided by the person who owns the budget, not by whoever shouts last.

Why fix the date as well as the scope? Because a scope without a date stretches, and a date without a scope gets met by cutting quality on the core path, which is the one thing you cannot cut. Fix both, and the only lever left is to make each capability simpler, which is exactly the pressure an MVP needs.

Scope creep is never one big decision. It is thirty small, reasonable ones, each of which makes sense in the meeting where it was made. That is why it needs a rule, not good intentions. Teams that bite off more than they can chew in week three are usually still chewing in month six, and the market has moved on while their mouths were full.

AI makes building faster. It doesn’t make guessing cheaper.

AI-assisted delivery is real, and we use it every day. A developer with a good assistant scaffolds screens, writes tests and wires integrations in a fraction of the time it used to take. For an MVP that is genuinely good news: the build part of the budget shrinks, and you can get in front of users sooner.

Here is what it does not do. It does not tell you which six capabilities to build. It does not validate that anyone wants them. It does not write your positioning, design your happy path or decide what counts as success. It removes the friction that used to force teams to choose, and that friction, annoying as it was, protected budgets.

A concrete mixer that pours twice as fast does not tell you where the house should stand. Point it at the wrong plot and you get a wrong foundation in half the time, and concrete is famously hard to move. That is what we see in AI-built MVPs: twelve features in the time it used to take to build four, none of them validated, all of them now code that somebody has to maintain, test and explain to users.

The twelve-feature MVP is the most common AI-era mistake, and it has a convincing excuse: “it was almost free to build”. It was not. Each feature adds screens to design, states to handle, bugs to fix, copy to write, analytics to track and support questions to answer. Worse, each one splits the users’ attention and your data. With twelve features live, a flat result could mean any of twelve things. With six on one path, a flat result points to one of six steps.

The second AI-era trap is quieter: endless concept iteration. Generating a new version of the landing page, the onboarding or the whole product concept now takes minutes, so teams keep generating. Version four is better than version three. Version nine has a nicer gradient. Meanwhile no real user has touched any of them, and the runway keeps burning.

Philosophers call this Buridan’s ass: the donkey standing exactly between two equally good haystacks, unable to choose, starving to death out of perfect indecision. Give the donkey an AI and it gets nine haystacks and starves faster. Perfect is the enemy of good, and in an MVP it is also the enemy of the bank balance.

The rule we hold AI-assisted teams to is the same one we held slow teams to, with one addition. Validate the flow before you build, cap the release at five or six capabilities, and set a limit on concept rounds: two or three, tested with real users between each, then build. Use the time AI saves to test more, not to build more. That is the only way the speed turns into money.

Validate the user flow before you build it

The cheapest moment to find a broken happy path is before anyone writes production code. The flow is still a diagram and a clickable prototype, and changing it costs an afternoon. After the build it costs a sprint. After the launch it costs the users who hit the problem, and they do not come back to see the fix.

Schools figured this out a long time ago. Nobody sits the real exam without a mock first. The mock is cheap, it does not count, and it shows precisely which topics you do not know while there is still time to learn them. A prototype test is the mock exam of an MVP: it shows where users get lost while the fix is still a sketch.

Start with the flow itself. Map the happy path from the moment a user arrives to the moment they get value, including every other person involved. In a two-sided product that means both sides: in Quillbill the freelancer sends, but the client opens, reads and pays. Then mark the obvious failure points and what happens at each one.

Then test it. Build a clickable prototype of the happy path, find five or so people who match your audience, give each of them the job in one sentence and watch without helping. You are looking for three things: where they hesitate, where they misread what the product is for, and where they expect something that is not there. The last one is gold, because it often reveals a missing capability that belongs in the five or six, or a capability you planned that nobody reaches for.

A flow test also exposes the missing product decisions, which are the real reason MVPs overrun. Who can see an invoice once it is sent? What happens when a client pays half? Is VAT per line or per invoice? Every one of those questions will be answered eventually. The only choice is whether a product owner answers it in a workshop or a developer answers it at 11 pm by guessing.

Minimum viable product for an app

Everything above applies to a mobile or web app, but apps add a few costs that catch founders off guard. The store, the platforms and the device each have opinions, and each opinion adds time between “finished” and “in users’ hands”.

Start with the platform question, because it quietly doubles budgets. Building iOS, Android and web on day one to find out whether anyone wants the product is buying three dogs to find out whether you like walking. You will spend the whole time on feeding and vet bills, and learn nothing about walking you could not have learned with one. Pick the platform where your audience already is, and let the evidence earn the second one. For some products that is a web app that works well on a phone; for others it is one native platform; cross-platform frameworks can help, but they reduce build effort, not the design, testing and store work per platform.

The stores have their own rules about how minimal a product can be. As of 2026, Apple’s App Store Review Guidelines ask for submissions that are final versions, with placeholder text and temporary content removed (section 2.1, App Completeness), and warn that an app which is little more than a repackaged website, or not particularly useful, may be turned away (section 4.2, Minimum Functionality). An MVP with “coming soon” screens is not only a weak test. It can be a rejected submission.

Google Play adds a clock. As of 2026, Google’s Play Console Help states that new personal developer accounts created after 13 November 2023 must run a closed test with at least 12 testers opted in continuously for at least 14 days before they can apply for production access. Either way, review and testing time belongs in the MVP plan, not in the week after the build.

Then the app-specific design decisions that matter most for an MVP:

• Let people reach value before you ask for everything. A sign-up wall with company name, VAT number, address, logo and bank details before the first invoice is a clinic that makes you fill in six pages of medical history before it tells you whether it treats your problem. Ask for what the first job needs, when it needs it.
• Ask for permissions at the moment they make sense. A notification prompt on first launch, before the user has done anything, gets the answer it deserves.
• Design the offline and interrupted states of the core job. Phones lose signal in lifts and on trains. An invoice half-written in a tunnel must still be there when the train comes out.
• Plan the update path. Once people install an app, old versions stay in the wild. Decide early how you will ask users to update when the core changes.

If you want to go deeper into how the design process works for a first app release, our MVP UX design guide walks through it screen by screen.

Launch early enough to learn

The point of an MVP is not to launch. It is to learn while you can still do something about what you learned. That means the launch has to leave time and money on the other side of it.

Every MVP has two clocks running. One is the budget: every week of the build spends runway that could have paid for the second iteration. The other is the market: competitors ship, customers find workarounds, the window you spotted starts to close. Launch too late on either clock and the result, however clear, arrives when you can no longer act on it. You have missed the boat, and the boat left with your money on it.

Waiting for the perfect launch is waiting for a dry week in Manchester to paint the fence. The forecast will always look better next week. Meanwhile the wood rots. Founders tell us they will launch “when it’s ready”, and “ready” moves every time the team gets closer to it, because there is always one more thing that would make it better.

Work backwards instead. Start from the money you need after launch: enough to run the product, talk to users, and build at least one serious iteration based on what they tell you. Subtract that from the budget. What is left is the budget for the MVP, and it sets the scope, not the other way round. If six capabilities do not fit, the job is too big, and the answer is a smaller job, not a smaller quality bar.

Put it plainly: every week you do not launch, you choose to keep paying for guesses instead of evidence. That is sometimes the right choice; a broken core path is worth a week. “One more feature” almost never is.

After launch: decide with rules you set before kick-off

The first weeks after an MVP launch are noisy. A few users love it and email you. A few hate it and email you louder. The numbers wobble. Every founder instinct says “just a bit more time” or “just one more feature and it’ll click”. That is sunk cost talking, and it has a very persuasive voice.

In football, the rules are agreed before kick-off, for a reason. Nobody gets to change what counts as a goal at half-time because they are losing. Set your MVP decision rules the same way: before launch, in writing, with the thresholds from your measurement plan. Then, when the data comes in, you are reading a result, not negotiating with one.

In practice there are four outcomes, and each needs a different response:

• Keep going. Users reach the value moment and come back at or above your threshold. Now you earn the right to add the seventh capability, and the data tells you which one.
• Fix the flow. Users want the result but drop at a specific step. That is a design and build problem, not a market verdict. Fix the step, measure again.
• Change the audience or the promise. The wrong people sign up, or the right people do not recognise the product as theirs. Back to the drawing board on positioning, and possibly on who the MVP is for.
• Stop. The right people reach the value moment and still do not come back. The value proposition did not hold. That is a painful result and a cheap one, compared with the alternative of learning it after version three.

The fourth outcome is the one nobody plans for, and it is the one that saves the most money. An MVP that proves an idea wrong for a fraction of the full budget is a success. An MVP that is kept on life support because nobody set a stopping rule is the most expensive product in the company, and it is usually the one with the nicest pitch deck.

The MVP mistakes we find most often

We have seen every shape of MVP go wrong, and the patterns repeat with almost comic reliability. If you recognise your product in more than two of these, the problem is not the build.

The platform in disguise. The MVP is scoped for the company the founders hope to be in three years: team accounts, role permissions, an admin console, integrations with five tools. It is buying a family-size corner sofa for a studio flat because you will have kids eventually. It does not fit through the door, and you are sleeping on it alone for years. Build for the users you are testing with now.

The beautiful shell. Months go into brand, illustration and animation, and the core job behind them is thin or broken. It is a gift box wrapped by a professional, with nothing inside. The first user unwraps it in ten seconds, and all that ribbon becomes an expensive disappointment. Design effort in an MVP goes to the happy path first, the polish second.

The ugly and broken excuse. The mirror image: “it’s an MVP, it doesn’t need to look good or work properly”. Plain is fine. Confusing is not, and broken is fatal. Users do not grade on a curve because you told the investors it was early.

The untested feature list. A build is commissioned from a feature list, with no flow, no positioning and no measurement plan, and the founder only sees what they bought on launch day. That is buying a pig in a poke with your runway. Nobody validated the parts, so nobody knows whether they add up to a product, and it is a common story behind the finished MVPs nobody uses.

The silent launch. The MVP goes live with no plan for how the target audience will find it. Twenty friends sign up, nothing happens, and the idea is declared dead. You did not test the idea. You tested whether strangers can find a product nobody told them about. Plan the channel as carefully as the features.

The everybody MVP. “It’s for freelancers, agencies, small businesses and accountants.” Four audiences with four jobs means four half-products. Pick one audience whose problem is sharpest and whose feedback you can reach.

The forever beta. The product has been “in MVP” for two years, collecting features and never making a decision. It is no longer testing anything; it is just a product with low standards and a permanent excuse.

How we scope an MVP: the order of work

We do MVP work in the same order every time, because each step produces something the next one needs. Skipping a step never saves the time it seems to; it just moves the cost to a later, more expensive moment.

1. Name the value proposition and the audience. One sentence: who it is for, the job it does, the result they get. Output: a promise the team agrees on, and the first missing decisions surfaced.
2. Map the happy path and its failures. From arrival to value, both sides of the product if there are two. Output: a flow everyone recognises, with the obvious unhappy paths marked.
3. Choose five or six capabilities. Run every candidate through the four questions, park the rest with reasons. Output: the capability list.
4. Test the flow with a clickable prototype. Five or so target users, one task, no help. Output: a revised flow and a list of what users expected and did not find.
5. Write the release boundary. Capabilities in and out, definition of done, date, change rule. Output: one signed page.
6. Design the core and its states. Every screen on the happy path, the failure states, the first screen’s positioning. Output: designs engineering can build without guessing.
7. Build, instrument and harden the core path. Measurement plan wired in, the core broken on purpose and fixed. Output: a release candidate that works every time on the path that matters.
8. Launch into a real channel and read the result against the rules. Output: one of four decisions, on a date agreed in advance.

The first five steps are cheap compared with the build, and they are where most of the money is saved. Every decision made in step one is a decision a developer does not have to guess at in step seven.

Why ANODA turns the MVP wishlist into a coherent first release

A faster development team can build the wrong scope faster. A prettier prototype can keep everyone excited while the central product decision stays unresolved. ANODA connects the audience, the core job, the release boundary and the interface before those guesses become code you have to maintain.

For AispireMe, we designed the education-planning MVP across four roles: research, connected user flows, information architecture, wireframes, desktop UI, a clickable prototype and a reusable UI kit. That combination gives a first release a product structure, not just a polished entrance screen.

Come to ANODA with the wishlist, the deadline and the budget. We will shape the release around the job customers need, settle the missing decisions and give your team the complete flow and design states it needs to build. You get a focused product to take to users while there is still room to act on what you learn.

When to bring in outside help

Bring ANODA in when the first release needs a clear product direction: one customer job, a focused scope and an interface that carries people all the way to value. We give your team the decisions and design foundation it needs before the build starts consuming the runway.

Bring someone in when the pattern is already visible: the scope keeps growing, the release date keeps moving, the team cannot agree on the one sentence, or an MVP is live and nobody can explain why users leave. That is usually not a talent problem. It is a missing decision problem, and people inside the company are often too close to the vision to cut it down to one job.

That is the work we do. ANODA scopes and designs MVPs, exposes the product decisions that are still missing, and supports the build and the measurement through launch. We turn faster delivery into a focused release, with product decisions settled and the path to value designed. Our job is to get you in front of real users with a coherent product and budget left for the next improvement. If you want the wider background first, the rest of our thinking on product design sits in the ANODA UX blog.

The decision rule

When you are deciding what goes into your minimum viable product, ask these questions in order and stop at the first one without a clear answer:

1. Can we say in one sentence who the MVP is for, what job it does and what result the user gets?
2. Is there a complete happy path from arrival to that result, tested with target users?
3. Does the first screen promise exactly what the MVP delivers, and nothing more?
4. Does the core path work every time, including its five most likely failures?
5. Do we know the value moment, the repeat behaviour and the thresholds, in writing?
6. Is the scope five or six capabilities at most, inside a signed release boundary?
7. Will there be enough budget and time after launch to act on what we learn?

If every answer is yes, build and ship. If one is no, that is the next piece of work, and it is cheaper now than at any later moment.

An MVP is not a cheap product. It is a cheap answer. Choose five or six core capabilities at most, draw a fixed release boundary, validate the user flow, and launch while the market and the budget are still there to hear what the users say.