MVP & Roadmap Planning
Patterns for defining what to build first and in what order.
Core Principle
"Build the smallest thing that proves value."
An MVP is not a half-built product—it's a complete vertical slice that validates assumptions.
MoSCoW Prioritization
| Priority |
Definition |
Criteria |
| Must Have |
System doesn't function without |
Core journey incomplete, no workarounds |
| Should Have |
Important but not blocking |
Workarounds exist, high value |
| Visible as Placeholder |
UI ships visible but non-functional at launch; wired up in a later phase |
Surface needed for UX coherence/nav completeness; functionality deferred |
| Could Have |
Nice to have |
Enhances experience, low priority |
| Won't Have |
Explicitly out of scope |
Prevents scope creep, document for later |
Visible-as-Placeholder Tier — When To Use
Standard MoSCoW leaves a gap: features that need to be visible at launch but not functional yet. Naming this tier explicitly makes the app feel coherent without over-promising.
Use Visible-as-Placeholder (not Could-have) when:
- Removing the surface would leave a hole in nav, settings, or a flow users will notice
- A linked feature elsewhere references this surface (deep links, empty-state CTAs, dashboard tiles)
- The functional version is planned for a known later phase
Use Could-have instead when the feature's absence is invisible or there is no committed plan to ship it.
See reference.md § Visible-as-Placeholder for a worked marketplace example with five surfaces.
MVP Scoping Checklist
Phased Delivery Pattern
Each phase should:
- Build on previous phase (not parallel development)
- Be independently deployable
- Have clear success criteria
- Include tests for new functionality
Dependency Ordering
Order features by:
| Factor |
Question |
| Technical |
What must exist first? |
| Value |
What provides most value soonest? |
| Risk |
What validates riskiest assumptions? |
| Learning |
What teaches us most about the domain? |
Roadmap Template
| Phase |
Features |
Success Criteria |
Dependencies |
| MVP |
[Must-haves] |
[Measurable outcomes] |
None |
| Phase 2 |
[Should-haves] |
[Measurable outcomes] |
MVP complete |
| Phase 3 |
[Could-haves] |
[Measurable outcomes] |
Phase 2 complete |
Extensible Algorithm Design
Design algorithms for evolution using stable interfaces. MVP delivers value immediately while building ground truth for future ML phases. Evolution path: Deterministic (MVP) → Statistical (Phase 2) → ML/embeddings (Phase 3) → LLM-powered (Phase 4). Switch implementations via dependency injection against a stable Protocol interface; MVP uses zero ML infrastructure.
See reference.md § Extensible Algorithm Design for the interface pattern, key principles, and workstream-split sizing. See examples.md for sample roadmaps.
