Feature Request Process: 7 Steps From Inbox to Shipped
A feature request process is the set of steps that takes an idea from the moment a customer mentions it to the moment you tell them what you decided. The version that holds up has seven steps: capture every request in one place, record the context, merge duplicates, score against clear criteria, decide and explain, build and track, then close the loop with the people who asked. Skip any one and requests pile up, the loudest customer wins, and users stop asking.
This guide walks through each step with the fields to record, a worked scoring example and the mistakes that quietly break the workflow.
TL;DR
- Put every request into one tracker, whatever channel it came from. Email, chat and call notes are inputs, never the system of record.
- Record the problem, the requester, the source and the evidence, not just the solution the customer proposed.
- Merge duplicates so demand shows up as a count, then score on a few fixed criteria so you stop reacting to the loudest voice.
- Always give an answer, even a "no", and show status publicly: under review, planned, in progress, shipped.
- Notify everyone who asked when the feature ships. That last step is what keeps people submitting.
Table of Contents
- What a feature request is, and what makes one useful
- Step 1: Capture everything in one place
- Step 2: Record the context, not just the ask
- Step 3: Merge duplicates and group by need
- Step 4: Score requests on fixed criteria
- Step 5: Decide and explain
- Step 6: Build, track and show status
- Step 7: Close the loop when it ships
- Our perspective: keep the process boring and the board public
- Where a feedback board fits in this process
- Common mistakes that break the workflow
- FAQ
- Sources
What a feature request is, and what makes one useful
A feature request is a customer or colleague telling you something your product should do that it does not do today. The useful ones describe a situation, not only a button.
Open source maintainers have thought about this longer than most. The RStudio team's guidance on writing good feature requests says a strong request can include relevant examples or research, attempted alternatives, standards or conventions it follows, and a sketch or other illustration. Its model example is simple and specific, gives context, and ties the problem to a proposed solution.
Take that as your quality bar for the intake form. "Add dark mode" is a wish. "I review dashboards at night on call and the white background hurts, I currently use a browser extension that breaks the charts" is a request you can score, because it tells you who is affected, how often and what they do today.
Step 1: Capture everything in one place
Requests rarely arrive through a form. They show up in support chats, sales calls, account manager emails, community threads and social posts. One engineering team's account of managing feature requests describes exactly this: requests arriving by email, WhatsApp, Slack, phone and meeting notes, with records scattered across documents, spreadsheets, a ticketing tool and email threads. Their fix was to centralize intake in a single tool, which saved time and made recurring themes visible.
The rule is simple. Anything that comes in through another channel gets copied into the official tracker before anyone processes it further. A published intake SOP states the same rule: requests from email, chat or meetings are transferred into the tracker first.
You have three practical options for the tracker:
- A spreadsheet or doc. Fine for the first twenty requests. It breaks when several people need to add, vote and comment.
- Your engineering backlog. Tempting, but it mixes raw customer wishes with committed work. Our piece on backlog and roadmap drift explains why that blend causes trouble.
- A dedicated feedback board. Customers post and vote themselves, and your team sees demand without transcribing anything. This is what we build, more on that below.
If you are weighing the always-on approach against asking people directly, see how teams collect user feedback through always-on channels and a weekly probe.
Step 2: Record the context, not just the ask
A request without context cannot be prioritized later. When a support agent logs it, they should capture enough that a product manager who never spoke to the customer can understand it.
The intake SOP above lists the core fields: requester, date, affected product or area, problem, desired outcome, impact, urgency and evidence. PostHog's feature request handbook adds good habits for preserving evidence: an internal summary, the customer's direct quote, the source, the request date, a source URL and screenshots where they help.
A practical field list:
| Field | Why it matters |
|---|---|
| Title (problem-first) | Makes searching for duplicates possible |
| Customer quote, verbatim | Keeps the original words, not your paraphrase |
| Requester and segment | Shows who is asking: free user, paying team, enterprise |
| Source and link | Lets anyone go back to the conversation |
| Date | Shows whether demand is growing or stale |
| Current workaround | Reveals how painful the gap really is |
| Impact and urgency | Feeds scoring in step 4 |
If you want ready-made forms, we collected four feature request templates you can copy, and six email replies for support teams to send when a request lands.
Step 3: Merge duplicates and group by need
Ten customers will ask for the same thing in ten different ways. If you leave them as ten tickets, none looks important. If you merge them, you have a count.
The intake SOP recommends searching the backlog and recent request history for duplicates or overlap, linking duplicate records and consolidating requests that describe the same underlying need. Plane's guide to managing feature requests at scale adds that consistent request definitions help teams group similar requests, spot patterns and prioritize fairly instead of reacting to whoever is loudest.
Two habits make this easier:
- Write titles as problems. "Export reports to PDF" and "Send monthly report to my boss" are the same need. Group under the need.
- Merge, don't delete. Keep each requester attached to the merged record so you can notify all of them later.
A public board does much of this for you. Before posting, a user searches existing ideas and votes on a match instead of writing a new one. Votes become your duplicate count.
Step 4: Score requests on fixed criteria
Once requests are grouped, you need a repeatable way to rank them. Gut feel works until two stakeholders disagree.
The intake SOP lists criteria teams can use: customer impact, revenue impact, compliance need, operational efficiency, effort, risk and strategic alignment, with the score, rationale and assumptions written down. You do not need all seven. Pick three or four and keep them stable.
Here is a simple worked example using 1 to 5 scales for reach (how many users), value (how much it helps each one) and strategic fit, divided by effort:
| Request | Reach | Value | Fit | Effort | Score |
|---|---|---|---|---|---|
| Slack notifications | 4 | 3 | 4 | 2 | 5.5 |
| PDF export | 3 | 2 | 2 | 2 | 3.5 |
| Custom roles | 2 | 5 | 3 | 5 | 2.0 |
The score is (reach + value + fit) divided by effort in this toy model. The formula matters less than the discipline: every request gets scored the same way, and the reasoning is written next to the number so you can revisit it when assumptions change.
Votes are one input, not the verdict. A request with 200 votes from free users and one with 12 votes from your largest paying accounts mean different things. Record both. For a deeper method, read how to prioritize feature requests without guessing.
Set a review rhythm
The engineering team mentioned earlier ran weekly reviews with three priority levels: high for immediate pickup, medium for an upcoming sprint and low for a future sprint. You can copy the shape. A fixed weekly or biweekly slot means requests never wait on someone remembering them, and each one leaves the meeting with an owner and a next review date.
Step 5: Decide and explain
Every request ends in one of four outcomes:
- Planned. You will build it, and you may give a rough timeframe.
- Under review. You need more information or more demand.
- Not planned. It does not fit the product, with a reason.
- Already possible. There is a way to do it today, and you point to it.
The "no" is the step most teams skip, and it costs them. A request that sits unanswered tells the customer nobody is listening. A short, honest "not planned, because it pulls the product away from X" respects their time and often produces a better follow-up request.
Write the rationale down as part of the record. Six months later, when someone asks again, you can paste the reasoning rather than reconstruct it.
Step 6: Build, track and show status
Once a request is planned, its status should move visibly: under review, planned, in progress, shipped. Internally, link the request to the engineering ticket so progress updates flow back without anyone copying notes.
Visibility matters inside the company too. The engineering team we cited published sprint-planning documents and release notes in a shared chat channel and presented product and engineering updates in biweekly all-hands meetings. Their experience suggests that centralization and visible status cut down on chaos and stakeholder uncertainty. If sales and support can see status on their own, they stop pinging product managers for it.
For customers, the equivalent is a public roadmap. There are several formats, from simple three-column lists to date-free themes, and we compared them in four public product roadmap formats. If you are new to the idea, the roadmap section of our beginner guide is a gentle start.
Step 7: Close the loop when it ships
This is the step that turns a one-time request into a habit. When a feature ships, everyone who asked or voted should hear about it directly, not only through a blog post they may never read.
A workable routine:
- Change the request status to shipped. If your tracker notifies voters automatically, that may be all you need.
- Send a short note to the requesters: what you built, how to use it and a link to the docs or release notes.
- Ask one follow-up question: does this solve what you described? Their answer catches misses early.
- Thank the people who asked, by name where you can. Customers who see their idea shipped tend to submit more.
Do the same for decisions that go the other way. Telling voters "we decided not to build this, and here is why" is also closing the loop.
Teams that collect feedback inside the product can pair a timed survey with a public board, as we describe in feedback inside your app, so the loop closes in the same place the request began.
Our perspective: keep the process boring and the board public
We build a feedback board, so we see the same failure again and again. A team starts with good intentions, a spreadsheet and a Slack channel. Within a quarter the requests live in six places, nobody knows what was promised, and the roadmap is whatever the last angry email said.
Our view is that the process should be boring. One place for requests. Fixed fields. Votes visible. A short list of statuses that mean the same thing to everyone. When a process is boring, people follow it, and when people follow it, product managers spend their time deciding rather than hunting.
We also think the board should be public by default. Customers who can see what others have asked for stop submitting duplicates, they add votes and comments with context, and they can watch an idea move from under review to shipped without writing to anyone. Private boards have their place, for internal ideas or sensitive accounts, but most of the trust comes from visibility.
Finally, pricing should not punish participation. That is why every Petĩra plan includes unlimited users, ideas and votes at a flat rate. A feedback process works better when you never have to wish fewer customers would join in.
— Aron
Where a feedback board fits in this process
A dedicated board covers steps 1, 3, 6 and 7 almost by itself: customers post ideas, vote on existing ones, comment, and see status change from under review to planned, in progress and shipped. Your team gets email notifications, moderation tools, an embeddable widget, a public roadmap and integrations with Slack, Discord and GitHub.
If you already track requests elsewhere, you do not start from zero. Petĩra imports from Canny, Fider or a CSV file, and you can export everything as JSON or CSV at any time. Custom domains and custom CSS let the board look like part of your product.
Plans are published on the pricing page: Free at €0 per month, Pro at €19 per month or €190 per year, and Team at €49 per month or €490 per year. You can compare how that sits against the rest of the market in our pricing comparison of 12 feedback tools, or try Petĩra and move your first requests in an afternoon.
If your requests currently live in a workspace tool, our guide to tracking Notion feature requests helps you decide whether to keep them there or move them.
Common mistakes that break the workflow
- Treating the customer's solution as the requirement. Ask what they are trying to do. The best answer is often smaller than what they proposed.
- Counting votes without segments. Raw totals hide who is asking.
- No owner. A request with no named owner and no review date is a request that will sit.
- Mixing requests with the committed backlog. Keep demand and commitment separate, and promote a request only when you decide to build it.
- Promising dates. Say "planned" or "in progress". Dates become commitments, and slipping them costs trust.
- Going silent after shipping. If nobody hears about the release, the loop is open.
FAQ
What is a feature request process?
It is the repeatable path a request follows: capture, add context, merge duplicates, score, decide, build and notify the requester. Its purpose is to make sure every request is recorded once, judged consistently and answered.
How do you write a good feature request?
Describe the problem and the situation first, then the outcome you want, then any idea for a solution. Add what you do today as a workaround and, where it helps, an example or a sketch. Specific context lets the product team judge value without a follow-up call.
How do you prioritize feature requests?
Pick three or four criteria, such as how many users are affected, how much value each gets, fit with strategy and effort. Score every request the same way and write down the reasoning. Use votes as one input alongside the segment of the people who voted.
What should you do with requests you will not build?
Answer them. Mark the request not planned, give a short reason and, when possible, point to a workaround. People accept a clear no far better than silence, and your reasoning stays on record for the next time someone asks.
Sources
- Writing Good Feature Requests, RStudio wiki
- Feature request tracking, PostHog handbook
- Managing Feature Requests, Nivoda engineering
- Feature Request Intake and Prioritization SOP Template, MangoApps
- Managing feature requests from customers at scale, Plane