Insights · Product · 3 June 2026
What belongs in an MVP, and what does not
MVP has come to mean whatever the speaker wants to build. The original meaning is more useful: the smallest thing that tests whether strangers want what you are making.
The pitch deck said MVP. The feature list said otherwise: accounts, profiles, chat, payments, referrals, an admin panel, and a dashboard, all marked launch critical. Eight months later there was still no launch, and no evidence anyone wanted the thing being polished.
MVP has drifted into meaning whatever the speaker wants to build. The original meaning is sharper and far more useful: the smallest thing that tests whether strangers want what you are making. Recovering that meaning is worth real money, so here is the working version we use on our own products and our clients' first versions.
One loop, done properly
A strong first version contains one loop: the single sequence of actions a user repeats, built well enough that repeating it feels good. For a journal app: write, save, return tomorrow. For a marketplace: list, find, transact. For an assistant: ask, get a useful answer, ask again.
Everything else in the product either serves that loop or waits. The test for any feature is brutally simple: if the loop works without it, it waits. Settings screens, profiles, six sign in options, admin dashboards and dark mode have all sunk schedules for products that had not yet proven anyone wanted the loop itself.
What minimum must never mean
Minimum does not mean broken, and the word viable is carrying more weight than people give it. Three things stay in every first version, whatever else is cut.
The loop itself stays at full quality, because the loop is the thing being tested, and a bad version of it tests nothing except users' patience. Measurement stays, because a launch you cannot read is a firework, not an experiment: a handful of events answering "did they return" is enough, a full analytics suite is not required. And a way to reach you stays, because early complaints are the most valuable data the product will ever collect, and they arrive exactly once.
Security and data ownership also stay. Cutting corners there does not make a build minimal. It makes it a liability with a login page.
Scoping one honestly, in four moves
Write the loop as one sentence, and if it will not fit in one sentence, the product is not understood yet. List every feature you have imagined, then move everything except the loop to a version two list you keep in the open, so postponement stays a plan instead of becoming an argument. Set the success measure before launch, a number, not a feeling: forty percent of week one users return in week two, or it did not work. Then ship to a small group first, because fifty honest users teach more than five thousand silent installs.
The part nobody writes down
The hard part of an MVP is not the building, it is the restraint, and restraint has a compounding payoff that deserves to be said out loud. A team that ships the loop in six weeks gets its first real learning in week seven. The team that ships everything in eight months gets its first learning in month nine, and most of what it built was guessed wrong, because it was all built before anyone could learn anything.
The point of a first version is not to be small. Small is a side effect. The point is to make the next decision with evidence instead of hope, as early as the calendar allows.