Mmcp.market

good-strategy-bad-strategy skill

by wondelai·wondelai/skills·2.3k stars·MIT

Formulate and audit real strategy using Richard Rumelt''s "Good Strategy Bad Strategy": an honest diagnosis, a guiding policy, and coherent action instead of goals, vision, and wishful thinking. Use when the user mentions "good strategy bad strategy", "strategy kernel", "diagnosis guiding policy coherent action", "our strategy is just goals", "strategic planning", "mission vs strategy", "annual plan", or "is this actually a strategy". Also trigger when auditing a strategy doc or pitch deck for fluff, turning a goal list into real strategy, formulating strategy for a product or company, or finding leverage and proximate objectives. Covers the kernel of strategy, bad-strategy detection, and sources of power. For product positioning, see obviously-awesome. For uncontested markets, see blue-ocean-strategy.

A100/100content scan

Is the good-strategy-bad-strategy skill safe?

Clean: nothing in its files matched our rules. We read 6 files in the folder on 2026-09-28.

No findings.

Install the good-strategy-bad-strategy skill

A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description.

git clone --depth 1 https://github.com/wondelai/skills.git /tmp/skills
mkdir -p ~/.claude/skills
cp -r /tmp/skills/plugins/wondelai-skills/skills/good-strategy-bad-strategy ~/.claude/skills/good-strategy-bad-strategy
available in every project

In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub

The instructions your agent would load

SKILL.md as published, without the frontmatter. Read it on GitHub

Good Strategy Bad Strategy

A framework for creating and auditing strategy, distilled from Richard Rumelt's Good Strategy Bad Strategy: The Difference and Why It Matters. Good strategy has a simple underlying logic — an honest diagnosis of the critical challenge, a guiding policy for overcoming it, and coherent actions that carry the policy out. Use this skill to detect the four hallmarks of bad strategy and to replace goal lists and vision decks with a working kernel.

Core Principle

Strategy is coherent action backed by an honest diagnosis — not goals, vision, or wishful thinking. A goal ("20% growth") names an ambition; a strategy explains how the ambition will be achieved given the actual obstacles. Bad strategy is not the absence of strategy but an active substitute for it: buzzword fluff, refusal to name the challenge, and laundry lists of initiatives. The heart of strategy work is choice — concentrating effort and resources on the one or two pivotal objectives whose accomplishment unlocks everything else.

Scoring

Goal: 10/10. Score strategies, plans, and strategy documents by walking the eight rows of the Quick Diagnostic and counting how many pass. Report the current score and the specific changes needed to reach 10/10. The bands below name what each tier looks like; the row count keeps the rating reproducible run to run.

  • 9-10 (8 rows pass): Complete kernel — honest diagnosis, choiceful guiding policy, coordinated resource-backed actions — aimed at a pivot point, with an explicit list of what will not be done
  • 7-8 (6-7 pass): Kernel present but one element weak: thin diagnosis, a policy that rules little out, or actions not yet coordinated and funded
  • 5-6 (4-5 pass): The challenge is named, but the plan is a list of independent initiatives and some goals masquerade as strategy
  • 3-4 (2-3 pass): Mostly goals, targets, and vision statements; no diagnosis; fluff in key passages; nothing ruled out
  • 0-2 (0-1 pass): Pure bad strategy — buzzword fluff, dog's-dinner objective lists, denial of the real challenge

Framework

1. The Kernel of Good Strategy

Core concept: Every good strategy shares the same structure: a diagnosis that defines and simplifies the critical challenge, a guiding policy — the overall approach chosen to overcome the diagnosed obstacles — and coherent actions: coordinated, resource-backed steps that carry out the policy. A document missing any of the three is not yet a strategy.

Why it works: A diagnosis replaces the overwhelming complexity of reality with a simpler story that highlights what is critical, often by analogy to a known pattern. The guiding policy channels effort by ruling out vast realms of possible action — like guardrails, it directs without dictating every move. Coherent actions turn intent into coordinated force; most plans fail by jumping straight from ambition to a list of independent initiatives.

Key insights:

  • The diagnosis is the strategy's pivot: Gerstner reframed IBM's 1993 challenge from "mainframes are dying, break the company up" to "our advantage is integrated capability; the obstacle is internal coordination" — and everything downstream changed
  • A guiding policy is not a goal or a vision — it is an approach ("ride wave X by concentrating on Y"), and a real one feels like a choice with losers
  • If a competitor could paste your guiding policy into their deck unchanged, it is a platitude, not a policy
  • Coherent actions reinforce one another — each step makes the others easier — and every one carries an owner, resources, and a date
  • A kernel needs no mission, vision, or values preamble; it fits on one page
  • Most failed "strategies" skip the diagnosis entirely — prescribing before examining

Applications:

Ethical boundary: An honest diagnosis names internal causes too — never soften it to protect egos or settle politics.

See references/kernel.md when you actually draft a kernel — diagnosis craft, guiding-policy formulation, coherent-action design, a fill-in template, and two worked examples with owners and done-tests.

2. Detecting Bad Strategy

Core concept: Bad strategy is not the absence of strategy — it is its own species with four hallmarks: fluff (gibberish masquerading as strategic concepts), failure to face the challenge, mistaking goals for strategy, and bad strategic objectives (dog's-dinner laundry lists or blue-sky impracticalities).

Why it works: Naming the hallmarks turns a vague sense that "this deck says nothing" into specific, fixable findings. Bad strategy persists for identifiable reasons — choice is painful, templates are easy, and positive thinking feels like leadership — so detection must hunt for substitutes for choice, not just bad writing.

Key insights:

  • Fluff test: restate the sentence in plain words — "our fundamental strategy is customer-centric intermediation" collapses to "we are a bank," which says nothing
  • If the document never names the obstacle, the strategy cannot be evaluated or improved — International Harvester's 1979 plan never mentioned its toxic labor relations, the actual problem
  • "20% growth, 20% margin" is a goal; exhortation to push harder is motivation, not a lever — strategy is the lever
  • Dog's dinner: a city plan with 47 "strategies" and 178 action items has no strategy; blue-sky: "become the leading platform" restates the end state and skips the how
  • Bad strategy has causes: unwillingness to choose (every real choice creates losers — DEC's consensus produced mush), template-style vision-mission-values planning, and New Thought culture (belief that visualizing success produces it)
  • The negation test: if the opposite of a statement is absurd ("we will not be customer focused"), the statement carries no information

Applications:

See references/bad-strategy.md when auditing a deck or plan — per-hallmark detection checklists, before/after rewrites, why bad strategy proliferates, and a step-by-step deck-audit procedure with a report format.

3. Sources of Power

Core concept: Good strategy applies strength where it has the greatest effect, drawing on recurring sources of power: leverage (anticipation, pivot points, concentration), proximate objectives (targets close enough to actually hit), chain-link systems (quality matched across links), design (premeditated, coordinated configuration), focus, and using advantage (asymmetries protected by isolating mechanisms).

Why it works: Resources are always scarce relative to ambitions. Power comes from asymmetry — knowing something rivals don't, pressing where effort is amplified, or concentrating where they are spread thin. A strategy that names no source of power is hoping effort alone will win, which is matching strength against strength.

Key insights:

  • Leverage = anticipation × pivot point × concentration: anticipate predictable behavior, find the point where effort is amplified, then commit past the threshold where results become visible
  • A proximate objective is one the team can see how to hit; under high ambiguity, choose closer targets — a JPL engineer made Moon-lander design feasible by simply deciding a lunar soil model others could build against
  • In chain-link systems, performance is capped by the weakest link — investing in strong links is wasted until the weak one is fixed, which is why such systems stay stuck
  • A fully matched chain is also the deepest moat: IKEA's in-house design, flat-pack logistics, and warehouse showrooms each fit the others, so copying one link gains a rival nothing
  • Design-type strategy — tight, premeditated coordination of parts — pays when stakes are high and resources scarce; integration buys performance at the cost of flexibility
  • An advantage matters only at the point of contention: deepen it, broaden it, or strengthen isolating mechanisms (network effects, brand, patents, tacit know-how) that block imitation

Applications:

Ethical boundary: Build isolating mechanisms on delivered value — lock-in engineered purely to trap users eventually isolates you from them.

See references/sources-of-power.md when choosing where to apply strength — leverage, proximate objectives, chain-link systems, design, focus, and advantage, each with a when-to-use test (unlock test, addressability test, coherence check).

4. Riding Dynamics and Fighting Inertia

Core concept: Waves of change — technology shifts, deregulation, demographic change — are the attacker's best friend: they redistribute advantage and reset rules the incumbents had mastered. Incumbents are held back by three kinds of inertia (routine, culture, proxy) and by entropy — the unmanaged drift into blur and waste.

Why it works: In stable periods incumbents win on scale and accumulated advantage; in transitions their strengths become anchors — they defend legacy margins, rerun obsolete playbooks, and answer to cultures built for the old world. You don't need to predict the future, only to recognize that the present has already changed and act on it before those who can't.

Key insights:

  • Guideposts for sensing waves: rising fixed costs (force consolidation), deregulation or rule changes, predictable biases (people extrapolate the present), incumbent response (watch them protect old margins), and attractor states (where the industry "should" land given the technology)
  • An attractor state disciplines hype: ask "in the end state, who does the work and who gets paid?" — "all data transport becomes IP" correctly guided Cisco's rise
  • Inertia by routine yields to new metrics and outside hires; inertia by culture requires simplification and breaking insulated units; inertia by proxy means the incumbent profits from its customers' inertia — banks kept paying low deposit rates because depositors were slow to move
  • A rival's inertia is an exploitable asymmetry: attack where responding would force them to break their own economics
  • Entropy shows up as blurred product lines, drifting prices, and accidental cross-subsidies — weeding it is real strategy work even with no competitor in sight

Applications:

Ethical boundary: Ride waves by serving the new need better — never by manufacturing fear about the old one.

See references/dynamics-inertia.md when a market is shifting or an incumbent is stuck — guideposts for spotting waves, diagnosing the three inertia types and entropy, and attacker playbooks for exploiting a rival's inertia.

5. Thinking Like a Strategist

Core concept: A strategy is a hypothesis about what will work, not a deduction from goals. Work like a scientist — diagnose, formulate, test against evidence, revise — and use deliberate techniques (create-destroy, the virtual panel of experts, a written first-person kernel) to defend judgment against first conclusions and herd opinion.

Why it works: The mind grabs the first plausible frame and defends it; groups converge on comfortable consensus. The market is an expensive place to discover you were wrong — cheap, disciplined destruction of your own ideas before commitment buys that learning early.

Key insights:

  • Treat strategy as a hypothesis and the market as the lab: Howard Schultz's Italian espresso-bar concept survived because he kept revising it against evidence — dropped the opera music, added chairs, offered nonfat milk
  • Create-destroy: generate genuinely different alternatives, then attack your own front-runner as hard as you would attack a rival's plan
  • Convene a virtual panel of experts: simulate the specific critiques of people whose judgment you respect — borrowed standards beat solo blind spots
  • First conclusions are the enemy; before accepting any diagnosis ask "what else could be going on?"
  • Keep the kernel written down — a strategy that lives in your head is unfalsifiable — with the list of what you choose not to do beside it
  • Independent judgment matters most when the crowd agrees: the market capitalized Global Crossing's hype while the underlying numbers said otherwise

Applications:

Ethical boundary: Use the virtual panel to find flaws, not to stage imagined authority blessing a foregone conclusion.

See references/case-studies.md for fully worked end-to-end examples — a SaaS annual-plan audit, a startup concentration decision, and a vision deck rewritten into a kernel.

Common Mistakes

Quick Diagnostic

Further Reading

  • "Good Strategy Bad Strategy: The Difference and Why It Matters" by Richard Rumelt
  • "The Crux: How Leaders Become Strategists" by Richard Rumelt
  • "Playing to Win: How Strategy Really Works" by A.G. Lafley & Roger L. Martin
  • "7 Powers: The Foundations of Business Strategy" by Hamilton Helmer

About the Author

Richard Rumelt is professor emeritus at UCLA Anderson School of Management and one of the world's most influential thinkers on strategy — McKinsey Quarterly dubbed him "the strategist's strategist," and The Economist named him among the 25 most influential living management thinkers. He distilled four decades of research and consulting into Good Strategy Bad Strategy (2011) and The Crux (2022).

More skills from wondelai/skills

  • A37signals-wayBuild lean, opinionated products using the 37signals philosophy from "Getting Real", "Rework", and "Shape Up". Use when the user mentions "Getting Real", "Rework", "Shape Up", "37signals", "Basecamp method", "six-week cycles", "fixed time variable scope", "appetite vs estimates", "betting table", "breadboarding", "fat marker sketch", "build less", "underdo the competition", "opinionated software", "we have too many meetings", "how do we ship faster", or "stop overbuilding". Also trigger when cutting scope to ship sooner, running a small team, or avoiding long-term roadmaps. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.
  • A37signals-wayBuild lean, opinionated products using the 37signals philosophy from "Getting Real", "Rework", and "Shape Up". Use when the user mentions "Getting Real", "Rework", "Shape Up", "37signals", "Basecamp method", "six-week cycles", "fixed time variable scope", "appetite vs estimates", "betting table", "breadboarding", "fat marker sketch", "build less", "underdo the competition", "opinionated software", "we have too many meetings", "how do we ship faster", or "stop overbuilding". Also trigger when cutting scope to ship sooner, running a small team, or avoiding long-term roadmaps. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.
  • A37signals-wayBuild lean, opinionated products using the 37signals philosophy from "Getting Real", "Rework", and "Shape Up". Use when the user mentions "Getting Real", "Rework", "Shape Up", "37signals", "Basecamp method", "six-week cycles", "fixed time variable scope", "appetite vs estimates", "betting table", "breadboarding", "fat marker sketch", "build less", "underdo the competition", "opinionated software", "we have too many meetings", "how do we ship faster", or "stop overbuilding". Also trigger when cutting scope to ship sooner, running a small team, or avoiding long-term roadmaps. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.
  • Aarchitecture-optimizationGuided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable. Orchestrates eight skills phase by phase - working-with-legacy-code, clean-architecture, software-design-philosophy, refactoring-patterns, system-design, ddia-systems, release-it, pragmatic-programmer - every phase carries its method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (PERFORMANCE.md, ARCHITECTURE.md, ARCHITECTURE-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to make an app faster, untangle drifted boundaries, fix slow endpoints and queries, or says ''it works but it is slow and getting worse''. For an untested prototype, improve-code-quality; for an aged codebase you fear to touch, remove-technical-debt; for greenfield structure, design-code-architecture; for marketing-site page speed, improve-website. For one framework in isolation, invoke that skill directly.
  • Aarchitecture-optimizationGuided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable. Orchestrates eight skills phase by phase - working-with-legacy-code, clean-architecture, software-design-philosophy, refactoring-patterns, system-design, ddia-systems, release-it, pragmatic-programmer - every phase carries its method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (PERFORMANCE.md, ARCHITECTURE.md, ARCHITECTURE-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to make an app faster, untangle drifted boundaries, fix slow endpoints and queries, or says ''it works but it is slow and getting worse''. For an untested prototype, improve-code-quality; for an aged codebase you fear to touch, remove-technical-debt; for greenfield structure, design-code-architecture; for marketing-site page speed, improve-website. For one framework in isolation, invoke that skill directly.
  • Aarchitecture-optimizationGuided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable. Orchestrates eight skills phase by phase - working-with-legacy-code, clean-architecture, software-design-philosophy, refactoring-patterns, system-design, ddia-systems, release-it, pragmatic-programmer - every phase carries its method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (PERFORMANCE.md, ARCHITECTURE.md, ARCHITECTURE-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to make an app faster, untangle drifted boundaries, fix slow endpoints and queries, or says ''it works but it is slow and getting worse''. For an untested prototype, improve-code-quality; for an aged codebase you fear to touch, remove-technical-debt; for greenfield structure, design-code-architecture; for marketing-site page speed, improve-website. For one framework in isolation, invoke that skill directly.
  • Ablue-ocean-strategyCreate uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "the market is too crowded", "how do we stand out", or "escape the price war". Also trigger when exploring a new market category, or finding underserved or non-customers. Covers the Four Actions Framework, Six Paths, buyer utility map, and value-cost trade-offs. For real strategy formulation and bad-strategy detection, see good-strategy-bad-strategy. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
  • Ablue-ocean-strategyCreate uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "the market is too crowded", "how do we stand out", or "escape the price war". Also trigger when exploring a new market category, or finding underserved or non-customers. Covers the Four Actions Framework, Six Paths, buyer utility map, and value-cost trade-offs. For real strategy formulation and bad-strategy detection, see good-strategy-bad-strategy. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
  • Ablue-ocean-strategyCreate uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "the market is too crowded", "how do we stand out", or "escape the price war". Also trigger when exploring a new market category, or finding underserved or non-customers. Covers the Four Actions Framework, Six Paths, buyer utility map, and value-cost trade-offs. For real strategy formulation and bad-strategy detection, see good-strategy-bad-strategy. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
  • Aclean-architectureStructure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.
  • Aclean-architectureStructure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.
  • Aclean-architectureStructure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.

All agent skills → · MCP servers