What Is an MVP and What Should It Include?

Start with the belief. Examples are a small retailer paying a monthly fee to track staff attendance from a phone, or a distributor switching from phone orders to a simple ordering link. Every scope decision follows from that sentence.

One founder tests whether anyone wants the product at all, and can survive a rough interface and concierge-style manual work behind the scenes. Another already holds preorders and is testing whether the workflow can be automated reliably, so its testers cannot tolerate rough edges when their daily work depends on it.

Write a falsifiable hypothesis down first. When a requested feature does not help answer it, the feature does not belong in version one, however useful it might be later.

Shallow kills more MVPs than small. A product with ten screens that each do one thing badly helps less than a product with three screens that carry a user through one real task.

Consider a furniture retailer testing whether customers will book in-home measurement visits online instead of phoning the showroom, where the whole MVP is three steps. The customer picks a date. The customer receives a confirmation. Staff see the booking on a shared calendar. A loyalty scheme, SMS reminders and a staff app are all sensible ideas, yet none is needed to learn whether customers 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 on your team quietly doing something by hand behind the screen? If not, it is unfinished however polished it looks.

Other feature requests fall into three groups. Some make the core journey more pleasant, some serve a second type of user, and some only matter after version one has proved itself. None belongs in the first release. Treat version one as disposable.

Apply a simple filter. For each proposed feature, ask whether removing it would stop the core journey from working, and if it still runs, defer the feature until users complete the journey.

Minimum describes scope, not safety. An MVP that stores customer names, phone numbers or payment details still needs secure passwords, backed-up data and a named person who is told when something breaks. Reuse proven boilerplate for sign-in and backups.

Support deserves the same attention. Even a tiny first release needs a way for a stuck user to reach someone, and an email address or a phone number is enough at this stage. Without a channel, the MVP fails quietly and nobody learns why people left, which wastes the whole test and the money already spent on building it.

Define success before launch. Write down what would count as encouraging, as a clear no and as ambiguous, for example the share of booking-page visitors who complete a booking within a few weeks.

These thresholds also set the next step. If the result is encouraging, build the next layer, and if it is a clear no, rethink the idea itself and not just the interface. An ambiguous result calls for a longer test. Deciding in advance stops you from reading any outcome as a reason to carry on regardless, which is how a weak idea absorbs months of budget.