How to Plan an MVP Before Development Starts

Define one useful customer journey, test the riskiest assumptions and agree what a first release must prove.

An MVP needs a clear learning objective. A smaller version of a large feature list can still leave the most important question unanswered: will the intended user complete the task and find the outcome useful? Start by defining that task before discussing screens or a technology stack.

Choose one user and one outcome. For a booking product, the first journey might be a customer finding an available appointment and receiving confirmation. Provider onboarding, cancellation and support still matter, but the team should distinguish what must work in the first release from what can be handled through a documented manual process.

Write down the assumptions. Perhaps users will share a particular document, staff can respond within a certain window or a partner system exposes the data you need. Rank assumptions by the cost of being wrong. The GOV.UK discovery guidance offers a useful approach: understand the problem, its costs and its constraints before committing to a solution.

Use a prototype for questions about the experience. Show representative users a clickable flow and ask them to complete a task without coaching. Watch where they hesitate and what they misunderstand. A prototype can help test comprehension; it does not establish that the production system is secure, reliable or capable of handling real demand.

Use a technical trial for questions about feasibility. If the product depends on importing legacy records or integrating with a partner API, test that dependency early. Record the limitations and failure cases. A beautifully designed interface cannot resolve a missing data source or an integration the provider does not support.

Define a complete first journey. Specify the starting state, successful outcome and common exceptions. For the booking example, include an appointment becoming unavailable, a failed confirmation and an accidental duplicate request. Agree what the user sees and how the team recovers. Small scope should still be coherent scope.

Agree acceptance and learning criteria separately. Acceptance criteria describe whether the release works as specified. Learning criteria describe what you want to discover after release, such as where users abandon the journey or whether they return. Select measures that match the question; do not treat a large sign-up count as proof that users achieved their goal.

Plan the first weeks after launch. Assign someone to review feedback, respond to problems and decide which changes come next. Reserve capacity for fixes and avoid promising a full roadmap before observing real use. Our SaaS and product development service can start with that focused scope. Bring your intended user, core task and biggest uncertainty to the first conversation.