good-strategy-bad-strategy
This Claude Code skill applies Richard Rumelt's strategy framework to help users formulate and audit real strategies built on honest diagnosis, guiding policy, and coherent action rather than goals and vision statements. Use it when analyzing strategy documents, annual plans, pitch decks, or product positioning to detect bad strategy hallmarks, replace goal lists with working strategy kernels, and identify leverage points and proximate objectives.
git clone --depth 1 https://github.com/wondelai/skills /tmp/good-strategy-bad-strategy && cp -r /tmp/good-strategy-bad-strategy/good-strategy-bad-strategy ~/.claude/skills/good-strategy-bad-strategySKILL.md
# 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.** Rate strategies, plans, and strategy documents 0-10 against the principles below. Report the current score and the specific changes needed to reach 10/10.
- **9-10:** 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:** Kernel present but one element weak: thin diagnosis, a policy that rules little out, or actions not yet coordinated and funded
- **5-6:** The challenge is named, but the plan is a list of independent initiatives and some goals masquerade as strategy
- **3-4:** Mostly goals, targets, and vision statements; no diagnosis; fluff in key passages; nothing ruled out
- **0-2:** 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:**
| Context | Application | Example |
|---------|-------------|---------|
| Annual planning | Kernel before targets | Diagnosis: week-one churn; policy: fastest time-to-value in segment; actions: onboarding rebuild + roadmap cuts |
| Strategy review | Trace each action to the policy | Initiative serving no policy → cut or re-justify |
| Pitch deck | Kernel slide, not goals slide | "The obstacle, our approach, three coordinated moves" |
**Ethical boundary:** An honest diagnosis names internal causes too — never soften it to protect egos or settle politics.
See: [references/kernel.md](references/kernel.md)
### 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:**
| Context | Application | Example |
|---------Build 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", or "opinionated software". Also trigger when cutting scope to ship faster, running small teams, avoiding long-term roadmaps, or eliminating meetings. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.
Create 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", "eliminate-reduce-raise-create", or "uncontested market". Also trigger when comparing pricing strategies, exploring new market categories, finding underserved customer segments, or asking how to stop competing on price. Covers the Four Actions Framework, buyer utility map, and value-cost trade-offs. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
Structure 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 architecture", "use case boundary", "onion architecture", "screaming architecture", or "framework independence". Also trigger when decoupling business logic from databases or frameworks, defining module boundaries, or debating where to put business rules. Covers component principles, boundaries, and SOLID. For code quality, see clean-code. For domain modeling, see domain-driven-design.
Write readable, maintainable code through disciplined naming, small functions, and clean error handling. Use when the user mentions "code review", "naming conventions", "function too long", "code smells", "readable code", "boy scout rule", "single responsibility", or "unit test quality". Also trigger when reviewing pull requests for readability, refactoring messy functions, debating comment styles, or improving error handling patterns. Covers SRP, comment discipline, formatting, and unit testing. For refactoring techniques, see refactoring-patterns. For architecture, see clean-architecture.
Engineer word-of-mouth and virality using the STEPPS framework (Social Currency, Triggers, Emotion, Public, Practical Value, Stories). Use when the user mentions "go viral", "word of mouth", "shareable content", "social currency", "why people share", "viral loop", "referral program", or "organic growth". Also trigger when designing shareable features, crafting social media campaigns, or building products that spread through peer recommendation. Covers environmental triggers and high-arousal emotional content. For sticky messaging, see made-to-stick. For persuasion tactics, see influence-psychology.
Build a weekly cadence of customer touchpoints using Opportunity Solution Trees, assumption mapping, and interview snapshots. Use when the user mentions "continuous discovery", "opportunity solution tree", "weekly interviews", "assumption testing", "discovery habits", "product trio", or "outcome-based roadmap". Also trigger when setting up regular customer feedback loops, prioritizing which experiments to run, or connecting discovery insights to delivery work. Covers experience mapping, co-creation, and prioritizing opportunities. For interview technique, see mom-test. For team structure, see inspired-product.
Audit websites and landing pages for conversion issues and design evidence-based A/B tests. Use when the user mentions "landing page isnt converting", "conversion rate", "A/B test", "why visitors leave", "objection handling", "bounce rate", "split testing", or "conversion funnel". Also trigger when diagnosing why signups are low, designing experiment hypotheses, or auditing checkout flows for friction points. Covers funnel mapping, persuasion assets, and objection/counter-objection frameworks. For overall marketing strategy, see one-page-marketing. For usability issues, see ux-heuristics.
Navigate the technology adoption lifecycle from early adopters to mainstream market. Use when the user mentions "crossing the chasm", "beachhead segment", "whole product", "early adopters vs. mainstream", "tech go-to-market", "bowling pin strategy", "technology adoption lifecycle", or "pragmatist buyers". Also trigger when a startup has early traction but struggles to grow beyond initial users, or when planning go-to-market for technical products. Covers D-Day analogy, bowling-pin strategy, and positioning against incumbents. For product positioning, see obviously-awesome. For new market creation, see blue-ocean-strategy.