assimovt/strategy-doc

Write strategy that forces hard choices. A strategy that doesn't say "no" to something isn't a strategy — it's a wish list. Strategy is not goals, not aspirations, and not a list of things you want to do. It's a coherent set of choices about where to play and how to win.

The Strategy Kernel (Richard Rumelt)

Every strategy document must contain these three elements:

1. Diagnosis

What's actually going on? Name the challenge clearly. A good diagnosis simplifies complexity by identifying the critical factors.

• "Our activation rate is 23% because new users don't understand the product's value in their first session."
• NOT: "We need to grow faster." (That's an aspiration, not a diagnosis.)

2. Guiding Policy

The overall approach for dealing with the challenge. This is the big directional bet — it rules things in AND rules things out.

• "Focus entirely on time-to-first-value for solo users before expanding to teams."
• NOT: "Improve the product across all dimensions." (That's not a choice.)

3. Coherent Actions

Specific, coordinated actions that execute the guiding policy. Actions should reinforce each other.

• "Rebuild onboarding as a guided first-project flow. Remove the team invite step from signup. Add inline tooltips on the three core features. Measure activation at 'first project completed' not 'account created.'"

Playing to Win Framework (Lafley/Martin)

Structure the strategy as five cascading choices:

1. Winning Aspiration: What does winning look like? (Not revenue targets — the change you want to create)
2. Where to Play: Which customers, segments, geographies, channels? Be specific about what you're NOT pursuing.
3. How to Win: What's your competitive advantage in your chosen space?
4. Capabilities: What must you be great at to win this way?
5. Management Systems: How will you track whether the strategy is working?

Each choice constrains the next. If "Where to Play" doesn't narrow the field, it's not a choice.

Guidelines

• CRITICAL: Every strategy doc MUST include what you will NOT do. A strategy without tradeoffs is not a strategy.
• NEVER confuse strategy with goals. "Reach $10M ARR" is a goal. "Win the PLG segment by being 10x faster to deploy than enterprise alternatives" is strategy.
• NEVER list more than 3 strategic priorities. If everything is a priority, nothing is.
• ALWAYS include a diagnosis that names the core challenge. If you can't name the problem, you can't solve it.
• ALWAYS make the guiding policy falsifiable. Someone should be able to argue against it.
• NEVER write strategy in a vacuum. Ground it in competitive reality, customer evidence, and your actual capabilities.

Example: Good vs Bad

Bad guiding policy:

"We will build the best product in the market by focusing on quality, speed, and customer satisfaction."

Good guiding policy:

"We will win technical PMs at Series A-B startups by being the fastest path from customer insight to shipped feature — sacrificing enterprise compliance features and multi-team coordination to stay opinionated and fast."

The good version names who, names what you're sacrificing, and could be argued against.

---

Built on Good Strategy Bad Strategy (Richard Rumelt) and Playing to Win (Lafley/Martin). Skills from productskills.