COBOXThe smallest product that proves the idea works.
Not a stripped-down demo, and not the full vision either — an MVP is a real product, scoped tightly enough to reach customers fast and honestly enough to tell you the truth about whether it works.
What an MVP actually is
An MVP is a working product, not a prototype and not a pitch deck. The difference from a “full product” is scope, not quality: it does one thing — the core job customers hired the idea to do — and does that one thing reliably enough to be trusted with real use. Everything else waits.
What should be included
Start from the single outcome a customer needs, then work backward to the minimum set of screens, logic and integrations required to deliver it end to end — including the boring parts (accounts, payments if money changes hands, basic error handling) that make the product trustworthy rather than just demoable. A common mistake is building the impressive parts of an idea and skipping the plumbing; customers notice the plumbing first.
What should not be included
Secondary user roles, configuration options, “nice to have” integrations, and anything designed for a scale the product doesn’t have yet all belong on a deferred list, not in the MVP. These are cut points, not compromises — most of them will matter later, once the core product has proven itself and there’s real usage to prioritise against.
Product discovery and feature prioritisation
Discovery takes the output of idea validation — the customer, the problem, the business model — and turns it into a concrete feature list, ranked by how essential each item is to the core outcome versus how much it costs to build. We use this ranking to draw a firm line: everything above it ships in v1, everything below it is documented for later, not forgotten.
UX and architecture decisions that matter this early
UX at MVP stage is about removing friction from the one flow that matters, not covering every edge case. Architecture decisions, meanwhile, need to balance two things in tension: building fast enough to launch on a realistic timeline, and not making choices that make the product expensive to change once real usage tells you what to build next. We deliberately avoid both extremes — over-engineering for a scale that doesn’t exist yet, and cutting corners that create rework within months.
Development, launch and measurement
Build proceeds against the scoped list, with visible progress rather than a black box until “done.” Launch is planned as an event with a small, real audience, not a quiet release into nothing — and instrumented from day one, so usage (not guesses) tells you what customers actually do with the product.
Iteration: what happens after launch
The first weeks of real usage are the most valuable input the product will ever get. We review what customers actually did against what the deferred-feature list assumed they’d need, and re-prioritise from there — which is usually a very different list than the one drawn up before launch.
MVP scope decision framework
| Question | If yes | If no |
|---|---|---|
| Is this required to deliver the core outcome? | Include in MVP | Defer |
| Does the product break or mislead users without it? | Include in MVP | Defer |
| Is it needed only above a scale the product doesn’t have yet? | Defer | Reassess against the other rows |
What is an MVP?
An MVP (minimum viable product) is the smallest version of a product that lets real customers use it to get a real outcome — built specifically to test whether the product works for them, not to showcase every feature you eventually want.
How do you decide what’s in an MVP and what’s not?
We start from the single core outcome the product must deliver, then include only what’s required to deliver that outcome credibly and safely. Anything that improves the experience but isn’t required to prove the core value — extra settings, secondary user roles, non-essential integrations — is deferred, not deleted, and tracked for after launch.
How long does MVP development take?
It depends entirely on scope, which is exactly why scoping is done first rather than guessed at. A tightly-scoped MVP is usually measured in weeks; a broader one in a small number of months. The plan sets the timeline before the build starts.
Should an MVP be ’good enough’ or should it look polished?
Both, in the areas that matter. The core flow — the part customers actually use to get value — needs to work reliably and feel trustworthy. Polish on parts of the product customers won’t touch yet is effort spent in the wrong place.
What happens after the MVP launches?
Real usage becomes the input for what to build next — not opinion. Cobox measures how the MVP is actually used, feeds that back into prioritisation, and iterates from there. See Digital Product Development for the fuller lifecycle.