# Roadmap Steer

> Prioritizes features and manages product roadmap. Triggers ONLY when: user asks to prioritize features, plan a roadmap, evaluate feature requests, or decide what to build next. Do NOT trigger during development or when implementing already-decided features.

- Skill: `docat0209/roadmap-steer` (Agent Skill)
- Install (CLI): `npx skillmds@latest add docat0209/roadmap-steer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/docat0209/roadmap-steer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: Docat0209 (https://skillmd.com/u/docat0209)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/docat0209/roadmap-steer

---


# Roadmap-Steer SOP

## 1. RICE Scoring (Intercom Framework)

Score every feature request. Highest RICE score = build next.

**Formula:** `RICE = (Reach × Impact × Confidence) / Effort`

| Factor | How to measure | Scale |
|---|---|---|
| **Reach** | Users affected per quarter | Actual number (e.g., 500 users/quarter) |
| **Impact** | Effect on target metric per user | 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal |
| **Confidence** | How sure are you about estimates | 100% = high (data-backed), 80% = medium (some evidence), 50% = low (gut feel) |
| **Effort** | Person-weeks for solo dev (person-months for teams) | Actual estimate (e.g., 2 weeks) |

**Example:**
- Feature: "Add CSV export"
- Reach: 200 users/quarter, Impact: 1 (medium), Confidence: 80%, Effort: 1 week
- RICE = (200 × 1 × 0.8) / 1 = **160**

**When RICE isn't enough:** RICE optimizes for incremental value. For strategic bets (platform pivots, new markets), use judgment — RICE can't score vision.

> Source: [Intercom — RICE Prioritization](https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/), [ProductPlan — RICE Scoring Model](https://www.productplan.com/glossary/rice-scoring-model/)

## 1.5 Milestone Creation

Once RICE scoring identifies the next feature to build, create a GitHub Milestone before any code is written.

**Milestone name:** use a descriptive feature name that communicates scope at a glance.
- Good: "CSV Export", "User Dashboard v1", "Webhook Delivery Retry"
- Bad: "Sprint 3", "Next feature", "Q2 work"

**Optional deadline:** derive from the Effort estimate in your RICE score. A 2-week effort estimate maps to a deadline 2 weeks from today. If confidence is below 80%, add a 25% buffer.

**Create the milestone via GitHub API:**
```bash
gh api repos/{owner}/{repo}/milestones \
  --method POST \
  --field title="CSV Export" \
  --field description="Allow users to export their data as a CSV file" \
  --field due_on="2026-04-11T00:00:00Z"
```

Replace `{owner}` and `{repo}` with your actual values. Omit `due_on` if effort confidence is low.

**After creating the milestone:** invoke `work-breakdown` to decompose it into atomic GitHub issues, each scoped to a single unit of work that can be completed and reviewed independently.

## 2. Saying No to Feature Requests

Most requests won't make it. Have a framework, not an apology.

**Response template:**
> "Thank you for the suggestion. This doesn't fit our current direction because [specific reason]. I've noted it for future consideration."

**Valid reasons to say no:**
- Doesn't serve the core use case (scope creep)
- Effort far exceeds impact (low RICE)
- Only one user asked (not representative)
- Would add complexity that hurts the majority of users

**Never say:**
- "Maybe later" without meaning it — it creates false expectations
- Nothing at all — silence is worse than a polite no

## 3. Feature Request Management

Track in a single place. Keep it simple.

**Spreadsheet/issue tracker columns:**
| Column | Purpose |
|---|---|
| Requester | Who asked (customer name or support ticket) |
| Request | What they want (in their words) |
| Frequency | How many different users asked for this |
| RICE score | Calculated priority |
| Status | `noted` → `evaluating` → `planned` → `building` → `shipped` / `declined` |

**Process:**
- Log every request when it comes in (takes 30 seconds)
- Review the full list monthly
- Re-score top 10 items with fresh data
- Pick the highest-RICE item that aligns with current strategy

## 4. Build vs Buy vs Integrate

**Decision rule:** build only if it's your core differentiator AND no existing solution is 80%+ good enough.

| Question | Build | Buy/Integrate |
|---|---|---|
| Is this your competitive advantage? | Yes | No |
| Does an 80%+ solution exist? | No | Yes |
| Will maintaining this distract from core product? | No | Yes |
| Is time-to-market critical? | No | Yes |

**For solo devs:** bias heavily toward buy/integrate. Your time is your scarcest resource. Use APIs, SaaS tools, and open-source before building anything that isn't your core product.

> Source: [TheCodev — Build vs Buy Framework](https://thecodev.co.uk/build-vs-buy-framework/), [Vadim Kravcenko — Build vs Buy](https://vadimkravcenko.com/shorts/build-vs-buy-vs-nocode/)

## 5. Public Roadmap

**Benefits:**
- Transparency builds user trust
- Reduces "when will you add X?" support tickets
- Creates accountability and momentum

**Risks:**
- Competitors see your plans
- Creates user expectations you may not meet
- Pressure to ship dates instead of quality

**Recommendation:** share themes and directions, not specific features or dates.
- Good: "Q2 focus: collaboration features"
- Bad: "Shipping real-time multiplayer editing on March 15"

**Tools:** GitHub Projects (free, public), Linear public roadmap, Canny (feedback + roadmap).

## 6. Anti-Patterns — Do Not Fall Into These

**Feature parity with competitors:**
Compete on your differentiator, not their feature list. You will always lose a feature count war against a larger team. Instead, be 10x better at one thing.

**Building for the loudest customer:**
The most vocal user is often not representative. One enterprise customer demanding a feature does not mean your 500 other users want it. Check the frequency column.

**Roadmap by committee:**
Gathering input is good. Deciding by vote is bad. Users can tell you their problems (valuable). They cannot design your product (that's your job).

**Planning too far ahead:**
A 12-month roadmap is fiction for an early-stage product. Plan 6 weeks in detail, 3 months in themes, beyond that in bets.

> Source: [Intercom Blog](https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/), [SaaSFunnelLab — RICE Guide](https://www.saasfunnellab.com/essay/rice-scoring-prioritization-framework/)

## Next Steps
Report to user: "Next feature decided: [name]. RICE score: [N]. Milestone created: [name]"

Suggested next steps (user decides):
- Feature decided → "Run work-breakdown to decompose"
- Community request → "Run community-engage to respond"