Product strategy is the discipline of making explicit, evidence-backed choices about which critical problems to solve right now. It is not a deliverable handed down as a prioritized list — "fundamentally the product strategy is about making those choices."
It's distinct from three things it's commonly confused with:
Product strategy exists to make both of those true at once: "The product strategy is how we make the product vision true and how we make the business strategy true." Its two inputs are the product vision and the company's current objectives (which themselves reflect business strategy) — the chosen critical problems must "take you towards your vision... and pay the bills along the way."
A real strategy makes hard choices about what NOT to do, backed by data and reasoning — see Amazon's Six-Page Narrative. A strategy that only asserts belief without evidence is "wishful thinking," not strategy.
Why it matters — the missing-strategy diagnosis: most companies' chronic "prioritization problems" are actually lack-of-focus problems in disguise. When a real strategy exists, prioritization becomes implicit — the strategy has already decided what matters. Symptoms of the absence of strategy include never-ending prioritization debates and annual operating plans (AOP) that fund whole projects upfront as a "dog and pony show," instead of funding discovery first.
See Introducing Focus as a Reversible Test for how to introduce real focus into an org that lacks it, and Earning the Right to Define Problems for how product teams progress toward the problem discovery that feeds this strategy.
Product strategy has exactly two goals: moving closer to the Product Vision, and keeping the business financially viable — sequenced around what can actually be monetized right now. A strategy that only chases the vision without regard for near-term viability isn't one a business can survive on; one that only chases viability without regard for the vision has no direction.
Whether AI belongs in a strategy at all is almost always 'yes' — the harder question is whether a specific problem is technically ready for a probabilistic solution, and what guardrails that solution needs. A good strategy addresses both: readiness (can AI actually solve this reliably enough right now) and guardrails (what constraints wrap the probabilistic behavior).
For the work of crafting the strategy itself, 'the primary tool is the brain' — AI tools can sharpen that thinking, or, used carelessly, become a substitute for doing it.
A Product Vision rarely changes; a strategy changes often, sometimes forced by external shocks (e.g., COVID). It should be treated as a living document, revisited and updated at least quarterly rather than set once and left alone.
Strategy documents are also treated as more sensitive inside a company than its code, since they state plainly what leadership has decided is and isn't worth the company's attention right now — higher political stakes than any implementation detail.
Good strategy synthesizes three elements:
A strategy missing any of the three collapses back into either a Roadmap (Feature/Project List) (focus without transparency or a real bet) or wishful thinking (a bet without transparency): 'a lot of product strategies are just wishful thinking... There is no real analysis about how and why that's going to happen.'
The most common reason a strategy fails isn't that it was a bad strategy — it's a good strategy paired with execution that proved too difficult to actually crack. Capacity compounds against ambition: 'just because you can do one in x amount of time doesn't mean you can do two in 2x' — an argument for the focus half of strategy, since taking on fewer bets keeps execution difficulty within reach.
Most 'prioritization problems' teams complain about are actually symptoms of not having a real Product Strategy at all. If you have a strategy, prioritization is implicit — the strategy already names the critical problems to solve right now, so there's nothing left to 'prioritize' in the sense of adjudicating between co-equal options. Diagnose a chronic prioritization backlog as a missing-strategy problem before treating it as a scheduling or process failure.
A product strategy has exactly two outputs: (1) the prioritized problems to solve this quarter or year, and (2) the 'why' behind that choice — the data, argument, and interdependencies that justify it. The problem list alone is not a strategy; without the reasoning it can't be defended, taught to the org, or revisited when circumstances change. See Amazon's Six-Page Narrative for a preferred format for capturing both together.
Product strategy has two goals it must satisfy at once: move the company toward its Product Vision, and keep the business financially viable in the meantime. This means sequencing which critical problems to tackle now based partly on what can be monetized soon, not purely on what's closest to the vision.
"Even their code I think is less valuable to them than their strategy" — the strategy itself, not the roadmap or the codebase, is treated as the company's most valuable asset, because it's the record of which problems were chosen and why.
Example: Datasite divested underperforming business units specifically to fund the product line its strategy had already proven out — a Business Strategy move (divestiture, reallocating capital) following from, and validating, a product-strategy bet.
Leah Hickman: product strategy is "the prioritized list of problems to solve," which should ladder up to Product Vision and business needs. This framing is what sits above the key results and hypotheses in her Outcome-Based Roadmap Reframing.
Hickman's shorthand definition: 'The easiest way I think about product strategy is it's the prioritized list of problems to solve.' That list should ladder up to Product Vision and business needs, and the Roadmap (Feature/Project List) (or outcome-based roadmap) is derived from it — built as a prioritized list of problems, not a prioritized list of features.
Cagan defines product strategy as immersing yourself in insight in order to decide which problems are worth solving — i.e., most important to pursue. He calls Discovery (Product Discovery Process) his personal favorite and most hands-on part of the job, but ranks strategy as more impactful to the company, since strategy is what decides what discovery even gets pointed at.
Cagan draws a sharp line between Discovery (Product Discovery Process) (the hands-on, creative work of building solutions — his personal favorite part of the job) and product strategy (deciding which problems are worth pointing discovery at in the first place). He ranks strategy as more impactful to the company than discovery precisely because it gates discovery: the best discovery work is wasted if it's aimed at a low-value problem, so strategy's job is to make sure discovery effort only gets spent on the most important problems.