What it means
Customers, employees and partners may all suggest product changes, arriving through support, sales calls, research or an in-product form. Capture the context, not only a feature name: who asked, the use case, frequency, current workaround and consequences.
A short direct quote may help explain the need, and customer privacy and access limits should be respected in the feedback system. Atlassian discusses feature requests and customer feedback as inputs to product decisions, and Productboard describes linking feedback to ideas.
These workflows help organise evidence but do not prescribe a single prioritisation formula. Distinguish a problem from a proposed solution: a fictional accounting app receives "add a dashboard," and asking which decision the customer cannot make today reveals that late invoice alerts matter more than a new screen.
Tagging and merging need care. A fictional support agent tags requests for CSV export, yet some customers need raw transaction lines while others want tax summaries, and a fictional team groups five complaints about slow checkout when two relate to payment errors and three to too many fields.
Merge duplicates without losing original context and keep links to the source feedback, because treating different problems as one request would obscure the fixes. Prioritisation considers user value, business goals, reach, urgency, cost and risk, estimated with evidence where possible, and a loud requester should not automatically outrank a widespread issue.
A fictional enterprise client asks for a custom report; sales identifies potential revenue, but engineering finds ongoing maintenance costs, so leaders compare it with other work before agreeing. A fictional user asks for a mobile app, yet interviews show they need to approve one transaction while travelling, which a responsive approval page could meet without a separate app.
Requests can also reveal gaps in onboarding, reliability or policy rather than missing features. A fictional user cannot find an existing filtering option, so the team improves labels and help text and closes the request with an explanation rather than shipping another filter.
A roadmap shows intent and priorities, not an unconditional delivery guarantee, since dependencies, security and testing can change timing, and a fictional team tells a customer a request is being evaluated without promising a launch next month. Some requests introduce privacy, accessibility or compliance risk, and a popular request is not automatically lawful or safe.
A fictional analytics team considering sharing user-level data with account admins checks consent and permissions before building, and finds aggregated reporting may fit the need better. Track status in a simple lifecycle of received, researched, prioritised, planned, released or declined, explain any decline without blaming the requester, and after release measure whether the change solved the underlying problem using usage, customer outcomes and support feedback.
In practice
Real-world examples.
Example
A customer of an accounting app asks for a dashboard, but the product team learns the real need is overdue invoice alerts. It ships a simple alert before considering any new screen. The original requester is told what was built and why.
Example
Several requests for CSV export in an e-commerce platform are split by underlying use case: raw order lines for analysts and tax summaries for finance teams. Each use case is logged separately with its own source tickets. The team then builds the tax summary first because more customers cited it.
Example
A software team declines a proposed feature because it would duplicate an existing tool, but improves the existing workflow instead. It explains the reason to the requester without blaming them. The evidence is kept so that the decision can be revisited later.
Formula
Calculation
There is no universal formula, but some teams use a simple illustrative score: priority score = (customers affected x impact rating) / effort in person-weeks. The impact rating runs from 1 (minor) to 3 (major), and every input is an estimate that should be stated with its assumptions.
Worked example: Request A is a CSV export that affects 400 customers, has an impact rating of 2 and needs 4 person-weeks. Score A = (400 x 2) / 4 = 800 / 4 = 200. Request B is a compliance report that affects 50 customers, has an impact rating of 3 and needs 1 person-week. Score B = (50 x 3) / 1 = 150.
Request A ranks higher on the score, but the score is not certainty. If Request B is needed to meet a regulatory duty, or if the 50 customers are the largest accounts, leaders may rightly choose B first, so the score informs the discussion rather than replacing judgment.Case study
Seen in the real world.
In this fictional case, Northstar Software, an invented company, receives 40 requests for offline access. Interviews show that most come from field staff with unreliable connectivity, and only a few come from office users who simply prefer a desktop app. The team tests a limited offline draft flow with a small group, measures whether work is saved reliably and updates the requesters on progress.
It does not promise full offline capability before testing. After release, the team compares support tickets about lost work before and after the change and asks the original requesters whether the problem is solved. The case is illustrative and the numbers are invented.
Watch out
Common mistakes.
- Recording only a proposed solution without the underlying need.
- Counting duplicate tickets as proof of the number of unique customers.
- Promising delivery before the team has decided and tested.
Questions
People also ask.
Does a feature request guarantee a build?
No. It is evidence for a product decision.
What should be captured with a request?
The user's goal, context, current workaround and source feedback.
What happens after a feature ships?
Check whether it solved the original problem and tell requesters what changed.
From the founder's library
Take it further with the book.
Build your financial confidence beyond this definition. Shihan's full-length guide, Accounting Fundamentals, takes the same plain-English approach and turns it into a complete, practical playbook for non-finance managers, business owners and students - with chapter-end quiz answers and presentation slides included.
25% off with code MMHQ25, applied at checkout. Priced in USD - checkout may show the equivalent in your local currency.
View the book and save 25%