The smallest useful version is harder to define than it looks

The phrase has been hollowed out

"Minimum viable product" got bent out of shape over the last decade. The phrase started as a discipline — release the smallest version that lets you learn whether the idea is real — and ended up as a marketing label. Half of the things called MVPs are actually under-resourced platforms. The other half are half-built demos pretending to be products. The discipline got lost between the two.

The version of the phrase worth keeping is "the smallest useful version." Smallest, because most teams ship too much. Useful, because most teams ship too little. The word in the middle is the one that gets dropped most often.

Useful is the missing word

A demo can be small. A platform can be useful. The interesting category is the version that is small enough to ship in weeks and useful enough that someone will actually use it. That intersection is where good early products live, and it is harder to define than it sounds.

The test we apply is simple. If only one person uses this V1, and they use it for one workflow, and they get a real outcome they could not get before, did the build justify itself? If the answer is yes, the scope is right. If the answer requires "well, if a hundred users come and three features get added and this integration is built," the scope is wrong.

Useful is also not the same as impressive. Most useful V1s are not demoable in a way that flatters the team. They look unfinished because they are. The screens are direct. The features are sparse. The polish is concentrated only in the parts the user actually touches. The trade is intentional. Polish everywhere is the most expensive form of waste at this stage.

The one workflow, not the platform

The most common scope failure we see is teams building a platform instead of a workflow. A platform is a set of capabilities. A workflow is a sequence a real person follows to get a real outcome. Platforms are infinite. Workflows are bounded. V1 should be a workflow.

The discipline is to pick the single workflow that creates the most value, build it end to end, and refuse to build anything else until that workflow is live and working. Not the front half of three workflows. Not the back half of two. The whole of one.

The reason this matters is that workflows are testable in production in a way that capability sets are not. If the workflow works for the first user, the scope of V2 reveals itself. If it does not, no amount of additional capability would have saved it.

The first list of things to cut

Every V1 has a list of features that look essential and are not. The list is remarkably consistent across projects. Admin roles and permissions beyond the simplest two. Multi-tenant architecture in a product that has one tenant. Settings screens for preferences nobody has yet expressed. Notification systems for events that have not happened yet. Customisation options for a product whose default no one has tried. Integrations the team thinks users will want before any user has asked.

All of these will eventually be needed if the product succeeds. None of them are needed in the first useful version. The discipline is to identify them, name them as deferred, and protect the scope from them.

The list of things that stay in, even when scope is tight

There is a counter-list, and it is the part where most under-scoped V1s fail. The boring infrastructure stays. Authentication. Reasonable error handling. A basic audit log for actions that change data. A small set of metrics that lets the team see whether the product is being used. A backup of the data, even if it is manual. A way to roll back if a release breaks something.

None of these are exciting. All of them are the difference between a V1 that holds up to a real user and a V1 that fails the first time something goes wrong. The temptation is to defer them all in the name of shipping faster. The math does not work. An hour of authentication work in week one is worth a week of incident response in month three.

The shape of a good V1

Most V1s we ship for clients look the same in the end. One core workflow, executed end-to-end. Two or three screens, often fewer than the team expected. A small set of admin or operational views for the team running the product. The infrastructure boring enough that the team forgets it is there. A documentation note that names what was intentionally left out. And a roadmap of what V2 looks like if the workflow gets used.

The shape is unimpressive on a slide. It is reliable in production. That trade is the discipline.

Three questions before scope is locked

We use a short test before any V1 scope is signed off, and they are the same three questions every time.

If the product launches tomorrow with only this list, does the first user get a real outcome? Not a partial outcome. Not a promise of an outcome. The outcome they came for.

If the project runs out of time at the halfway mark, do we still have something shippable? If the answer is no, the scope is too entangled. The features need to be re-sequenced so the most useful ones land first.

If the workflow gets used and we have to ship V2, do we know what V2 should be? The honest answer is sometimes "no, and we will know after V1 ships." That is a fine answer. It is the answer that signals V1 is a learning artefact rather than a final form, and it is usually the right place to be.

The last point is the one teams skip most often. V1 is not the product. It is the version of the product that lets the team learn what the product should be. Everything that interferes with that learning — extra features, premature polish, capability the user did not ask for — should be cut, and the version that ships should be small enough to be slightly embarrassing.

Embarrassing, because the team can see all the things it does not yet do. Embarrassing is fine. Useful is the bar. The two are not the same.