A 30-day MVP is credible only when the scope, starting conditions and decision process fit that window. It is not a promise that every product idea can reach production in a month. Define the smallest release that answers a real business question for a named user group. Then agree what working means, who accepts it and which risks can stop the schedule.
Start with one outcome and one journey
Take a hypothetical internal request portal. The question is whether staff can submit a request and receive a visible decision without chasing email. The journey is submit, review, approve or decline, and inspect status. That can provide a useful boundary for discovery. A marketplace, billing platform, mobile application and broad analytics suite are different outcomes, even if someone calls them essential future features.
Write the outcome in a sentence that a buyer and engineer interpret the same way. Name the first users, the expected volume and the data they handle. Choose one success measure, such as completion without support, and collect a baseline where possible. Adoption and commercial demand remain hypotheses to test; shipping the interface does not prove them.
Agree the scope as observable behavior
| Included behavior | Example acceptance evidence |
|---|---|
| Submit a valid request | Required fields are checked; successful submission has a visible reference |
| Review within the correct Organization | Authorized reviewers see allowed requests; cross-Organization access is rejected |
| Approve or decline | Only permitted roles can decide; the stored status matches the displayed result |
| Recover from a failed submission | The user sees a useful error and can continue without losing their input |
| Operate and hand over | A named owner can deploy, inspect failures and follow the recovery instructions |
Agree realistic accessibility, security and performance expectations with the workflow. These are part of making the included journey usable. Cut feature breadth when time is tight. Do not make authentication, permission checks or essential error handling optional to preserve a launch date. Identify which tests run automatically and which acceptance checks need a business reviewer.
Make exclusions explicit
- No native mobile app unless it is the selected first surface; agree the required browser and device support.
- No historical data migration beyond an agreed sample or import format.
- No billing, advanced reporting, custom role builder or additional Organization workflows unless essential to this journey.
- No unconfirmed third-party integration, production access or external approval assumed to arrive on time.
Exclusions prevent two parties from buying different products with the same words. Record them beside the included scope, not in a forgotten meeting note. When a new requirement arrives, compare it with the release objective. Exchange it for work of comparable effort, defer it, or change the time and budget with an explicit decision.
Check readiness before starting the clock
Before agreeing a start date, confirm a decision-maker, representative data, design direction, required system access and the acceptance owner. Define whether 30 days means calendar days or working days in the proposal. Agree response times for reviews and what happens if a dependency stalls. An unresolved payment-provider approval or unavailable ERP administrator is a schedule risk, not spare engineering capacity.
| Planning checkpoint | Decision or evidence |
|---|---|
| Opening week | Confirm the journey, prototype, access and acceptance examples |
| Second week | Demonstrate the complete thin workflow using representative data |
| Third week | Test permissions, failure paths and business acceptance cases |
| Final period | Resolve release blockers, document operation and decide on rollout |
This sequence is illustrative, not a delivery guarantee. The work overlaps, and the calendar depends on the agreed scope and readiness. A weekly demonstration should expose decisions early. If the complete journey is still blocked halfway through, revise the release boundary instead of using a polished screen as evidence that the workflow is nearly finished.
Specify what the buyer receives
Acceptance includes source access, deployment configuration, test evidence, known limitations and an operating guide. Name who owns hosting, credentials and support after delivery. Distinguish defects against agreed behavior from new feature requests. Agree the support period and response expectations in the proposal rather than assuming an unlimited maintenance obligation.
For product engineering, bring the user journey and the decision you want the first release to enable. If unresolved architecture or integration questions dominate the scope, start with software architecture. The engagement comparison explains when a bounded project fits and when an ongoing team is more useful.