An MVP is not a smaller version of the final product — it is the fastest honest test of your riskiest assumption. The goal of the first eight weeks is validated learning, not feature completeness. This is the cadence we run with founders.
Weeks 1–2: Cut scope to the one thing
Most MVPs fail because they try to prove too much. We run a scoping workshop to find the single core loop that, if it works, makes everything else worth building. Everything outside that loop is explicitly deferred — written down, not deleted, so the team stops debating it.
Weeks 3–6: Build in instrumented slices
We ship a thin end-to-end slice in week 3 and thicken it weekly, with analytics wired in from the first slice. Weekly demos against the real product keep scope honest. Clean, tested code on the core path; deliberately scrappy everywhere else.
Weeks 7–8: Launch to real users and measure
A soft launch to a controlled cohort beats a perfect launch to nobody. We watch the core-loop metric daily and treat the first week of real usage as the actual spec for v2 — because it is.
Key Takeaways
- Define the single core loop and defer everything else in writing.
- Ship an instrumented end-to-end slice by week 3.
- Demo weekly against the real product to keep scope honest.
- Let the first week of real usage write the v2 spec.