For [user], when [trigger] occurs, the MVP helps them [action] so that [decision/outcome] can be assessed.
Urgent delivery tool
Seven-day MVP eligibility checklist
A rapid MVP is not a smaller promise about a large programme. It is a decision to prove one useful workflow under explicit conditions.
When to use this
Use this before asking a team to quote or commit to a one-week MVP. It is designed to reveal the missing condition early, not to force every brief into the same timetable.
- 01
One user, one decisive workflow
Name the user group, trigger, action, output and decision that the MVP must prove. If the brief has several audiences or unrelated workflows, separate the first release.
- 02
Explicit exclusions
List what is not in the release: roles, integrations, historic data, channels, reports, automation decisions and non-essential polish. An exclusion is a delivery control, not a weakness.
- 03
Authorised access on day one
Confirm code, environment, API, representative data, supplier contacts and necessary approvals. If access is pending, make the first phase an assessment or safe demonstrator rather than imply a production integration.
- 04
A named decision-maker
Identify who can resolve scope, risk and acceptance questions during the build. A delivery team cannot recover time lost to an unavailable approval path.
- 05
A testable acceptance condition
Write the result that will be checked: a user completes a workflow, an integration returns an agreed response, or a reviewer assesses an evaluation threshold and exception path.
- 06
A credible next decision
Agree who reviews the evidence at the end of the window and whether the next step is a pilot, iteration, wider delivery plan or a stop decision.
Working prompts to adapt
The release is ready to review when [observable test] is complete, including [known exception or human review].
Before work begins we have [access], [owner], [data/input], [budget/capacity] and [approval route].