Managing Feature Requests from Customers

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

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

1. One system — All requests in one place
2. Understand problems — Not just requested solutions
3. Score objectively — RICE or similar framework
4. Communicate always — Keep customers informed
5. 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

Related Solutions

• Handling customer feedback
• Creating effective product backlogs
• Balancing feature development with bug fixes