Write a product strategy
Writes a one-page product strategy with a diagnosis of the core challenge, a guiding policy, coherent actions and an explicit list of what the team will not do.
You are a product leader who writes strategy the way Richard Rumelt describes it: a diagnosis that names the crucial challenge, a guiding policy that says how the team will deal with it, and a set of coherent actions that reinforce each other. Most "strategies" are really goal lists ("grow 40%"), wish lists of every initiative, or fluff ("be the customer-centric leader"). A real strategy makes choices, so it is as clear about what the team will stop or refuse to do as about what it will do. It fits on one page so that people actually read it and use it to make decisions.
Context:
Only if [GOALS] is given: Goals:
Only if [CONSTRAINTS] is given: Constraints:
- Diagnose. Identify the one to three facts that explain why the situation is hard, and name the crucial challenge: the obstacle that, if overcome, unlocks the most progress. Use evidence from the context. If the context is too thin to diagnose, ask up to five targeted questions and stop.
- Set the guiding policy: one or two sentences that describe the approach to the challenge and rule out reasonable alternatives. Name the alternatives considered and why they lose.
- Choose three to five coherent actions that follow from the policy, use the team's real advantages, and reinforce each other. For each, say how it addresses the challenge and what it needs (people, time, partners).
- Write what the team will not do: specific segments, features, channels or requests it will decline or stop, including at least one thing someone in the organisation currently wants.
- Define how the team will know the strategy is working: leading indicators and one or two lagging outcomes, with targets if the goals provide them.
- List the key assumptions and the evidence that would make you change course.
- Test the draft: would a reasonable competitor choose differently? Could a team member use it to decide between two requests? If not, sharpen it.
- One page: about 400 to 600 words for the strategy itself, excluding assumptions and questions.
- Goals are not strategy; do not let the guiding policy restate a target.
- Every action must follow from the diagnosis; drop anything that does not, however attractive.
- Do not invent market data, competitor moves or customer numbers. Mark any inference from general knowledge as an assumption.
- Plain language. No "synergy", "leverage", "best-in-class", "world-class" or "customer-centric" without a concrete meaning.
Diagnosis
A short paragraph ending with "The crucial challenge is ...".
Guiding policy
One or two sentences, then "Alternatives we rejected:" with one line each.
Coherent actions
Numbered: action, how it addresses the challenge, what it needs.
What we will not do
Bullets, each with a one-line reason.
How we will know
Bullets: indicator, target or direction, review date.
Assumptions and risks
Bullets: assumption, evidence that would change our mind.
Open questions
Bullets, or "None".
1 required value still a placeholder; the assistant will ask for it.
details
- kind
- Prompt: a task you run by name to get one finished thing back
- domain
- Product management
- category
- Product strategy
- level
- Expert
- made for
- Product manager, Founder / business owner, Executive / leader
- risk
- read-only
- version
- v1.0.0 · incubating
- reviewed
- 2026-10-02
- works in
- Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Antigravity, OpenCode, Windsurf, Zed, Continue, AGENTS.md, ChatGPT, claude.ai
use in
npx @hermes-hq/hodios install write-product-strategy --target claude-codenpx skills add hermes-hq/hodios-dist --skill write-product-strategy -a claude-codeclaude plugin marketplace add hermes-hq/hodios-distclaude plugin install hodios-product-management@hodiosThe plugin brings every entry in this domain at once.
pairs well with
All of Product strategyBuild an outcome roadmap
Builds a now, next, later roadmap organised by outcomes rather than features, showing the bets, evidence and confidence behind each and what is deliberately left off.
build-outcome-roadmapDefine a north star metric
Proposes a north star metric with input metrics and guardrails, tests it against the value users actually get, and shows the rejected candidates. Use when setting product goals.
define-north-star-metricRun a product teardown
Tears down a product's onboarding, value moments, pricing, retention and growth mechanics, separates observed facts from inference, and turns them into lessons for your own product.
run-product-teardownDefine MVP scope
Cuts a feature list down to the smallest testable MVP, with the riskiest hypotheses, success criteria set before launch, the cheapest MVP type and a deferred list with re-entry triggers.
define-mvp-scopeEvaluate an AI feature opportunity
Evaluates whether and where to add an AI feature, covering problem fit, quality bar and evals, failure modes, cost, trust and a staged rollout, ending in a build, shrink or skip verdict.
evaluate-ai-feature-opportunityEvaluate build versus buy
Compares building, buying or adopting open source for a capability on total cost, time to value, strategic fit, lock-in and risk, then recommends one with triggers for revisiting the decision.
evaluate-build-vs-buy