Churn-Ranked Refocus Roadmap
When you're bleeding to competitors, throw out the plan and build the churn list, sorted by ARR.
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 6
- Confidence
- 93%
When Mixpanel discovered in 2018 that ~40% revenue churn on its core product was going to competitors — not to the category dying — it abandoned all existing planning and rebuilt the roadmap directly from years of churn reasons collected by CS and sales, grouped into problems and sorted descending by ARR. The top ten became the roadmap. The design of the process deliberately violates product best practice in order to buy the one thing that matters in a table-stakes gap crisis: speed.
Origin
Run by Vijay Iyengar and the Mixpanel product/engineering org from 2018 to 2019 after a churn post-mortem showed customers were leaving for competitors, not abandoning product analytics.
Core principles
- 01Diagnose churn before you act on it: leaving for a competitor is a feature-gap problem; leaving the category is a market problem. They demand opposite responses.
- 02Speed comes from extreme clarity and focus, not from more process.
- 03Rank by revenue at risk, not by internal enthusiasm — the churn ledger is the market's own prioritisation.
- 04Translate feature requests into problems, then put engineers in direct contact with the customers who have them.
- 05This approach outlives its usefulness fast; it is a fire-fighting mode, not a permanent operating model.
How to run it
- 1
Diagnose the churn honestly
Dig into why customers actually left. Mixpanel found the need for product analytics was intact — customers were churning to competition because the core product had fallen behind on features.
Pro tip If the answer is 'they still need this, they just bought it elsewhere', you have a focus problem, not a strategy problem.
Watch out If the need itself is evaporating, do not run this playbook — building the churn list will just make you the best vendor in a dying category.
- 2
Throw away the existing plan
Discard all current planning and in-flight work that doesn't serve the core. Mixpanel said a hard no to its two adjacent product categories and pointed the entire engineering team at the core.
Watch out Expect this to be organisationally brutal — teams have roadmaps and identity attached to the work you are cancelling.
- 3
Mine the churn ledger
Take every churn reason customer success and sales have collected — Mixpanel had years of them — group them by category (roughly the product capabilities you'd need to build), and sort descending by the ARR attached to each group.
Pro tip This only works if CS and sales have been painstakingly logging loss reasons. If they haven't, start logging today; the asset compounds.
- 4
Take the top ten and call it the roadmap
Cut the ranked list at roughly ten items. That is the roadmap. No further prioritisation ceremony.
- 5
Give each engineer a bucket and direct customer access
Assign each engineer a problem bucket and put them in direct contact with the customers who have it — not features handed down, but problems to be understood and solved. Iyengar notes this violates roughly a million product best practices, and did it anyway.
Pro tip Convert buckets from features into problems before assigning them; the engineer should invent the solution, not implement a spec.
Watch out Feature count is a vanity metric. Mixpanel shipped ~100 features in a year and Iyengar is explicit that the number means nothing — win rate and retention were the real signal.
- 6
Exit the mode deliberately
Once you are no longer bleeding on table stakes, stop. The pure speed mode produces low-reach, inconsistent features and hits diminishing returns. Mixpanel followed it with a design-led architecture phase.
Pro tip Watch for the exit signal: features start delivering less each time, and each one has to be rebuilt for every part of the product.
Watch out Staying in this mode too long is how you accumulate the design debt that the next phase has to pay off.
In the wild
Facing ~40% revenue churn with a 50-person engineering team spread across three domains (product analytics, messaging, data infrastructure), Mixpanel cut the two adjacent categories, rebuilt the roadmap from ARR-ranked churn reasons, and gave every engineer a customer-facing problem bucket. Early builds were core table stakes — behavioural cohorts creatable from any report, advanced funnel analytics, flows visualisation.
→ About 100 features shipped in the first year, with immediate improvements in win rate and retention. Across the full 2018 to late 2021/2022 arc, retention went from ~60% to ~90% and NPS from 16 to 50.
Iyengar's justification for suspending best practice: you can't mow your lawn while your house is on fire. In a competitive context where table-stakes features have already been validated by the market, discovery ceremony adds little and speed is the scarce resource.
→ The team optimised purely for speed during the crisis phase, then deliberately switched modes once the fire was out.
Common mistakes
Running the speed playbook as your permanent operating model
It is an approach that outlives its usefulness pretty fast. Sustained, it produces a pile of inconsistent features with low reach, no coherent system architecture, and diminishing returns per feature shipped.
Shipping features instead of solving problems
Mixpanel deliberately converted the churn buckets into problems and exposed engineers to the customers who had them. Handing engineers a feature list to implement gets you the vanity metric without the retention improvement.
Measuring success by feature count
Iyengar flags his own 100-features number as a vanity metric. The scoreboard is win rate, retention, and NPS — not throughput.
Is it for you?
Best for
Product leaders at a company losing core-product customers to competitors on table-stakes feature gaps, with a small engineering team spread across too many domains
Not ideal for
Category creation, greenfield products with no churn ledger, or steady-state teams where holistic design and discovery should lead
From the transcript
“we did something very simple we took all the churn reasons that our customer success and sales teams have been painstakingly collecting for years group…”
“I just gave every engineer you know direct access to customers and give them a bucket to go work on which I think goes against…”
“we needed to optimize for Speed and speed comes when you have extreme Clarity on what you want to do and focus”
“was our retention went from about 60 to 90 and our NPS went from 16 to 50.”
From the episode
An inside look at Mixpanel’s product journey
Vijay Iyengar (Head of Product)