MVPs need atomic-unit tests

Most MVP debates start in the wrong place. The team opens a roadmap, lists everything a first customer might expect, then argues about which features can be delayed. Authentication stays because it feels basic. Dashboards stay because investors will ask for them. Notifications stay because engagement needs a nudge. Sharing stays because growth needs a story. By the end, the MVP is not a minimum viable product. It is a small version of the product the team hopes to become.

The better starting point is colder and more useful: what is the one product object this MVP must make more valuable?

That is the thesis. MVPs need atomic-unit tests, not feature bundles. A feature bundle asks, “What can users do?” An atomic-unit test asks, “What noun does the product create, improve, circulate, or protect?” Fred Wilson’s atomic-unit framing is helpful because it separates features as verbs from product objects as nouns, then forces the team to identify the fundamental unit of the service before arguing about functionality: What’s The Atomic Unit Of Your Product/Service?.

If the team cannot name that unit, it cannot govern scope. It can only negotiate taste.

Features are verbs, but products need nouns

Features sound concrete because they are easy to demo. Upload, invite, comment, filter, export, approve, schedule, tag, summarize. They create movement in a planning meeting. They also hide the hardest question: movement around what?

A project management MVP might be tempted to ship tasks, comments, files, timelines, notifications, and reports. Those are not all equal. If the product’s atomic unit is the task, the MVP must make task creation, ownership, status, and completion unmistakably better. If the atomic unit is the project brief, then task lists may be secondary. If the atomic unit is the decision, then comments and approvals matter only when they improve the life of that decision.

The distinction is not semantic. It changes what counts as scope. A feature that strengthens the atomic unit belongs in the first conversation. A feature that creates a second product object probably belongs in a later bet. This is the same discipline behind saying that product prioritization cannot let the roadmap hold everything. The issue is not that teams lack ideas. The issue is that they lack a unit that makes ideas comparable.

Without the noun, every verb looks reasonable. With the noun, many verbs become obviously premature.

What is the atomic unit of this MVP?

Use this question before estimating work. Put it at the top of the scope review, not at the end when the team is already defending tickets.

Write one sentence: “The MVP exists to make one [object] more valuable for one [user] in one [situation].”

Examples:

• A founder building a hiring workflow might write: “The MVP exists to make one candidate profile more valuable for one hiring manager during shortlisting.”
• A team building a learning product might write: “The MVP exists to make one practice attempt more valuable for one learner after a mistake.”
• A B2B operations tool might write: “The MVP exists to make one exception case more valuable for one operations lead before escalation.”

The sentence should feel almost too narrow. That is the point. It prevents the MVP from pretending to test a market while actually testing a bundle of assumptions. If the unit is a candidate profile, the first release does not need every recruiting workflow. It needs enough creation, enrichment, review, and reuse around the candidate profile to prove that this object deserves to exist.

This also keeps discovery honest. Interviews often produce feature requests because users describe gaps in the language of current tools. The product team must translate those verbs back into objects. When a customer asks for alerts, the question is not “Should we build alerts?” It is “Which object becomes more valuable if the user is alerted at the right moment?” That is close to the discipline in discovery interviews needing decision logs: capture what the team decided from the evidence, not just what someone said.

The four-loop atomic-unit test

Once the object is named, run four loops. Keep them visible in the scope review.

First, the creation loop. Can the right user create or capture the object with tolerable effort? This is not the same as having a beautiful editor. It means the object can come into existence with enough structure to matter. For a candidate profile, that might be name, role fit, source, notes, and current stage. For a practice attempt, it might be prompt, response, mistake, and feedback.

Second, the consumption loop. Can someone get value from the object without a founder narrating the demo? A task must tell someone what to do next. A decision record must explain the option chosen and the reason. An exception case must show why it needs attention. If the object needs a call with the product team to be understood, the MVP is not testing product value yet.

Third, the circulation loop. Can the object travel to the next useful context? This does not always mean social sharing. In B2B products, circulation might mean assignment, reuse in a meeting, export to an existing system, or reference during review. The atomic unit becomes stronger when it moves through the work instead of staying trapped inside the prototype.

Fourth, the learning loop. Can the team see whether the object became more valuable? This can be qualitative at first, but it must be inspectable. Did the hiring manager return to the candidate profile before the next interview? Did the learner repeat the practice attempt? Did the operations lead resolve the exception faster or with less confusion? If there is no learning loop, the MVP becomes a delivery milestone rather than a product test.

These loops create a practical scope filter. A feature belongs in the MVP only if it helps create, consume, circulate, or learn from the atomic unit. If it does none of those, it is probably comfort scope.

Where MVPs get bloated

Bloat usually enters through respectable doors. One door is persona multiplication. The team says the MVP serves the buyer, the admin, the end user, the analyst, and the executive. That may be true for the mature product, but it is usually fatal for the first test. Each persona brings its own object, and each object brings its own feature set.

Another door is reporting. Teams add dashboards before they have a stable unit worth reporting on. A dashboard around weak objects creates the feeling of product completeness, but it rarely creates value. First make the unit useful. Then report on how it behaves.

A third door is platform thinking. Teams add settings, permissions, integrations, and extensibility because they want the architecture to survive success. Some of that work may be necessary, especially in regulated or enterprise contexts. But the atomic-unit test still applies. Which part is required to protect or move the core object now, and which part is speculative platform insurance?

Finally, bloat enters through optimism. Teams keep a feature because it might unlock an unknown use case. That is a bet, not a requirement. If you keep it, write the bet down with a stop condition. Otherwise it will become invisible scope. That is why product bets need kill criteria, not optimism applies directly to MVP work.

Use the unit to cut scope

A useful MVP scope review is not a voting session. It is a test of fit between features and the atomic unit.

Start with a wall or document split into five columns: object, create, consume, circulate, learn. Put the named atomic unit in the first column. Then place every proposed feature under the loop it strengthens. If a feature fits nowhere, cut it. If a feature requires naming a second object, move it to a later bet. If two features strengthen the same loop, keep the simpler one unless the risk being tested demands the richer one.

The ritual should end with three outputs. One, a single atomic-unit sentence. Two, a first-release loop map. Three, a bloat list that is explicitly deferred, not silently forgotten. This makes future disagreement easier because the team can ask whether new pressure changes the unit or only adds another verb.

Before the next scope review, write the one object the product must make more valuable. If that sentence is hard to write, do not compensate by adding features. Stay with the noun until the product has a center.