Your biggest customer just asked for a feature. Your instinct says build it. That instinct is wrong more often than founders admit.
The mistake isn't listening to customers. It's weighting every request the same way: whoever asked most recently, most loudly, or writes the biggest check gets the roadmap slot. That's not prioritization. It's whoever complained last.
The squeaky wheel problem is a math problem
A customer paying you $80,000 a year who threatens to leave in 90 days is not the same signal as a customer paying you $80,000 a year on a locked three-year contract. Same revenue, completely different urgency. Most founders score both the same because both come from "our biggest customer."
The fix is a churn-risk multiplier. A renewal inside 90 days with an active escalation gets weighted 2 to 3x its base revenue. A locked multi-year account gets 0.8 to 1x, because they aren't going anywhere regardless of what you build next. This single adjustment stops your roadmap from being hijacked by whoever is loudest this month.
Why "our biggest customer wants it" is the wrong justification
Single-customer requests get built for one bad reason: they feel like a decision has already been made for you. A $150K account emails your CEO directly, and suddenly a two-week feature becomes urgent even though nine other customers never asked for it.
Filter for frequency before you filter for size. If fewer than three separate customers have asked for something, or it hasn't come up in at least ten total requests, it doesn't go on the roadmap automatically. It goes into a strategic review instead, where you ask whether this is genuinely where the market is heading or whether one account is trying to turn your product into their internal tool.
This also kills a second problem: customer success teams labeling every enterprise ask "critical for renewal" to jump the queue. If "critical" isn't reserved for accounts with a documented renewal date inside 90 days, an executive escalation, or a named competitive threat, the word stops meaning anything within a quarter.
The weighting framework
Score every feature request on three inputs instead of one:
- Revenue at risk: the account's ARR, multiplied by a churn-risk factor (0.8x for locked or safe accounts, up to 3x for accounts with an active escalation or a renewal inside 90 days)
- Expansion signal: does building this unlock upsell or a larger contract with this account, or accounts like it, not just retention
- Request frequency: how many distinct paying accounts have asked for the same thing, independent of who asked first or loudest
A useful starting split for early-stage B2B SaaS: weight churn-risk reduction and expansion revenue roughly evenly, and let raw adoption frequency make up the rest. That keeps you from either only firefighting renewals or only chasing whichever feature has the most upvotes on your feedback board, which tends to reward vocal free-tier users over the accounts actually paying you.
A worked example
Two requests land in the same week.
Account A pays $100,000 a year, renews in 60 days, and has emailed twice about switching to a competitor. Only that one account has asked for the feature. Run the math: $100K times a 2.5x churn-risk multiplier is a $250,000 weighted score, but it fails the frequency filter, since only one account is asking. That sends it to a strategic review instead of an automatic build.
Account B also pays $100,000 a year, is locked into a contract for two more years, and isn't at risk of leaving. But six separate accounts have asked for the same feature, unprompted. The revenue-weighted score is lower (0.9x, since there's no urgency), but the frequency signal is high. That one clears the bar to build.
Account A looks more urgent on paper. Revenue and risk are both real. But it fails the frequency filter, so it goes to a strategic conversation, not straight into the sprint. Account B has less dramatic urgency but a much stronger signal that this is a product direction, not a favor for one account. Most teams build for A because someone is upset right now. The frequency-weighted score points at B, and B is usually the better six-month bet.
What to do this week
Pull your last 20 feature requests into a spreadsheet with four columns: account, ARR, days to renewal, and how many other accounts asked for the same thing. Score each one with the churn multiplier above. You'll likely find at least one request currently at the top of your roadmap that only clears the bar because it came from whoever emailed most recently, not because the data supports it.
Frequently asked questions
Should I ever build a feature for just one customer?
Sometimes, but treat it as a strategic bet, not a default. Only do it when the account's revenue and risk are large enough on their own to justify the engineering cost, and say so explicitly rather than pretending it's a broader roadmap priority.
What if my biggest customer threatens to leave over a feature?
That's a real signal and belongs in the churn-risk multiplier. The problem isn't accounting for it, it's treating every large account's ask as equally urgent regardless of whether they're actually at risk of leaving.
How many customer requests count as a real pattern?
Three separate accounts is a reasonable floor for early-stage SaaS. Below that, you're building for an individual, not the market, even if the request sounds reasonable.
Does this framework replace talking to customers?
No. It changes what you do with what you hear. Keep having the conversations. Stop letting whoever spoke last set the roadmap by default.