A common failure Gibson Biddle calls out: teams believe they have a Product Strategy when what they actually have is only a Roadmap (Feature/Project List) — a list of things to build, with no underlying DHM-style rationale (DHM Framework (Delight, Hard-to-Copy, Margin-Enhancing)) for why those particular things and not others. A roadmap without a strategy behind it can't be used to say no to off-strategy ideas, which Biddle treats as one of strategy's core jobs: letting a leader decline requests 'nicely' by pointing to the reasoning, not just asserting authority. See also Inventory-as-Vision Anti-Pattern for the parallel failure one level up, at vision rather than strategy.
Gibson Biddle names this directly: "many folks think they have a strategy and really all they have is a roadmap." His fix is procedural: articulate the underlying hypotheses about how you'll delight customers in hard-to-copy, margin-enhancing ways before building the roadmap, then derive the task list from those hypotheses rather than starting with the list of things to build. See DHM Framework (Delight, Hard-to-Copy, Margin-Enhancing).
A guest on Lenny Rachitsky's podcast described founding LocalMind roughly 10-12 years earlier, an app built on top of Foursquare and Gowalla that let users ask people checked in nearby real-time questions (e.g., whether a bar across town was worth going to). In hindsight, the team never had much of a strategy to win — winning would have meant becoming the app people default to whenever they're deciding where to go, and a real strategy would have named that destination and worked backward to the steps needed to get there. Instead, the team just kept building and shipping features that made the product more useful and more fun, without any of it converging toward that or any other defined direction.
The general lesson: making a product more useful or more fun is not the same as making strategic progress — feature-shipping can feel productive while the product drifts with no destination. See MBA-Approach Strategy Failure Mode (High-Level Theory Without Bets) for the opposite-pole failure: staying at pure theory and never landing on execution.
In Janakiraman's Present Forward: A Five-Phase Process for Problem-Focused Strategy, the strategy document and the roadmap are produced as two separate artifacts by design — the strategy doc (written by the PM alone, ~3-4 pages, following a fixed structure covering pillars, non-focus areas, and the why per Good Strategy's Three Components: Pillars, Non-Focus, and Why) is finished and rolled out via the Strategy Rollout Socialization Ladder before roadmap prioritization happens. Keeping the documents physically separate is presented as a structural guard against the strategy silently collapsing into a feature list.
Chandra Janakiraman treats resourcing — what percent of engineering goes to each pillar, what specifically gets built — as deliberately out of scope for the strategy phase of Present Forward: A Five-Phase Process for Problem-Focused Strategy: "I actually don't recommend thinking about resources in the strategy phase." A strategy doc should stand as a companion to the roadmap, not fold the roadmap in: "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." The strategy's job is to force explicit pillars and non-focus areas (Good Strategy's Three Components: Pillars, Non-Focus, and Why) even without full resourcing certainty — "we may be wrong but we're not confused." Resourcing and build decisions are resolved afterward, at the roadmap stage.