Most MVPs fail because they try to look finished. Screens get added because a competitor has them, or because an internal wishlist grew during workshops. The product launches late, confused, and still does not answer the only question that matters: will the customer use this to get something done?
An MVP is not a smaller version of the final product. It is the smallest thing that lets a real customer complete a real job, so you can learn what should be built next.
Start with the job, not the feature list
Who is the customer? What are they trying to do today, with or without you? What makes that job slow, risky or incomplete? The first release should help them finish that job more clearly than the alternative — even if the alternative is a spreadsheet, a WhatsApp thread or a phone call.
Everything else is a candidate for later: extra roles, extra dashboards, extra settings, extra polish that does not change whether the job gets done.
What can wait
Admin tools that only the team will use. Edge-case workflows that almost nobody hits in the first month. Customisation that exists to avoid making a decision. Multi-sided features before one side of the marketplace actually works.
Waiting is not the same as ignoring. It is a sequence. You ship the path a customer has to take, watch where they stall, then build the next piece from evidence instead of opinion.
How we decide
We ask what must be true for a customer to trust the product enough to complete the first important action. That usually includes the core flow, the information they need to decide, and a way to recover if something goes wrong.
If a feature does not change that first action, it does not belong in the first release. It belongs in the next conversation, after you have seen what people actually do.