Most product teams don't have a strategy problem. They have a naming problem.
They call a roadmap a strategy. They call quarterly themes a strategy. They call a pile of stakeholder requests a strategy. Then they wonder why engineering feels busy, design feels fragmented, leadership feels unconvinced, and customers don't feel much of anything.
I've sat in enough roadmap reviews to know the pattern. Someone says, "Our strategy is to win in AI, improve engagement, and deepen enterprise adoption." That sounds polished. It also tells the team almost nothing about what challenge matters most, what trade-offs they'll make, and what gets cut.
That confusion matters more now because PMs are being asked to think strategically earlier in their careers. A 2025 Productboard survey of 1,200 PMs found that 68% struggle with strategic alignment in their roadmaps, and job-seeking PMs face a 40% increase in strategy-related interview questions as of 2026 according to this PM-focused writeup on Rumelt's framework. The market is asking for strategic thinking, but most PM advice still teaches prioritization mechanics, not strategy construction.
Richard Rumelt's Good Strategy Bad Strategy is useful because it cuts through that confusion. But most summaries stop at the CEO level. PMs need the field version. The version you can use in your next roadmap meeting, your next AI planning offsite, and your next interview loop.
Why Most Product 'Strategy' Is Actually Bad Strategy
The most popular advice in product is also some of the worst. "Talk to customers constantly." "Align stakeholders." "Ship fast and iterate." All of that can help. None of it is strategy.
A team can run customer interviews every week and still chase the wrong problem. A PM can align ten stakeholders around a roadmap that has no real impact. A startup can ship fast in six directions and call the chaos learning.
That's what bad strategy looks like inside product organizations. It usually appears in one of three forms:
- Feature-led planning: The roadmap is a list of outputs with no clear theory of advantage.
- Goal-only planning: The document says "grow retention" or "win enterprise" but never explains how.
- Consensus planning: Every function gets something, so no customer problem gets solved thoroughly.
PMs feel this quickly. Engineering gets whiplash. Design works on disconnected surfaces. GTM teams can't tell a clear story. Leadership asks why the roadmap looks ambitious but not convincing.
Good strategy in product is not a vision statement. It's a sharp explanation of where you'll focus and what you'll ignore.
This is why good strategy bad strategy matters so much for PMs. Strategy isn't reserved for founders and executives. It's a daily working skill. Every time you decide whether to invest in onboarding, reliability, workflow depth, AI assistance, integrations, or monetization, you're making strategic choices whether you admit it or not.
If you don't make those choices explicitly, your org will make them accidentally. That's when roadmaps turn into political artifacts instead of competitive ones.
The Kernel of Good Strategy Your North Star
Richard Rumelt's book, published in 2011, has sold over 500,000 copies worldwide, and its core idea, the kernel of good strategy, was cited as a key influence in NVIDIA's 2010s turnaround. During that period, NVIDIA's market cap grew from $5 billion in 2011 to over $2 trillion by 2023, as noted in these notes on Good Strategy Bad Strategy.
That kernel has three parts. Diagnosis. Guiding policy. Coherent actions.
Diagnosis names the real problem
Most PMs skip this part because it feels slower than ideation. That's a mistake.
Diagnosis is your explanation of what's blocking progress. Not the visible symptom. The underlying constraint. If activation is weak, diagnosis isn't "activation is weak." That's reporting. Diagnosis might be: new users don't reach value because setup requires cross-functional admin work that small teams won't complete.
A good diagnosis simplifies reality without oversimplifying it. It says, "Among all the mess, this is the obstacle that matters most."
In product work, diagnosis often comes from combining:
- Behavioral data: Funnel drop-offs, retention patterns, usage depth
- Customer evidence: Call notes, support logs, sales objections
- Competitive context: Where rivals are stronger, slower, or overbuilt
- Operational truth: What your team can deliver well
If you need a useful companion piece on setting a product-level organizing metric once your diagnosis is clear, Aakash Gupta's thinking on North Star vision is helpful because it connects strategic intent to what teams measure.
Guiding policy sets the lane
Guiding policy is not a mission. It's not "customer obsessed AI innovation."
It's a policy because it tells the org how you'll approach the challenge. It creates boundaries. It rules out attractive distractions.
If the diagnosis is that users fail to adopt because setup is too complex, a guiding policy might be: simplify first-run success for the smallest viable team before expanding advanced workflow depth.
That one sentence does real work. It deprioritizes edge-case customization. It shifts design energy toward defaults. It changes what sales can promise. It reframes AI features from flashy add-ons to setup accelerators.
Many teams in startup environments struggle with the desire for strategy to encompass everything. It can't. If you're working on early-stage products, resources on mastering startup product design can be useful because design choices often either reinforce the policy or subtly undermine it.
Practical rule: If your guiding policy doesn't force at least one meaningful trade-off, it probably isn't a policy.
Coherent actions make the strategy real
This is the difference between a strategy deck and a winning product plan.
Coherent actions are a coordinated set of choices that reinforce each other. Not independent bets. Not "we'll also do this." They should feel designed, not collected.
A PM should be able to point to each roadmap item and explain why it supports the policy. If the policy is setup simplification, coherent actions could include:
- Reduce setup decisions: Replace open-ended configuration with opinionated defaults.
- Shorten time to first output: Generate sample data, example workflows, or starter content.
- Use AI where it removes friction: Auto-map fields, summarize uploaded files, or draft first outputs.
- Rebuild onboarding instrumentation: Track where users stall and why.
- Retrain GTM messaging: Sell speed-to-value, not broad flexibility.
Notice what's missing. A random pricing experiment. A dashboard redesign nobody asked for. Three enterprise asks from one loud prospect. Good strategy cuts those off.
NVIDIA's story matters because it shows this isn't academic. The kernel works when a company identifies the challenge, chooses a focused policy, and backs it with coordinated actions over time. PMs need the same discipline at product scope.
The Four Red Flags of Bad Strategy Waving in Your Roadmap
Most bad strategy reveals itself long before results go bad. You can usually spot it in the roadmap doc, the kickoff deck, or the language leaders use when they're trying to sound strategic.
Rumelt's four hallmarks are a practical PM diagnostic. Once you know them, you can't unsee them.
Fluff
Fluff is strategy theater. Fancy language standing in for hard choices.
Bad PM example: "Harness AI-powered personalization synergies to transform user engagement across the platform."
That sounds important. It says nothing.
Better PM example: "Use AI recommendations to help returning users find relevant content faster in the existing feed experience."
The second version names a user, a problem, and an approach. It gives design and engineering something to respond to. It can still be wrong, but at least it's concrete.
Failure to face the challenge
This is common in healthy-looking companies. Teams talk about expansion before they've admitted what isn't working.
Bad PM example: "Expand into enterprise with advanced governance and admin controls."
Maybe. But what if the actual challenge is that mid-market customers still don't adopt the core workflow after purchase? Then enterprise expansion becomes avoidance disguised as ambition.
Intel's pre-1984 persistence in DRAM is the classic warning. In Rumelt's framing, they ignored the challenge posed by Japanese cost advantages and kept pursuing vague goals, contributing to margins collapsing from 40% to under 10%. More broadly, bad strategies are linked to execution failure rates of 80-90% in major enterprises, as summarized in this review of Rumelt's argument and the Intel example.
Mistaking goals for strategy
A goal says where you want to go. Strategy says how you'll deal with the obstacle in the way.
Here's the comparison PMs need:
| Statement type | Example | Problem |
|---|---|---|
| Goal | "Become the leading AI assistant for finance teams" | No path |
| Plan fragment | "Launch AI chat, reporting, and forecasting" | Features without logic |
| Strategy | "Win finance teams by making reconciliation faster inside existing workflows before expanding into broader planning use cases" | Focused response to a challenge |
I see this in interviews constantly. Candidates describe aspirations and outputs, then call it strategy. Senior PMs don't get promoted for naming the destination. They get promoted for designing the route.
Bad strategic objectives
These are objectives that teams can't operationalize, or that don't address the core issue.
Bad PM example: "Ship a world-class AI platform by Q4."
That's not an objective. It's a slogan with a deadline attached.
Good PM example: "Reduce friction in the highest-volume user workflow by embedding AI assistance directly in-task rather than launching a separate AI workspace."
That objective is narrow enough to guide work. It can shape hiring, UX, platform decisions, and launch scope.
If every team can interpret the objective differently, the objective isn't strategic enough.
A quick self-test
Look at your current roadmap and ask:
- Does the language hide the problem?
- Have we named the obstacle, or only the ambition?
- Do our top initiatives reinforce one another, or are they politically balanced?
- Would a new PM understand what not to do from this strategy?
If the answer to that last one is no, you're not looking at strategy. You're looking at a negotiated task list.
Your PM Toolkit for a Ruthless Strategy Audit
A strategy audit should feel uncomfortable. If it doesn't, you're probably reviewing formatting, not judgment.
I use a simple rule in product reviews. A strategy should survive five brutal questions. If it fails any of them, pause execution and tighten the thinking before you ask the team to commit more cycles.
The five-question audit
What is the challenge?
If the answer starts with a business goal, you're already off track. The answer should name a friction point, market constraint, competitive weakness, adoption barrier, or capability gap.What are we choosing not to do?
Strong strategies exclude. Weak ones accumulate. If nobody can name the sacrifices, there probably aren't any.Can the guiding policy fit in one sentence?
Not because short is elegant. Because long usually means blurred. The sentence should create guardrails that help teams reject good ideas that don't fit.Do the roadmap items reinforce each other?
Many plans often collapse due to this. The initiatives look individually reasonable but collectively random.Where is the point of greatest impact?
Not every problem deserves equal investment. Good PMs isolate the point where effort changes the trajectory of the product.
For competitive inputs during this exercise, a structured reference like this competitive analysis framework template helps teams separate real product asymmetries from vague fear of competitors.
What to bring into the meeting
Don't walk into a strategy audit with a slide deck only. Bring evidence.
- A one-page diagnosis: Summarize the core challenge in plain English.
- Behavior snapshots: Include the product signals that support the diagnosis.
- A decision log: List the major trade-offs under discussion.
- Competitive notes: Show where rivals are meaningfully stronger, weaker, or different.
- A kill list: Name initiatives that sound useful but don't support the policy.
The fastest way to expose weak strategy
Ask each cross-functional lead to answer this question privately:
"What is the one thing this roadmap is designed to fix or win?"
If you get five different answers, don't argue about prioritization yet. You don't have a prioritization problem. You have a strategic coherence problem.
This is also one place where one publisher resource can help. Aakash Gupta's content is built for PMs who want sharper product judgment and career growth, and it's useful as one input alongside your own roadmap reviews, market evidence, and team retrospectives.
A short scorecard
Use this in your next review:
| Audit area | Strong answer | Weak answer |
|---|---|---|
| Diagnosis | Names a specific obstacle | Repeats a KPI trend |
| Guiding policy | Creates trade-offs | Sounds like a company value |
| Actions | Mutually reinforcing | Assorted initiatives |
| Leverage | Focuses effort | Spreads investment evenly |
| Clarity | Easy to explain | Dense and buzzword-heavy |
A strategy audit isn't about sounding smarter. It's about protecting the team from spending a quarter building disconnected things.
Crafting Your First Good Product Strategy A Step-by-Step Guide
Most PMs don't need a bigger strategy framework. They need a usable process.
When I'm helping a team build a product strategy from scratch, I keep it brutally simple. Start with diagnosis. Then write a guiding policy that creates boundaries. Then build coherent actions that stack.
Phase one diagnosis
Don't begin with brainstorming. Begin with evidence synthesis.
Pull together four inputs:
- User behavior: Where do users stall, abandon, return, or deepen?
- Customer language: What exact frustrations show up in interviews, demos, support tickets, and sales calls?
- Competitive pattern: Where do competitors win deals or attention?
- Internal capability reality: What can your team build and sustain well?
Then write a diagnosis memo using this template:
| Prompt | Your answer |
|---|---|
| What is happening? | Describe the visible product problem |
| Why is it happening? | Name the likely underlying cause |
| Why now? | Explain why the challenge matters this planning cycle |
| Why us? | Clarify the capability or asset you can use |
| What would be a costly misread? | Note the tempting but wrong diagnosis |
For broader structure, this product strategy framework is a useful reference because it helps connect diagnosis to market choice and execution logic.
A common AI product example: teams say, "We need an AI copilot because users expect AI." That's not a diagnosis. A stronger diagnosis sounds like this: users abandon complex workflows because they don't know the next best action, and the current product asks them to translate intent into too many manual steps.
That diagnosis creates options. The first one doesn't.
Phase two guiding policy
Now write the policy. One sentence is enough if it's sharp.
Use this formula:
We will address [core challenge] by [approach], prioritizing [focus] over [alternative].
Examples:
- We will address weak first-week adoption by simplifying setup and reducing configuration before expanding advanced customization.
- We will address workflow abandonment by embedding AI assistance inside core tasks, prioritizing in-context guidance over a standalone chatbot.
- We will address enterprise sales friction by proving reliability in the existing workflow before adding adjacent platform surface area.
Notice what these do. They pick a lane. They also reject another lane.
If you're working through AI-specific business choices like capability sourcing, operating model, or team focus, materials that help you develop your AI strategy can be useful inputs. The important thing is that your policy still reflects your product's diagnosis, not generic AI ambition.
Phase three coherent actions
Most strategy work fails here. The diagnosis is thoughtful. The policy sounds smart. Then the roadmap becomes a bucket for requests.
Your actions should act like a system. If one item disappeared, the rest should make less sense.
Build them in layers:
Core product moves
These directly express the policy. If the policy is setup simplification, you redesign onboarding, defaults, and first-run UX.Enabling capabilities
Instrumentation, internal tools, taxonomy cleanup, model evaluation workflows, permissions architecture. Teams often skip these and then wonder why delivery stalls.Go-to-market alignment
Sales decks, onboarding messaging, lifecycle emails, pricing packaging, success handoffs. Product strategy without GTM alignment usually dies in interpretation.
A useful gut check is this: could you explain why every action belongs without saying, "stakeholders asked for it"? If not, cut it.
This short talk is a useful companion if you want another lens on strategic thinking in practice.
A draft strategy example for an AI product
Let's make it concrete.
Diagnosis
Users drop off before repeated use because the product expects them to compose complex prompts and stitch outputs into their workflow manually.
Guiding policy
Win repeat usage by reducing cognitive load inside the existing workflow, prioritizing embedded assistance over broad standalone AI functionality.
Coherent actions
- Redesign the main workflow to surface suggestions at the point of decision.
- Preload high-quality prompt scaffolds based on job-to-be-done.
- Add lightweight review and edit controls so users trust outputs without leaving the task.
- Instrument output acceptance, edit behavior, and abandonment reasons.
- Train sales and success teams to position the product as workflow acceleration, not general AI.
The best product strategies read like a set of linked choices. The worst read like a parking lot of ideas.
That's the whole game. Clear challenge. Sharp policy. Linked actions.
Applying Good Strategy in the Unpredictable World of AI
A fair criticism of good strategy bad strategy is that the book came out in 2011. AI product markets don't behave like stable categories. Models shift fast. Costs move. User expectations reset quickly. Teams ask whether a classic framework is still useful.
It is. In fact, high uncertainty makes disciplined strategy more important, not less.
The core adaptation is this: in AI, your diagnosis and coherent actions need shorter feedback loops. The kernel stays. The planning cadence changes.
What bad AI strategy looks like
A lot of AI roadmaps are still slogans wearing technical clothes. "Lead in GenAI." "Build an AI-native platform." "Own the future of agentic workflows."
That isn't enough. In the AI space, 72% of startups exhibit bad strategy by mistaking funding for a plan, leading to 30% higher burn rates, and a 2026 HBR analysis found that AI firms using coherent strategies achieve 3.2x higher ROI by focusing on specific data moats rather than vague goals like leading in GenAI, according to this discussion of recent critiques and AI-era extensions of Rumelt's framework.
The practical takeaway for PMs is blunt. AI doesn't excuse vagueness. It punishes it faster.
How to adapt the kernel for AI PM work
Use a hybrid approach. Keep Rumelt's kernel, but run it with scenario awareness.
Diagnosis under model volatility
Your diagnosis shouldn't start with "we need our own model" or "we should add an agent." It should start with a product constraint.
Try prompts like:
- Where does the user currently need judgment help, not just content generation?
- What part of the workflow breaks when outputs are inconsistent?
- What proprietary context do we have that generic tools don't?
- Where does trust matter more than novelty?
If you want a broader view of how PMs are handling this space, AI product management is a useful category lens because it frames the product problems beyond model hype.
Guiding policy as a set of bets
In AI products, policy often needs to settle hard choices such as:
- Build versus buy: Own core intelligence or orchestrate external capabilities
- Assist versus automate: Keep humans in loop or remove steps outright
- Workflow depth versus horizontal breadth: Solve one painful job thoroughly or cover many shallowly
- Reliability versus speed of experimentation: Tighten quality or expand learning surface
A good policy might be: use external models for general generation while concentrating internal effort on proprietary workflow context, evaluation, and trust controls.
That's strategic because it defines the source of advantage. It also tells engineering where not to overinvest.
Coherent actions as learning systems
In AI, coherent actions aren't only features. They're also evaluation loops, fallback design, human review mechanisms, prompt libraries, data pipelines, and pricing choices.
Here's where many PMs get confused. They think adaptability means staying broad. It doesn't. It means choosing a focused hypothesis and building the mechanisms to learn fast inside it.
In AI products, strategy isn't a promise that the market will stay stable. It's a design for learning where advantage can come from.
The teams that do this well don't chase every model release. They decide what part of the customer problem they want to own, then shape the product, operations, and GTM around that decision.
How Demonstrating Good Strategy Gets You Promoted
Promotion panels and hiring loops don't reward PMs for sounding ambitious. They reward PMs who can reduce ambiguity, make trade-offs, and align teams around a coherent plan.
That's why strategy has become such a separating skill. Plenty of PMs can prioritize a backlog. Fewer can explain the obstacle, define a policy, and connect roadmap choices into a clear competitive argument.
The interview answer most PMs give
Asked, "What's your strategy for improving adoption of our AI product?" many candidates answer like this:
"We'd interview users, identify pain points, build a chatbot, improve onboarding, launch education, and iterate based on feedback."
Nothing there is terrible. None of it is strategy.
The answer strong PMs give
A stronger answer sounds like this:
"I'd start by diagnosing where adoption breaks. My working hypothesis is that users don't fail because they lack interest in AI, they fail because the product asks them to change behavior too much up front. My guiding policy would be to reduce friction inside the existing workflow before expanding AI surface area. The coherent actions would focus on in-task assistance, simpler defaults, tighter instrumentation around first-use and repeat-use behavior, and clear GTM positioning around one high-value use case."
That answer signals judgment. It shows structure. It tells the panel you know how to think, not just how to brainstorm.
How to turn this into career capital
Use the kernel in three places:
- In roadmap reviews: State the diagnosis before you show initiatives.
- In promo packets: Frame your work as a strategic response to a business challenge, not as a list of shipped features.
- On your resume: Rewrite bullets around challenge, policy, and coordinated action. If you need help phrasing those stories, this guide on how to craft impactful resume accomplishments is a practical reference.
You should also study how to communicate impact upward. Guidance on how to get promoted is useful here because promotion is usually less about effort and more about whether leaders see evidence of scope, judgment, and the capacity to multiply impact.
PMs who practice good strategy bad strategy thinking stand out because they make messy situations legible. They don't just say what the team should do. They explain why this problem matters, why this path is right, and why the other good ideas can wait.
If you want more practical product management frameworks like this, explore Aakash Gupta. His work covers product strategy, growth, hiring, and PM career development in a format built for both aspiring and experienced product leaders.
