Name the riskiest assumption first
Before listing features, state what must be true for the product to work: a customer will pay, a supplier can fulfil a request, or a workflow saves enough time to justify a switch. Identify the evidence that would support or challenge that assumption. This keeps an MVP focused on learning rather than on matching a competitor's full feature list.
Choose one audience and one end-to-end journey that can test the assumption. Map what the user provides, what the system does, what happens when something fails and how the team will support the transaction.
Separate must-have behaviour from later ideas
A first release still needs a complete, dependable path for its core task. Authentication, payments, notifications or an admin view may be essential depending on the product; animations, advanced recommendations and secondary roles may wait. Rank each feature by whether it is required to test the assumption, not by how exciting it sounds in a pitch deck.
Write acceptance criteria in plain language and include empty, error and permission states. A clickable prototype can test comprehension before engineering begins. It cannot validate backend reliability or willingness to pay, so be explicit about what each test proves.
Estimate the whole product, not just the screens
A realistic MVP estimate considers design, frontend, backend, data, integrations, security, testing, deployment and the tools needed to support early users. The number of screens alone says little about the work: one screen may depend on a complex payment or location service, while several information pages may be straightforward.
Ask who owns the cloud accounts, app-store accounts, source code, analytics and future maintenance. Make scope changes visible and agree how they affect timing and cost. A staged plan can protect a budget while keeping the architecture understandable.
Plan what happens after the first release
Define the event that marks a successful test, how you will collect feedback and who will respond to defects. Track activation and completion of the core task rather than downloads alone. Set a review date to decide whether to improve, change direction or stop investing in the assumption.
DeshoStudio helps founders shape MVP strategy, product design and first-release builds. Bring the problem, intended audience and constraints to a discovery conversation before committing to a feature list.
An MVP is the smallest complete test of an important assumption, not a smaller version of every planned feature.
