Three connected skills plus a router, covering strategy one altitude above the product: what the company is betting on, where it plays, and how it decides. Written for designers. Companion to the product-strategy plugin.
A company strategy is a set of written refusals with names attached.
The pattern across every good artifact in this space is the same, and it isn't ambition:
- the Business Hypothesis Canvas has a Not A Focus column, and most refusals in it carry a reason
- SPIDER names a single Approver — the buck stops with them — and separately names who must be Aligned to carry it out
- staged rollout gates are caps, not targets: no more than five partners, then no more than ten
- a trade-off grid permits "Unclear" as a verdict instead of forcing a score
- a checkpoint process ends with an explicit revert and clean up
- market selection includes a readiness gate — can we actually serve this market today
- a hyper-local experiment's real finding was that it didn't scale, and that got written down
Every one is a mechanism for making something un-ambiguous and un-reopenable. Statements of intent constrain nobody; a refusal with a reason and a name does.
Why a designer should care. You experience the absence of those refusals one altitude down — as scope that never closes, bespoke work per market that doesn't compose, a decision approved in a meeting that quietly doesn't happen. The product-strategy plugin names the symptom (shipping their org chart to the customer, where organisational indecision surfaces in the interface). This plugin is where the decision that would have prevented it gets made.
company-strategy ── where the refusals get made (or don't)
▼
product-strategy ── where their absence is a strategy gap
▼
the interface ── where it becomes your problem
Skills
| Skill | Job |
|---|---|
company-strategy |
Overview and router — the through-line, how the pieces connect, which one to reach for |
company-hypothesis |
What the company is and isn't — Business Hypothesis Canvas (Now / Future / Not A Focus), Plan on a Page and the strategy equation, the use-case Value Proposition Canvas, brand ladder with weighted archetypes, shared-language slides, plus founder context |
market-entry |
Where to play — market selection criteria, market tiering, the "can sales volume be increased?" issue tree, and a worked regional growth strategy with content loops and support-ticket data |
company-decisions |
Deciding and making it stick — SPIDER (Advocate / Approver / Asked / Aligned), trade-off analysis, an 8-checkpoint process with Lead / Contribute / Inform, staged rollout gates, and the pillar narrative for a kickoff |
Skills load on their own when the work calls for them. You don't need to invoke them by name.
Commands
| Command | Does |
|---|---|
/hypothesis-canvas |
Builds or pressure-tests a Business Hypothesis Canvas, starting from what you're refusing |
/market-tree |
Decomposes a growth or market-entry question into an assessable issue tree |
/decision-doc |
Writes a stuck decision up as SPIDER, with a trade-off grid and the people named |
Same altitude question, different answer. Company strategy decides what the company is betting on; product strategy decides how a product wins in the market it plays in.
The clean boundary: product-strategy's strategy-stack holds a five-layer model — mission, company strategy, product strategy, roadmap, goals. This plugin is the company-strategy layer of that stack, which is layer two.
Three places they meet:
- Ways to Grow (Extend / Create / Manage / Adapt) lives in
growth-and-defensibilityand frames everything inmarket-entry. Geographic expansion is usually the Adapt quadrant. - All the general storytelling frameworks — SCQA, PAR, form factor choice, the three PM audience types — live in
strategy-narrative.company-decisionsholds only the company-kickoff-specific pillar structure. - Two value-proposition artifacts, deliberately. The use-case canvas here is a company-level grid across segments;
pmf-and-positioning's four-component positioning is the product-level version. Don't mix them in one document.
Four topics that could plausibly have gone here live in product-strategy instead, because that's where they belong: three storytelling frameworks (story structure and PAR, the PM audience types, story timing) are in strategy-narrative, and org design is in strategy-stack's operating-cadence reference. Ways to Grow is in growth-and-defensibility and is cross-referenced from market-entry.
Most of what's here comes from strategy artifacts built for real use inside companies rather than from teaching material, which has two consequences worth stating because they change how you should use it.
The strength is worked shapes rather than complete methods. Where product-strategy gives frameworks with procedures, this gives structures that were built to do a job in a specific organisation. Use them as shapes to copy and adapt, and expect to supply the procedure yourself.
Several frameworks are named more completely than they are specified. Where that's the case, the skill says so rather than filling the gap:
- SPIDER — six sections named (Situation, People, Ideas, Decision, Explanation, Rollout); only Situation and People carry a defined internal structure. The remaining four are named sections without a prescribed template. The one structural rule that is specified: Explanation and Rollout stay separate.
- Business Hypothesis Canvas — seven sections and the Now / Future / Not A Focus column structure are specified; there's no worked example of a fully completed canvas.
- Market tiering — two of its pillars are worked out in detail and a third, earlier one is referenced without content. The skill flags the likely subject of the missing pillar as an inference rather than asserting it, and tells you to derive it from your own audience work.
- Trade-off analysis — the grid, the verdict-plus-rationale rule, the permitted "Unclear" verdict, and the no-weighted-score rule are all specified. The dimensions are chosen per decision by design, so there is no canonical list.
- The pillar narrative — the structure is specified; the worked example runs to two pillars, which is fewer than a real kickoff would carry, and only one of the two lands on a dated commitment. Add the date; that's the half that makes a pillar falsifiable.
- The double-diamond-to-phase correspondence in the checkpoint model — the phases map to checkpoint columns; lining the diagram's four stages up against the three phases is a reading, not part of the model.
The rule the whole set follows: a confident generalisation about mechanism or consequence is an interpretation; the framework itself is what appears in the tables, structures, and named roles. Every "don't invent this" instruction in these skills is there deliberately — an invented procedure that looks authoritative is worse than a flagged gap.
Two topics in company-hypothesis — what counts as pre-product traction, and modelling a five-year plan with funding rounds and regulatory capital as first-class lines — are founder and leadership concerns rather than design craft. They're marked as such in the skill. Useful if you're doing founder or consulting work; skippable otherwise, and worth skipping if you're teaching this to a design audience.
This is a plugin for Claude — it works in Cowork (Claude desktop app) and in Claude Code. A plugin is a folder of skills: markdown files that Claude loads on its own when the work matches, plus commands you invoke with a slash.
Cowork (desktop app)
- Clone or download this repo.
- Zip the folder, or use the folder directly.
- In the desktop app, add it via the plugin installer.
Claude Code
Clone into your plugins directory:
git clone git@github.com:USERNAME/company-strategy.git \
~/.claude/plugins/company-strategyThen restart Claude Code. The skills appear in /help and load automatically when a conversation matches their triggers; the three commands become /hypothesis-canvas, /market-tree and /decision-doc.
Checking it worked. Ask something like "what are we explicitly not doing?" or "this decision keeps getting reopened" — the relevant skill should load without you naming it. If nothing fires, the skill descriptions are what drive triggering; they're in the frontmatter of each SKILL.md and can be edited.
.
├── .claude-plugin/
│ └── plugin.json plugin manifest — name, version, keywords
├── commands/ slash commands
│ ├── hypothesis-canvas.md
│ ├── market-tree.md
│ └── decision-doc.md
├── skills/
│ ├── company-strategy/ router — start here
│ │ └── SKILL.md
│ ├── company-hypothesis/
│ ├── market-entry/
│ └── company-decisions/
├── LICENSE
└── README.md
Each SKILL.md has YAML frontmatter with a name and a description. The description is the whole triggering mechanism — Claude reads it to decide whether to load the file, so it's written to be specific and a little pushy. The body is what Claude reads once it does.
The frameworks are the stable part; the framing is not. If you're picking this up for your own use, the things most worth changing:
- The audience. Every skill has a For designers section and the router opens on a designer through-line. If you're a PM, those are the paragraphs to rewrite — the frameworks underneath don't change.
- The skill descriptions. If a skill isn't firing when you expect it to, edit its
descriptionfrontmatter rather than the body. That's the only field that affects triggering. - The router.
skills/company-strategy/SKILL.mdholds the routing table. If you add or remove a skill, update it there or Claude will keep pointing at something that doesn't exist.
MIT — see LICENSE. The frameworks referenced here are established industry practice and aren't claimed as original; the writing, structure, and the designer framing are mine.
0.1.0