Build a three-horizons product strategy map

The Three-Horizons Trap Most Product Teams Fall Into

Product teams default to one of two failure modes: 100% Horizon 1 (optimize what works until growth stalls) or 100% Horizon 3 (moonshots with nothing shipping). Michael Porter argued in "What Is Strategy?" that strategy is the disciplined choice to deploy scarce resources for maximum impact — not the deployment itself. Reforge's Product Strategy Stack notes that the most common artifact labeled "strategy" is really a compilation of Horizon 1 features ranked by the loudest stakeholder.

How the Build a three-horizons product strategy map Prompt Works

The prompt forces a three-row table with explicit resourcing percentages, kill criteria, and one comparable company per bet. The kill criteria is the load-bearing element — without pre-committed wind-down thresholds, Horizon 2 and 3 bets absorb budget indefinitely without being held accountable to the hypothesis that justified them.

When to Use It

• Leadership is asking why your roadmap looks identical to last year.
• You inherited a product org with all optimization and no net-new bets.
• A board meeting is coming and you need a defensible resourcing mix.
• Growth is stalling and the team needs permission to fund adjacencies.
• You are the new head of product and want to reset the planning cadence.

Common Pitfalls

• Labeling the same roadmap "Horizon 1". Three-horizons only works if Horizon 2 and 3 bets exist. Restating Horizon 1 in three rows is not strategy.
• Missing kill criteria. Without pre-committed thresholds, Horizon 3 bets become zombie projects that consume budget without accountability.
• Ignoring the resourcing split. Declaring horizons without reallocating engineering weeks is theater. The split is what forces real tradeoffs.

Sources

• What Is Strategy? — Harvard Business Review
• The Product Strategy Stack — Reforge
• Product Strategy Overview — Silicon Valley Product Group
• Product Strategy in Three Steps — Reforge