Six weeks is enough to release something valuable when the team is solving one well-defined problem. It is not enough to compress a year-long roadmap into a smaller calendar. The difference is scope discipline.
Before design starts, write down the user, the moment of need and the observable change the product must create. If a feature does not help test that chain, it is a candidate for the next release.
Keep the complete journey
An MVP should be narrow, but it should not be broken. A customer must be able to arrive, understand the offer, complete the core task and know what happens next. Cutting an entire supporting workflow is often safer than leaving every workflow half-finished.
We protect trust, accessibility, analytics and basic operational tooling. Those are not polish. Without them, teams cannot safely serve users or learn from the release.
Use evidence to earn scope
Agree on success signals before implementation. Combine product analytics with support conversations and direct observation. Review them every week, and only expand scope when the current behavior is understood.
A strong six-week release is not the end of development. It is a credible first version with enough structural quality to support the next decision.
