Here is a pattern I see in nearly every company between its first big customer and its tenth. You land a marquee account. They are paying real money, maybe a quarter of your revenue. They have requests. The requests are reasonable, they come from a paying customer, and the path of least resistance is to build them. So you do.
Six months later you look at your roadmap and realize most of it is their roadmap. Every sprint has a feature only they asked for. Your engineers can recite that customer's org chart. And the next prospect in your pipeline keeps asking for things your product does not do, because you spent the quarter building for one account instead.
This is one of the most expensive traps in early-stage product, and it does not feel like a mistake while you are in it. It feels like good customer service.
Why this happens to careful founders
It is not laziness or weak product sense. It is a set of incentives that all point the same direction.
The revenue is concrete and the cost is hidden
The big customer's money is in the bank. The features you are not building for everyone else are invisible: prospects who quietly went elsewhere, churned trials who never told you why. You are trading a measurable gain for an unmeasured loss, and humans are bad at that trade. Industry surveys consistently show that close to half of product decisions are credited to customer feedback, but they rarely ask whose feedback, or how many customers it represented.
One loud account drowns out a hundred quiet ones
The customer in your inbox every week is vivid. The hundred users who would benefit from a different feature are an abstraction. Vividness wins backlog fights it should lose.
Saying no to a big account feels like risking the relationship
It does not have to. But in the moment, "we'll build that" is easier than the conversation about whether it belongs in the product at all.
How to tell a signal from a single-account demand
Not every request from a big customer is a trap. Some of them are the best product intelligence you will ever get. The skill is telling them apart.
Ask how many other customers have this problem
Salesforce runs a version of this at scale: if one enterprise customer hits a problem, they assume others have it too, and they build for the pattern. That logic only works if you actually check. When a request comes in, the first question is not "can we build it" but "who else needs this." If the honest answer is "nobody has asked," you are looking at a custom build, not a product feature.
Separate the problem from the solution
Big customers often arrive with a solution already designed: build this specific screen, add this exact field. Underneath is usually a real problem that several customers share, with a more general solution you could ship once and sell many times. Your job is to dig past their spec to the need. The need might be roadmap-worthy even when their exact feature is not.
Watch the shape of your backlog
The clearest tell is structural. Open your last two months of shipped work and tag each item by who asked for it. If one account's name is on more than a third of it, the roadmap has already tipped, whatever you intended. This is the same kind of pattern-in-the-data read I do when I look at where a team's time actually goes versus where they think it goes.
What to do when you are already in it
Most founders do not catch this until they are a few quarters deep. That is recoverable.
Price the custom work as custom work
If a feature genuinely only serves one account, it can still be worth building, but it should be paid for as bespoke development or professional services, not absorbed into the product roadmap for free. Charging for it forces the honest question of whether they value it enough to fund it.
Build a real intake that ranks by reach
Replace "whoever emails loudest" with a lightweight system that scores requests by how many customers they touch and how much they move your core metric. It does not need to be a tool. A shared list with two columns and a weekly decision is enough. The point is to make the trade-off visible instead of letting the loudest voice win by default.
Decide what your product is, and let that be the filter
A roadmap is a series of hard noes in service of a few yeses. If you cannot say what your product is for, every request looks equally valid and the biggest customer wins by default. This is strategy work, and it is one of the things a fractional technical leader earns their keep on: being the person who can tell a founder which requests to decline and why.
FAQ
Is it ever right to build a feature for just one customer?
Yes, when the contract justifies it and you price it as bespoke work, or when that one customer is a true design partner whose problem you are confident generalizes. The danger is doing it by default, for free, without checking whether anyone else needs it.
How much of my roadmap is too much for one account?
A rough rule: if a single customer is driving more than a third of your shipped work and they are not paying separately for it, you have a problem. Above half, you are a custom dev shop with one client, whatever your pitch deck says.
My biggest customer is threatening to churn unless I build their feature. Now what?
Then it is a commercial negotiation, not a roadmap decision. Decide what that account is worth, what the feature costs to build and maintain, and whether keeping them on those terms is good business. Sometimes the right answer is to let a demanding account go rather than let it own your product. If you want a second opinion before that call, book a call.