reaperinvest Feature Request System
When to Use This Skill
Use this skill when you need to:
- Design a system for collecting and organizing customer feature requests
- Build a prioritization framework for evaluating requests
- Create a public or internal roadmap connected to user feedback
- Set up voting, tagging, and status workflows for feature management
DO NOT use this skill for bug tracking systems, customer support workflows, or product roadmap strategy. This is for the feature request collection and prioritization system specifically.
Core Principle
A FEATURE REQUEST SYSTEM IS NOT A SUGGESTION BOX — IT IS A DECISION-MAKING TOOL THAT CONNECTS CUSTOMER VOICE TO PRODUCT PRIORITIES WITH TRANSPARENCY.
Phase 1: Brief
Required Inputs
| Input | What to Ask | Default |
|---|---|---|
| Product type | "What is the product?" | No default — must be provided |
| Request volume | "How many feature requests do you receive per month?" | Under 50 |
| Current process | "How do you handle feature requests today?" | Email or ad hoc |
| Public or internal | "Should customers see and vote on requests, or is this internal only?" | Public voting board |
| Team size | "Who reviews and prioritizes requests?" | Solo founder |
| Existing tools | "Do you use any project management tools currently?" | None specific |
GATE: Confirm the brief before designing the system.
Phase 2: Design the System
Collection Channels
Define where requests enter the system:
| Channel | Capture Method |
|---|---|
| In-app widget | Feedback button → form submission |
| Support inbox → tag and forward | |
| Support tickets | CS team tags feature requests |
| Social media | Manual capture into system |
| Sales calls | CRM note → feature request tag |
| Public board | Direct user submission |
Request Template
Every request captured with these fields:
- Title: Short, descriptive name
- Description: What the user wants and why
- Use case: The specific scenario driving the request
- Requester info: Name, plan tier, account value
- Category: Feature area (e.g., billing, reporting, integrations)
- Priority score: Calculated (see Phase 3)
Status Workflow
Submitted → Under Review → Planned → In Progress → Shipped → Closed (Won't Do)
GATE: Confirm system design before building the prioritization framework.
Phase 3: Prioritization Framework
Scoring Model (RICE)
| Factor | Description | Scale |
|---|---|---|
| Reach | How many users will this affect? | 1-10 (% of user base) |
| Impact | How much will it improve their experience? | 1-3 (low/medium/high) |
| Confidence | How sure are we this will work? | 50-100% |
| Effort | How much work to build? | 1-10 (days/weeks) |
RICE Score = (Reach x Impact x Confidence) / Effort
Decision Matrix
| Score Range | Action |
|---|---|
| 50+ | Prioritize for next cycle |
| 20-49 | Plan for future cycle |
| 10-19 | Monitor for additional votes |
| Under 10 | Acknowledge and defer |
Voting System Rules
- One vote per user per feature
- Allow users to add context with their vote ("I need this because...")
- Show vote counts publicly to build engagement
- High-value customers (enterprise, high MRR) can be weighted internally
Phase 4: Polish
1. Communication Templates
Request received: "Thanks for the suggestion! We have logged your request for [feature]. You can track its status and vote at [link]."
Status update: "Update on your request: [feature] has moved to 'Planned' — we are targeting it for [timeframe]. We will notify you when it ships."
Request shipped: "Great news — [feature] is live! You asked for it, we built it. Try it out: [link]."
Request declined: "We reviewed your request for [feature] and decided not to pursue it at this time. Here is why: [brief reason]. We appreciate the feedback and encourage you to keep sharing ideas."
2. Roadmap Integration
- Link feature requests to roadmap items
- Show a public "what we are working on" page with 3 columns: Planned, In Progress, Shipped
- Update the board monthly at minimum
- Celebrate shipped features with "You asked, we built" messaging
3. Quality Checklist
## Feature Request System Checklist
- [ ] Collection channels defined (in-app, email, support, social)
- [ ] Request template captures title, description, use case, and requester info
- [ ] Status workflow has clear stages (Submitted → Shipped or Closed)
- [ ] Prioritization framework uses a scoring model (RICE or similar)
- [ ] Voting system allows users to support requests
- [ ] Communication templates exist for received, planned, shipped, and declined
- [ ] Public or internal roadmap is connected to the system
- [ ] Monthly review cadence is set for prioritization
- [ ] "Won't Do" requests are communicated with a reason
- [ ] System integrates with existing project management tools
Example
Product: SaaS project management tool Volume: 30 requests/month
Public board categories:
- Integrations (Slack, Zapier, etc.)
- Reporting & Analytics
- Task Management
- Mobile App
- Billing & Account
Top request card example:
## Dark Mode
Votes: 47 | Status: Planned | Category: UI/UX
"Add a dark mode option for the web app and mobile app."
Top voter comment: "I work late nights and the white interface is blinding. Even a simple dark theme would make a huge difference." — Sarah K., Growth Plan
Anti-Patterns
- Building everything users ask for — popular requests are not always the right priorities. Use scoring to balance demand with strategy.
- Black hole feedback — collecting requests without ever updating status destroys trust. Close the loop.
- No decline path — never saying no means an infinite backlog. Have a "Won't Do" status with a reason.
- Letting vote count alone decide — a feature with 100 votes from free users may matter less than a request from your top 5 paying customers.
- Overcomplicating the system — a spreadsheet beats a complex tool nobody uses. Start simple.
Recovery
- Overwhelmed by request volume: Batch-process weekly instead of daily. Group similar requests to reduce duplicates.
- No votes on the board: Seed it with known requests from support emails. Announce the board to existing users.
- Conflicting requests: Document the tradeoffs. Present both options to a small user group for tiebreaking feedback.
- User angry about declined request: Respond personally. Explain the reasoning and suggest a workaround if one exists.