How to manage feature requests: when to build, and when to wait

A feature request can sound like an obvious priority when you're reading it. Then you open the next one, and that sounds important too.

The hard part of feature request management is deciding what deserves your team's time. Votes help you see what people are asking for. Comments help you understand why. But neither tells you, on its own, whether something is worth building now.

For that, you need to connect the request to a problem, weigh the likely benefit against the work involved, and compare it with your other priorities. Here's a practical way to do that, including what to say when the answer is “not yet” or “no”.

Track each request in one place

Requests arrive through support, sales calls, community chats and feedback boards. Give each distinct request a central record so you can assess it alongside the others.

A board such as Fider gives people somewhere to post suggestions, vote and discuss them. A spreadsheet can also work, provided someone keeps it updated. You can leave the original support conversations where they are and link to them from the central record.

For each request:

1. Check for an existing entry. Add new evidence to that record rather than splitting the conversation across duplicates. If you close a duplicate, direct the requester to the original so they know their suggestion is still being considered.
2. Identify the problem behind the suggestion. “Add a red badge” is a proposed solution. Ask what the badge would help someone notice or do. Keep their original suggestion, but record the underlying problem too.
3. Record who is affected. Note the relevant customer or user group, where the request came from, and any examples or workarounds. Keep private customer details in an internal record, linked to the public discussion where appropriate.
4. Give it an honest status. Make clear whether you're considering it, planning it, working on it or declining it. Explain meaningful changes in the same place people follow the request.

The record should help a teammate understand the request without retracing every conversation. It doesn't need a full business case at this stage.

Read the votes alongside the problem

Votes make expressed interest visible. They're useful for spotting requests to investigate, especially when feedback would otherwise be scattered across separate conversations.

They also reflect who saw the request and chose to participate. A heavily promoted post may attract more votes than an equally important problem that few people have found. Low participation doesn't establish that a problem is unimportant.

Before treating a popular request as a priority, check three things.

Who's asking?

For B2B products, look at distinct customer accounts as well as individual voters. Ten people from one company tell you something different from ten people at ten companies. The first may reveal a problem affecting a whole team; the second suggests it extends across customers. Anna Debenham's formula for prioritizing feature requests dedupes repeat requests from the same company for exactly this reason, “as this can inflate the total weight.”

For a consumer app or game, individual users may be the more useful unit. Either way, ask whether the people requesting the change belong to the audience you're building for.

A request from one specific target segment can be worth pursuing. It doesn't have to appeal to everyone.

What are they trying to do?

Read the comments and supporting conversations. How often does the problem occur? What happens when it does? Can users work around it, and how much effort does that take?

If several people mention the same time-consuming workaround, that gives you more to investigate than just a vote total. But a quiet comment thread isn't automatically weak evidence: the original post might already explain the need clearly.

Also look for different suggestions that point to a shared problem. Requests for Slack alerts, Discord alerts and webhooks might really mean that folks just want timely notifications. That gives you a useful discovery question: where do these users need the information, and what would make it actionable? It doesn't mean that one integration will satisfy everyone.

Is the need still current?

Look at recent requests and conversations as well as the lifetime total. An older post might describe a problem that has changed, or one that's still unresolved.

If interest has recently increased, investigate why. More customers might be encountering the problem, but the post might also have appeared in a newsletter or been shared by a customer. Both are useful context for interpreting the numbers.

Put the demand in proportion

Where you have the data, compare the number of requesting accounts with the number that could benefit.

So suppose that during the past quarter, 25 distinct accounts ask for a better export method within your software's reporting system. If 200 accounts used reporting in that period, that's 12.5%. If 4,000 used it, it's about 0.6%.

(Analytics company Metabase uses the same logic for measuring feature adoption after launch: adopting accounts divided by eligible active accounts, not your whole customer base.)

So those figures describe the share of those who expressed a need. They don't tell you how many others have the same problem or how important it is. Or even whether your proposed fix would help.

Listening to current users of a feature can be a useful starting point, but you may also need to think about customers who avoid it because of the missing capability.

If you don't have reliable usage data, record what you know and investigate the gaps. A precise-looking ratio built from mismatched numbers won't improve the decision.

Weigh the benefit against the work

A request can have clear demand and still be the wrong thing to build next. Once you understand the problem, think about what solving it would achieve and what it would displace.

Ask:

• How much would it help? Would it remove a recurring obstacle and save substantial time? Or would it make an occasional task slightly nicer?
• Which goal does it support? It might help users get started, reduce support work, improve retention or deliver a better experience in a part of the product you've chosen to focus on.
• What would it take? Include discovery, design, engineering, testing and ongoing maintenance. Ask the people doing the work about uncertainty and dependencies.
• What would you postpone? Compare it with the other worthwhile work competing for the same capacity.

Votes can inform this discussion, but they can't answer every question. A popular request might still have an uncertain solution or a high maintenance cost. A less popular one could solve a severe problem with only a small change.

If your team uses the RICE framework for calculating priorities, use feedback board evidence to support the relevant estimates. Comments and customer conversations can help establish the problem and likely impact; usage data can inform reach; engineering input can inform effort. Confidence means how much evidence you have that your estimates are realistic. Votes can help demonstrate interest, but they don’t establish the likely benefit or development effort.

Example: the smaller request goes first

Imagine a small B2B software team choosing between two requests: nicer-looking dashboards, or better report exports. Here's how the demand looks:

Request 1: dashboard themes

• Expressed interest: 80 votes from 55 accounts.
• Problem described: Customers want more control over appearance.
• Evidence gathered: Comments list several different preferences.
• Estimated work: Several weeks, with continuing design and testing work.
• Fit with the team's existing goal: Limited connection to this quarter's focus on making reporting easier to use.

Request 2: report export improvement

• Expressed interest: 25 votes from 25 accounts.
• Problem described: Finance teams manually reformat exports every week.
• Evidence gathered: Five interviews reveal the same workaround, and support has matching cases.
• Estimated work: A few days for a limited change, subject to technical checks.
• Fit with the team's existing goal: Directly supports making reporting easier to use.

Yes, the first one has more total votes. But the export improvement addresses a clearly described problem, appears relatively small to build and supports the team’s existing goal of making reporting easier to use.

The themes request can stay open while the team clarifies which changes would help most. Its votes are still useful evidence that this needs looking at—just maybe not right now.

When to investigate or wait

Separate a request that needs investigation from one that simply isn't a priority yet.

If a problem looks consequential but you don't understand it, assign a next step. Speak to a few affected users and examine the relevant support cases. You could even test a proposed solution. Give someone responsibility for bringing the findings back.

If the problem is understood but other work matters more, explain that and set a review point. You don't need to pretend that more votes are the only thing you're waiting for before taking action.

GitLab's planning handbook has a useful example: requests that fit its direction but have little demand can be marked as “Awaiting further demand”. It also advises against closing an issue simply because it's old.

On your own board, explain what you're waiting for. That might be more evidence of the problem, or completion of a dependency. Or you could be waiting for free capacity after dealing with an existing commitment.

For example:

We understand that this would save time for teams managing several workspaces. We're prioritizing reporting improvements this quarter, so this isn't planned yet. We'll review it during our next planning round. In the meantime, examples of how you handle this today would help us assess the scope.

Choose a review cadence that fits your planning cycle. When you revisit the request, check whether the need, evidence or cost has changed. Avoid leaving an item open indefinitely without letting its followers know.

Keep “planned” for work you've actually decided to pursue. If plans change, update the explanation. Our guide to public roadmaps shows you how those expectations develop.

When to say no

Decline a request when you have a clear reason for not pursuing it. It might fall outside your product's purpose. It could introduce unacceptable complexity, or require ongoing work that's not worth committing to.

Be specific about whether you're declining the proposed solution or the underlying capability. You might reject a complicated new settings panel while still investigating the problem it was meant to solve.

Thank the requester, explain the decision and offer a workable alternative (if one exists). Avoid suggesting that more votes could change your mind when the real issue is product direction.

For example:

Thanks for explaining how you'd use this. We're keeping the product focused on collecting and discussing feedback, so we don't plan to add a full project-management system. We're declining this request so you have a clear answer.

Post the decision where people follow the request. Our guide to closing the feedback loop covers how to keep users informed as their suggestions move forward.

Make the decision, then check the result

Before moving a request to planned, you should be able to explain:

1. The problem and who experiences it.
2. The evidence that it's worth addressing.
3. Why the proposed change is a suitable response.
4. The expected benefit, effort and continuing cost.
5. Why it deserves capacity ahead of other work.
6. What you'll check after release to see whether it helped.

Answering these questions gives you a basis for a decision. You might still decide to wait or decline. If an important answer is missing, identify what you need to learn before committing.

Once you ship, return to the people who described the problem. Did they use the change? Did it remove the workaround or obstacle? If possible, check relevant usage data inside your product alongside their responses. Shipping the requested feature and solving the original problem aren't always the same thing.

Make request review a regular part of your planning. Even a short session means you can handle duplicates, status updates and straightforward decisions.

Fider gives users a place to submit, discuss and follow suggestions. It helps prevent feature request management from being a chore. Instead, it becomes a really useful process for you and your users. The board does the collecting, you do the deciding.

‍