The minimum viable product keeps becoming a full product. How do we narrow it?
Unbounded first releaseDefine the smallest release that can test or deliver the intended value safely. Separate what is necessary for that result from desirable completeness and future convenience.
What to do now
- State the first release's purpose
- Identify indispensable user journeys
- Remove features that do not support that purpose
- Agree explicit later-release candidates
When to escalate
Escalate when
The first release cannot test or deliver its stated purpose within constraints.
Who decides
The scope owner and authorized sponsor
Example
An enrollment release includes registration and confirmation but postpones advanced marketing dashboards.
Mistake to avoid
Defining minimum as everything every stakeholder initially requested.
Prevent a repeat
Review ambiguous requirements and unresolved acceptance conditions before the affected work begins.
Suggested ApprovedFlow setup
- Projects
- Tasks
- Documents
- Approvals
Keep the agreed scope and acceptance evidence with the project; record any proposed change and its decision separately. See the platform
Related cases
- How can we manage scope when users discover needs during delivery?Evolving requirements
- Our project overlaps with another team's system. Where should the boundary be?Unclear scope interface
- When should we stop building and start measuring results?Unbounded output production
- A release introduces a serious defect. What should the team do first?Release incident response