What Is an MVP and What Should It Include?

Before deciding what goes into an MVP, it helps to be precise about what it is for. An MVP exists to test a specific belief about your business, such as 'a small retailer will pay a monthly fee to track staff attendance from a phone' or 'a distributor will switch from phone orders to a simple ordering link.' Everything else about scope follows from that one sentence.

This matters because two founders can both say they are building an MVP and mean very different things. One is testing whether anyone wants the product at all. Another already has paying interest and is testing whether their specific workflow can be automated reliably. The first can survive a rough interface and manual steps behind the scenes. The second usually cannot, because the people testing it are already relying on the current process to run their business.

Writing the hypothesis down before scoping anything else keeps later feature debates short. When a requested feature does not help answer the hypothesis, it does not belong in version one, regardless of how useful it might be later.

The most common way MVPs go wrong is not that they are too small — it is that they are too shallow. A product with ten screens that each do one thing badly is less useful than a product with three screens that let a user finish one real task from start to finish.

Consider a mid-sized furniture retailer that wants to test whether customers will book in-home measurement visits online instead of calling the showroom. The complete path is: customer picks a date, customer receives confirmation, staff sees the booking on a calendar. That is the entire MVP. A loyalty programme, SMS reminders, and a staff mobile app are all reasonable ideas — none of them are required to test whether customers will book online at all.

The test for 'complete' is simple: can a real customer, unaided, start the journey and reach a genuine outcome without anyone in your team quietly doing something manually behind the scenes to make it work? If the answer is no, the journey is not complete yet, even if it looks finished on screen.

Once the core journey is defined, most other feature requests fall into one of three groups: things that make the core journey more pleasant, things that serve a second type of user, and things that only matter after the first version has already proven itself. None of these three groups belongs in the first release.

A practical filter is to ask, for each proposed feature, whether removing it would stop the core journey from working. If the journey still works without it, the feature is not essential — it may still be worth building, but it is worth building after you have evidence the core journey is used, not before.

'Minimum' describes scope, not quality or safety. An MVP that stores customer names, phone numbers, or payment details still needs the basics done properly: passwords or access handled securely, data backed up, and a clear owner who is told when something breaks. These are not extra features to add later — they are part of what makes the smallest version usable at all.

The same applies to support. Even a very small first release needs a way for a confused or stuck user to reach someone — an email address or a phone number is enough at this stage. Shipping a product with no way to report a problem is a common cause of an MVP quietly failing without anyone ever finding out why.

An MVP without a defined learning goal is just a small piece of unfinished software. Before it goes live, write down what result would count as encouraging, what would count as a clear no, and what would be genuinely ambiguous. For the furniture retailer example, that might be: 'encouraging' means at least a meaningful share of visitors who reach the booking page complete a booking; 'a clear no' means almost nobody who reaches the page books at all, even after a few weeks of traffic.

This step also sets the next-step criteria: what happens if the result is encouraging (build the next layer), what happens if it is a clear no (stop or rethink the idea, not just the interface), and what happens if it is ambiguous (extend the test or fix a specific friction point before deciding). Deciding this in advance protects you from reading whatever result you get as a reason to keep going regardless.