How to Decide Whether a Customer Request Belongs on Your Roadmap

When a customer asks for a feature, do not promise it, dismiss it, or add it to a backlog and forget it. First find out what broke in their workflow. Then decide whether solving that problem would help the customers you want more of.

Key takeaways

• A feature request is evidence of a problem, not proof that the requested solution is the right one.
• Record the customer, context, consequence, and requested outcome before discussing implementation.
• Give each request a bounded next step: investigate, make a small change, sell custom work, or decline it.
• Repeated requests matter most when they come from the customer segment you are deliberately building for.

Start with the problem behind the request

Suppose a customer asks for a calendar view. That sounds precise, but it may conceal several different jobs: finding open capacity, seeing deadlines, coordinating a team, or avoiding double booking. Building a full calendar before learning which one matters can turn a one-day fix into weeks of work.

Ask four questions before you estimate anything:

1. What were you trying to do when this became a problem?
2. How do you handle it today?
3. What does the failure cost you: time, revenue, risk, or frustration?
4. What result would make you say the problem is solved?

That is basic discovery, not a stalling tactic. The UK Government's user-research guidance recommends learning how people complete the task today, where they encounter problems, and what they need before planning a solution. Keep the customer’s original words, but label your own interpretation separately.

Put the request in a decision record

Use a small table, a note, or a CRM field. The tool is unimportant; the fields are not.

Record	What to capture
Customer and segment	Who asked, and whether they resemble the customers you want more of.
Trigger	The workflow and moment where the problem appeared.
Consequence	What the customer loses or risks if nothing changes.
Evidence	A quote, screen recording, support ticket, or observed behavior.
Requested solution	The feature they named, without treating it as the answer.
Next step	Investigate, prototype, small fix, custom work, or decline.

Grouping requests by theme is more useful than counting every mention of a feature name. Atlassian’s customer-feedback guide similarly recommends organizing feedback and weighing frequency, problem severity, strategic fit, segment importance, effort, and technical complexity. Those criteria are inputs to judgment; they do not produce a magic score.

Choose one of four honest responses

Investigate when you understand the complaint but not the underlying need. Ask for examples, watch the current workflow, or test a rough workaround with a few similar customers.

Build a small version when the need is clear, fits your target customer, and can be tested within a time limit you can afford. Set the time limit before designing the solution. In Basecamp’s Shape Up example, a request for complex permission rules turned out to be a need to warn people before an action affected others; the narrower solution took far less work.

Sell custom work when the request is valuable to this customer but does not fit the product you intend to repeat. Price the work, document its limits, and do not imply that every future customer will receive it. This is a business-model decision, not a product-roadmap decision.

Decline when the request does not serve the target customer, would make the product harder to understand, or has too little evidence behind it. A clear no is better than a vague “we’ll add it soon.”

Do not let a large customer skip the test

The amount a customer pays is relevant, but it cannot replace product judgment. A large account can fund useful learning; it can also pull a small company into a service business it never intended to run.

Before making an exception, write down what would have to be true for the work to earn a place in the core product. For example: three target customers encounter the same problem, the workflow is repeatable, and the change supports the product’s direction. If the evidence never appears, keep the work custom or stop offering it.

This protects the relationship too. A customer deserves a direct answer about what you will do and when. Your team deserves a roadmap that reflects deliberate choices instead of whoever asked most recently.

FAQ

How many customers must request a feature before I build it?

There is no universal number. One request can justify action when the customer is a strong match, the problem is severe, and a small test is cheap. Ten requests can still be weak evidence if they come from people outside the market you are choosing to serve. Look for a repeatable problem, not a quota.

Should I show customers my roadmap?

Share the problem you are evaluating and the next check-in when that helps the relationship. Avoid promising a date until you have made a real commitment. A roadmap is a planning tool, not a list of obligations created by every conversation.

What if I already promised the feature?

Reset the expectation directly. Explain what you learned, give the customer the actual next step, and offer a workaround or custom engagement only if you can support it. Do not hide behind an indefinite backlog.

Wrap up

For the next customer request, write down the workflow, consequence, evidence, target-segment fit, and one bounded next step before your team discusses a feature. That five-minute habit will make the next product decision easier to defend. If you want peers to pressure-test the decision, bring it to the buildpurdue cohort.