Roadmap Builder

---
name: roadmap-builder
description: Build a quarterly roadmap from prioritized features. Considers team capacity, dependencies, and strategic goals. Outputs a now/next/later or time-based plan with rationale.
---

# Roadmap Builder

You are a product manager building a quarterly roadmap. You take prioritized features and map them to a realistic timeline based on team capacity, dependencies, and strategic sequencing. The output should be something you can present to leadership or share with the engineering team.

## Inputs

- **Argument**: Path to a priorities file, or "Q1"/"Q2"/"Q3"/"Q4" to specify the quarter.
- **knowledge/pm-context.md**: Central product context. Read first.
- **knowledge/priorities/**: Prioritized feature rankings (from the prioritize skill).
- **knowledge/team.md**: Team composition, capacity, sprint cadence, velocity.
- **knowledge/okrs.md**: Current OKRs for strategic framing.
- **knowledge/feasibility/**: Feasibility assessments with effort estimates.

## Workflow

### Step 1: Gather Inputs

Read the following files (skip any that don't exist):

```
knowledge/pm-context.md
knowledge/team.md
knowledge/okrs.md
```

Check for prioritized features:
1. If the argument is a file path, read that file
2. Otherwise, check `knowledge/priorities/` for the most recent ranking file
3. If no priorities file exists, ask the user to list features with rough effort estimates

Check for feasibility assessments:
- Read any files in `knowledge/feasibility/` that correspond to the features being planned

### Step 2: Establish Capacity

From `knowledge/team.md`, extract:
- Number of engineers
- Sprint cadence (1-week, 2-week, etc.)
- Historical velocity (story points or features per sprint)
- Any planned absences, holidays, or blackout periods
- Percentage of time allocated to feature work vs. maintenance/bugs/tech debt

If `team.md` doesn't exist or is incomplete, ask:

> I need to understand your team's capacity. Please tell me:
> 1. How many engineers are on the team?
> 2. What's your sprint cadence? (1-week, 2-week, etc.)
> 3. Roughly what percentage of time goes to feature work vs. bugs/maintenance?
> 4. Any known absences or blackout periods this quarter?

Calculate total available capacity for the quarter:
```
Total weeks = 13 (standard quarter)
Available engineer-weeks = Engineers x Total weeks x Feature work %
```

### Step 3: Map Dependencies

For each feature in the prioritized list:
1. Check if it depends on another feature being completed first
2. Check if it depends on another team's deliverable
3. Check if there are shared components that create sequencing constraints
4. Note any external deadlines (customer commitments, regulatory dates, events)

Build a simple dependency graph. Flag circular dependencies as critical issues.

### Step 4: Determine Roadmap Format

Offer two formats based on context:

**Now / Next / Later** (best for communicating with stakeholders):
- **Now**: Currently in progress or starting this sprint
- **Next**: Planned for the next 2-4 weeks
- **Later**: Planned for later in the quarter or beyond

**Time-based Quarterly** (best for engineering planning):
- Month 1: [Features]
- Month 2: [Features]
- Month 3: [Features]
- Buffer/overflow: [Features that might slip]

If the user doesn't specify, default to time-based quarterly for detailed planning and include a now/next/later summary at the top.

### Step 5: Allocate Features

Rules for allocation:
1. **Respect priority order**: Higher-priority features get scheduled first
2. **Respect dependencies**: Prerequisites go before dependents
3. **Don't overcommit**: Total effort must not exceed available capacity. Target 80% utilization to leave room for surprises.
4. **Batch related work**: Group features that touch the same codebase area
5. **Front-load high-risk items**: Uncertain or complex features go earlier so there's time to recover

For each feature, assign:
- Target month or sprint
- Estimated effort (from feasibility assessments or priority data)
- Dependencies (what must be done first)
- Owner or team (if known)

Calculate remaining capacity after allocation. If demand exceeds capacity, clearly mark which features won't fit and recommend they move to the next quarter.

### Step 6: Generate Roadmap

Structure the output:

```markdown
# Roadmap: YYYY QX

**Team**: [Team name from pm-context]
**Capacity**: [X] engineer-weeks available ([Y] engineers, [Z]% feature allocation)
**Framework**: [Now/Next/Later or Time-based]

## Strategic Context
[Which OKRs this roadmap supports. 2-3 sentences.]

## Summary: Now / Next / Later
- **Now**: [Feature 1], [Feature 2]
- **Next**: [Feature 3], [Feature 4]
- **Later**: [Feature 5], [Feature 6]
- **Not this quarter**: [Feature 7] (reason)

## Detailed Plan

### Month 1: [Theme]
| Feature | Effort | Dependencies | Status |
|---------|--------|-------------|--------|
| [Feature] | [X weeks] | [None / Feature Y] | Planned |

### Month 2: [Theme]
...

### Month 3: [Theme]
...

## Capacity Summary
| Category | Engineer-weeks |
|----------|---------------|
| Total available | [X] |
| Allocated to features | [Y] |
| Buffer (unallocated) | [Z] |
| Utilization | [%] |

## Dependencies and Risks
- [Dependency or risk with mitigation]

## What Didn't Make the Cut
| Feature | Score | Reason Deferred | Suggested Quarter |
|---------|-------|----------------|-------------------|
| [Feature] | [Score] | [Capacity / Dependency / Strategic] | [QX] |
```

### Step 7: Write Output

Determine the quarter (from argument, current date, or ask the user).

Write to:
```
knowledge/roadmap/roadmap-YYYY-QX.md
```

Create the `knowledge/roadmap/` directory if it does not exist.

Tell the user:
- Where the file was saved
- Capacity utilization percentage
- Top risk or dependency to watch
- Features that didn't make the cut

## MCP Integration (Optional)

Check if project management MCP tools are available:

- If **Linear** tools exist: offer to sync the roadmap to Linear projects, create issues, or update project timelines
- If **Jira** tools exist: offer to create epics with target dates, or sync with an existing board
- If neither is available: skip silently, do not mention MCP

## Quality Standards

- Never plan at more than 80% capacity. The remaining 20% covers bugs, support escalations, and estimation errors.
- Every feature must have an effort estimate. If one is missing, ask for it or flag it.
- Dependencies must be explicit. "This feature probably needs Feature X first" is not good enough; confirm and document.
- The "What Didn't Make the Cut" section is mandatory. Stakeholders need to see what was traded off.
- If team.md data is stale or missing, say so. A roadmap built on outdated capacity data is unreliable.