An MVP answers one question, not several
Six-week projects rarely fail by running out of time. More often they reach week six with something that works, and the founder still can't tell whether the idea does. That happens when the project was scoped around features and nobody wrote down the question.
So week one produces a single sentence, and everything else follows from it. "A marketplace for X" becomes "will suppliers list inventory without us calling them?" "An AI writing tool" becomes "will people paste in their own document instead of starting from a template?"
A good question has a wrong answer you would believe. If no result would change your plans, you're developing for reassurance, and six weeks is an expensive way to get it.
What you cut, in order
Once the question is fixed, the cuts get much easier to make. Roughly in the order they go:
- Settings and preferences. These are almost always a way of avoiding a decision. Pick the default.
- Admin interfaces. A spreadsheet and a person make a perfectly good back office for v1.
- Onboarding beyond the first screen. If the product needs a tour before anyone can use it, treat that as a finding about the product.
- Every account state you do not need to test. Password reset can be an email to you.
- The second user type. Even two-sided products test one side first.
Three things never get cut: the moment the product delivers its value, the state where things go wrong, and the instrumentation that answers the question. We treat analytics as the main deliverable of an MVP, so it's never optional.
How the six weeks are spent
The six weeks don't run in a straight line from design to development. Design stays about a week ahead the whole way through:
- Week 1 the question, the flow and what we are not developing, written down and agreed.
- Week 2 core screens designed, with backend and infrastructure started in parallel.
- Weeks 3 to 4 the development. Design stays a week ahead and deals with whatever development turns up, and it always turns up something.
- Week 5 real data, real edge cases and deployment to your infrastructure. This week is always messier than the plan suggests.
- Week 6 instrumentation, handover and the walkthrough.
When six weeks is the wrong answer
We turn this format down more often than we run it. It doesn't fit when the product needs a regulatory review before launch, or when the core value depends on integrations you don't control yet. It also doesn't fit when there's no open question left. If you already have paying users and a roadmap, you need a team more than you need a sprint.
And it doesn't work when the founder can't be available. With a decision-maker who answers within a day, six weeks is enough. With a weekly review cycle, the same project takes ten weeks and ends worse.