Cannibalize Your Own Product Every 6-12 Months
Make your current product look silly on a fixed cadence instead of only shipping what users ask for
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 4
- Confidence
- 90%
A product strategy that deliberately resists incrementalism. On a 6-to-12-month cadence, the team builds bets big enough to make their own existing product look dumb — disrupting themselves before a competitor does. It runs on a two-roadmap structure: a public roadmap driven by user requests, and a 'secret roadmap' of longer-horizon bets users aren't even asking for.
Origin
Varun Mohan's cannibalization principle at Windsurf; the two-roadmap structure is credited to Gaurav from Captions, a prior Lenny's Podcast guest who called it the 'secret roadmap.'
Core principles
- 01The value of any lead (even being first agentic IDE) depreciates fast unless you keep re-proving yourself
- 02Incremental features feel safe but are table stakes, not the reason you win
- 03You must keep listening to users — they're the reason you exist — while also building what they can't articulate
- 04Online excitement clusters on short-term weekly wins, but the company-defining work is 3-9 months out
How to run it
- 1
Run a public roadmap from user feedback
Maintain the normal roadmap built from feature requests, user feedback, and data. Ship incremental improvements on a visible cadence (Windsurf ships 'waves' every couple weeks).
Watch out Treat these as table stakes — necessary to keep users, but not the source of durable advantage.
- 2
Run a secret roadmap of self-disrupting bets
Maintain a separate roadmap of longer-horizon bets (3-9 months) informed by where you think the world is going, not by current user requests or data.
Pro tip Mohan: you'll need to re-prove yourselves 'in ways in which our users are not even asking.'
- 3
Set the 6-12 month cannibalization bar
Hold the team to the standard that every 6-12 months the new work should make the existing product look silly and its form factor look dumb.
Watch out Don't let the safety of adding 'one more button' crowd out the disruptive bets — incrementalism is the comfortable trap.
- 4
Hold the tension deliberately
Keep both roadmaps alive at once: iterate for current users while investing in efforts that disrupt your own product. Neither pure incrementalism nor pure moonshotting wins.
Watch out Ignoring users entirely is as dangerous as never disrupting yourself — they're the reason you exist.
In the wild
Rather than keep shipping incremental AI features inside existing IDEs (VS Code), the team judged the existing surface was capping the value users got, and built an entirely new agentic IDE — a bet that made their prior in-IDE product look limited.
→ Porting the same ML models into Windsurf's custom UI tripled their autocomplete acceptance rate with no model change.
Common mistakes
Optimizing only for weekly wins
The internet rewards short-term shipping, but Mohan says the company-defining work is the 3-9 month self-disrupting bets, not the weekly increments.
Building only what users request
User-requested drop-downs and buttons are table stakes; winning comes from re-proving yourself in ways users aren't asking for.
Is it for you?
Best for
Product leaders in fast-moving categories where today's differentiation depreciates quickly
Not ideal for
Mature, slow-moving products where stability and incremental reliability matter more than self-disruption
From the transcript
“we should be cannibalizing the existing state of our product every 6 to 12 months. Every 6 to 12 months, it should make our existing…”
“the value of that is going to depreciate very quickly unless we continue to reprove ourselves and we will need to reprove ourselves in ways…”
“they have the the the real road map ... and then they have the secret road map which is completely not informed by users or…”
From the episode
Building a magical AI code editor used by over 1 million developers in four months: The untold story of Windsurf
Varun Mohan (co-founder and CEO)