Feature request prioritization workflow
Intake, triage, prioritization, and roadmap placement.
Every product gets feature requests faster than the team can build them. Without a workflow, they pile up, duplicates get lost, decisions get made inconsistently, and customers wonder why their feature never moved. This template shows a repeatable intake-to-roadmap pipeline: requests get auto-classified and checked for duplicates, triaged for scope fit, voted on by customers, and then prioritized by impact and effort.
The workflow makes visible where most teams get stuck: the triage bottleneck (too many requests, not enough time to review each one), and the prioritization gap (strong customer demand vs. strategic fit). Seeing both in one diagram helps teams communicate about trade-offs without meetings spiraling.
When to use this template
- Building a request intake system — use this flowchart to design your survey tool, GitHub issue template, or feature request form, so every request hits the same workflow.
- Explaining your product process to customers — when someone asks why their request is not shipped yet, point them to this diagram so they understand: was it deduplicated? Does it fit the roadmap? Is it high-impact enough to fast-track?
- Team workshops on prioritization — sketch this flowchart on a whiteboard and debate the criteria for each decision point (what makes a feature "in scope"? what vote threshold triggers prioritization?). This diagram becomes your shared rubric.
How to adapt it
Refine the decision points to match your product and process:
- Add a Beta testing gate: high-impact features go to select customers for feedback before committing to a sprint.
- Insert a Complexity assessment before scheduling: features marked "high effort" get broken into smaller subtasks or delayed a quarter.
- Extend the workflow with Shipped + Feedback loop: once a feature launches, gather user feedback and route improvements back to the intake queue.
Visual edits regenerate clean Mermaid, so you can iterate on the workflow logic with your team without syntax overhead.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
flowchart TD
A[Customer submits request] --> B[Auto-classify & triage]
B --> C{Duplicate?}
C -->|Yes| D[Merge with existing]
D --> E[Aggregate votes]
C -->|No| F{Fits roadmap?}
F -->|Out of scope| G[Decline with reason]
G --> H[Notify customer]
F -->|Maybe| I[Add to backlog]
I --> J[Quarterly review]
F -->|Aligns| K[Prioritize with impact]
K --> L{High impact?}
L -->|Low| M[Schedule for later]
M --> N[Assign to future sprint]
L -->|High| O[Fast-track to backlog]
O --> N
E --> P{Vote threshold?}
P -->|Meets threshold| J
P -->|Below threshold| I
N --> Q[Dev commits to sprint]
Q --> H
Frequently asked questions
- Why does every feature request go through triage before prioritization?
- Triage (auto-classifying and checking for duplicates) is a scalability gate. If you skip it, you end up manually reviewing hundreds of near-identical requests. Triage catches duplicates, tags requests by category, and surfaces which features are actually common vs. one-off asks from vocal users.
- What does 'fits roadmap' mean?
- It's a quick alignment check: does this request fit the product vision and strategic direction? If it's a legitimate feature but orthogonal to your product (e.g., a feature request to add FTP support to a cloud storage service), it's out of scope. Declining clearly saves the customer from hoping.
- How do I decide if a feature is 'high impact'?
- Use a lightweight scoring model: user votes (how many customers want it), effort (rough dev cost), and strategic value (does it unblock team goals?). This diagram doesn't prescribe a formula because every company weighs them differently. You can annotate the 'High impact?' diamond with your scoring rubric.
- Why merge duplicates instead of just tracking them separately?
- Merged duplicate tracking gives you a real vote count — if 50 customers ask for the same thing in different ways, merging aggregates those votes into a single priority signal. It also prevents your product roadmap from splitting effort across similar-but-separate features.