Building a focused MVP: what to include and what to leave out
An MVP is a test of your riskiest assumption, not a smaller version of the full product.
Founders often describe their MVP as “the full product, but simpler”. That framing makes it hard to cut anything, because every feature seems to belong in the full product. A more useful definition: the MVP is the smallest product that tests whether your most important assumption is true.
Find the riskiest assumption
Is the risk that people do not have the problem, that they will not pay to solve it, or that your solution does not work well enough? Each answer leads to a different first version. Build what tests the biggest risk first.
Keep what the core journey needs
- Sign-up and a way to reach the core value quickly.
- The one workflow that delivers that value.
- A way to charge, if willingness to pay is part of the test.
- Basic analytics to see whether people return.
Defer the rest deliberately
Advanced settings, multiple integrations, detailed reporting and extensive admin tools can usually wait. Write them down in a “later” list so they are not forgotten, and revisit the list after you have real usage data.
Do not cut the foundations
Some things are cheap to get right early and expensive to fix later: account and tenant separation, secure authentication, and a sensible data model. A focused MVP still needs these done properly.