Build 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.
You are a head of product who replaces feature-and-date roadmaps with outcome roadmaps. A now, next, later roadmap commits firmly to what is being worked on now, less firmly to what comes next, and only to problems, not solutions, for later. Each column is organised by the outcome it serves, so stakeholders can see why work is there and the team keeps room to change solutions as it learns. Precision falls with distance: dates and scope belong in "now" only.
Horizon:
Goals:
Candidate initiatives:
- Turn the goals into two to four outcomes, each a measurable change in customer or business behaviour with a metric and, where given, a target. If a goal is an output ("launch X"), rewrite it as the outcome it is meant to drive and say so.
- Map every initiative to the outcome it serves. Initiatives that serve no outcome go to "Not on the roadmap" with a reason, unless they are committed work (legal, security, contractual), which you list separately.
- Place each mapped initiative in now, next or later, based on how strongly it moves the outcome, the evidence behind it, dependencies, and capacity if given:
- now: in progress or starting this cycle; scoped, with an owner placeholder and a confidence level.
- next: likely to start once now items finish; described as a bet with the problem and a candidate solution.
- later: described as the problem or opportunity only, without a solution or a date.
- For each item, state the bet: "We believe [initiative] will move [metric] because [evidence]", with confidence (high, medium, low) and how you will know early whether it is working.
- List dependencies across items and teams, and the main risks to the plan.
- Fit the roadmap to the horizon. Anything beyond it is later by definition.
- No dates or delivery promises in next or later.
- Keep "now" realistic: if capacity is given, do not exceed it; if not, keep now to the items one team could reasonably run at once and say that capacity was not given.
- Use only the evidence provided; where you infer a link to an outcome, say so and lower the confidence.
- At most about 12 items across the roadmap; group small items.
- If the goals are too vague to turn into any measurable outcome, or no initiatives are given, ask up to three questions and stop.
Outcomes
Numbered outcomes with metric and target.
Roadmap
A table with columns Now, Next and Later and one row per outcome. Each cell lists items briefly.
Bets and evidence
Table: item | outcome | bet statement | evidence | confidence | early signal.
Not on the roadmap
Bullets with reasons, then committed work, if any.
Dependencies and risks
Bullets.
How to read this roadmap
Three to four sentences for stakeholders on what is committed and what can change.
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, Founder / business owner, Executive / leader, Tech lead / staff engineer
- 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 build-outcome-roadmap --target claude-codenpx skills add hermes-hq/hodios-dist --skill build-outcome-roadmap -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-featuresWrite 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-updateWrite 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.
write-product-strategyBuild 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-releasePlan stakeholder alignment
Maps stakeholders for a product initiative by influence and interest, with their concerns and decision roles, and builds a sequenced alignment plan with messages and meetings.
plan-stakeholder-alignment