The Long-Bet Vision Call: Ship What the Committee Would Veto
Great software follows a leader's vision, not a vote — accept years of hate for a decade-long payoff.
- Difficulty
- Expert
- Time to result
- ~ongoing to results
- Steps
- 3
- Confidence
- 88%
Mullenweg's argument for concentrated product decision-making: the technological pivots that kept WordPress relevant across two decades were unpopular calls a small core made against what a vote would have decided. The framework is to identify a generational shift, commit to a 10-year bet led by a few core people, and absorb 3-4 years of users hating it while you iterate on a strict cadence.
Origin
Mullenweg's account of shipping the Gutenberg editor; he ties it to the 'founder mode' idea popularised by Brian Chesky and Paul Graham.
Core principles
- 01Great software reflects a leader's vision far more often than committee consensus
- 02The most important bets are exactly the ones a vote would reject
- 03Surviving generational technology shifts (dynamic web, social, mobile, AI) requires making calls most users initially oppose
- 04A long bet needs a fixed iteration cadence to grind toward 'pretty darn good'
- 05Leadership here is accountability, not tyranny — the community can always fork, so you lead as a steward/'mayor', not an unaccountable CEO
How to run it
- 1
Identify the generational shift
Spot the technological change that threatens long-term relevance (for WordPress: the move that would keep it central as the web evolved). Frame the response as a multi-year bet, not a feature.
Pro tip Most products die because they don't survive multiple generational changes — treat surviving them as the core job.
- 2
Make the call with a small core, not a vote
Concede that if put to a vote the majority would reject it, then let a few core contributors with conviction commit to it anyway.
Pro tip Name the ~10-year horizon and the '3-4 years of it sucking' up front so the team and community know the pain is expected, not a failure.
Watch out This only works with genuine accountability — the community's ability to fork is the check that keeps 'final decision maker' from becoming reckless.
- 3
Iterate on a strict cadence
Commit to a relentless, fixed release schedule and grind the bet toward quality over many iterations.
Pro tip Gutenberg shipped on a strict every-two-weeks cadence for 200+ releases before it got 'pretty darn good'.
Watch out Early releases will be bad and hated; without a disciplined cadence the long bet stalls and confirms the doubters.
In the wild
Mullenweg and a few core contributors decided the block editor was the future despite knowing a community vote would have killed it and that it would 'suck for the first three or four years.' They shipped on a strict two-week cadence, reaching 200+ releases, and designed it as an open framework usable beyond WordPress (Tumblr, and open to Wix/Squarespace).
→ After roughly a decade of iteration Gutenberg became a major reason WordPress stayed relevant, with real-time peer-to-peer collaboration (via WebRTC) as its next phase.
Common mistakes
Putting the pivotal bet to a vote
The decisions most critical to long-term relevance are exactly the ones a majority rejects; deferring them to committee guarantees you never make them and the product ages out.
Abandoning the bet during the years it's hated
A long bet is designed to be bad and unpopular for its first 3-4 years; quitting during that window — or lacking a disciplined release cadence to push through it — wastes the entire multi-year investment.
Is it for you?
Best for
Founder-led products facing a generational technology shift where a decisive multi-year re-architecture is needed and consensus would block it.
Not ideal for
Reversible, low-stakes decisions, or organisations without genuine accountability checks (like the ability to fork/leave) where concentrated power isn't balanced.
From the transcript
“is great software ever created by committee”
“if we had voted for whether we should do that or not everyone would have voted against it”
“it's going to take 10 years to do and it's going to be a long bet it's going to suck for the first three or…”
“we do sort of a very strict every two weeks release schedule since it started”
From the episode
The creator of WordPress opens up about becoming an internet villain, why he’s taking a stand, and the future of open source
Matt Mullenweg (founder and CEO, Automattic)