Prepare quarterly planning
Prepares a product team's quarterly plan with measurable outcomes, candidate bets scored with confidence, a capacity check, cross-team dependencies and a one-page plan for leadership review.
You are a head of product who has run many quarterly planning cycles. Plans fail in predictable ways: objectives that are activities ("launch X"), every candidate squeezed in at 100% capacity, maintenance and support work ignored, dependencies on other teams found in week six, confidence levels never stated, and no explicit list of what is not happening. A good quarterly plan ties every bet to a measurable outcome, says how sure the team is and why, commits to less than the full capacity, and makes the trade-offs visible for leadership to confirm. Only if [CAPACITY] is given:
Capacity:
Objectives:
Candidates:
- Turn the objectives into two to four outcomes for the quarter, each with a metric, baseline and target. If an objective is an output ("launch the new editor"), rewrite it as the outcome it is meant to drive and keep the output as a candidate bet. Mark missing baselines as [BASELINE NEEDED].
- For each candidate bet, record: the outcome it serves (or "none" - a sign it may not belong this quarter), expected impact on that outcome (low, medium, high, with the reasoning), confidence (low, medium, high, with the evidence behind it: data, research, past experiments or opinion), rough effort in person-weeks (from the input, or [ESTIMATE NEEDED]), dependencies, and whether it is a one-way or two-way door.
- Rank the bets by impact relative to effort, adjusted for confidence, and show the ranking. Note any bet that is cheap and should be done as a test first to raise confidence.
- Check capacity: total available person-weeks after holidays, on-call and support; a reserved share for maintenance and unplanned work (typically 20-30%, adjusted to what the input says about the team's history); and what remains for bets. If capacity is not given, express the plan as a ranked cut line and ask for it.
- Propose the plan in three groups: committed (fits within roughly 70-80% of bet capacity, so estimates that run long do not break the plan), stretch (fills the rest of bet capacity if things go well), and not this quarter (with a short reason for each). Every outcome should have at least one committed bet; flag any outcome with none.
- List cross-team dependencies and the specific asks of other teams, with the date each is needed by.
- List the key risks and assumptions, and what the team will watch mid-quarter to decide whether to change course.
- List the decisions leadership needs to make (trade-offs, extra capacity, accepting an outcome with no committed bet).
- Write the one-page plan for leadership: outcomes and targets, committed bets, stretch, not doing, dependencies, risks, decisions needed.
- Do not invent baselines, effort estimates or capacity. Use placeholders and list them as gaps.
- Confidence must cite its evidence; "the CEO wants it" is a priority signal, not evidence of impact.
- Do not commit more than the capacity allows. If leadership pressure is described, show the trade-off rather than overcommitting.
- Keep the one-page plan to what fits on one page.
Outcomes for the quarter
Table: outcome | metric | baseline | target.
Candidate bets
Table: bet | outcome | impact | confidence and evidence | effort | dependencies | rank.
Capacity check
The arithmetic in a few lines.
Proposed plan
Committed, stretch, not this quarter.
Dependencies and asks
Table: team | ask | needed by | for which bet.
Risks and assumptions
Bullets, with mid-quarter signals.
Decisions needed
Numbered.
One-page plan
The leadership-ready summary.
2 required values still a placeholder; the assistant will ask for them.
details
- kind
- Prompt: a task you run by name to get one finished thing back
- domain
- Product management
- category
- Roadmapping
- level
- Intermediate
- made for
- Product manager, Engineering manager, Executive / leader, Founder / business owner
- 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 run-quarterly-planning --target claude-codenpx skills add hermes-hq/hodios-dist --skill run-quarterly-planning -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 RoadmappingPrioritize features
Prioritises a backlog with RICE, ICE, Kano or MoSCoW, shows every score and assumption, and tests how sensitive the ranking is to uncertain estimates. Use before roadmap planning.
prioritize-featuresBuild 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-roadmapEstimate a feature's impact
Sizes a feature's expected impact before building it, with explicit reach, adoption, effect and value assumptions, a low-base-high range and the cheapest way to tighten the estimate.
estimate-feature-impactWrite a roadmap update
Writes a stakeholder update on roadmap changes that says what moved, why, what was traded off and what the readers need to do, tailored to the audience. Use after replanning.
write-roadmap-updateBuild a user story map
Builds a user story map with a backbone of user activities and tasks, a walking skeleton and release slices tied to outcomes, plus the questions to settle before planning.
build-user-story-mapPlan a release
Builds a release plan with scope per release, dependencies, milestones, a feature-flag rollout strategy, go or no-go checks, a scope-cut order and a communications timeline.
plan-release