Customer Feature Requests | RICE Scoring, Prioritization

Collect, evaluate, and prioritize customer feature requests with RICE scoring and transparent communication. Build what matters most systematically.

8 min read

Customer feature requests are gold—they tell you what users need. But without a system, you either build everything (impossible) or nothing (wrong). Effective request management means collecting systematically, evaluating objectively, and communicating transparently.

Request Management Challenges

Challenge	Poor Approach	Better Approach
Too many requests	Build everything	Prioritize systematically
Loudest customer wins	React to pressure	Score objectively
No visibility	Requests in emails	Central system
No response	Customer feels ignored	Transparent communication
Wrong things built	Guess what's needed	Understand real problem

Collection System

Single Intake Point

FEATURE REQUEST INTAKE
══════════════════════

COLLECTION CHANNELS:
─────────────────────────────────────
All routes lead to GitScrum:
├── Support tickets → Tagged, linked to GitScrum
├── Sales feedback → Submitted to GitScrum
├── Direct customer email → PM adds to GitScrum
├── In-app feedback widget → Auto to GitScrum
├── User research sessions → PM documents
└── Customer success → Logs in GitScrum

SINGLE BACKLOG:
─────────────────────────────────────
GitScrum Feature Requests Board:
┌─────────────────────────────────────────────────────────┐
│  Submitted  │ Under Review │ Planned │ Building │ Done │
├─────────────────────────────────────────────────────────┤
│  [Request 1]│ [Request 5]  │[Req 10] │[Req 15]  │      │
│  [Request 2]│ [Request 6]  │[Req 11] │          │      │
│  [Request 3]│              │         │          │      │
│  [Request 4]│              │         │          │      │
└─────────────────────────────────────────────────────────┘

NO SCATTERED REQUESTS:
├── Not in random emails
├── Not in sales spreadsheets
├── Not in support system only
└── One place to find everything

Request Template

FEATURE REQUEST TEMPLATE
════════════════════════

SUBMITTED REQUEST FORM:
─────────────────────────────────────
Customer: [Company/User name]
Submitted by: [Internal person or customer]
Date: [Submission date]

## Request Summary
[One-line description]

## Problem Statement
What problem are you trying to solve?
[Customer's actual problem, not solution]

## Proposed Solution
What would you like us to build?
[Customer's suggestion]

## Impact
How would this help your business?
[Quantifiable if possible]

## Workaround
How are you handling this today?
[Current solution/pain level]

## Priority to Customer
How critical is this to you?
☐ Nice to have
☐ Important
☐ Critical
☐ Blocking (would stop using product)

─────────────────────────────────────

INTERNAL ENRICHMENT (PM adds):
─────────────────────────────────────
## Customer Context
ARR: $50K | Plan: Enterprise | Since: 2022

## Request Count
3 other customers requested similar

## Strategic Alignment
Aligns with Q2 OKR: Improve retention

## Technical Notes
Engineering estimate: Medium effort

Evaluation Process

Understanding the Real Problem

PROBLEM DISCOVERY
═════════════════

DON'T JUST BUILD THE REQUEST
─────────────────────────────────────
Customer says: "Add a CSV export button"
Surface need: CSV export
Real problem: Need to report to leadership
Better solution: Maybe a dashboard, or
                 scheduled report email

DISCOVERY QUESTIONS:
─────────────────────────────────────
1. "What are you trying to accomplish?"
   → Understand the goal

2. "Walk me through your current process"
   → See the pain points

3. "What happens if you can't do this?"
   → Gauge priority

4. "If we solved this perfectly, what would it look like?"
   → Understand success criteria

5. "How often do you need this?"
   → Frequency = priority indicator

RESULT:
├── Understand real problem
├── May find better solution
├── Validate importance
├── Scope appropriately
└── Build right thing

RICE Scoring

RICE PRIORITIZATION FRAMEWORK
═════════════════════════════

RICE = (Reach × Impact × Confidence) / Effort

REACH: How many customers affected?
─────────────────────────────────────
├── 0.5: Single customer
├── 1: Few customers (~10)
├── 2: Many customers (~50)
├── 3: Most customers (~100+)
└── 4: All customers

IMPACT: How much value delivered?
─────────────────────────────────────
├── 0.25: Minimal
├── 0.5: Low
├── 1: Medium
├── 2: High
└── 3: Massive

CONFIDENCE: How sure are we?
─────────────────────────────────────
├── 50%: Just a guess
├── 80%: Reasonable confidence
└── 100%: High confidence

EFFORT: Person-months to build
─────────────────────────────────────
├── 0.25: Few days
├── 0.5: Week
├── 1: Month
├── 2: Quarter
└── 4: Half year

EXAMPLE:
─────────────────────────────────────
Feature: Scheduled CSV Reports
Reach: 2 (50 customers need this)
Impact: 1 (medium value)
Confidence: 80% (talked to customers)
Effort: 0.5 (1 week)

RICE = (2 × 1 × 0.8) / 0.5 = 3.2

Compare to other features:
├── Feature A: RICE 3.2 ← Priority
├── Feature B: RICE 2.1
├── Feature C: RICE 1.8
└── Build in RICE order

Prioritization

Prioritization Meetings

FEATURE PRIORITIZATION PROCESS
══════════════════════════════

MONTHLY PRIORITIZATION:
─────────────────────────────────────
Attendees: Product, Engineering Lead, Customer Success

1. REVIEW NEW REQUESTS (30 min)
   ├── Each request summarized
   ├── Customer context provided
   ├── Initial RICE score assigned
   └── Quick discussion

2. UPDATE EXISTING (15 min)
   ├── New votes/requests added
   ├── Customer status changes
   ├── Priority adjustments
   └── Remove obsolete

3. STACK RANK (15 min)
   ├── Sort by RICE score
   ├── Adjust for strategy
   ├── Discuss top 10
   └── Confirm next quarter plan

OUTPUT:
├── Prioritized backlog
├── Top items for next quarter
├── Decisions communicated
└── Requests updated

Saying No Gracefully

DECLINING FEATURE REQUESTS
══════════════════════════

TEMPLATE RESPONSE:
─────────────────────────────────────
Subject: Update on your feature request

Hi [Customer],

Thank you for the feature request for [feature].
We've reviewed it with our product team.

While we understand the value this would bring,
we're currently prioritizing [other area] based
on impact across our customer base.

Your request remains in our backlog (ID: FR-456),
and we'll reassess it in [timeframe].

In the meantime, here are some alternatives:
├── Workaround: [suggestion]
├── Similar feature: [existing capability]
└── Integration: [third-party option]

We appreciate your feedback—it helps us build
a better product.

Best,
[Name]
─────────────────────────────────────

KEY ELEMENTS:
├── Acknowledge the request
├── Explain (don't just reject)
├── Provide alternatives
├── Keep door open
└── Maintain relationship

Communication

Request Status Updates

CUSTOMER COMMUNICATION
══════════════════════

STATUS UPDATES:
─────────────────────────────────────
When status changes, notify customer:

SUBMITTED → UNDER REVIEW:
"Thanks for the suggestion! Our product team
is reviewing this week."

UNDER REVIEW → PLANNED:
"Great news! Your request for [feature] is
now on our roadmap for [timeframe]."

PLANNED → BUILDING:
"We've started building [feature]! Expected
release in [timeframe]."

BUILDING → RELEASED:
"Your requested feature [feature] is now live!
Here's how to use it: [link]"

DECLINED:
"After review, we've decided not to build
[feature] at this time because [reason].
See alternatives: [link]"

AUTOMATION:
├── Status change triggers email
├── Customer sees their request status
├── Transparency builds trust
└── Reduces "any update?" inquiries

Public Roadmap

PUBLIC FEATURE ROADMAP
══════════════════════

WHAT TO SHARE:
─────────────────────────────────────
NOW (Current Quarter):
├── Feature A: In development
├── Feature B: In testing
└── Feature C: Starting soon

NEXT (Next Quarter):
├── Feature D: Planned
├── Feature E: Planned
└── Feature F: Planned

FUTURE (Considering):
├── Feature G: Under review
├── Feature H: Collecting feedback
└── +47 more in backlog

WHAT NOT TO SHARE:
├── Specific dates (things slip)
├── Uncommitted items as promised
├── Internal priorities
└── Competitive information

BENEFITS:
├── Customer sees progress
├── Reduced status requests
├── Builds confidence
├── Collects feedback/votes
└── Shows responsiveness

GitScrum for Requests

Feature Request Workflow

GITSCRUM REQUEST MANAGEMENT
═══════════════════════════

PROJECT: Feature Requests

BOARD:
├── Submitted: New requests
├── Under Review: PM evaluating
├── Prioritized: Scored, waiting
├── Roadmapped: Committed to build
├── In Development: Building
├── Released: Shipped
└── Won't Do: Declined

LABELS:
├── Customer: [company names or segments]
├── Theme: ux, performance, integration, etc.
├── Priority: P1, P2, P3
├── Effort: S, M, L, XL
└── Strategic: Q1-goal, retention, growth

CUSTOM FIELDS:
├── RICE Score
├── Request count (how many customers)
├── ARR Impact (total ARR of requesters)
├── Strategic alignment
└── Target quarter

VIEWS:
├── By customer
├── By theme
├── By RICE score
├── By target quarter
└── By status

Best Practices

For Feature Requests

One system — All requests in one place

Understand problems — Not just requested solutions

Score objectively — RICE or similar framework

Communicate always — Keep customers informed

Say no gracefully — With alternatives

Anti-Patterns

FEATURE REQUEST MISTAKES:
✗ Requests in scattered emails
✗ Loudest customer wins
✗ No prioritization framework
✗ Building without understanding problem
✗ No response to customers
✗ Promising everything
✗ Never saying no
✗ No visibility into status