How to stop a single loud customer from skewing your roadmap
Before a request becomes a roadmap commitment, check two numbers that have nothing to do with how loud it arrived: how many separate accounts have independently asked for the same underlying thing, and whether the size of one account, not its breadth, is what's making the case. A customer who sends fifteen messages about the same feature is one account, no matter how the volume feels from inside the inbox. A five-person company and a two-thousand-person company hitting the same wall in the same month, without ever talking to each other, are two accounts, and worth acting on even if neither one ever escalates.
Most roadmaps don't get skewed by bad judgment. They get skewed by an input that was never counted correctly in the first place: message volume and account revenue both look like demand, and neither one is the same thing as breadth. A team that tracks how many times a request was mentioned, or how big the account behind it is, will reliably overweight the customer who talks the most or pays the most, whether or not their problem is shared by anyone else. The fix is to separate the count that matters (distinct accounts) from the two that don't (message frequency and account size), and to decide the threshold before the first persuasive request shows up.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionWhy one account feels like more than one account
A single vocal customer generates a pattern that looks a lot like demand from the outside: repeated mentions, escalating tone, a champion who cc's a VP, maybe a renewal date that gets mentioned more than once. None of that is fabricated, and none of it means a second account wants the same thing. It means one account wants it badly.
The confusion happens because urgency and breadth get read off the same signal: how often something comes up. A request that surfaces fifteen times from one company and a request that surfaces fifteen times from fifteen companies produce an identical-looking count in a spreadsheet column labeled "mentions," and only one of them tells you anything about your broader customer base. If your tracking doesn't separate "how many times was this said" from "how many accounts said it," the loudest account wins by default, every time.
The Fernsby thread that almost became Q1's top priority
Fernsby Robotics was a mid-market logistics customer paying close to the top of the pricing tier, and its operations lead, Corinne Ekwall, was active daily in the shared Slack Connect channel. Over three weeks in October, Corinne asked for a specific feature five separate times, in five different phrasings:
Corinne Ekwall, Fernsby Robotics: Any update on letting us set custom approval chains per warehouse? We talked about this on the QBR call too.
Corinne Ekwall, three days later: Following up, this is becoming a blocker for our Q1 rollout to the second site.
Corinne Ekwall, the following week: Wanted to flag again that the per-warehouse approval thing is still open. Happy to hop on a call if it helps prioritize.
By the third message, two people on the product team had independently proposed adding it to the next sprint. It read like sustained, escalating demand, and Fernsby's contract size made the case feel stronger. When the team pulled every other mention of approval-chain customization from the last two quarters, from support tickets, other Slack channels, and the sales call notes, it found nothing else: no other account had ever raised it. One account was highly motivated and persistent. The underlying request had a total addressable count of one.
Fernsby's request didn't get built next sprint. An n=1 request with a $140k account behind it is a negotiation, not a roadmap signal, so it got logged as a scoped, paid custom capability discussion instead.
Set the account-count threshold before the first hard case
The reason this decision is hard in the moment is that nobody agreed on the rule in advance, so it gets litigated fresh every time a persistent customer applies pressure. Fix that by deciding, in a calm week, what counts as evidence:
- One account, however loud: treat it as a custom-build or workaround conversation, not a backlog item. Say so directly, the way you would with any other request you're declining.
- Two independent accounts, unprompted: log it as a real theme worth tracking, not yet worth building.
- Three or more independent accounts within a rolling quarter: it's a legitimate roadmap candidate, and now the actual prioritization work can start, with revenue and urgency as inputs to that process rather than reasons to skip it.
The number two or three isn't a universal constant, pick what fits your customer base size, but the discipline is universal: write the threshold down somewhere the whole team can see it before the next Corinne shows up, so the answer to "should we build this" doesn't depend on who's arguing hardest that week.
Let revenue break ties, not make the case
None of this means big accounts don't matter. A $140k account is worth more attention than a $2k one, and if Fernsby's request had come from three of your five biggest accounts at once, that's a legitimate signal to move faster, not slower. The mistake is letting account size substitute for account count instead of sitting beside it.
Steve Blank told a version of this failure in his write-up of a founder he calls Satish, who ran a rigorous customer development process, built almost everything his prospective customers asked for, and priced the product the way they requested, only to watch nobody convert from free to paid (Steve Blank, "Killing Your Startup By Listening to Customers"). Blank's point wasn't that Satish talked to the wrong people. It's that he let responsiveness to whoever he was talking to replace a decision about which segment the business was built for: "Your job is not to make every possible customer happy. Pick the customer segments and pricing tactics that drive your business model." The same failure shows up at request-triage scale: a large account's preferences are real information, but they're not a substitute for checking whether the rest of your customer base needs the same thing.
Where a spreadsheet stops catching this
A spreadsheet with columns for requester, company, and mention count works as long as someone is disciplined about filling it in every time, and as long as volume stays low enough that one person can hold the whole picture in their head. It starts missing the pattern in two predictable ways: requests that arrive in different words in different channels don't get recognized as the same underlying ask, so "custom approval chains," "per-site sign-off rules," and "warehouse-level approvals" sit in three separate rows instead of one counted topic, and account context, which accounts, what they're worth, whether any are near renewal, has to be looked up by hand in the CRM every time someone wants to check whether a request is broad or just persistent.
That second gap is where teams end up either skipping the check, and repeating the Fernsby mistake, or spending twenty minutes in Salesforce every time a loud request shows up. We build Modem, and this is the exact seam it's built for: it reads requests as they arrive across Slack, support tickets, and sales calls, collapses differently worded versions of the same ask into one topic, and syncs the Salesforce integration so each topic shows the accounts and opportunities attached to it, not just a raw mention count. The product's own framing for this: "Topics rank by how often and by whom they are raised, so the list of what to build next reflects demand, not the loudest thread." Because that account and deal context lives in a context graph connecting each request to the people and companies behind it, the account count in the Fernsby example is a query, not a research project. We're the vendor here, so weigh that against the fact that below a few dozen requests a month, the manual version above is genuinely enough.
The smallest version to start this week
Pull the last quarter of requests for whatever feature is currently getting the most pressure from a single account, and count accounts, not mentions. If it's one account, write down the threshold you'll use going forward (two independent accounts to log it, three to build it) and share it with whoever else takes these calls. The next time a Corinne shows up with a strong case and a big contract, the team won't have to decide the rule and the request at the same time.
