Every Single Feature Request Is One Data Point Until You Prove It Otherwise: How Product Teams Test Market Signals Before They Reach The Roadmap
Product teams should treat every feature request as a single data point until the request converges across genuinely independent sources, counted by originating account rather than by the number of channels it appears in.
Product teams rarely have a shortage of market input. The challenge is that they cannot tell which input represents a market pattern and which represents one persistent voice. The fix is a filter applied before prioritization that tests whether sources are actually independent.
This post explains how product teams can filter feature requests before roadmap prioritization using a two-axis roadmap filter. Axis one is a convergence test that checks source independence and problem convergence. Axis two uses market intelligence (MI) to track market changes that no customer has raised.
Who this is for: Product leaders, product managers, and product marketers who decide what goes on a roadmap and need a defensible way to decline a loud feature request.
Key Takeaways
Most product teams have more market input than they can sort through. Adding more product discovery to a team without a filter produces a longer backlog, not better roadmap decisions.
A feature request is a legitimate market signal only when it converges across genuinely independent sources. Sales call notes, support tickets, and customer success reviews can all trace back to a single account, which can look like convergence but is not.
Customers report solutions, not problems. Five accounts asking for the same feature can have five different underlying problems, and building the requested feature could leave most of those problems unsolved.
The convergence test only detects needs customers already know to ask for. Regulatory shifts, competitive repositioning, and substitution threats never arrive as feature requests, so the two-axis roadmap filter adds a second axis for market changes that no customer has raised.
Building a feature for one large customer is a legitimate commercial decision when you label and measure it as a commercial decision rather than presenting it as market evidence.
The two-axis roadmap filter belongs between intake and prioritization. Applied after a build is underway, the filter becomes a justification exercise.
Key Terms Used In This Post
Feature request: a customer's proposed solution to a problem, recorded in any channel such as sales call notes, support tickets, customer success reviews, or user interviews.
Independent source: a distinct originating account and conversation. Multiple mentions that trace back to the same account count as one independent source.
Convergence test: a check on whether a feature request appears across multiple independent sources.
Problem convergence: agreement across sources on the underlying problem customers are trying to solve, as distinct from agreement on the feature they requested.
Two-axis roadmap filter: a checkpoint between intake and prioritization that combines the convergence test (axis one) with market intelligence on external changes no customer has raised (axis two).
Product Teams Are Drowning In Market Input
Product teams are often told their problem is that they are not listening to the market. In CTRS's experience, not listening is rarely the problem. Between customer interviews, support tickets, sales escalations, usage analytics, qualitative data, competitor teardowns, and whatever the CEO heard at a conference, most product teams have more market input than they can process.
Most product teams lack a way to rank market input. Without a deliberate ranking method, ranking happens by default, and the default value is volume and proximity. The feature request that gets built is the one attached to the most persistent voice, the largest logo, or the most senior person in the building. None of those factors correlate reliably with what the market wants at scale.
Put another way: more product discovery does not fix a ranking problem. Adding market input to a team that cannot sort the input it already has produces a longer backlog and the same decision quality.
Convergence Is The Right Test, Supported By Source Independence
For many organizations, they look to validate a feature request by looking for convergence: the same request appearing across multiple channels. Organizations following that advice look for a request that shows up in three places and treat it as real.
While the convergence test is directionally correct, it fails in a specific way that trips up well-run product teams. The standard convergence test counts channels, when what matters is independent sources.
Illustrative example: six touchpoints that trace back to one account.
The following example is illustrative. It describes a common pattern, not a specific client engagement.
Consider an integration request that appears in three sales call notes, two support tickets, and one customer success account review. That's six touchpoints across three channels, and every standard convergence test passes.
Tracing each touchpoint to its origin changes the count. Four of the six touchpoints trace back to a single account. The fifth came from a prospect that same account referred. The sixth came from a sales rep who heard the account discussing the integration and asked another customer whether they wanted it too. All six touchpoints originate with one account, so the integration request is one data point. The organization mistook its own internal echo for a market pattern.
How to check source independence
Channel diversity is easy to measure and easy to fake. Source independence determines whether a feature request actually reflects a market pattern. Before a feature request clears the convergence test, trace each instance back to the originating account and the originating conversation. If the count collapses when traced, the feature request spread is really one data point.
Evidence thresholds for committing build time
Product teams can also fail by being too strict. Teams that dismiss every early market signal as noise until it appears in a statistically comfortable number of places will always arrive at the market late, because early market signals are easy to miss. Convergence is a threshold for committing build time, not a threshold for paying attention.
Product teams should set evidence thresholds in advance so they don't negotiate them case by case. A workable default:
One independent source: log the feature request and watch for recurrence. A single source earns attention, not build time.
Two independent sources: investigate, starting with the problem each source was trying to solve.
Three or more independent sources, with the underlying problems converging: commit build time.
Customers Report Solutions, Not Problems
A feature request is a customer's own solution to a problem they've already diagnosed, usually shaped by what they think the product can do. Five accounts asking for the same feature feels like a clear market signal.
Asking what each of five requesting accounts was trying to accomplish can surface five different jobs. One account wants to reduce manual data entry. Another is trying to satisfy an auditor. A third is working around a permissions model that does not match how its team is organized. Building the requested feature solves at most one or two of the five underlying problems, and adoption reflects that.
Checking problem convergence doesn't require new research, but it may require collecting more information on feature requests and trouble tickets. For every instance in a convergence count, write down the problem the customer was solving, not the feature the customer asked for. If the problems converge, the feature request represents a market pattern. If only the requests converge, the feature request is a coincidence of vocabulary.
Market Intelligence Shows Whether A Pattern Is Market-Wide Or Specific To Your Customers
Product discovery methods are good at depth. A user interview explains what one person experiences and why. Usage analytics show what people do inside a product. Both methods are essential, and neither can show whether a pattern is specific to one company's customer base.
Market intelligence (MI) answers the question a company's own customers cannot: whether a pattern is happening across the market or only to that company.
The distinction between a market-wide pattern and a company-specific pattern changes product decisions. A workflow complaint that appears across a company's customer base and across its competitors' customer bases is a category problem, and solving it first is a positioning advantage. The same workflow complaint appearing only in one company's own accounts is an implementation or onboarding problem, and a new feature is the expensive way to fix it.
Market intelligence works alongside product discovery, not replacing it. Product discovery generates roadmap candidates. Market intelligence shows which of those candidates are attached to something the market is actually moving toward.
The Two-Axis Roadmap Filter
The convergence test has a structural limitation: it detects only needs customers already know to ask for. A roadmap run entirely on the convergence test produces a product that responds perfectly to yesterday and is completely blind to big-picture changes in a category.
For example, nobody submits a feature request about a regulatory change coming in eighteen months. The two-axis roadmap filter addresses the convergence test's limitation by adding a second, externally focused question.
Axis one: does the feature request converge across independent customer sources?
Axis one of the two-axis roadmap filter is the convergence test, applied with source-independence and problem-convergence checks. Axis one protects build time from single-voice requests.
Axis two: what is changing in the market that no customer has raised?
Axis two of the two-axis roadmap filter uses market intelligence to track external change: regulatory direction, competitive moves, technology shifts, and changes in how buying decisions get made in the sector. Axis two is where the roadmap items that matter in three years come from.
Building For One Large Customer Is A Commercial Decision, Not Market Evidence
Product teams sometimes need to build a feature for a single large account. Renewal risk, a strategic reference, or a contract that funds the next two hires can each justify a single-account build. Building for one account is a legitimate business decision.
Single-account builds cause damage when a commercial decision gets described as market evidence. When "we are building this because our largest account will not renew without it" becomes "the market is asking for this" (or worse - “No, really! It’s a repeatable solution!”), three things break:
The product team stops looking for the real market pattern.
Success gets measured against broad adoption that was never going to happen.
The next single-account feature request arrives with a precedent behind it.
Labelling a single-account build correctly prevents all three problems. A correctly labelled single-account build is recorded as a commercial decision, measured on whether the account renews, and does not set a precedent for the roadmap.
The Two-Axis Roadmap Filter Belongs Before Prioritization
The two-axis roadmap filter belongs between intake and prioritization. Any feature already in a sprint has advocates, and applying the filter at that stage turns it into an exercise in justifying work already underway.
The standing check for every roadmap candidate
The working version of the two-axis roadmap filter is a short standing check applied to every candidate before it competes for build time:
How many independent sources support the feature request, traced back to origin?
What problem was each source trying to solve?
Does anything in the external market environment support or contradict the feature request?
What evidence would you expect to see if the pattern were real, and is any of that evidence missing?
Who should own the two-axis roadmap filter
Product marketing is usually the right owner of the two-axis roadmap filter because it already sits between market data and roadmap decisions and has no stake in a particular feature getting built. Where a dedicated market intelligence function exists, the filter belongs there. The core requirement is that the person applying the filter does not own the roadmap, because a filter applied by the person who wants a particular answer is not a filter.
Start With One Rule: Count Sources By Origin, Not By Channel
More market input is not the goal for product teams. Better sorting is.
Start with this rule: no build decision rests on a single source, no matter how loud, and count a source by originating account rather than the channel it was recorded in. Run your current top three roadmap candidates through that rule this week. If one of them collapses to a single account when traced back, you have recovered the build time that feature would have consumed, for roughly an hour of tracing.
Tracing sources to origin does not slow down legitimate opportunities. Tracing slows down the feature requests that were never opportunities, and those requests are where roadmap time actually goes.
Frequently Asked Questions
How many independent sources make a feature request a pattern?
Two genuinely independent sources are enough to investigate a feature request. Three or more independent sources, with the underlying problem converging rather than only the requested feature, are enough to commit build time. Product teams should set these thresholds in advance so they don't negotiate them case by case.
What is the difference between channel diversity and source independence?
Channel diversity counts how many channels a feature request appears in, such as sales call notes, support tickets, and customer success reviews. Source independence counts how many distinct originating accounts and conversations sit behind the request. Six touchpoints across three channels can trace back to one account, which makes them one independent source.
What should a product team do if a large customer's feature request fails the filter?
A product team can still build a large customer's feature request if the commercial case justifies it, as long as the build is recorded as a commercial decision. Measure a single-account build on retention of that account, not on adoption across the customer base.
Does the two-axis roadmap filter replace user interviews or usage analytics?
The two-axis roadmap filter does not replace user interviews or usage analytics. User interviews and usage analytics generate roadmap candidates and explain the reasons behind customer behaviour. The filter decides which candidates carry enough market weight to earn build time.
Who should own the two-axis roadmap filter?
The two-axis roadmap filter should be owned by someone without a stake in the roadmap outcome. Product marketing is the usual owner. A dedicated market intelligence function is a better owner where one exists.
How do product teams catch market signals that never appear as feature requests?
Product teams catch market signals that never appear as feature requests by monitoring the market deliberately, on a separate cadence from request intake. The monitoring should cover regulatory direction, competitor positioning, and shifts in buyers' own markets. Market intelligence monitoring has to be scheduled, because nothing in an inbound request queue will prompt it.
Work with CTRS
CTRS Market Intelligence pressure-tests product roadmap assumptions against market evidence before build time gets committed. If a candidate on your roadmap rests on a single persistent voice, contact CTRS for an outside read on whether the market is actually asking for it.
About the author: Aaron Cruikshank is President of CTRS Market Intelligence. Since 2003, he and CTRS have supported more than 1,000 projects for growing SMEs, major brands and public-sector organizations, from market assessments to decision support. His background includes an Associate Vice President role at Ipsos. Aaron also speaks on market intelligence at conferences, on podcasts and in company workshops. More about Aaron · aaroncruikshank.com
Comments