An MVP is a learning instrument
An MVP should test a meaningful product assumption with the smallest coherent experience. It is not a synonym for an unfinished product or a permission to ignore reliability. The question is which uncertainty matters enough to resolve before investing in a broader build.
Start by defining a target user, the job they need to complete, and evidence that would change the next decision. A focused product discovery process helps separate the core journey from nice-to-have features and internal preferences.
Cut breadth, preserve the path
A focused first version can have fewer workflows, integrations, roles, or reporting views. It should still have clear ownership of its data, understandable boundaries, basic security, and a deployment process the team can repeat.
Avoid premature infrastructure for hypothetical scale, but document deliberate trade-offs. A small modular boundary around the riskiest domain can preserve options without creating an elaborate architecture before the product has users.
Validate the whole journey
A prototype can test comprehension and usability; a working MVP can test behavior in context. Decide what each method can and cannot tell you. Make it possible to observe where users succeed, where they pause, and whether the product solves the intended problem.
Operational basics matter too: error reporting, backups where appropriate, access controls, and a way to respond when something breaks. These controls reduce the cost of learning from a real product.
Plan the next decision
Before launch, agree how the team will interpret the evidence and who can approve a change in direction. A good MVP creates a clear next question. Its architecture and scope should make it possible to answer that question without forcing the team to rebuild everything.