Which Customer Requests Should You Actually Build?

Do not build a customer request because a customer asked loudly, pays the most, or threatens to leave. Build when the request reveals an important problem shared by customers you deliberately want to serve, the problem fits your strategy, and the economics and effort make sense.

The key move is to separate the problem from the solution the customer proposed. A request is evidence. It is not an instruction.

Early companies often have a simple loop: a customer asks for something, the founder promises it, the team builds it, and the customer is happy. That loop can be useful while you are learning. It becomes dangerous when every request becomes a roadmap item.

Customer feedback comes through sales calls, support, interviews, usage, reviews and feature requests. Atlassian recommends combining qualitative feedback with quantitative signals and organizing requests by themes such as customer segment, severity, business impact and workflow stage. Its roadmap guidance also ties roadmap items to product strategy and goals rather than treating the roadmap as a list of requests.

That distinction matters because customers usually describe the solution they can imagine. They may ask for an export, integration, dashboard, approval step or custom workflow when the underlying problem is something broader. If you copy the requested solution directly into the roadmap, you can solve one account while making the product harder to understand for everyone else.

Before a request becomes a build decision, run it through seven questions.

Write the request in two sentences: first what they asked for, then the business problem underneath it. If you cannot state the underlying problem clearly, do not build yet. Ask for an example of the moment when the problem occurs, what they do today, and what happens if they do nothing.

A useful translation looks like this:

Request: “Can you add a custom approval workflow?”

Problem: “Our finance team cannot reliably control who can approve purchases above a certain threshold, so work gets delayed or approvals happen outside the system.”

The second version can be tested against other customers. The first is only a feature specification.

One request can be strategically important, but one request is not automatically a pattern. Look for the same underlying problem across multiple customers, prospects, support conversations, churn reasons, usage behavior or lost deals.

Amazon Business describes a similar operating approach: sales teams log customer needs as voice-of-customer requests, review them, and use them to shape the roadmap, with emphasis on solving problems that serve a broad range of use cases.

Do not reduce this to a crude vote count. Ten requests from poor-fit customers can be weaker evidence than two serious requests from the exact segment you are trying to win.

A feature can be valuable to the wrong customer. That is a strategic trap.

Ask:

• Does this customer fit our intended segment?
• Would we want ten more customers like them?
• Does the problem occur in the segment we are trying to grow?
• Does solving it strengthen our core promise?

If the answer is no, the request may belong in a paid service, integration, partner solution or a polite no-not in the core product.

This is where founders often overbuild. A customer asks for a feature, but the real solution might be better documentation, onboarding, a configuration change, a workflow change, a service layer or a smaller product improvement.

Treat the requested feature as one hypothesis. Generate at least two alternatives before committing engineering time.

A roadmap needs a point of view. Current product guidance from Atlassian frames prioritization around customer insight plus strategic alignment, impact, reach and feasibility rather than feedback volume alone.

A good request should strengthen something the company already intends to become better at. If it pulls you into a new customer type, a new workflow, a new pricing model and a new support burden simultaneously, you may be accepting a new business model without admitting it.

Do not compare only feature value with engineering cost. Include the cost of future complexity.

Consider:

• build effort
• testing and maintenance
• support burden
• onboarding complexity
• documentation
• future exceptions
• pricing implications
• effect on other customers

A small feature that creates five new support paths is not small. A larger feature that removes a recurring manual problem for hundreds of good-fit customers may be the cheaper decision over time.

When uncertainty is high, test the underlying problem first. Try a manual workaround, prototype, mock interface, concierge process, paid pilot or limited release. The objective is not to fake a product. It is to learn whether the problem is important enough to justify a durable solution.

Every meaningful request can usually land in one of five buckets:

Build now: strong problem, strong segment fit, repeated evidence, strategic fit and acceptable economics.

Investigate: the problem looks important, but the pattern or solution is still uncertain.

Test manually: the problem is credible but a full product change is premature.

Serve separately: the request is valuable to a customer but is outside the core product. Price it as a service, integration or custom engagement if that fits the business.

Say no: the request is low-value, poor-fit, strategically distracting or likely to create disproportionate complexity.

This is better than a simple feature-request queue because it preserves uncertainty instead of turning every conversation into a commitment.

Large customers deserve attention. They do not automatically deserve roadmap control.

A high-value account can expose a serious enterprise problem that should become a product investment. It can also be an exception that only exists because the customer operates differently from the market you want. The job is to determine which one you are looking at.

Intercom has described a similar sales-to-product discipline: sales should investigate why the customer is asking, whether the request reflects a broader trend, and avoid turning every request into a product commitment.

The right response to a big customer's request is therefore not “yes” or “no” on the call. It is: “Let us understand the problem, check whether it repeats, and come back with the best solution.”

Score each dimension from 0 to 2:

This is not a universal formula. It is a forcing function for a better conversation. A high score still requires product judgment. A low score tells you why you should hesitate.

Do not throw the information away. Record the underlying problem, customer segment, context, workaround and reason for the decision. If the same problem appears later, you should be able to see that it is a pattern rather than rediscovering it from zero.

Also close the loop with the customer. Tell them whether you are building it, testing it, solving it another way, or declining it. Feedback systems are more useful when customer input remains connected to the eventual decision rather than disappearing into a backlog.

The best customer request is not necessarily the most urgent request, the most expensive customer request, or the request made most often.

The strongest product signal is a repeated, important problem among customers you want more of, with a solution that strengthens the business instead of creating a permanent exception.

That is the difference between customer-led learning and customer-controlled product strategy.

This article synthesizes current product-feedback and roadmap guidance from Atlassian, Intercom and Amazon Business. Public discussions were used only as question discovery; the article does not treat social anecdotes as evidence. The decision scorecard is an SOE editorial synthesis rather than a published industry standard.

Explore related questions around customer fit, offer design, growth channels and repeatable sales before turning an individual request into a product commitment.

Related reading: \2 · \2