A 90-day MVP plan is useful when it forces a team to choose a narrow, testable outcome. It is not a universal promise that any software product can launch in three months. Complexity, approvals, integration readiness and owner availability can change the schedule.
Define the minimum useful workflow rather than the minimum number of screens. A booking product needs an actual reservation and staff recovery process. A dashboard needs reliable data and a decision it supports. A login page plus attractive navigation does not establish either outcome.
Choose one complete journey
For a hypothetical maintenance-request product, the first release might let a customer submit a request, let staff assign it and show the customer a confirmed status. Payment, advanced scheduling and AI diagnosis can remain outside the initial scope.
List the exceptions that would make the journey unusable: missing details, duplicate submission, unavailable staff and a cancelled request. The MVP must handle the important exceptions, even when it defers less essential features.
Use the horizon to sequence evidence
| Planning window | Evidence to produce |
|---|---|
| Early discovery | Workflow agreement and risky dependency tests |
| Initial implementation | One working vertical slice |
| Iteration | Representative user feedback and complete exceptions |
| Release preparation | Migration, access, monitoring and recovery checks |
| Controlled launch | Measured use and a defined feedback decision |
These are stages, not fixed promises for each week. Adjust the timing to the actual dependencies.
Test the risky integration first
If the product depends on a payment, identity or inventory service, establish access and a realistic test before building the surrounding interface. A mock response is useful for development but must be labelled as a substitute.
Identify approval delays and account setup that sit outside the development team's control. Include a fallback only when it is acceptable to the business, not as an unnoticed reduction in scope.
Make trade-offs visible
Maintain a required-outcome list and a deferred list. When a new request enters, identify what it displaces or how it affects the budget. This is more honest than preserving the deadline by hiding missing behaviour.
Use demonstrations of the complete journey to prioritise. Feedback on colours and wording can matter, but it should not consume the entire review while record correctness and recovery remain unresolved.
Set a release standard
A releasable MVP needs server validation, permissions, durable data and understandable errors where the workflow requires them. It also needs a real hosting plan and operational ownership.
For a web product, decide whether pages are static, server-rendered or depend on runtime services. Verify the chosen deployment path rather than assuming a successful local build guarantees production behaviour.
Plan the first operating period
Choose who answers incidents, how users report problems and which evidence will guide the next investment. Measure completed tasks, exceptions and support effort. Do not label every unfinished requirement a future enhancement if it blocks the promised workflow.
A strong 90-day plan ends with a reviewable product and a decision about its next stage. The calendar is a constraint for choosing scope; it is not evidence that the scope is feasible. A short discovery phase may reveal that a smaller release or a longer horizon is the responsible choice.
Primary references
Related reading
Our web apps work can help turn these requirements into a practical implementation and review plan.