How many customers need to ask before you build it?

There is no number, and looking for one is the mistake. What determines whether feedback justifies building is the strength of the evidence, not the count: whether the accounts are independent, whether they described a problem or proposed a solution, whether they acted or merely said, and what it costs you to be wrong. Five weak signals justify less than one strong one.

Everyone wants a threshold. Three requests, ten requests, five percent of your base. It would make the decision mechanical, and the appeal is obvious when you are staring at a list of things people have asked for and trying to work out which ones are real.

Every guide that answers this hedges into "it depends," which is true and useless. The more honest version is that the question has the wrong shape. Counting treats every request as one unit of evidence, and requests are wildly unequal as evidence. Once you see that, the question changes from how many to how good, and that one has real answers.

Why doesn't a number work?

Because a count measures how many people spoke, which is a poor proxy for how many people are affected or how much it matters.

Three problems make the count unreliable, and they compound. The customers who tell you things are not a random sample of your customers, they are the engaged and articulate ones. The same problem described in different words splits into several small counts that each look insignificant. And a count treats a passing mention from a trial user identically to a blocking issue raised by an account approaching renewal.

There is also a deeper issue, which research on startup validation has started to make explicit. Work examining how early-stage software companies validate ideas before building has found that prior studies mostly measured validation by volume of activity rather than by the strength of the evidence produced, and set out to test whether evidence type matters more than quantity. That framing, evidence strength over evidence volume, is exactly the shift this question needs. The study looks at validating a product idea rather than a single feature, so the transfer is by analogy rather than direct finding, but the principle holds at both scales: what you learned matters more than how much you collected.

What makes feedback strong evidence?

Five properties. The more of them a piece of feedback has, the less of it you need.

Independence. Five accounts who have never spoken to each other raising the same problem is strong. Five mentions from one account is one piece of evidence repeated. A request that spread through your user community, where people are upvoting something they saw someone else post, sits somewhere in between and is weaker than it looks.

Unprompted. Something a customer raised spontaneously, while trying to do their job, is stronger than something they agreed to when you asked "would you find X useful?" People say yes to hypothetical features readily and reliably. The strongest evidence arrives without you asking for it.

Behavioural, not just stated. What someone does beats what someone says. A customer who built a workaround, exports to a spreadsheet every Monday, pays for a second tool to cover the gap, or has a person on staff doing it manually has demonstrated the problem costs them real money. That is worth far more than an enthusiastic "that would be great." This is also why interviews need care: people describe their behaviour inaccurately and predict their future behaviour worse. See how to run customer interviews that actually uncover insights for getting at behaviour rather than opinion.

Problem-anchored, not solution-anchored. "I spend forty minutes every Monday updating records one at a time" is strong evidence. "Add bulk edit" is weaker, because the customer has already converted their problem into a solution and thrown away the detail you need. The distinction and why it matters is covered in the difference between feedback, a feature request, and a pattern.

Account weight. Who is affected, what they pay, and whether they are near renewal. In B2B this is not a tiebreaker, it is often the dominant factor, and it is the one raw counts erase entirely. How to combine it with the others is covered in how to prioritize feature requests without just counting votes.

So when is one customer enough?

More often than the counting instinct suggests, in three specific situations.

When the account is large enough that the revenue alone justifies it, one is enough. This is not caving to a big customer, it is the account weighting working correctly.

When the evidence is behavioural and severe, one can be enough. A customer who has a person on staff doing manually what your product should do has given you stronger evidence than twenty people clicking upvote.

When the cost of building is trivially low, one is enough, which brings us to the factor most discussions of this question leave out.

How much evidence you need depends on what it costs to be wrong

This is the part that actually resolves the question, and it is why a fixed threshold can never work.

The evidence bar should scale with the cost of the mistake. A two-hour change that is easy to reverse needs almost no evidence, because if you are wrong you lose an afternoon. A six-month platform commitment that will shape your architecture needs a great deal, because being wrong costs half a year and a rewrite. Applying the same threshold to both is how teams simultaneously over-research small things and under-research large ones.

Three dimensions set the bar: how long it takes to build, how hard it is to reverse, and how much it constrains what you can do next. A feature that is quick, removable, and independent of everything else is cheap to be wrong about. One that is slow, embedded, and constrains your roadmap is expensive.

This is also why the question has become more pressing recently rather than less. As the cost of building has fallen, the cost of building the wrong thing has not, so the balance between the two has shifted and the right threshold has moved for cheap work while staying put for expensive work. That shift is the subject of should the roadmap be an input or an output.

The practical version of this, which venture investors put well when discussing validation, is to start from the question you need answered and then choose the cheapest test that can answer it. Sometimes the cheapest test is building the thing. If a change takes two hours, building it is a faster way to learn than a week of research, and the research was never the responsible option, it was the procrastinating one.

What should you do when the evidence is weak but the request is loud?

Investigate rather than build or decline.

The weak-evidence case is not a decision, it is an unanswered question, and the right response is the cheap test that would answer it. Talk to two or three of the accounts involved and find out what they were actually trying to do. Check whether the problem appears elsewhere in your feedback described differently. Look for the behavioural tell: are they working around it, and how much does that cost them?

That investigation usually resolves the question in either direction quickly, and it is far cheaper than either building on thin evidence or declining something that turns out to be real. How the resulting evidence becomes an actual decision is covered in how customer feedback becomes a product decision.

Weak evidence vs. strong evidence, compared

When this doesn't apply

If you are pre-product-market-fit, this framework can mislead you. Your current customers may not be the customers you want, and weighting their evidence heavily can pull you deeper into the wrong segment. Early on, a weak signal from the right kind of customer can be worth more than strong evidence from the wrong kind.

If you are building something genuinely new, feedback will underdetermine the decision no matter how you weigh it. Customers describe problems inside the frame they already understand. Evidence strength is a good guide for improving what exists and a poor guide for inventing what does not.

And none of this removes judgment. A strong body of evidence tells you a problem is real and worth solving. It does not tell you that you are the one who should solve it, or that solving it fits where you are going. Strategy still has a veto that no amount of evidence overrides.

Frequently asked questions

1. Is there really no number at all? Not one that transfers between contexts, because the right threshold depends on your total customer count, your revenue concentration, and what the build costs. A useful substitute: ask whether you could defend the decision by describing the evidence out loud. "Four independent enterprise accounts, two with workarounds in place" is defensible. "Eleven upvotes" is not.

2. What if lots of customers ask but the evidence is all weak? Volume of weak evidence stays weak, but it is a good reason to go looking for strong evidence. A widely requested feature with no behavioural backing is a prompt to talk to a few of those customers and find out what they are actually trying to do. Often the real problem turns out to be adjacent to what they asked for.

3. Does an upvote count as evidence? Weakly. An upvote is prompted, low-cost, and solution-anchored, three of the properties that make evidence weak. It tells you someone recognised a description and agreed with it. It does not tell you the problem costs them anything. Treat upvotes as a signal to investigate rather than a count to act on.

4. How do I weigh one enterprise account against many small ones? By revenue and risk rather than headcount, in most B2B cases. One account representing a large share of revenue legitimately outweighs many small ones, and that is the weighting working rather than a failure of fairness. The exception is when the small accounts represent the segment you are trying to grow into.

5. Should the threshold be different for bugs? Yes, and usually lower. A bug is evidence that something is broken rather than a hypothesis about what customers want, so a single credible report can justify a fix. The counting question belongs to feature decisions, where you are inferring demand, not to defects, where you are confirming a fault.

Lane is built for evidence rather than counts: it groups feedback into problems, keeps the account and revenue attached to each one, and preserves the customer's own words, so you can judge how strong the evidence is instead of how tall the pile is.