A portfolio planning framework that divides a company's bets into three time horizons so that short-term performance pressure does not crowd out investment in future growth.
How should we allocate investment across our current core business, emerging bets, and long-range explorations?
Three Horizons is a portfolioPortfolioPortfolioA grouping of products by strategic axisView reference → planning framework that sorts a company's bets by time horizon: the core business that generates most of today's revenue, the emerging businesses that will matter in two to five years, and the exploratory bets that may define the company a decade out. Its purpose is to stop short-term performance pressure from crowding out the investments needed for sustained growth.
Mehrdad Baghai, Stephen Coley, and David White introduced the framework in The Alchemy of Growth, published by McKinsey in 1999. The book was based on a multi-year research programme studying how companies managed to sustain profitable growth across business cycles. The authors found that the companies with the most durable growth trajectories were not the ones that maximised returns on the core business at the expense of everything else. They were the ones that actively tended all three time horizons simultaneously, allocating people, capital, and management attention across the full range. McKinsey subsequently published the framework as part of its Enduring Ideas series, and it has been absorbed into standard strategy vocabulary in most large organisations. Steve Blank and others later challenged the original timescales, arguing that in fast-moving markets Horizon 3 ideas can emerge and scale in months, not years, but the fundamental logic of the three-bucket structure has held.
Horizon 1 is the core business. It generates most of today's cash, has a clear operating model, and is managed primarily for efficiency and yield. A cloud storage company's paid team plans are a Horizon 1 product.
Horizon 2 is the emerging business. These are bets that have some evidenceEvidenceValidationData supporting or refuting a hypothesisView reference → behind them and are generating early revenue or clear demand signals, but have not yet scaled. They needNeedUserA user need, pain, desire, or constraintView reference → investment, management attention, and a degree of protection from the short-term pressures applied to H1. The same cloud storage company building an enterprise document workflow product would sit in Horizon 2: real product, real customers, but not yet a major revenue line.
Horizon 3 is the exploratory portfolio. These are experimentsExperimentValidationA test designed to validate a hypothesisView reference →, small investments, pilot programmes, or research bets aimed at options that could become core businesses in five to ten years. They are not expected to generate profit; they are expected to generate learningLearningValidationAn insight gained from an experimentView reference → and options. A small team within the same cloud storage company experimenting with AI-native file organisation is a Horizon 3 bet.
A worked example. A B2B software company runs a time-tracking product that generates 80% of revenue (H1). It is building a workforce analytics layer on top of that data with early enterprise customers paying for access (H2). A two-person team is quietly exploring whether payroll integrations could turn the product into a payroll assistant, with no revenue target attached (H3). At the annual planning session the company allocates roughly 70% of engineering to H1 (maintenance, performance, upsell featuresFeatureProduct SpecificationA product capability or featureView reference →), 20% to H2 (new analytics features, sales support for enterprise accounts), and 10% to H3 (the payroll experiment, no deadline). This split is a deliberate choice, not the default that emerges when every team maximises its own roadmapRoadmapProduct SpecificationA strategic plan of features and milestonesView reference →.
Three Horizons is most useful at the portfolio and company level, during annual or quarterly planning when leadership is setting investment priorities across a portfolio of products or bets. It provides language for having an honest conversation about whether the company is under-investing in its future, over-investing in bets with no current signal, or consuming H2 and H3 resources to meet H1 targets.
It is less useful at the level of a single product team whose scope does not span multiple time horizons. It also fails when the horizon labels are applied to projects without honestly assessing their maturity: labelling an H2 bet as H3 to protect it from revenue pressure, or mislabelling an H1 optimisation as innovation. The original timescales (0-2 years, 2-5 years, 5-10 years) have also been criticised as too slow for digital product contexts where a competitorCompetitorMarket IntelligenceA competing product or companyView reference → can move from experiment to dominant product in 18 months. Teams in fast-moving markets should treat the horizons as maturity categories, loosely tied to time.
Three Horizons is a tree pattern in the portfolio category. The framework maps the full portfolio as a hierarchy of entities, with the company's overall strategic portfolio at the root and individual products and bets as branches. The Unified Product Graph models it this way:
portfolioPortfolioPortfolioA grouping of products by strategic axisView reference →, the top-level node representing the company's full collection of products and bets across all three horizons.productProductStrategyThe product being created, the root of the graphView reference → entities, the shipped, revenue-generating products that constitute the core business.portfolioPortfolioPortfolioA grouping of products by strategic axisView reference → entities at a lower maturity level, grouping emerging investments that share a strategic themeStrategic ThemeStrategyA high-level strategic focus area for a planning periodView reference → or market.portfolioPortfolioPortfolioA grouping of products by strategic axisView reference → entities too, grouping early-stage experiments and research programmes that do not yet warrant individual product nodes.product_areaProduct AreaPortfolioA grouping of products by organisational axisView reference → entities, the functional or customer-facing domains within a given product.capabilityCapabilityStrategyAn ability that enables value deliveryView reference → entities, representing technical or organisational competencies that serve more than one horizon simultaneously.Structuring a portfolio this way means each horizon is visible, each bet has a clear home, and the relationships between horizons (a capability that serves H1 and underpins an H2 bet, say) are modelled as edges and not buried in a spreadsheet.