Your MVP Probably Has Too Many Must-Haves

Before deciding what belongs in an MVP, decide what the business needs to achieve or learn next.

When teams define an MVP, the conversation often starts with a list of features. Authentication, payments, notifications, analytics, user roles, integrations, an admin dashboard. The list grows quickly, and eventually someone has to decide which items are nice-to-haves and which ones are must-haves.

The problem is that we tend to make that distinction by imagining the product we eventually want to operate. A mature marketplace may need a sophisticated reputation system. A financial product may need extensive reporting. A B2B platform may eventually need role-based permissions, integrations, audit logs, and administrative tooling.

All of those things can be important without being necessary today. Whether something is a must-have depends on what the business is trying to accomplish at that particular stage.

This is why I think there is a useful question missing from many MVP discussions:

Must-have for what?

If we can't answer that clearly, we're probably not ready to decide what belongs in the product.

Start with the outcome, not the feature list

Imagine a startup building a two-sided marketplace. It isn't difficult to come up with a credible list of capabilities the eventual product might need: provider profiles, verification, search, matching, messaging, payments, dispute resolution, ratings, notifications, automated payouts, and an operations dashboard.

The mistake isn't putting those capabilities on a roadmap. The mistake is assuming they belong in the first version simply because they belong in the long-term vision.

Suppose the biggest unanswered question for this business is whether it can consistently connect customers with suitable providers and produce a transaction that both sides consider successful. If that's the question, the first product only needs enough capability to produce those transactions and allow the team to learn from them.

Customers need some way to communicate what they're looking for, and there needs to be enough supply to serve them. But matching might initially be handled by an operator rather than an algorithm. Communication could happen through WhatsApp or email instead of an in-app messaging system. Provider verification could be manual, and some operational workflows could live in a spreadsheet.

None of those choices would make sense at scale, but scale isn't the problem we're trying to solve yet. At this stage, we're trying to understand whether the transaction works at all.

Once it does, the questions change. We may want to know whether customers will pay, whether providers respond quickly enough, whether transactions are completed consistently, whether customers return, or where the operation begins to break as volume increases.

Each question may require a different version of the product. That's why the definition of a must-have shouldn't be fixed. It should change as the business moves from one meaningful outcome to the next.

What happens if we don't build it?

One practical way to challenge scope is to take every proposed must-have and ask what happens if it isn't built now.

Sometimes the answer makes the decision fairly easy. Without a particular capability, customers may be unable to complete the core workflow. The product may not be safe to use with real customer data, or the team may be unable to test the assumption it set out to validate. Those are good reasons to include something in the current scope.

Other answers deserve more scrutiny. Perhaps someone on the team would have to perform the task manually for the first 20 customers. Maybe the team would have to use a spreadsheet temporarily, or the experience would be less polished than everyone would like. Sometimes the justification is simply that everyone agrees the product will eventually need the feature.

Those are real costs, but they are different from saying the next meaningful outcome cannot be achieved without the feature.

This distinction matters because every feature built into an early product does more than consume development time. It embeds assumptions about how the business is supposed to work. A workflow assumes certain steps. A permission model assumes certain roles. An automation assumes that a process happens predictably enough to automate. A dashboard assumes we already know which information matters.

When those assumptions haven't been tested, building more can mean committing to more before we know enough.

Manual work can be useful

Teams often treat manual work as evidence that an MVP is unfinished. If a person still has to approve something, match two parties, review an exception, move information between systems, or intervene in a workflow, the instinct is to automate that step before putting the product in front of customers.

There are certainly processes that need automation from the beginning, particularly when manual intervention would create unacceptable security, compliance, reliability, or customer-experience risks. But there are also situations where doing something manually for a while is exactly what helps us understand how it should eventually work.

If someone on the team handles the first 20 customer requests, for example, they see the exceptions that weren't anticipated in the original workflow. They hear the questions customers actually ask. They discover which information is missing and which information nobody uses. They see where transactions fail and what it takes to recover them.

If that process had been automated from the beginning, those assumptions would already have been encoded into software.

Manual work, in that context, isn't simply unfinished engineering. It can be a way of learning enough about a process to automate the right version of it later.

The goal, of course, isn't to keep the business manual. The goal is to avoid investing in automation before we understand what we're automating.

A complete product and a useful MVP are not the same thing

Part of the difficulty is psychological. Completeness feels like progress.

A product with polished onboarding, notifications, analytics, multiple user roles, settings, and an administrative interface looks more credible than one built around a narrow workflow with some manual operations behind the scenes. Teams can see what they've built, which makes feature completion an appealing way to measure progress.

But an early-stage business can have a surprisingly complete product and still not know whether customers care enough about the problem, whether they'll change their behavior to use the solution, whether they'll pay, or whether they'll return.

A much simpler product may already be answering those questions.

This is why I don't find "percentage complete" particularly useful when thinking about an MVP. Complete relative to what? If we're measuring against the product described in a roadmap, perhaps we're 80% finished. If we're measuring how much uncertainty we've removed from the business, the answer could be very different.

An MVP is better understood as the product required to move the business from its current state of uncertainty to the next useful piece of evidence. Sometimes that evidence is demand. Sometimes it's willingness to pay, repeat usage, a successful transaction, or a measurable operational improvement.

The important thing is to define that outcome before defining the scope.

Sometimes the minimum product is barely a product

There is another implication that can be uncomfortable for teams that are eager to build: not every unanswered question requires software.

If we don't know whether customers care enough about a problem, conversations with customers may teach us more than another feature. If we don't know whether they'll pay, testing an offer may be more useful than building a payment system. If we don't understand an operational workflow, observing it may be more valuable than automating it. If we don't know whether two sides of a marketplace can be matched successfully, manually matching them may provide the evidence we need.

This doesn't mean prototypes, spreadsheets, or manual processes are substitutes for a real product indefinitely. It means software should be built when software is the appropriate mechanism for reaching the next meaningful outcome.

That changes the objective. We're no longer trying to build the smallest product because small is inherently better. We're trying to make the smallest reasonable commitment of time, capital, and complexity required to learn enough to make the next decision.

Let the scope grow with the evidence

A validation-first approach can sometimes be mistaken for an argument in favor of permanently simple products. It isn't.

Successful products become sophisticated because the problems they solve eventually require sophistication. The difference is in how they get there.

Once we know customers want the solution, it makes sense to invest in improving the experience. Once we know they'll pay, we can justify better transaction infrastructure. Once we've seen a manual process work consistently, we have a much stronger basis for automating it. Once we've encountered real exceptions, we can design the system around the exceptions that actually happen rather than the ones we imagined might happen.

Complexity introduced this way has evidence behind it.

This is also why the scope of an MVP shouldn't be determined by asking how closely it resembles the final product. We don't know exactly what the final product should be yet. That's one of the things the MVP is supposed to help us discover.

The better sequence is to decide what meaningful outcome the business needs next, identify what must be true to reach it, and build only what is necessary to make that outcome possible. Then we use what happens to decide what deserves to be built next.

The next time a feature is described as a must-have, then, the most useful response may not be to argue for or against it. It may simply be to finish the sentence: must-have for what?

If the answer is clear, deciding what belongs in the MVP becomes much easier. Some capabilities will genuinely be necessary now. Others may be important later. And some may turn out to solve problems that the business never actually encounters.

An MVP doesn't need everything the final product may eventually require. It needs what the next meaningful outcome cannot happen without.