The MVP Postmortem: Questions to Ask Yourself Six Months In

What you actually need to know

• Six months is not a deadline -- it is a checkpoint. The postmortem forces an honest evaluation of whether the hypothesis was validated, not just whether the product was launched.
• The three postmortem questions that matter most: did paying customers renew without manual intervention, does the cohort retention curve flatten (rather than going to zero), and do the user conversations confirm the hypothesis or surface a different one?
• Most MVPs have a partial result at six months: the hypothesis was directionally right but the target customer, the onboarding flow, or the pricing was wrong. Partial results are not failures -- they are inputs to the next iteration.
• Technical debt at six months is a strategic question, not a technical one. The question is whether it is slowing the iteration that the postmortem reveals is necessary.
• The postmortem decision has three options: persevere with specific changes, pivot to a new hypothesis, or stop. All three are legitimate. The failure mode is continuing without making one of the three decisions explicit.

The core argument

The MVP postmortem is the most important meeting that most founding teams do not schedule. They launch, they watch the metrics, they ship features, and they react. What they do not do is stop and ask the structured question: was the hypothesis validated?

The reason it matters is that all subsequent decisions -- what to build next, whether to hire, how to market the product -- depend on whether the hypothesis is confirmed. Building product features on an invalidated hypothesis is like adding floors to a building with no foundation. Each new feature is more investment in the wrong direction.

The six-month mark is the right time because it is long enough to have meaningful user data (cohorts, retention curves, support conversations) and short enough that the founding team's memory of the original hypothesis is still accurate. At twelve months, the team has usually rationalized the results in a way that makes the honest postmortem harder. At three months, the data is too thin to be conclusive for most products.

The postmortem is not a performance review and it is not a celebration. It is a diagnostic.

The hypothesis validation question

Before any other postmortem question, the founding team needs to restate the original hypothesis in writing and evaluate it against the evidence.

The hypothesis format: "We believe [type of user] will pay [price point] for [capability] because [problem]."

The evidence comes from four sources:

Revenue data: How many unique paying customers? What is the monthly recurring revenue at the six-month mark? What is the average revenue per account? These numbers tell you whether anyone is willing to pay, not just whether they like the product.

Retention data: Of customers who signed up in month one, what percentage are still active in month six? Plot the retention curve -- does it flatten (indicating a retained core audience) or continue declining toward zero (indicating a leaky bucket)? A curve that flattens at any percentage indicates retained value; a curve that reaches zero indicates the product does not retain.

Cohort data: Has retention improved for customers who signed up in later months versus earlier months? Improving cohort retention indicates that product improvements are working. Flat or declining cohort retention indicates the retention problem is not being solved.

Conversation data: Pull the last twenty support conversations and twenty user interviews. What did users say they were getting from the product? Does it match the hypothesis? If users consistently describe a different value than the one in the hypothesis, the hypothesis may have been wrong about what problem the product actually solves.

The customer segment question

The most common postmortem finding is that the hypothesis was right, but for the wrong customer segment.

Ask: which users are retaining? If there is a subsegment of users with materially higher retention than others, identify what distinguishes them. They may be a different size company (SMB vs. mid-market), a different role (the operator vs. the manager), or a different use case (they use the product for X, not Y).

For Expert Tutorials, the six-month postmortem revealed that individual developers retained at much higher rates than teams. The hypothesis had targeted developers in general, but the product had implicitly been optimized for self-directed learners rather than team training use cases. That finding drove the next six months of product direction: deepen the individual developer experience, not build team features.

This is a common postmortem pattern. The product works for a specific subset of the target customer. The postmortem makes that visible and allows the team to narrow the customer definition, which improves the efficiency of every subsequent acquisition and retention investment.

The onboarding question

A high-retention product with a poor onboarding flow looks identical to a low-retention product in the aggregate retention curve. Both show high early drop-off. The difference is that the high-retention product has a group of users who made it through onboarding and retained well -- and the low-retention product does not.

The postmortem must separate onboarding failure from product failure.

Look at the activation metric -- the point in the product where a user has experienced the core value proposition for the first time. For an invoice reminder product, activation might be "user added a customer and sent a first reminder." For a project management tool, activation might be "user created a project and added a task."

What percentage of signed-up users reached activation? If the activation rate is under 30 percent, the onboarding is the primary problem, not the product itself. Fix the onboarding before concluding the hypothesis is wrong.

What is the retention of users who reached activation versus those who did not? If activated users retain at 60 percent and non-activated users retain at 5 percent, the product works -- the distribution problem is getting users to activation.

The technical debt question

At six months, technical debt is a strategic question: does it prevent the team from shipping the changes the postmortem reveals are necessary?

Three categories:

Acceptable debt: Features built quickly for the hypothesis test that work but are not production-polished. Messy code, limited error handling, manual processes that have not been automated. If the hypothesis was validated, this debt is next on the priority list. If the hypothesis was invalidated and a pivot is happening, this debt may be irrelevant.

Active liability: Anything in the payment processing, authentication, or data integrity path that is fragile. This debt must be addressed before scaling, regardless of the postmortem result, because it creates customer-facing risk.

Invisible debt: Architecture decisions made for the current hypothesis that constrain the next hypothesis. A schema designed around the current product entity that would require a migration if the product pivots. Identified by asking: "If we pivot to [alternative hypothesis], what would need to be rewritten?"

Common mistakes founders make in the postmortem

1. Evaluating success based on vanity metrics (signups, page views, social shares) rather than the hypothesis-specific metrics (paying customers, retention, revenue). A product with 5,000 signups and zero paying customers has not validated the hypothesis.
2. Rationalizing churn as "the product just needs more features." Some churn is product gaps; sustained, high churn with no flattening retention curve is an invalidated hypothesis. More features on a wrong hypothesis do not fix the hypothesis.
3. Not pulling the conversation data. Survey results are not conversation data. Structured interviews and support tickets are. Founders who skip the qualitative layer miss the signal that the product is solving a different problem than the one the hypothesis targeted.
4. Treating the postmortem as a team retrospective rather than a hypothesis evaluation. The team did a great job; that is not the question. The question is whether the hypothesis is confirmed.
5. Not making the postmortem decision explicit. The team discusses the results, agrees things need to change, and then continues without a formal persevere/pivot/stop decision. Three months later, the same conversation happens again. The postmortem must end with a decision.

Where to start: a 3-step MVP postmortem

Step 1: Restate the original hypothesis in writing and assemble the four evidence sources. Revenue data, retention curve, cohort data, and conversation data. If the conversation data is thin (fewer than twenty user conversations), schedule interviews in the week before the postmortem meeting.

Step 2: Run the four postmortem questions with the founding team. Was the hypothesis validated? Which customer segment is retaining? What is the activation rate, and is the drop-off a product problem or an onboarding problem? What technical debt is active liability versus acceptable debt?

Step 3: Write the postmortem decision document. The original hypothesis (validated / partially validated / invalidated), what users actually value (drawn from conversation data), what the MVP got wrong (features unused, onboarding failures, wrong segment), and the decision (persevere with specific changes, pivot to a new hypothesis, or stop). Share the document with anyone who will be affected by the decision.

The Review That Shapes What Comes Next

Yashveer Singh. Founder of Yashveer Labs. The six-month postmortem for Expert Tutorials was the most useful meeting I ran in the first year of the product. The retention curve had flattened -- but at a lower percentage than I expected. The conversation data showed that individual developers were retaining and teams were not. The onboarding analysis showed that users who completed the first guided module retained at 71 percent; users who did not complete the first module retained at 8 percent. The postmortem decision was persevere, with two specific changes: narrow acquisition to individual developers, and redesign onboarding to get every user through the first module. Both changes were shipped in the following six weeks. The next cohort's sixty-day retention was 38 percent, up from 21 percent. The postmortem produced that result. Launching another six months of features without the postmortem would have produced the same 21 percent.

Related reading

• The MVP Feature Checklist: What to Build, What to Cut, and Why
• The Five Hour Founder Audit: Are You Ready to Build?
• The Modular MVP: Building So You Can Pivot Without Burning Everything
• The Honest MVP Checklist: 25 Items Before You Launch