This chapter works through how a company gets from "why we exist" to "which problems we're solving this quarter": the mission → vision → strategy → roadmap ladder, Eriksson's decision stack and its diagnostics, what separates a real product vision from a mission statement or a feature inventory, and the three-part quality bar — focus, transparency, a placed bet — that any strategy artifact has to clear. It then walks the two working methods the corpus develops in detail: Janakiraman's Present Forward process (working group, strategy sprint, pillars, doc, rollout ladder) and Olsen's problem-space toolkit (benefit ladders, importance-vs-satisfaction, the product strategy grid). It closes on the failure modes, the maintenance cadence, and the cases — Oculus/Portal, Zynga, Slack — where results, not process, were the scoreboard.
Start with the ladder, because most strategy confusion is really a layer confusion. Mission → Vision → Strategy → Roadmap Hierarchy separates four things: mission is why the company exists (enduring, measured in decades), **Product Vision** is what the company will do over a defined horizon to bring that mission to life, **Product Strategy** is how the vision gets executed, and the roadmap is near-term execution detail — the layer this book hands off to Roadmaps, Prioritization, and Outcomes.
A mission makes a poor vision because it constrains nothing. "We are in business to save our planet" is a great mission and a crappy vision; Google's "organize the world's information" has the same defect — it inspires but puts no muscle on the bones, so teams can justify almost anything under it. A vision is a specific derivation of the mission instead of a restatement: Kaiser Permanente's "quality affordable healthcare" produced the telehealth-focused "Get Care Now," which shipped just before the COVID-19 pandemic; John Deere's "farm of the future" is one instance of the recurring "smart [domain] of the future" pattern that shows up when an old-economy mission gets a technology-forward vision built on top of it.
Chandra Janakiraman reads the same ladder in terms of resources: mission and vision express purpose, strategy is the layer that forces an explicit choice about where scarce people, time, and attention get deployed, and only then does the roadmap turn that choice into an ordered list. His Resonance Analogy for Strategy (Frequency Amplification) is the argument for why that middle layer carries the weight — pluck a system at its natural frequency and a small input amplifies; push at any other frequency and the same effort dissipates as noise. Strategy's job is to find the frequency, not to work harder at the wrong one.
The word "strategy" itself covers three distinct things, and the corpus keeps them apart. Business Strategy is the set of market and go-to-market choices. Product strategy is which problems the product org solves. Product vision is long-term direction. They interlock in both directions: a business-strategy shift usually reaches the product org as a target — "a third of revenue from Europe by year end" — not as a prescribed feature list, and it's then on discovery (the mechanics of which belong to The Product Operating Model) to find what actually has to change, and on product strategy to decide which of those changes matters most right now.
Product strategy proper is the discipline of making explicit, evidence-backed choices about which critical problems to solve now — "fundamentally the product strategy is about making those choices." It takes two inputs (the vision, and the company's current objectives), serves two goals at once (move toward the vision, keep the business financially viable, sequenced around what can actually be monetized soon), and produces exactly two outputs: the prioritized problems, and the why behind them — the data, argument, and interdependencies. The problem list alone isn't a strategy; without the reasoning it can't be defended, taught, or revisited. Leah Hickman's shorthand is the compact version: "the easiest way I think about product strategy is it's the prioritized list of problems to solve." Cagan's is that strategy means immersing yourself in insight to decide which problems are worth pursuing — and he ranks it as more impactful to the company than discovery itself, which he calls his personal favorite part of the job, precisely because strategy gates discovery: the best discovery work is wasted if it's aimed at a low-value problem.
Several formal definitions circle the same discipline. Dan Olsen's five-part version: strategy is a plan for how you will win, requires actual decisions rather than restated goals, balances customer-centricity with competitive awareness, names an explicit time horizon (1 vs. 3 vs. 5 years produce different strategies), and above all names what you'll say no to — invoking Jobs: "People think focus means saying yes to the thing you're focusing on… it means saying no to the hundred other good ideas." Gibson Biddle borrows Hamilton Helmer's: Strategy as a Route to Continuing Power in a Significant Market (Helmer) — a durable, defensible route in a market worth controlling, illustrated with the Silk Road rather than a single clever move. Lafley and Martin's Playing to Win Framework supplies five cascading questions (winning aspiration, where to play, how to win, what capabilities, what management systems) used less as a process than as a cross-check on a finished document. And Stukan's Strategy's Three-Part Structure: Where We Are / Where We're Going / How — where we are, where we're going, how we'll get there — locates where misalignment usually starts: leaders articulate the first two and leave the "how" implicit, so everyone substitutes their own.
Vision does a different job from all of this. It isn't a prioritization device; it's an alignment device — "how do you make sure everybody's rowing in the same direction? That's product vision." That job becomes load-bearing past roughly ten product teams; below that, ad hoc coordination mostly works. Small companies often don't need a written vision, since everyone holds the direction in their heads — but they still need a strategy, because they still face the question of what to work on next.
Martin Eriksson's The Decision Stack (Eriksson) turns the ladder into five questions an organization must be able to answer, each owned by one layer: where are we going (vision), how will we get there (strategy), what's important right now and how do we measure it (objectives and key results), what actions will we take (opportunities), and how do we choose between those actions (principles). Read top-to-bottom the stack answers "how"; read bottom-to-top it answers "why." The layers aren't independent — they interlock, each higher decision narrowing the options below it, which is what makes real delegation possible: teams can filter their own opportunities without re-litigating first principles every time. Eriksson deliberately avoids calling it a framework so nobody applies it rigidly; any existing tool can fill a layer, and established companies are meant to use it diagnostically — find what's already there, connect it, refine it — rather than replace their artifacts wholesale.
The strategy layer is the one most often missing or done badly, and the reason is political rather than intellectual: real strategy means closing off options, and leadership frequently prefers to keep them open — Optionality Avoidance as a Strategy Failure Mode. The strategy layer also explicitly includes "the core to protect," the existing offering that has to keep working, not just the new bets. The objectives layer is deliberately tool-agnostic: OKRs are one option, NCTs (Narratives, Commitments, Tasks) (narratives, commitments, tasks) another, and VMOs get named as a third — though the source doesn't actually explain what a VMO is, so this chapter's material is thin there. What matters is that the layer connects up to strategy and down to opportunities, and that the team agrees what the term concretely means before adopting it. At the opportunities layer, anything that doesn't connect back to stated strategy gets dropped; the worked example in Eriksson's own material narrows ten candidate opportunities to four once the filter is applied.
Principles sit at the bottom, and the placement is a design choice rather than a hierarchy claim. A principle is a strong reflection of strategy, but proposing or challenging one feels psychologically safer to a team than challenging strategy directly, so putting principles at ground level where the daily work happens makes them likelier to be proposed, tested, and revised. Company values usually fail as decision tools because they encode no trade-off — "we value innovation" tells nobody what to do when two good things conflict. A principle only becomes useful stated as a concrete choice: Monster's CEO ruling that if the company builds the best possible experience for job seekers, recruiters have to follow. Principles arise top-down from articulated strategy, or bottom-up when a team hits the same decision repeatedly — escalate it, debate it with data, then codify the resolution instead of re-deciding from scratch. Tamar Yehoshua's account of Amazon under Bezos is the same mechanism at product-tenet level (Unwavering Operating Principles Make an Org Easier to Navigate): be customer-driven, never ship an icon without a text label. The specific content mattered less than the constancy — because the rules never moved, teams could predict what leadership would accept without asking.
The stack is fractal (Fractal Stacking (Mini Stacks Laddering into a Macro Stack)): each team has a mini stack that should ladder into the company's macro stack, with vision and strategy shared at the business-line level and objectives, opportunities and principles defined locally. The splitting rule is divergence — break into a sub-stack only where a team's answers genuinely differ, not by default. On authorship, Eriksson's split is Top-Down Bets, Bottom-Up Validation: the big organization-wide bets get set top-down so everyone pulls the same way, while insight from product, marketing, sales, and customer service validates or challenges them rather than originating them wholesale.
Most of the practical value is diagnostic, and the tools are cheap:
Rollout follows "think big, start small": pick the single weakest layer — often objectives — improve just that one, verify it ladders up and down, and expand outward. The two most common adoption failures are trying to build all five layers at once in a single offsite, and skipping the step of first getting organizational agreement that clarity is actually missing. The oft-cited HBR finding that 95% of employees can't name their organization's strategy is read here not as proof that leadership never set one, but that the stack decays after being built well — which makes clarity a maintenance problem, not a launch-day one.
Almost all of this chapter's vision material comes from one voice — John Moore of SVPG — with Cagan and a few practitioner cases alongside, so read it as one well-developed school rather than a survey. Moore's central claim is that the dominant real-world failure isn't a bad vision leading a company astray; it's Vision Vacuum: No Vision, Not Bad Vision, Is the Real Failure Mode — roughly 80% of companies have no real vision at all. That leaves a gap between the enduring mission and the yearly revenue target, and the gap doesn't stay empty: it fills ad hoc, project by project, with nothing connecting the choices to a coherent "what we'll do over the next few years."
A real vision has two jobs — inspire (people want to feel they're leaving a dent on the universe) and focus/align like a north star. Without it, companies default to incremental, revenue-only thinking. Three Core Vision Ingredients are non-negotiable: validated business and customer problems (not assumed ones), alignment with corporate/executive strategy, and at least a glimpse of the revenue path. Supplementary Vision Ingredients add the zing — a customer/business "wow" narrative of the future state, awareness of industry trends, a competitive leapfrogging angle (Gen AI is the current example) — but they make an already-grounded vision inspiring, never a groundless one valid.
The tests are blunt and worth memorizing. Three-Question Vision Test: can you say what problems you're solving and for whom; can you say how you'll make customers' lives better; can you see corporate strategy and company identity reflected in it. "If I cannot answer the question, what problems are you going to solve and who are you solving those problems for? You don't have a vision." The reviewer-side companion is "Tasting the Food" Vision-Substance Metaphor: like tasting a dish and naming the cinnamon and paprika, you should be able to name the specific validated problems, strategic bets and revenue logic baked in — if all you can report is that it was "exciting" or "ambitious," there were no real ingredients. And Non-Product Function Excitement as Vision Litmus Test checks the audience: product and engineering tend to grok a good vision naturally, so their enthusiasm is weak signal; whether the CFO, finance, corporate affairs, marketing and sales get excited is the real test, because that's what the corporate-strategy and revenue legs are for.
The most common counterfeit is Inventory-as-Vision Anti-Pattern: poll every team for what they're working on, compile the list, wrap a narrative around it afterward. The tell is directionality — a real vision gathers insight, takes a stand, and forces prioritization trade-offs before being communicated, whereas an inventory-vision can never say no to anything, because it was built out of what's already in flight. Ambition needs calibrating in both directions. Audacious but Calibrated: Vision Must Match Company Readiness: vision is what takes a company from incremental to audacious, but Microsoft's internally-mocked "flying car" video failed because it was disconnected from the company's actual readiness and identity, while SpaceX carries an equally audacious Mars vision because the culture was built to pursue it. In the other direction, The Vision Bar Is 'Genuinely Improve Customers' Lives,' Not 'Change the World' lowers the bar for what counts at all: Cagan argues iPhone-level world-changing ambition is an unnecessary standard, and points to Workiva — unglamorous SEC-compliance software, one of the best places to work — as proof that genuinely improving customers' lives is a sufficient vision. The same calibration applies to launch rhetoric: Production / Launch Milestone notes that shipping to real users carries the hope of market disruption, but the claim should match what the product and company can actually deliver.
On authorship, the material is emphatic and slightly uncomfortable: Vision Authorship: Never a Collective Enterprise — a vision "can never be a collective enterprise." It's authored and filtered by the single most senior product leader (CPO, CTO, or VP Product, whichever exists), with the CTO supplying feasibility and the CFO the revenue path as inputs, not co-authors. "The number one stakeholder in my opinion for a vision is the CEO" — ideally the vision's heaviest user, someone who returns to it constantly when making calls, not someone who signs off once. Bland Mediocre Middle vs. Opinionated Founder Detail-Care generalizes the point: company-wide initiatives designed to survive broad cross-functional criticism regress to a bland mediocre middle that offends and excites nobody, while opinionated founders who care intensely about specific, even quirky details have outsized positive effect. Consensus at scale is treated as a design failure mode, not a safe default. Scope follows the same logic — Vision Scope: One Integrated Vision, Except for Multi-Business-Unit Giants says most companies need exactly one integrated vision, with genuinely multi-business-unit giants (Amazon: AWS, retail, Alexa) the real exception; if you're justifying a second vision, check whether your business units are separate companies or just teams.
Horizon is actively contested. The legacy norm was 3–5 years, some companies have pushed toward ten, and Vision Time Horizons Are Compressing Under AI-Driven Change argues the opposite under Gen AI pressure: ~18 months, with annual reviews — citing Superhuman's shift from speed/automation to "AI-powered communication quality" and Adobe's rapid Firefly integration as visions rewritten mid-cycle. Whatever the horizon, Vision Sprint Prerequisites: Homework Before the Room insists the homework precedes the room: a vision sprint runs about a week and is a synthesis exercise, not a discovery one, so it needs validated customer problems and corporate-strategy clarity already in hand — don't run one while corporate strategy decisions are still three months out. Trainline Research Method (Deep-Then-Broad Validation) is Moore's method for the validation leg: go deep first with smaller-scale qualitative research across key geographies to surface problems nobody has studied, then go broad with quantitative data to confirm they're representative.
A vision only functions if it's known — "it's not a vision if nobody knows about it." Vision Communication: Medium and Cascade Method favors video as a medium for its emotional carry, while warning that a slick video with a tagline and none of the core ingredients is marketing, not vision. All-hands presentations mostly demonstrate alignment rather than comprehension: everyone nods, few can restate it. The more effective path is a one-on-one cascade down the org, and the real check is a spot test — pull a random engineer and ask what the vision statement actually means. The same body adds three scaling techniques: co-creation is itself the best communication (people who shaped a decision don't need it re-explained), embed the message in ceremonies that already exist (all-hands, standups, planning, quarterly kickoffs) instead of a single reveal, and push past the point of feeling repetitive — per the rule of seven and a Weiner paraphrase, once you're sick of saying it, people are starting to hear it.
What a vision buys, concretely: Vision as Customer Commitment Device (vs. Roadmap) argues that in a fast-changing market customers would rather commit to a company's 3–5 year future than to a list of near-term deliverables that may not survive the quarter — and internally it reduces the pull toward reactive restructuring around every new competitive threat. Duplex-vs-Skyscraper Investment Analogy prices the vacuum in architecture: build a two-story duplex without knowing a skyscraper is coming and it works fine until the skyscraper is required, at which point you re-platform from scratch; under this condition team topology gets reorganized roughly every five months as new threats appear. Life-Cycle Framing for Market Expansion is the expansion technique: map the whole life cycle of the customer process you serve and treat adjacent stages as the vision's natural boundary — Datasite's vision grew from a single diligence-stage platform to a full "M&A life cycle solution" spanning pre-deal, diligence, integration, ongoing operation and future M&A, justified by the stakes ("nothing is more expensive than an M&A deal"). Vision also works as a recruiting mechanism: at Palace Hotels, buy-in for the pilot team came from casting a future rather than listing problems — "we gave people futures to build rather than gave them problems to solve," targeting "wow that is amazing" from leadership and "I want to be on that team" from the floor. Those two company narratives are told in full in Transformation in Practice.
Finally, for the PM inside a vacuum: What to Do When Your Company Has No Real Vision says don't panic — form your own point of view on what the vision should be, lean on research teams to validate it, read Inspired and Empowered, start introducing ideas to your manager, and informally educate the company on what a real vision looks like. The aim isn't to single-handedly write the company's vision; it's to build the case and the muscle until leadership adopts one.
Good strategy synthesizes three things, and the absence of any one is diagnosable. Focus + Transparency + Placing a Bet (Strategy Quality Rubric) states them as an audit you can run on any document calling itself a strategy: focus (explicit choices about what to do and what not to do), transparency (the insights and data behind the choice are shared, not just the choice), and placing a bet (a real commitment to an approach with no guaranteed outcome). A document that lists initiatives without ranking them, without showing the evidence that produced the ranking, and without accepting the risk of being wrong fails the rubric whatever it's titled. Strip out transparency and the bet and you're left with a roadmap; strip out transparency and keep the ambition and you get wishful thinking — "a lot of product strategies are just wishful thinking… There is no real analysis about how and why that's going to happen."
Janakiraman's Good Strategy's Three Components: Pillars, Non-Focus, and Why is the same discipline stated as document structure, synthesized from Rumelt, Lafley/Martin, Porter and Sun Tzu: a handful of strategic pillars where resources concentrate, explicit non-focus areas stated out loud rather than left implicit, and the why behind both — reasoning that makes the choice look inevitable rather than arbitrary. Pillars without stated non-focus areas invite scope creep straight back in; pillars without a stated why can't survive a skeptical stakeholder or a change in circumstances.
Transparency's canonical artifact is Amazon's Six-Page Narrative. Instead of a deck, the case for a decision is written as six pages of prose, and Cagan names it his favorite output for a product strategy precisely because prose forces the data and reasoning onto the page rather than just the conclusion — which is what makes the bet checkable by someone else instead of an assertion taken on faith. Yehoshua, who was at Amazon, remembers the ritual mattering as much as the document: attendees read the memo silently at the start of the meeting rather than sitting through a presentation, which forced writers toward complete linear argument and readers toward actually engaging with it — after which Bezos polled every team lead in the room and gave his own view last.
Placing Bets (Strategy-as-Bets Framing) is the part people flinch from. A strategy is an argument for a series of bets, not a promise of outcomes: choosing means committing to a problem as the most important one right now without being able to guarantee the result, and "it's a lot better to be uncomfortable on the thing that you believe is genuinely the most important" than to hedge across everything. Documented reasoning also redistributes the downside — a bet placed transparently is absorbed by the narrative and the process rather than by the individual who made it, which is what earns room to be wrong without it reading as failure. Practical devices: the forcing question — "if you had to make one bet to deliver to your investors this year, which one is it?" — collapses a list of supposedly co-equal priorities into an actual choice; Stukan names two or three bets for the coming quarter before any roadmap is drafted, then builds the roadmap around them; and Biddle's Netflix examples show both the long and the hedged version — personalization was funded roughly ten years before there was evidence it improved retention rather than just engagement, while interactive content, live news and live sports ran as parallel "chips down" experiments to find the next wave. Those cases get their full treatment in Netflix, Consumer Science, and Strategy Storytelling.
Focus is the operational half, and it has a number attached. Work-in-Progress Limits for Strategic Focus caps concurrent strategic focus areas at roughly two or three — not ten, and certainly not seventy — on the reasoning that parallel bets compete for the same scarce leadership attention and execution capacity, so nominal parallelism produces real slowdown rather than real throughput. The construction analogy: foundation, then walls, then roof; crowding the site with materials for a later phase creates clutter and risk without accelerating anything. Violate it and you get Peanut Butter Strategy — resources spread thin, even, everywhere, covering the surface and adding depth nowhere, the visible symptom of a leadership team that never did the choosing. The corpus treats evenly-spread resourcing across stakeholder asks as a warning sign that no real strategy exists regardless of what the documents claim, and reframes scale complaints as focus problems: a 300,000-employee company asking for $50M more budget gets "what if you focused" instead, and four-engineer teams are observed running circles around 200-person ones. Cagan puts the stakes plainly — "a company is going to live or die based on the choices it makes — which opportunities your company pursues, which threats you decide to take seriously."
Two refinements sit on top. Multi-Team Parallel Assignment for Critical Bets deliberately violates the WIP discipline for the highest-stakes problems only: assign the same critical problem to more than one team so different skill sets attack it in parallel and the odds that at least one succeeds go up. Used broadly it defeats the focus it's embedded in. And Introducing Focus as a Reversible Test is the change-management wrapper for organizations that have never worked this way: frame focus as a reversible experiment for a limited period, say plainly that the org can revert, and — critically — let the CEO or leadership team pick the focus area themselves. That halves the leap of faith, since leadership only has to trust that focusing is right, not also trust someone else's pick. Focus doesn't mean starving everything else: keep-the-lights-on maintenance and tech debt stay separate, always-funded categories, a distinction Roadmaps, Prioritization, and Outcomes develops.
Two sanity checks close the loop. Runway Reality-Check Exercise (Airbnb Workshop) — the Airbnb workshop where participants draft a grandiose founder strategy, then check it against the real constraint of a four-person startup with 12–18 months of runway — forces the gap check between ambition and resources before commitment. Sufficient-Pain Heuristic pushes from the other side: if building it is easy, it's probably not that special, because low-difficulty ideas have likely already been done. And when good strategies fail, the corpus says the usual cause isn't a bad choice but execution that proved too hard to crack, with capacity compounding against ambition — "just because you can do one in x amount of time doesn't mean you can do two in 2x." Which is itself an argument for the focus half: fewer bets keeps execution difficulty inside reach.
The failure modes cluster at two opposite poles of one axis. At one end, Mistaking a Roadmap for a Strategy — pure execution with no destination. Biddle names it directly: "many folks think they have a strategy and really all they have is a roadmap," a list of things to build with no underlying rationale for why those things and not others. The cost is specific: a roadmap can't be used to decline off-strategy requests nicely, by pointing at reasoning rather than asserting authority. The illustrating anecdote is LocalMind, an app built on Foursquare and Gowalla that let users ask people checked in nearby real-time questions; in hindsight the founder saw the team never had a strategy to win — winning would have meant becoming the default app when deciding where to go — so they just kept shipping features that made the product more useful and more fun without any of it converging on a destination. Making a product more useful is not the same as strategic progress. (Biddle's own fix runs through his DHM hypotheses, developed in Netflix, Consumer Science, and Strategy Storytelling.)
At the other end, MBA-Approach Strategy Failure Mode (High-Level Theory Without Bets) — pure destination-talk with no execution. Strategy conversations stay comfortably at market trends, competitive landscape and pontificating about emerging technology, and never descend into concrete plans, recommendations, bets and investments, because concrete bets are riskier and more falsifiable than theory. Both poles skip the same missing middle: translating ambition into an executable plan. A real strategy needs both a named win condition and the worked-out steps.
Janakiraman's structural guard against the first pole is physical separation of artifacts. The strategy doc and the roadmap are produced as two documents by design — "it's important not to include like a road map as part of a strategy doc because a strategy doc is meant to be separate from the road map" — and resourcing is walled off entirely: "I actually don't recommend thinking about resources in the strategy phase." Conflating what we can afford to build with what matters most is treated as a category error, resolved downstream at the roadmap stage. The strategy's job is to force explicit pillars and non-focus areas even without full resourcing certainty: "we may be wrong but we're not confused."
Then the political failures. Optionality Avoidance as a Strategy Failure Mode is the root one: exec teams often don't want to do real strategy work, because it means closing off options, so the strategy layer stays aspirational — and the tell is that individually interviewing the same exec team produces a different answer from nearly everyone. Outsourcing Strategy (Political Failure Mode) is the hedge that follows: hire an outside firm to produce the strategy, and the incentives are asymmetric — if it works the leader who commissioned it claims the decision, if it fails the consultants take the blame. It's a symptom rather than a strategy problem per se: it signals the organization never built internal muscle for gathering evidence, making the trade-offs, and writing the why down. The fix is moving ownership back inside even if that's slower and messier. (The same body carries Cagan's parallel argument about outsourced engineering being structurally incompatible with the product model, since engineers there are expected to contribute to discovery and problem-framing rather than implement handed-down specs — see The Product Operating Model for what that role actually involves.)
The individual-level failures are more sympathetic and just as costly. Product Strategy Excuses as Fear-Avoidance takes apart the two standard excuses — "I don't have time" (usually paired with "I have it in my head" or "our plans and goals already reflect it") and "we don't have a company-level strategy, so how can I be expected to have a product one" — and argues both are rationalizations. The real cause is fear of two kinds: a private suspicion of not being good at strategy, and dread of how whatever gets produced will be received. It's compared to writer's block, and the prescribed fix isn't a technique but a sequence — recognize the fear, accept it as the actual obstacle, then work on it. The companion practical answer for the second excuse lives in What to Do When Your Company Has No Real Vision: even a fully crisp company strategy would only supply minor directional guidance, so its absence is an information-gathering gap rather than a blocking dependency. Substitute bottom-up common sense (reasonable assumptions about revenue growth, key segments, active users) plus top-down cues mined from all-hands, CEO remarks and investor decks — and accept that the genuinely hard, undelegable part is unchanged either way: insight and creativity about your specific product, segments and differentiation.
Shreyas Doshi's Strategy 'Keeps Changing' as a Clarification-and-Buy-In Failure reframes the most common PM complaint of all. When "strategy and priorities keep changing every week," at least half the time it isn't external chaos — it's that the PM, group PM or director never clarified a strategy for their own area and got explicit buy-in on it upward. The mechanism is mundane: a strategy's whole point is to be the framework future decisions get evaluated against, and without one agreed, upper management has nothing to filter against, no time or context to derive a strategy on the PM's behalf, so they default to reacting to whatever is newest. What feels imposed is frequently a vacuum the PM left open. The other half of cases are real and not clarification failures: a genuinely undisciplined organization, a genuinely fast-moving industry (crypto a few years back, AI now), or an upstart deliberately shifting to react to a larger incumbent — which Doshi treats as legitimate on one condition, that it's done intentionally rather than stumbled into.
Finally, a caution about the whole genre of strategic advocacy. Always-True Statements (Vacuous Consensus Claims) flags claims that are true in essentially every room — "we need better processes," "we need to be more customer obsessed," "we need to be product led" — and get nodding agreement precisely because no company exists for which the opposite holds. Being right isn't a prioritization argument: dozens of other always-true statements compete for the same scarce attention. "Product Led" Is Not the Goal — Product and Business Success Is applies that to the corpus's own house ideology: product-ledness is one way to organize, not the target — the target is product and business success — and highly successful companies like Oracle and Salesforce aren't product led. And Only Senior Leaders Can Make an Org Product Led — ICs Don't Have the Capital to Spend is blunt about who can act on the claim even when it's correct: an IC PM at a 50,000-person telco, at General Motors or Bank of America, cannot make that company product led — "it is not going to happen" — because the only mechanism is a senior leader convincing the CEO, exec team and board that the change is worth trading against everything else, which costs career capital an IC doesn't hold. The advice that follows is deliberately unglamorous: make your own team more product led, learn what the environment can teach, upgrade your skills to the market's expected level, and move to a company that already knows how to do this. Org-wide change and who can drive it is the subject of Transformation in Practice.
Chandra Janakiraman's premise is a rejection: there is no strategy gene — "it was almost as if there was a strategy Gene you needed to be born with to be good at it" — and strategy is a learnable, repeatable procedure provided the inputs are gathered faithfully, since "the output is determined by the quality of your input." Present Forward: A Five-Phase Process for Problem-Focused Strategy (also "small-s strategy") is the resulting playbook: a problem-focused strategy on roughly a two-year horizon, run end to end in 8–12 weeks across five phases. Its structural bet is that alignment is a byproduct of how the strategy gets built — cross-functional co-creation and staged socialization — not something bolted on afterward with a persuasive deck.
Preparation (~4 weeks). A Strategy Working Group (Cross-Functional Strategy Co-Creation Team) — a temporary, PM-led, cross-functional team with at minimum engineering, product, design and data represented — splits six research streams one per member, each on a four-week deadline: behavioral-data meta-analysis, UXR insight meta-analysis, leadership interviews, competitive stack analysis, adjacent-roadmap review, and direct user observation for empathy. Results roll into a single shared preparation readout. The working group is distinct from the ongoing trio that runs day-to-day discovery (The Product Operating Model); it's a wider body assembled to produce one strategy, and the mechanism it exists for is simple — people who help build a strategy default to defending it.
The leadership-interview stream carries the most transferable technique, filed under Exec Strategy Interview Diagnostic. Leaders divide among working-group members for 1:1s using a fixed question set — what does success feel like, what does failure look like, what's the measure of success, what principles should we keep in mind, and any pet ideas you want considered. Asking directly about pet ideas is framed as strength and humility rather than deference: leaders carry unshared opinions they're shy to surface for fear of seeming to micromanage, and surfacing one early lets the group evaluate it on the same footing as everything else instead of having it reappear as a late veto. The "fruit story" is the cost of skipping this — bringing a reviewer a mango, then an apple, then a banana, each rejected, because nobody asked what they actually wanted first. A sound strategy can still be shot down on preference grounds.
Strategy Sprint (~1 week). Day 1 is a share-out that gets everyone on the same base data before any decision-making. Day 2 is, in Janakiraman's words, "literally the most important day in the entire like 8 to 12 weeks" — Strategy Sprint Day 2: Problem Clustering, Reframing, and Pillar Ranking runs four steps: each member independently writes the problems they see (before discussion, to avoid anchoring on the loudest voice), the problems get clustered into roughly 10–15 groups, each cluster is reframed from a negative problem into a positive opportunity, and the opportunities are scored against four criteria — expected impact, certainty of impact, clarity of levers (how well understood the mechanism is), and uniqueness of levers (how differentiated the approach would be). Scores are qualitative when data is thin, and the group debates and scores together, because the debate is what builds the alignment. Down-selection converges on exactly three pillars — a hard power-of-three constraint rather than the 3–5 range some practitioners use, justified on the grounds that fewer pillars force sharper focus.
The sprint also produces the winning aspiration via Newspaper Headline Exercise for a Winning Aspiration: each participant imagines a journalist covering the team's progress two years out and writes that article's headline alone, then the group converges with a "blender" technique — scanning all the headlines for recurring words and phrases and building one combined statement from them, rather than picking a favorite or averaging into blandness.
Design Sprint (~1 week). Each pillar becomes one to three How Might We / Fertile Questions — the phrasing credited to Andrew Chen for opening solution space wider than a flatter "how do we" would — with roughly an hour spent per pillar, then handed to design and UXR as a brief. Design Sprint for Strategy Pillars (Illustrative Concepts) is explicit that the goal is not deciding what to build: the mocks exist to make each pillar tangible enough for stakeholders to react to, persuasive rather than committal. Design picks its own format — the Google Ventures five-day Design Sprint if the open question is what this should look like, or the Bullseye Sprint (from a GV colleague) if the open question is who exactly it's for.
Document (~1–2 weeks). The PM writes it alone, 3–4 pages, following Strategy Doc Template (Present Forward): broader context; key insights and analysis; the strategic pillars with rationale plus an appendix carrying the Day-2 scoring table; the winning aspiration with the design concepts embedded; and closing alignment questions. It's shared as a near-final draft with the working group before rollout. The scoring appendix isn't decoration — it's what later lets a challenged pillar be defended on criteria instead of re-litigated from scratch.
Rollout (~2–3 weeks). Strategy Rollout Socialization Ladder escalates rather than announcing: roughly two or three key gatekeepers get 1:1 pre-flight meetings first, so nobody with veto power hears the strategy for the first time in a group; then broader stakeholder review in controlled settings; then team road shows in groups of eight to ten. Each rung is meant to land the strategy, not reopen it — "the purpose of the stage is to land it, it is not to like seek too much feedback, so it's a delicate balance" — and requests to change a pillar have to be argued against the original Day-2 criteria rather than granted on seniority or pushback alone. The influence craft this depends on is the subject of Stakeholder Power and Trust. As a final check, the finished document is run against the Playing to Win Framework's five cascading questions to confirm it answers them rather than just listing pillars with rationale.
Running alongside all of it is Future Backward (Big-S Strategy) — the aspirational counterpart. Where Present Forward is problem-focused, 8–12 weeks, two-year horizon and PM-led, Future Backward is anchored in mission and vision, aimed 5–10 years out, can run up to six months, and is led by design and UXR on the theory that blue-sky thinkers should be pointed at open-ended futures while metric-focused thinkers stay on nearer-term problem-solving. Its process: scan long-term cultural, social and technological trends; interview leadership about the far future; generate three distinct possible futures; build Concept-Car Prototyping (Big-S Strategy) prototypes of each — borrowed from auto shows, built to provoke rather than ship, with the real output being a single compelling nugget extracted from each before the prototype is discarded; test with real users; converge into the roadmap. The two tracks run as parallel tributaries feeding the same river rather than in sequence.
Dan Olsen's method comes at strategy from underneath — from the customer's problem rather than the org's decision layers — and it starts with one discipline. Problem Space vs. Solution Space treats the two as sides of one coin: problem space is the customer problem, need or benefit; solution space is the specific feature or design that meets it. Olsen calls defining who the customer is and what their problems are the PM's central job, cites 80–90% of new products failing, and splits the causes: teams either start from a solution instead of a problem, or validate a real problem that nonetheless isn't a good opportunity. He also splits problem work into two steps that get collapsed too often — first get specific about what the problem is, then separately validate that it's real by talking to customers, because a defined problem isn't an automatically validated one. Skipping the second is "throwing spaghetti at the wall and seeing what sticks."
The phrasing rules do a surprising amount of work. Solution Pollution is Olsen's term for smuggling a solution into a problem statement — writing "I don't want to walk" instead of "I need to travel short distances" — which forecloses other ways of meeting the need; the fix is restating at the benefit level and confirming that several meaningfully different solutions could satisfy it. User Story 'So I Can' Template gives the test: in "As a [type of user], I want to [do X], so I can [enjoy benefit Y]," the "I want to do X" clause is solution and the "so I can" clause is problem — audit a backlog by checking whether that clause names a genuine benefit rather than restating X or sitting empty. Benefits should start with a verb, not an abstract noun: "security" hides what the product actually does, while "protect my identity from theft" forces clarity. Olsen's convention keeps problem statements verb-led and competitive claims in comparative adjectives — faster, cheaper, nicer, safer — so the two framings don't blur on the same slide. When a stakeholder pitches a feature, his response surfaces the hidden problem statement rather than debating the feature: "I hear you saying we should build feature X — can you help me understand how's that going to benefit the customer?" Fishing/Bait Analogy (Target Customer) is the version for people who want to skip research entirely: the product is the bait and the target customer is the fish, so ask which fish we're trying to catch and whether this bait works on them.
Two complementary moves map the problem space. Onion Model (Problem-Layer Peeling) peels downward — a generic statement like "help me prepare my taxes" gets layers pulled back until you reach atomic benefits (avoid math errors, feel confident about audit risk, minimize time spent). Benefit Ladder climbs upward via five whys — "why does that matter to you?", repeated — until different customers' different complaints converge on the same one or two macro benefits. Olsen's TurboTax ladder tops out at improve confidence, save time, save money, each with children underneath. The strategic use is a filing test: sort every candidate feature idea into an existing rung, because most "new" ideas aren't new value at all, just another way to deliver an evergreen benefit. Needs outlast their solutions — "listen to music on the go" produced troubadours, transistor radios, the Walkman, the Discman, MP3 players, the iPod and finally phones — so a genuinely new top-level rung is rare and worth flagging when it appears. The deliverable of all this is a cleaned-up, deduplicated, laddered list of customer benefits, and that list, not a feature list, is the input to prioritization.
Importance vs. Satisfaction (Opportunity) Framework prioritizes it. Plot each need by importance to the target segment against satisfaction with the current solution; the high-importance, low-satisfaction corner is the biggest opportunity, scored as importance × (1 − satisfaction) and renderable as a heat map. Olsen shapes the two scales differently on purpose: importance on a 5-point one-sided scale, satisfaction on a 7-point bipolar scale with a neutral midpoint, because customers can be actively dissatisfied, not merely unsatisfied. When everything clusters at "extremely important," force differentiation with a finer scale, forced rank-ordering, or a constant-sum exercise ("distribute $100 across these needs"). Without survey data, use the coarse 3x3 grid, a team sticky-note exercise where the group debates each placement, or the line-from-corner shortcut — the shorter the line from the ideal corner, the bigger the opportunity. The case studies do the teaching: Segway targeted walking, already high on both importance and satisfaction, and won only niches (mall cops, tour guides); Uber targeted ground transportation, high-importance and low-satisfaction thanks to taxis, and filled an open gap. This is explicitly first-pass prioritization, done before engineering scopes anything.
Two Competitive Strategies: Upper-Left Capture vs. "To-11" Disruption turns that into two named competitive postures. Upper-left capture is the lower-risk one: nobody has to be dislodged from a solution they like, because no solution is liked yet. "To-11" disruption is the high-risk one: attack a need that's already well satisfied and try to reset the ceiling itself. Both Uber and Segway attacked a "getting somewhere" problem; the outcomes track the quadrant each chose, not execution quality alone. The gate on the risky path is the "10x Better" Rule — against an incumbent like Google Search, small improvements get absorbed by switching costs and habit, so the honest question is whether the solution is a dramatic leap or an incremental one; if it's "a bit better," the opportunity isn't really open.
The Product Strategy Grid is where all of this becomes a decision. Rows are customer needs for an explicitly chosen time frame (1 vs. 3 vs. 5 years produce different answers), each categorized as must-have, performance or delighter — the labels come from the Kano model, which this chapter's material uses without developing. Columns are your product plus competitors defined broadly in Porter's spirit: substitutes and manual workarounds count, so a spreadsheet, a taxi stand or duct tape belongs on the grid. Cells score low/medium/high on how well each competitor meets each need. Reading it surfaces where you're undifferentiated, where you're genuinely ahead, and whether you own a delighter nobody else has — and the intended output is small and specific: one performance benefit to win on plus one unique delighter, not a feature list. Olsen frames this as deliberately declining to fight a competitor's unbeatable strength. One refinement: weight a performance dimension by how often the target segment invokes it — shaving two seconds off a search is worth ~100 seconds a day to a 50-query power user and almost nothing to a rare searcher.
Downstream sits the Lean Product Process: brainstorm solutions for the chosen benefit and delighter, spec an MVP, prototype, validate with customers, then build — treating the grid's conclusion as a hypothesis to test, not a settled answer. Olsen's claim is that most product failures come from starting here, at solution and build, without the problem-space and grid work first. The recurring wreck is the must-haves-only MVP: a team falls behind, ships only the must-haves, creates no differentiated value, underperforms, and blames the MVP methodology rather than the scope decision that dropped the performance and delighter dimensions. The two halves hand off cleanly into ROI: the quadrant's opportunity score feeds Return, the scoped solution feeds Effort, so scoping effort is only spent on ideas already tied to a validated high-opportunity need. Tom Verrilli's version of the same loop states the expected impact as an explicit hypothesis, designs the smallest test that could check it, and lets the result decide the next version of the plan.
Since successful companies rarely publish their grids, Olsen reconstructs them with the Product Archaeologist Method — mining old Series A decks, later UX retrospectives and founder interviews, and mapping their claims onto the must-have/performance/delighter categories rather than accepting each artifact's own framing. It only works where a public trail exists, which is why the same two examples recur (he considered Airbnb and dropped it for lack of clear artifacts). Instagram's 2010 Strategy (Performance + Delighter Case Study): launching into a crowded photo-sharing category, Instagram matched competitors on must-haves and won on one performance edge (faster posting) plus one delighter (filters, then unique) — the grid pattern in the wild, compressed into a tagline. The implementation behind it is instructive because it wasn't compression tricks: Optimistic Background-Upload UX Pattern started the upload the instant the photo was taken rather than at Share, since 95–99% of photos taken get posted, and Uniform Aspect-Ratio Feed Normalization cropped everything to a square so a heterogeneous feed rendered consistently — a container-level fix rather than a per-photo one, and one users initially resented. The product itself came from Pivot via Usage-Driven Repositioning: when the broader Burbn check-in app stalled, the founders looked at what people actually did with it, found photos, and treated that narrower category as the new competitive set. Uber's Series A Positioning (Three-Dimension Case Study) is the rarer three-dimension win — "faster and cheaper than a limo, but nicer and safer than a taxi" — which Olsen attributes to context rather than exceptional execution: a monopolistic, customer-value-decoupled industry plus mobile and GPS that neither incumbent had opened several dimensions at once instead of the usual one. The benefits slide had a reusable structure: two problem bullets per competitor, then one synthesizing comparative line. That line is also where this chapter brushes against Positioning, Marketing, and Go-to-Market.
Underneath the whole toolkit is Olsen's account of why a PM needs it. He inverts Spider-Man — "with great responsibility comes power," and states the sharper version bluntly: "with great responsibility comes no power," since a PM is accountable for outcomes without authority over the people who build the thing. PM Motto: With Great Responsibility Comes Power resolves it by locating leverage in ownership of the problem space: rigorously defining the customer and the problem before anyone proposes a solution is the PM's unique value-add, distinct from prioritizing or spec'ing features — and buy-in earned that way is what formal authority never grants.
A strategy that ships and then sits is already decaying. Continuous Strategy Feedback Loop describes the maintenance mechanism: problems teams surface during solution discovery get routed back to the product leader rather than acted on unilaterally, and become inputs — alongside executive and business input — to the next cycle's strategy. That's what lets an org do genuine problem discovery without fragmenting its bets: newly discovered problems change next cycle's strategy, not this cycle's execution. The cadence is at minimum quarterly and in practice closer to continuous — "I believe that a product strategy is a living thing… it's just constantly updating as you learn" — and the contrast with vision is the cleanest statement of the difference between the two layers: "visions don't change, but strategies change a lot." Horizons scale to maturity: long for an established company, no longer than the runway for a startup. Eriksson frames quarterly as the new floor, replacing the older habit of setting vision at 3–5 years and strategy at 1–3 and then leaving both alone, with faster reaction when something like AI forces it. Cagan's version in Transformed is the same cadence with an explicit target: it replaces ad hoc, stakeholder-driven resource allocation where whoever complains loudest gets staffed. The corpus also notes two things about the document itself — external shocks (COVID is the example) can force a rewrite, and strategy docs are treated as more politically sensitive inside a company than its code, because they state plainly what leadership has decided isn't worth attention right now.
Feeding that loop takes standing channels rather than a research project. Four Sources of Insight (for Product Strategy) names four: customers, data, technology, and industry trends — with Cagan explicitly citing generative AI as the current instance of the technology source, meaning staying current on what new technology makes possible rather than only tracking the other three. Sustained over months, these are also what produce the judgment the earlier layers assume, which is the subject of Product Leadership and Career Craft. On AI in the strategy itself, this material's position is narrow and useful: whether AI belongs in a strategy at all is almost always yes, and the harder question is whether a specific problem is technically ready for a probabilistic solution and what guardrails wrap it. For crafting the strategy, "the primary tool is the brain" — AI can sharpen that thinking or quietly substitute for it. The larger disruption is AI and the Changing Shape of Product Work.
Whether the strategy actually reached anyone is testable. Strategy Penetration Test checks the individual contributors, not the team leads: offer someone alternate work and watch. If the strategy penetrated, they push back and explain why their current work matters in strategy terms; if it didn't, they escalate to their manager asking for "prioritization," because they have no independent basis to judge the trade-off. That's the strategy-side twin of the vision spot check in Vision Communication: Medium and Cascade Method — pull a random engineer and ask what the vision statement means — and it's the reason the 95%-can't-name-the-strategy finding behind Exec Strategy Interview Diagnostic gets read as decay rather than as a one-time communication failure.
And then the humbling part: process buys rigor and alignment, not correctness. Strategy Judged by Results, Not Process (Oculus vs. Portal) is the cleanest evidence in this chapter — Meta's Oculus and Portal growth teams ran the identical Present Forward process and arrived at similar pillars; Oculus succeeded and graduated into Meta's VR division, Portal was sunset. "Any strategy is only as good as the results it can produce." The market is the scoreboard. Zynga's Three Growth Pillars (Case Study) shows a different decay: three genuinely durable pillars — viral loops requiring an active social graph, pay-to-complete monetization, and cross-game network promotion — drove enormous growth in the Facebook-platform era, then lost fit when the market moved to mobile, where distribution and social graphs didn't reward the same mechanics. A pillar's shelf life is bounded by the conditions that made it resonate; a strategy is a bet tied to a market moment, not a formula.
The counterweight is Slack's Fixed Four-Box Master Plan, reported by Tamar Yehoshua from her time as CPO under Stewart Butterfield. In 2014 Butterfield sketched four boxes — a product people love, network effects (later Slack Connect), platform, and AI — and the skeleton stayed fixed for years while the initiatives inside each box and the yearly priorities changed repeatedly. The distinction it draws is the practical one to end on: a durable strategic skeleton, rarely revised, with a tactical layer underneath that revises constantly. That structure is also why Slack's changes never read as thrash, unlike the pattern in Strategy 'Keeps Changing' as a Clarification-and-Buy-In Failure — the destinations never moved, only which one got the most attention that year. How that yearly attention becomes an actual plan of work is where Roadmaps, Prioritization, and Outcomes picks up.