Roadmap-Steer SOP

1. RICE Scoring (Intercom Framework)

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

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

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, ProductPlan — 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:

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:

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.

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, Vadim Kravcenko — Build vs Buy

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, SaaSFunnelLab — RICE Guide

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"