FOUNDER MVP PLANNING
Plan the first useful product before more building begins
A strong MVP is not the smallest collection of features. It is the smallest useful product boundary that can be explained, reviewed, implemented, and tested.
PRACTICAL FRAMEWORK
A ten-part planning framework
Move from the real problem to a bounded, reviewable first phase before implementation decisions harden.
Define the problem.
Name the first realistic user.
Describe the current workaround.
Set the intended outcome.
Choose the smallest useful workflow.
Write explicit exclusions and non-goals.
Separate architecture assumptions from verified facts.
Identify evidence, risk, and missing decisions.
Define a narrow first phase.
Prepare a reviewable handoff.
CURRENT FRAMEWORK
Scope-boundary diagram
- Inside the first phase
One user · one complete workflow · one useful outcome
- Later
Secondary users · extended workflows · optional capability
- Explicitly excluded
Non-goals · unsupported operations · deferred integrations
Read visual as text
Start with one problem, one realistic user, and one complete workflow inside the first-phase boundary. Record later ideas and explicit exclusions outside that boundary.
DECISION CHECKLIST
Questions that make the first boundary reviewable
A useful first phase connects one realistic user and one complete workflow to explicit scope, evidence, and acceptance criteria.
What problem exists before any feature is proposed?
Who is the first realistic user rather than the broad future audience?
What workaround does that user rely on today?
What is the smallest complete workflow that creates a useful outcome?
What will explicitly remain outside the first phase?
Which architecture statements are assumptions rather than verified facts?
What evidence or unanswered decision could change the plan?
What must a developer be able to review before implementation?
| Planning decision | Practical question | Record |
|---|---|---|
| First user | Who encounters the problem often enough to act? | Specific role and context |
| Current workaround | How is the work completed today? | Tools, friction, and constraints |
| First use | What moment should cause the user to begin? | Trigger and starting input |
| Useful outcome | What complete result makes the workflow valuable? | Observable end state |
CURRENT FRAMEWORK
Planning sequence
- Problem
- First user
- Useful workflow
- Scope
- Assumptions
- First phase
- Handoff
Read visual as text
The planning sequence is problem, first realistic user, smallest useful workflow, scope and exclusions, architecture assumptions, first phase, and developer handoff.
COMMON MISTAKES & RISKS
Common MVP-planning mistakes
Most early plans become difficult to review when their boundaries and uncertainties remain implicit.
Starting with technology instead of the user problem.
Treating every requested feature as essential.
Leaving exclusions implicit.
Presenting architecture assumptions as proven.
Ignoring operational and data constraints.
Using “build everything” as the first phase.
Beginning implementation without acceptance criteria.
CURRENT PRODUCT MAPPING
How this framework maps to Airchor today
Create New Project provides a guided route from idea and scope through features, architecture assumptions, roadmap, evidence context, and a 14-document Project Blueprint.
CURRENT LIMITATION
Planning support does not validate the plan automatically
Airchor does not validate product-market fit, architecture feasibility, implementation cost, or technical estimates automatically. The output remains a planning draft for review.
NEXT ACTION