What Happens After an MVP Launch? A 90-Day Founder Roadmap

Agree product-specific conditions before reviewing the results. Record what would change the decision, who owns it and when unresolved evidence will become available. Reliability, research and commercial review continue across all three windows.

Days 1–30: make the product supportable and observable

Start with the complete customer journey, including any manual work behind the screen. Can someone complete the important task? Does the result reach the right person? Can your team identify a failure and help the affected customer?

Give incident handling, customer support and measurement a named owner. Agree what requires immediate escalation, what can enter the normal backlog and who can pause an affected feature. Keep the team’s actual support hours and responsibilities clear.

The GOV.UK guidance on running a live service treats ongoing support, measurement and improvement as continuing work. That principle is useful here; the government’s assessment requirements are not a startup launch checklist.

Maintain a compact support log: affected task, severity, recurring theme, workaround and owner. Include issues reported through email or conversations, not only tickets. Separate a confusing step from a defect, and a defect from a request for an additional capability.

Check that the essential events represent completed operations rather than button presses. Exclude known test activity, investigate missing or duplicate events and record which customers you cannot observe. Missing measurements are not automatically failed customer journeys.

Keep collection proportionate. The ICO’s data-minimisation guidance explains that personal data must be relevant and limited to what the purpose requires. Resolve collection permissions, access and retention for your actual setup; this roadmap is not a privacy compliance assessment.

Day-30 evidence gate: can the team explain the main failures, identify who will resolve them and trust the observations used for its next decision? If serious problems or measurement gaps remain, prioritise those and reconsider recruitment or feature expansion. A quiet support inbox alone does not answer the question: check whether people actually attempted the journey.

Days 31–60: investigate first value and behaviour

Define activation around the customer’s first useful outcome. For a hypothetical staff-scheduling product, this might be a workplace publishing a usable rota that the intended team can access. Creating an account is an earlier step, not evidence that the scheduling problem has been solved.

Find where intended customers struggle before that outcome. Review the journey alongside support evidence, then speak with people who completed it, people who stopped and people who needed help. Include different access needs and the staff doing any supporting work.

Ask about a recent actual task: what happened, what they expected, where they hesitated and what they did afterwards. GOV.UK’s interview guidance recommends open questions and real examples. Record what the participant demonstrated separately from your explanation of it.

Choose one important uncertainty for the next change. Perhaps the rota fails because availability information is missing, rather than because the calendar needs more features. Write down the explanation, the smallest useful test, the evidence you expect and any unacceptable side effects.

Compare observations carefully after the change. Different acquisition channels, customer types, assistance levels or product versions can affect the result. A higher completion rate after a release is an observation; it does not establish that the release caused the improvement. The Magenta Book’s evaluation guidance explains why attributing change requires considering what would have happened without the intervention. For consequential experiments, plan an appropriate comparison and analysis before interpreting results.

Day-60 evidence gate: which explanation has gained support, what remains uncertain and what should change next? Continue a promising investigation, address a different obstacle or leave the product unchanged while gathering more evidence. Record contradictory observations as well as encouraging ones.

Days 61–90: review repeat value and the next commitment

For a recurring product, examine whether customers repeat the useful behaviour at the interval their work requires. Specify the starting event, return event and observation window. For an episodic product, begin with whether the original task was completed successfully; investigate return behaviour only when another relevant need arises.

Use mature cohorts: groups whose full agreed observation window has elapsed. Amplitude’s retention documentation illustrates how return definitions and incomplete intervals affect calculations. Check your tool’s settings rather than assuming every chart uses the same denominator.

For a purely hypothetical monthly planning tool, define a return as another completed plan from 30 elapsed days after the first completion until just before 60 elapsed days. Suppose twenty accounts completed their first plan, but only eight have finished that whole return window. Of those eight mature accounts, five completed another plan within that interval: report 5/8, or 62.5%, with twelve accounts still pending. This is illustrative arithmetic, not a success benchmark. It describes the eligible cohort and cannot establish future retention or product-market fit.

Review the effort behind the result too. How much onboarding, correction and support did customers need? Which work was deliberately manual for learning, and which work would make continued delivery difficult? Keep collected revenue, trial activity and prospective sales distinct.

Bring the evidence to a defined investment decision. Set the next commitment in cash, team capacity and operating responsibility, with a review date. Include maintenance and support alongside the proposed improvement. Do not commit the remaining budget simply because the initial build is complete.

Day-90 evidence gate: choose a documented next step. You might deepen one valuable journey, focus on a narrower customer group, extend observation, test a different assumption or stop further development. If expansion is justified, use the pilot-to-rollout framework to plan a limited next group and its support needs.

Where evidence is immature, name what you are waiting for and when it will become observable. An extension needs a question, an owner and a spending boundary. Any decision to stop must also address existing customers, commitments and orderly service closure.

Choose metrics that fit the product’s rhythm

The following are proposed measurement choices, not industry benchmarks. Select the counting unit—person, account, organisation or transaction—and keep it consistent within a comparison.

Early milestones can guide investigation, but they are not substitutes for later outcomes. A completed setup does not establish retention; a purchase discussion is not collected revenue.

Show counts beside rates, label pending cases and record material differences between cohorts. Review comparable business cycles, including UK holidays or seasonal patterns where relevant. Use FlutterCraft’s early-stage product analytics guide for the detailed definitions and measurement worksheet.

Decide what can wait

Treat each feature request as evidence about a possible need. Ask who has the problem, how they handle it now and what would change if it were solved. A request from one large prospect may matter commercially, but it does not establish a need across your target customers.

Before committing substantial development, ask:

• Is there a demonstrated obstacle to the current customer outcome?
• Could clearer onboarding, support or a smaller change address it?
• What evidence would justify the larger investment?
• What continuing maintenance and operational work would it create?

Be cautious about broad automation before understanding the manual workflow, a second platform before investigating the first platform’s limitations, or additional reporting nobody uses to make a decision. These are proposed sequencing choices, not blanket rules. A critical accessibility barrier, contractual commitment or demonstrated customer need may change the priority.

Keep a visible “later” list with the reason for deferral and the evidence that would reopen the decision. This lets the team preserve useful ideas without treating every suggestion as a delivery promise.

Use a weekly founder review that closes a decision

Bring the founder, product or engineering owner, and the person closest to customer support together. Keep one shared record; the purpose is to decide the next useful action and check what the previous action established.

A useful proposed closing question is: “What have we learned that changes what we will do next?” If nothing changes, record why continuing is sensible and what evidence you still need. Do not manufacture a feature task to make the meeting feel productive.

Leave day ninety with a clearer customer promise, understood operational responsibilities and a justified next commitment. Start by booking the first review and assigning an owner to the core journey. For more practical founder and product guidance, join the FlutterCraft newsletter.

Research checked: 30 October 2026. Privacy and analytics-source review due: 28 January 2027. Full roadmap review due: 28 April 2027.