When Is a Feature Request Actually a Positioning Problem?
When the same request keeps arriving from people who were never going to buy, the roadmap is not behind. The positioning is off, and building the feature makes it worse.
On This Page
The same request has arrived four times this quarter, from four different accounts, and every one of them was a company you had to talk yourself into. The request is reasonable. It is well argued. Building it would take most of a quarter. And the customers who renew without a conversation, the ones you would clone if you could, have never once asked for it.
That is not a roadmap signal. That is a positioning signal, and telling the two apart decides whether the next quarter moves you forward or sideways. Feature requests and positioning are tangled together in a way most backlogs are not built to show: the ticket records what was asked for, and almost never records who asked, what they were trying to do, or whether they were ever the buyer you set out to serve.
This piece is a triage. It separates a genuine product gap from a market mismatch, using evidence you already hold, and then says what changes once you accept the answer, because the accepting is where most teams stop. It applies whether you are running an established product or preparing a product launch and reading the first requests you have ever received.
The request that will not go away
Repetition is what makes people move. Four requests for the same capability feels like evidence, and it is evidence, just not of the thing teams assume. Repetition tells you a population exists who want this. It does not tell you that the population is yours.
So ask a different question. Not how many people asked, but which people asked, and what happened to them afterwards. Requests are usually counted and almost never segmented, which is odd, because segmenting them takes an afternoon and counting them takes a dashboard nobody trusts.
The pattern worth learning to see is a request that clusters entirely outside your best-fit accounts. Not thinly spread, not mixed. Clustered. Every instance came from a trial that never converted, a deal that closed after a long argument about price, or an enquiry from an industry you do not recognise. That shape is not a gap in your product. It is a description of a different product, being requested by people who arrived at yours by mistake.
A gap and a mismatch arrive in the same ticket
A gap is a missing capability inside a job you already claim to do. A mismatch is a request for a job you do not do, from somebody who thought you did. Both are filed as "customer wants X", both are argued for sincerely, and they demand opposite responses. Build the gap and the product gets deeper. Build the mismatch and the product gets wider, which sounds similar and is not.
Here is the part that makes them hard to tell apart, and it is uncomfortable: a mismatch is usually more articulate. Somebody from an adjacent market has a clear picture of the product they want, because they have already used two of them elsewhere. Your actual best-fit customer often cannot describe what they need, because if they could describe it they would have found it. Fluency in a feature request correlates with the requester coming from somewhere else, and teams reward fluency because it makes the ticket easy to write.
A triage for feature requests and positioning
Run every repeated request through these five questions, in order. The first two do most of the work, and it is worth resisting the urge to jump to the fifth because it feels the most decisive.
- Who asked, and did they buy? Segment by account rather than by count. Ten requests from trials that never converted and ten from customers renewing next month are different data wearing the same shape.
- What job were they doing? Not the feature, the job. If the job is one you already claim on your own pricing page, this is a gap. If it belongs to a neighbouring category, it is a mismatch, however sensible it sounds.
- What did they compare you to? The alternatives named in the conversation tell you which market the requester filed you under. If that is not the market you meant, the request is about that, not about the feature.
- What happens if you say no? Do they stay and work around it, or do they leave? A request that has no effect on renewal is a preference. Preferences are worth knowing and are not roadmap inputs.
- Would your best customer notice? Describe the proposed feature to the accounts you would clone. Polite indifference from that group is the loudest answer in this list, and the one most often explained away.
Reading the same request two ways
Set the two readings side by side and the tells separate quickly. Most teams already hold every column of this table in a CRM and a support inbox, unjoined.
| Signal | Reads as a product gap | Reads as a positioning mismatch |
|---|---|---|
| Who is asking | Customers who renew without a fight | Trials, churned accounts, unqualified demos |
| How they describe it | In the language of their own job | In the language of another product category |
| Comparison set | Competitors you already name | Tools you do not consider competitors at all |
| Effect of a no | A workaround, mild irritation, they stay | They leave, or they never start |
| Best-fit reaction | Recognition, sometimes relief | Polite indifference |
| Where it arrived | Support, onboarding, usage data | Sales calls and cold enquiries |
| What building it does | Deepens the job you already do | Adds a second job with its own upkeep |
The bottom row is the one that costs money later. Every accepted mismatch adds a second job to the product, and a second job carries its own support surface, its own documentation, its own edge cases and its own reasons to break at three in the morning. That is the calculation set out in product, service, or feature, and our parent company has written about the ongoing side of it in the standing cost of a product. Run that calculation before the quarter is committed, not during the retrospective.
Volume is not the only distortion. One large account asking loudly outweighs twenty quiet ones in every meeting, and building for them is sometimes the correct commercial decision. Just name it as one: a choice about a single relationship, priced accordingly, rather than evidence about a market. Write it in the roadmap that way so the next planning cycle inherits the reasoning instead of the conclusion.
The demo that went well and should not have
Mismatches are manufactured upstream. They are made in marketing and sales, and they arrive in the backlog weeks later wearing the clothes of customer research. A demo that goes well with a prospect who was never a fit produces two things: a deal that will churn, and a list of requirements from a market you did not choose to enter.
The website is doing the qualifying whether you meant it to or not
If the pages describing your product are written broadly enough to attract everybody, they will, and then the qualification work moves to a person on a call and finally into your backlog. Writing for a narrower reader is not smaller marketing. It is the cheapest filter you own, and it works while everybody sleeps. That is the argument in what a SaaS website needs before the product is ready, and it is worth applying to the home page and the pricing page before it is applied to anything clever.
Churn says the same thing, later and more expensively
A mismatch that gets past the site and past sales reappears at renewal, and by then it has cost a year of support and a reference you will not get. Accounts that sign up and never reach the thing the product is good at are usually the same accounts that were asking for a different product all along, which is the connection drawn in why users sign up and never come back. The feature request was the early warning, and it was filed as a wish.
Positioning is the list of things you will not build
Positioning is usually discussed as a sentence: who it is for, what it does, why it is different. The sentence is the output. The input is a list of refusals, and a team that cannot name what it will not build does not have positioning, it has an aspiration. The list should be written, dated, and short enough that people remember it without opening the document.
- A fast answer in the room. "We do not do that" is only credible when it was written down before the meeting rather than improvised inside it.
- A roadmap you can defend. The refusals explain the sequence, and the sequence is what a board or a serious customer actually wants to understand.
- A cleaner brief for everyone else. Sales stops chasing the accounts that generate the mismatch. Support stops promising a date that nobody set.
- A record you can reverse honestly. A non-goal carrying a date and a reason can be revisited when the reason expires, which is a different act from quietly changing your mind.
A roadmap is a claim about who the product is for. Every feature accepted from outside that group edits the claim, whether or not anybody meant to make an edit.
What changes once you accept the answer
Deciding that a request is a mismatch is not a filing decision. If nothing changes except a ticket status, the same request returns next quarter under a different name, argued by somebody new, and the discussion starts from zero because no one recorded the reasoning.
The roadmap gets shorter and deeper
The immediate effect is subtraction. Items justified by mismatched demand come off, which frees more capacity than most teams expect, because those items were usually the large ones. What replaces them is depth in the job you already do: the second and third steps of a workflow your best customers complete somewhere else, in a spreadsheet, quietly, without ever filing a request about it. That work rarely arrives as a feature request at all, which is why strategy and analytics work tends to find it before the backlog does.
The pages that describe the product change too
Positioning that lives only in a slide deck is not positioning. It has to reach the pricing page, the onboarding email, the documentation and the sales script in the same week, or the old version carries on selling to the wrong people and generating the requests you just decided to refuse. That is a publishing problem as much as a strategy one. A workspace such as Acrosite takes the approach of generating the files, committing them and letting the deployment run, which is what makes a same-week change realistic rather than aspirational. Documentation carries more of this weight than teams expect, because it is what a serious evaluator reads before they ever speak to you, a case we have made in documentation as a growth channel.
The language changes as well, and this is the part that gets deferred because it feels cosmetic. It is not. The words on the page decide which search queries the product is found for, which comparison set a buyer files you under, and which requests arrive next quarter. Narrowing the messaging and verbal identity is how the filter actually gets built.
Start with the request you have argued about most
Take one request, the one that has come up in three planning meetings and been deferred in all of them. Pull every instance of it out of the backlog and attach four fields to each: the account, the segment, the renewal status, and what they compared you to. Most of the time the answer is visible within an hour, and it was visible all along, sitting in a count.
The honest limitation is that this triage is unreliable early. Before you have a base of renewing customers, there is no best-fit group to compare against, and every requester is a stranger. In that phase positioning is a hypothesis and requests are the cheapest way to test it, so build the thing that teaches you fastest and revisit the triage once retention gives you a reference class to measure against. Applying this framework to your first twenty customers will mostly produce false confidence.
And the condition under which the advice reverses: deliberate expansion. If you have decided to enter the adjacent market, the mismatch stops being noise and becomes your first requirement list, gathered for free by people who told you exactly what they need. The mistake is drifting there one accepted request at a time and calling the drift a roadmap. That decision belongs in strategy and positioning work, made once and out loud. If you want a second read on which requests you are actually receiving, tell us what keeps coming back and who has been asking for it.
Common questions.
How do you know if a feature request is worth building?
Look at who asked before you look at how many asked. Requests from customers who renew, describing a job you already claim to do, are product gaps worth building. Requests clustered among trials that never converted, churned accounts or unqualified enquiries usually describe a different product. Also ask what happens if you refuse: if nobody leaves, it is a preference rather than a requirement.
What is the difference between a product gap and a positioning mismatch?
A gap is a missing capability inside a job your product already claims to do, so building it makes the product deeper. A mismatch is a request for a different job from somebody who thought you did it, so building it makes the product wider and adds a second support surface, documentation set and failure mode. They arrive as identical tickets and demand opposite responses.
Should you build a feature just because a big customer asked for it?
Sometimes, but call it what it is. Building for one large account is a commercial decision about a single relationship, not evidence about the market, and it should be priced and recorded that way. The danger is that it enters the roadmap as validated demand, and the next planning cycle inherits the conclusion without the reasoning that produced it.
Why do the wrong customers keep asking for features?
Usually because something upstream is attracting them. Broad marketing copy, a home page written to appeal to everyone, or a demo process with no disqualifying questions will bring in buyers from adjacent markets who assume you do a job you do not do. Their requests are a description of that other job, and the fix is narrowing the pages rather than extending the product.
How do you say no to a feature request without losing the customer?
Answer with the job rather than the feature. Explain what the product is designed to do, why the request sits outside it, and what you would suggest instead, including another tool if one fits better. Customers accept a clear boundary far more readily than a vague maybe, and a written non-goal list makes the answer consistent across everyone who has to give it.
What should change on your website after a positioning decision?
The pricing page, the home page, onboarding emails, documentation and the sales script, all in the same week. Positioning that only exists in a strategy deck keeps losing to the older wording still published, which continues attracting the buyers you decided not to serve. Treat the update as a publishing task with an owner and a date, not as a follow-up item.
Facing this in your
own business?
Tell us where you’re headed — we’ll map the shortest honest route.