Three Horizons
Manage the core, the emerging and the future at the same time, with different goals, measures and funding for each.
To an executive
Today's profits fund tomorrow's growth only if the future gets protected budget. Run the core, emerging businesses and early bets together, each judged by its own measures.
To an engineer
Separate work that defends the core, builds new products and explores options, and judge each differently. Do not hold experiments to the efficiency targets of mature systems.
The idea
Mehrdad Baghai, Stephen Coley and David White of McKinsey set out the three horizons in The Alchemy of Growth (1999). A company's growth comes from three kinds of business at once:
- Horizon 1: extend and defend the core. The businesses that earn today's revenue and profit.
- Horizon 2: build emerging businesses. Ventures that are gaining traction and could become tomorrow's core.
- Horizon 3: create options for the future. Research, pilots and small stakes that may or may not pay off.
The horizons are not stages to pass through in turn. The point is to manage all three concurrently, because by the time the core declines it is too late to start the next one.
Why it works
It protects the future from the present. The core always has the most urgent claims on money and people. Naming the other horizons gives them a budget line that quarterly pressure cannot quietly absorb.
Each horizon needs different rules. Horizon 1 is measured on efficiency and profit, Horizon 2 on growth, Horizon 3 on learning and milestones. Applying core measures to an experiment kills it.
It makes the balance visible. Seeing spend split across three horizons turns "are we investing in the future?" into a number leadership can discuss.
Where it applies
- Technology portfolio balance: splitting spend between run (Horizon 1), grow (Horizon 2) and transform (Horizon 3).
- Roadmaps, where near-term platform work, scaling new products and exploratory bets need different time frames and governance.
- Architecture governance, where Horizon 3 work may need lighter standards and a sandbox, and Horizon 1 needs stability.
- Sourcing, where the core may suit long contracts and Horizon 3 needs short, cheap, reversible ones.
How to apply
- Classify the portfolio. Tag each initiative and its spend by horizon, and look at the actual split.
- Set a target mix. Agree with leadership how much goes to each horizon, and why.
- Give each horizon its own rules. Different measures, review cadences, risk appetite and architecture guardrails.
- Define how work moves. Decide what evidence moves a Horizon 3 bet to Horizon 2, and when Horizon 2 is ready to be run as core.
- Review the mix regularly. Shift spend as bets succeed or fail.
Example scenario
A bank's technology budget was nine-tenths run and regulatory change. Two digital ventures and an AI pilot were funded from leftovers, judged on cost and uptime like core systems, and kept slipping.
The enterprise architects tagged the portfolio by horizon and showed the split to the executive committee, which agreed a target mix and a separate fund for Horizons 2 and 3. Experiments got a sandbox with lighter controls and quarterly go or stop reviews. One venture was scaled into the core platform the next year; the AI pilot was stopped early and cheaply.
Questions to ask
- What share of this year's technology spend goes to each horizon, and is that a choice or an accident?
- Which Horizon 3 bets are we funding as options, and what would make us stop or scale each?
- Are we judging Horizon 2 and 3 work with Horizon 1 measures?
When not to use it
- Survival situations, where the core is failing and every resource must go to Horizon 1 for now.
- Single-product start-ups, where the whole company is effectively one Horizon 2 or 3 bet.
How it misleads you
Labels can become a political game: teams relabel core work as Horizon 3 to escape scrutiny, or ventures stay in Horizon 2 for years. The horizons also suggest neat time frames that real markets do not respect. Classify by the kind of uncertainty and the measures that fit, not by the team's preference.
Further reading
Last reviewed · Suggest an improvement