Bracketing (The Two-Track Future Bet)
Develop two possible futures at once so you can pick the winner instead of guessing.
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 75%
Bracketing is a hedging technique Microsoft engineers used whenever the direction of a future computing paradigm was genuinely unknowable. Instead of betting the company on a single vision, teams built two parallel product tracks — a conservative version that assumes today's interaction paradigm continues, and an ambitious version that fully commits to the emerging one — and kept both alive as long as possible. As real-world signals accumulated (competitor launches, hardware maturity, customer reaction), leadership collapsed the effort into whichever bracket the market was validating and killed the other. Used well, as in OS/2 vs. Windows, bracketing let Microsoft dominate an inflection point without guessing wrong years in advance. Used poorly, as in the multi-year, never-compiling Windows Longhorn effort, it can burn a company's best engineering talent for years with nothing shippable to show, which is why a hard collapse deadline is essential to the method.
Origin
Coined informally inside Microsoft by engineers describing how the company approached uncertain platform transitions — most visibly during the OS/2-versus-Windows era and later, disastrously, during the multi-year Longhorn/Vista development process.
Core principles
- 01Preserve optionality when the future paradigm is genuinely uncertain
- 02Set an explicit checkpoint for when you must collapse to one bet
- 03Let real market signals, not internal conviction, decide the winner
- 04Kill the losing bracket decisively so its talent can be redeployed
How to run it
- 1
Identify the Uncertain Paradigm
Recognize a technology inflection point where multiple plausible futures exist and it is genuinely too early to know which interaction model or architecture will win.
- 2
Build the Conservative (Low) Track
Develop a version of the product that assumes the current paradigm continues, protecting your existing market if the anticipated shift is slower or smaller than expected.
- 3
Build the Ambitious (High) Track
In parallel, develop a version that fully commits to the emerging paradigm, even if the underlying hardware, developer tools, or user base don't fully exist yet.
Pro tip Staff the ambitious track with people who genuinely believe in it — half-hearted moonshots rarely survive internal budget fights.
- 4
Watch for Real-World Signals
Track competitor launches, hardware maturity, and customer pilot feedback as objective evidence for which track the market is validating, rather than relying on internal opinion.
- 5
Collapse to the Winning Bracket
As the ship date approaches, commit fully to whichever track the market signals favor, and formally kill or shelve the other track, reassigning its people and code.
Watch out Letting both brackets run past the decision deadline is the single biggest failure mode — it burns your best talent on a project that may never ship.
In the wild
In the IBM era Microsoft bracketed with OS/2 (high-end, aligned with IBM's vision) and Windows (lower-end, PC-clone friendly), running both for years before market signals became clear.
→ Microsoft collapsed fully into Windows once its momentum was undeniable, and OS/2 was abandoned as a consumer platform.
Microsoft simultaneously pursued a cable-based 'Information Superhighway' vision (Cablesoft, Tiger) and an open internet browser strategy in 1994; once Mosaic's exponential growth became undeniable, they collapsed fully into the browser bet.
→ Internet Explorer became the dominant browser while the cable-based interactive TV projects were quietly abandoned.
Common mistakes
Letting Both Brackets Run Too Long
Windows Longhorn kept an overly ambitious high-end bracket (WinFS, Avalon, Indigo) alive for years without ever producing a working, compilable build, delaying any shippable product and burning enormous engineering talent.
Forcing Both Brackets Into One Shipping Product
Windows 8 tried to merge the touch-first Metro bracket and the legacy desktop bracket into a single release instead of collapsing to one, confusing both consumer and enterprise audiences at once.
Is it for you?
Best for
Large platform companies facing a genuine paradigm-shift decision (interaction model, architecture, form factor) where committing too early or too late both carry major downside.
Not ideal for
Teams without the discipline to set and honor a hard collapse deadline — without it, bracketing degrades into indefinitely funding two competing efforts.
From the transcript
“you basically develop two products concurrently one aimed below what the current technical capabilities are and one aimed above and as you get closer to…”
“they never built Longhorn like it did not compile they could not integrate all the different projects into one”
From the episode
Microsoft Volume II