Framework
You get 100+ feature requests monthly. Without triage, roadmap becomes reactive.
Triage system: Quickly categorize incoming requests. Only some go into backlog.
Categories
| Category | Definition | Action |
|---|---|---|
| Already planned | On roadmap or in progress | Confirm, give timeline |
| Fits strategy | Aligns with roadmap but not yet planned | Add to backlog, let requestor know |
| Nice to have | Valid but lower priority | Backlog (will likely never ship) |
| Out of scope | Doesn't fit product direction | Decline politely |
Actionable Steps
1. Assign Triage Owner
One person (PM or analyst) triages incoming requests.
2. Set SLA
Respond to every request within 48 hours.
3. Communicate Decision
Tell requester: Category + reason + next steps.
Key Takeaways
- Triage prevents feature-request overload. System says "no" to keep roadmap focused.
- Transparency on decision builds trust. Even "out of scope" feels fair if explained.
- Deduplication catches 30-50% of requests. Multiple customers asking for same thing.
- Pattern detection reveals customer needs you didn't know about.
The Feature Request Spiral
Picture this. Your product has been live for 3 years. You have 5,000 customers. By now, how many feature requests are in your system?
Common scenario:
- Year 1: 100 requests collected in spreadsheet
- Year 2: 500 requests, moved to Notion database
- Year 3: 2,000+ requests, database is unusable
- Year 4: Nobody looks at it; roadmap is whatever comes up in meetings
Result: Customers feel ignored. Product strategy becomes reactive (whatever customer yells loudest). Priorities unclear.
Root cause: No triage system. You said "yes" to capture, but didn't commit to process.
The 5-Stage Feature Request Triage System
Stage 1: Intake (When Request Arrives)
Source: Customer support ticket, feature request form, direct PM conversation, Slack message
Immediate action (within 24 hours):
- Log in central repository (not email, not Slack thread)
- Extract requester info: Company, use case, why they need it
- Acknowledge receipt: "Thanks for this request. We'll review it and get back to you."
Template (simple, copy-paste friendly):
Feature Request: [Name]
Requested by: [Company/Person]
Date requested: [Date]
Use case: [Why do they need it?]
Impact: [Revenue risk? Churn risk? Operational?]
Frequency: [First request or duplicate?]
Status: [New → Categorized → Decided]
Stage 2: Deduplication (Group Related Requests)
This is where most systems fail: They treat "Export as CSV" and "Send data to Sheets" as different features. They're the same: data portability.
Deduplication process:
Each new request: Is this similar to an existing request?
- Different wording, same intent? → Merge
- Related to same customer pain? → Link
- Part of larger trend? → Create feature epic
Example (Real):
- Request 1: "Export reports as PDF"
- Request 2: "Save dashboard as file"
- Request 3: "I need to print my dashboards"
- Request 4: "Export feature doesn't work with custom reports"
Deduplication insight: These 4 requests are actually 1: "Make data portable / printable."
Result: Instead of 4 scattered requests, you see 1 major theme. You categorize once. You deliver once. Visibility to all 4 requesters.
Tools for deduplication:
- Slite, Notion (human review, but searchable)
- Specialized tools: Canny, Uservoice (auto-dedup with ML)
- Simple approach: Monthly "dedupe session" by PM (1 hour)
Stage 3: Categorization (Is This Something We'd Ever Ship?)
After deduplication, categorize:
| Category | Definition | Example | Action |
|---|---|---|---|
| Strategic Fit | Aligns with roadmap and product direction | "SSO for enterprise customers" (roadmap item) | Add to backlog, prioritize |
| Valid but Future | Good idea, but not now. Doesn't break strategy. | "Dark mode" (might do later) | Backlog (lower priority) |
| Nice to Have | Valid request but lower impact and not strategic | "Different color themes" | Backlog (very low) |
| Out of Scope | Doesn't fit product vision | "Build competitor intelligence tool in our product" | Decline with reasoning |
| Duplicate or Already Exist | We already have this or similar | "CSV export" (we have this) | Communicate existing feature |
| Technical Limitation | Physically can't do this with current architecture | "Real-time sync on legacy database" | Explain limitation, offer workaround |
Stage 4: Prioritization (Within Categories)
For "Strategic Fit" and "Valid but Future" requests, prioritize by:
Impact × Frequency × Strategic Alignment:
- Impact: How many customers want this? ($X ARR at risk if we don't?)
- Frequency: How many requests? (15 = clear signal, 2 = maybe outlier)
- Strategic: Does this fit Q3 roadmap or Q4+?
Example scoring:
| Request | Customers | Frequency | Strategic Fit | Impact | Score | Priority |
|---|---|---|---|---|---|---|
| SSO integration | 12 | 12 times | High (roadmap) | $2M ARR at risk | High | DO NOW |
| Dark mode | 300 | 45 times | Medium | $0.1M nice-to-have | Medium | Q4 |
| API rate limits increase | 5 | 5 times | Medium | $50K revenue | Medium | Q3 |
| Custom branding | 20 | 20 times | Low (not roadmap) | $0.5M | Low | Backlog |
Stage 5: Communication & Feedback
For every categorized request, communicate back:
If Strategic Fit (shipping soon):
- "We're building this! Target: Q2. Here's why it matters to us too."
If Valid but Future:
- "Great idea. We're not prioritizing this right now because [reason]. It's on our radar for [timeframe]."
If Nice to Have:
- "Thanks for the suggestion. We've added it to our ideas list. We prioritize based on customer impact and strategic fit."
If Out of Scope:
- "This doesn't fit our product vision of [vision]. Here's why: [clear reasoning]. Alternative: [workaround or different tool]."
If Already Exists:
- "We actually have this! It's in [location]. Here's how to use it: [steps]."
Real-World Case Study: Triage System in Action
Company: B2B SaaS, 500 customers
Month 1: Before System
- 87 feature requests received (Slack, email, support tickets)
- 0 requests triaged
- Backlog unclear
- Customer follow-ups: "You said you'd look into export feature. Where is it?"
Month 2-3: Implement Triage
Week 1: Historical data cleanup
- 2,000 old requests deduplicated → 340 unique requests
- Major themes emerge: Export/portability (120 requests → 1 epic), Integrations (80 requests → 8 integrations), Performance (60 requests → 1 epic)
Week 2-4: Categorize all 340 requests
- Strategic fit: 45
- Valid but future: 120
- Nice to have: 110
- Out of scope: 45
- Already exist: 20
Month 4+: Weekly Triage
- New requests arrive (average 20/week)
- Each request categorized within 48 hours
- PM reviews trends weekly
- Quarterly: Review backlog, adjust priorities
Results (6 months later):
| Metric | Before | After | Change |
|---|---|---|---|
| Request response time | 7 days | 24 hours | 7x faster |
| Categorization accuracy | N/A | 95% | Clear |
| Customer satisfaction (on feature decisions) | 40% | 82% | +105% |
| Time spent on feature request management | 10 hours/week | 3 hours/week | -70% |
| Features shipped from backlog | 2/quarter | 6/quarter | +200% |
| Customer churn (to competitors' feature) | 8% | 3.2% | -60% |
Anti-Pattern: "Feature Request Voting"
The Problem:
- "Customers vote on features. Highest votes win."
- Result: Feature creep toward lowest common denominator
- Loudest customers win, strategic features lose
Example:
- Voting: "Dark mode" wins (300 votes). "Enterprise SSO" loses (12 votes).
- Reality: 12 enterprise customers worth $5M ARR. 300 consumers worth $50K.
The Fix:
- Use voting as input, not decision
- Weight by customer value (ARR, strategic importance)
- Don't let voting override strategy
- Communicate: "We see your votes. Here's how we prioritize."
Prodinja Connection
Feature requests are data about customer needs. If 50 customers ask for "export," that's a signal. If that signal is buried in a 2,000-row spreadsheet, it's invisible. Prodinja's Prioritization Studio is built to give each deduplicated request a RICE score — reach, impact, confidence, effort — and a Kano tag, then re-rank the backlog live as new requests roll in. Instead of a flat list, you get a ranked view where the requests with the strongest reach-and-impact case rise to the top, helping PMs move from reactive ("we got a request") toward proactive ("here's what the scoring says matters").
Key Takeaways (Expanded)
-
Deduplication reveals hidden patterns. Group "export to CSV," "send to Sheets," "download report" together. You'll see the real need.
-
Categorize ruthlessly. "Out of scope" is OK if explained. Customers accept "no" better than "maybe."
-
Communicate back every time. Even if it's "Nice to have, not prioritizing," acknowledgment is better than silence.
-
Use triage data to inform strategy. If 80 requests for integrations exist, integrations matter to customers.
-
Build process, not just system. Canny doesn't help if nobody looks at it. Weekly triage habit matters more than tool choice.