What actually belongs in the MVP?

When teams talk about MVPs, the conversation often moves to features almost immediately. What do we need for launch? What will users expect? What will make this feel competitive? What will stakeholders want to see? What are we missing?

And before long, the list grows.

That growth is understandable. There’s pressure to make a good first impression. There’s fear that users will judge what’s missing. There’s a temptation to compare an early product against more mature competitors and feel like the MVP needs to close the gap.

But viability isn’t about matching the field. It’s about whether the product can do the thing it was created to do. At minimum, can the user reach the intended outcome? Can the product solve the core problem?

If yes, you have something viable enough to learn from. If no, you don’t.

That’s the standard I keep coming back to. Not “does this feel complete?”, not “does this have enough features?”, but: can the user accomplish the intended outcome without this?

If the answer is yes, the feature may not belong in the MVP.

The more you discuss an MVP in terms of features, the easier it becomes to justify almost anything. A feature can be useful without being necessary. That distinction matters.

Maybe notifications would improve the experience. Maybe reporting would help. Maybe collaboration tools would eventually become important. Maybe AI would make the product more powerful. Maybe additional controls would make the experience feel more complete.

All of those things can be true. But the question isn’t whether a feature has value. The question is whether the core outcome depends on it.

That’s a much harder standard, and a much more useful one. It forces the team to separate what’s essential from what’s simply desirable.

I’ve watched this play out on a system built to track procurement and contract spend. During discovery, there was a clear case for automatically pulling procurement and invoice data in from source systems: less manual entry, fewer errors, faster updates, a more complete product. Nobody disputed that it would make things better.

But it wasn’t necessary for the MVP’s core outcome.

The real goal of that first release was to give the team one place to see procurement activity, contract funding, invoices, and remaining spend clearly enough to actually manage the work. You could accomplish that with manual data entry. So the automation got treated as an after-MVP capability, not because it lacked value, but because the core outcome didn’t depend on it yet.

That’s the uncomfortable part of this kind of decision. It’s easy to cut a feature nobody wants. It’s harder to cut one everyone already agrees would make the product better. The MVP was never trying to prove whether the data could be automated. It was trying to prove whether bringing the right financial information into one place would give the team the visibility they were missing. Manual entry could prove that on its own. So that’s where we started.

From there, the conversation can become more practical: rank the remaining features by importance and level of effort, consider the timeline, look for opportunities where a high-value, low-effort addition makes sense without putting the core release at risk.

The point isn’t to remove everything possible. The point is to be deliberate about what earns its way in.

There’s another trap in MVP thinking: the assumption that if something is truly minimum, it has to feel rough.

I don’t think that’s true. There’s a balance.

An MVP can have polish and intentionality. It can feel credible. The experience can be clear, the design can be thoughtful, and the core workflow can feel complete. It just doesn’t need to be the final form. It doesn’t need every refinement. It doesn’t need to account for every edge case. It doesn’t need to be a masterpiece.

There’s a big difference between building something focused and building something sloppy.

The goal isn’t to lower the quality bar. The goal is to narrow the scope.

Teams also struggle with how much they should anticipate what comes next.

There’s a legitimate concern here. You don’t want to build an MVP so narrowly that it becomes unusable the moment the product grows. It makes sense to start with a solid enough foundation that you can build on it and scale later.

But there’s a danger in designing too far ahead. If the core idea hasn’t been validated yet, then every future-facing decision is still based on assumptions. You may learn that the product needs to change. You may discover that users care about a different problem. You may need to pivot the workflow, the audience, the value proposition, or the product itself.

The more you build around an unvalidated future, the more expensive that change becomes.

So the balance is to create something stable enough to extend, but flexible enough to change.

This is the part of MVP thinking that matters most.

Everything sounds good in your head. The value feels obvious to you. The need makes sense. The usefulness feels clear. But none of that is enough. The product has to make sense to the people it’s for.

An MVP gives you a way to test the assumptions behind the idea in the real world. Do users see the same value you see? Does the problem matter enough? Does the product help in the way you expected? Do people understand how to use it? What do they care about that you didn’t anticipate? What’s missing? What did you think mattered that turns out not to matter very much at all?

That’s where the real value of an MVP lives. Not in proving that your original idea was right, but in discovering what’s actually true.

An MVP can validate your assumptions. That’s useful. It can also challenge them. That’s useful too.

If users don’t respond the way you expected, but their feedback shows you what’s actually important, that’s not a wasted MVP. It did its job. You learned before investing more. You found the gap before the product became more complex. You discovered what needed to change while changing it was still relatively cheap.

That’s a win.

An MVP is successful when it reduces uncertainty. Sometimes the answer is “yes, keep going.” Sometimes it’s “not yet.” Sometimes it’s “not like this.”

All three can move the product forward.

That may be the most important distinction. Version 1.0 is usually the first reasonably complete expression of a product. An MVP has a different responsibility. It exists to help you decide whether that product deserves to become version 1.0 at all.

So resist the urge to make it everything the future product might become. Don’t build for every possible critique. Don’t measure it against mature products that have had years to evolve. Don’t add features just because they would make the product more impressive.

Build enough to solve the core problem. Build enough to create the intended outcome. Build enough to learn. Then pay attention.