Roadmap Planning skill for Codex

A roadmap is a statement of intent about which problems the team will solve, in what order, and why. It is done well when every item traces to a strategic goal and a metric, confidence drops visibly the further out it goes, and a stakeholder can tell what will not happen this quarter.

Format: Now / Next / Later with outcomes

Horizon	Typical span	Content	Confidence
Now	Current 4-8 weeks	Committed problems with chosen solutions in flight	High; scope known
Next	Following 1-3 months	Validated problems, solution still being shaped	Medium
Later	3-12 months	Problems worth solving, little or no solution work	Low; may change or drop

Use dates only for genuine external commitments (contract, regulation, event). Mark them as such. A date on a Later item is a promise the team cannot keep.

Each roadmap item is an outcome card, not a feature:

### Reduce first-week drop-off for self-serve teams
Goal link: FY27 goal 2 - grow self-serve revenue
Metric: % of new workspaces with 3+ active members by day 7 (now 22%, target 35%)
Evidence: churn interviews (9 of 14 cited "couldn't get team on board"), funnel data
Candidate solutions: invite flow redesign, Slack invite, starter templates
Confidence: medium | Horizon: Next | Owner: Growth squad
Not doing: enterprise SSO onboarding (separate item, Later)

Workflow

- [ ] 1. Collect inputs: strategy/goals, OKRs, metrics, research, requests, commitments
- [ ] 2. Read the existing roadmap and what shipped last period vs what was planned
- [ ] 3. Group requests and ideas into problems (themes), not features
- [ ] 4. Link each problem to a goal and a metric; drop or park orphans
- [ ] 5. Prioritize problems (see $prioritization-frameworks for scoring)
- [ ] 6. Check capacity and dependencies; place into Now / Next / Later
- [ ] 7. Write the "Not doing" list
- [ ] 8. Produce audience views; review with the user before sharing

Step 3: from requests to problems

Ask “what would the customer be able to do, or stop suffering, if we built this?” for each request. Requests with the same answer belong to one problem. Example: “CSV import”, “Trello importer” and “copy from spreadsheet” all collapse into “New teams cannot bring existing work in, so they start empty”.

Step 6: capacity and dependency check

• Count teams (or squads), not people. Rule of thumb: a squad holds 1-2 Now items. More than that per squad means Now is a wish list.
• Reserve 20-30% of capacity for bugs, tech debt and unplanned work. Write the reserve on the roadmap so it is not silently consumed.
• For every Now item, list cross-team dependencies with a named contact and whether the other team has it in their own Now. A dependency on another team’s Later is a risk.

Converting a feature roadmap

Given a Gantt chart or feature list:

1. Ask what problem each feature solves; record the answer next to it.
2. Merge features that solve the same problem into one outcome card.
3. Features whose problem nobody can state go to an “Unclear rationale” list for the owner to justify or drop. Do not silently delete them.
4. Replace dates with horizons except true external commitments.
5. Show the old and new side by side so stakeholders see nothing was lost.

Audience views

Same roadmap, different cuts. Never maintain separate roadmaps that can drift.

Audience	Show	Hide
Leadership / board	Themes, goal links, metrics, major risks	Solution details, squad assignments
Engineering	Now items with scope, dependencies, reserved capacity	Sales commitments detail
Sales / CS	Problems being solved, what is Now vs later, what is not planned	Internal metrics, confidence scores, any date not committed
Customers (public)	Now and Next themes in customer language	Later, internal metrics, anything uncommitted

Sharing a roadmap externally (customer email, public page, sales deck) is an outward communication: show the exact text to the user and get approval before sending or publishing anything.

Review routine

Run monthly for Now, quarterly for the whole roadmap:

• What moved from Now to shipped? Did the metric move?
• What new evidence changed confidence on Next or Later items?
• What was added, and what was removed or pushed to make room?
• Record changes in a changelog section at the bottom with a one-line reason each.

Output template

# <Product> roadmap - <period>
Strategy: <1-2 sentences> | Last reviewed: <date> | Owner: <name>

## Now (committed)
<outcome cards>
## Next (shaping)
<outcome cards>
## Later (exploring)
<one-line problem statements with goal links>
## Not doing this period
- <item> - <reason>
## Capacity
<squads, reserve %, known constraints>
## Changes since last version
- <date>: moved X from Next to Now because <evidence>

Gotchas

• A roadmap with 15 Now items is a backlog. Push back with the capacity math.
• Outcome language can hide vagueness: “improve onboarding” is still a feature-free slogan unless it names the metric and target.
• Sales requests for dates on Later items: give the horizon and the confidence, not a date, and offer to revisit when the item reaches Next.
• Do not invent metric baselines. Write “baseline unknown - instrument first”.
• Keep tech-platform work on the roadmap as outcomes too (“cut deploy time to under 15 min so squads ship daily”); hidden platform work steals capacity invisibly.

Verification

Check that every Now and Next item has a goal link, metric, owner and confidence; every goal in the strategy has at least one item (or an explicit reason it does not); the number of Now items does not exceed squads x 2; and the Not doing list is non-empty. Read the sales view as if you were a customer: no sentence should read as a promised date that the team has not committed to.