Why Feature Requests Don't Always Mean Product-Market Fit

A founder hears it and feels validated: users keep asking for more. Surely that means the product has caught on and people are engaged enough to want it to do more.

Sometimes that’s exactly right. But feature request volume is one of the most commonly misread signals in early-stage products. It can mean real investment in what you’ve built — or it can be one of the clearer signs you do not have product-market fit yet, dressed up as engagement.

The difference isn’t in how many requests you get. It’s in what kind of requests they are, and who’s making them.

Why Feature Requests Feel Like Validation

Feature requests are easy to mistake for demand because they look like the thing PMF is supposed to produce: users caring enough about your product to want more from it.

A request also feels active in a way passive metrics don’t. A retention chart just sits there. A message that says “can you add X” feels like a person leaning in. Founders naturally weight it more heavily than a login they didn’t see happen.

But wanting more from a product and being satisfied with the product’s core job are two different things. A user can ask for ten new features while quietly failing to complete the one workflow the product exists to deliver. The request tells you they’re still in the room. It doesn’t tell you they’re getting what they came for.

The Real Split: Extending the Core vs. Replacing It

The single most useful lens for reading feature requests is whether they’re asking you to go deeper on what already works, or asking you to route around what doesn’t.

Extend-the-core requests build outward from a workflow the user already completes regularly. A user who books appointments weekly on your platform asking for calendar sync, recurring bookings, or SMS reminders is asking you to remove friction from something they’ve already proven they’ll do. That’s a genuine signal — the core is landing, and they want more of it.

Replace-the-core requests look similar on the surface but mean something different underneath. A user asking for a bulk CSV import, an API, or “can I just email this to someone on your team instead” is often telling you the interface you built doesn’t actually solve their problem end to end. They’re not extending the workflow — they’re trying to avoid it.

The tell is usually in what the request implies about current usage. Ask: does granting this request make the existing core workflow more valuable, or does it let the user avoid using the existing core workflow at all? If it’s the second, that request is closer to a symptom than a feature idea.

Signal	Extend-the-core pattern	Replace-the-core pattern
What’s being asked for	More depth, automation, or reach around an existing action	A workaround, shortcut, or alternate path that skips the current flow
What it implies about the core	Users complete it repeatedly and want it to do more	Users avoid completing it, or complete it reluctantly
Typical phrasing	“Can this also sync with…”, “Can I automate this step”	“Can I just send you a spreadsheet”, “Is there a way to skip this part”
Underlying signal	Genuine engagement with the core value	Core workflow isn’t fully solving the problem yet
Right response	Prioritize as a real roadmap candidate	Investigate why the core isn’t sufficient before adding on top

This is closely related to the broader question of separating useful MVP feedback from noise — but the extend/replace lens is specific to requests that arrive dressed as feature ideas rather than complaints, which is exactly why they’re easy to misread.

The Vocal Minority Problem

The second way feature requests mislead founders has nothing to do with what’s being asked — it’s about who’s asking.

Highly engaged users are structurally overrepresented in the channels founders actually see: support tickets, community Slack groups, direct emails, sales calls. A user who emails you twice a week is not two users — they’re one user who happens to be unusually vocal, and their requests will still show up in your notes as if they carry the weight of a larger group.

This creates a quiet bias. Founders end up building a roadmap shaped by whoever is loudest and most reachable, not by what a representative slice of the user base actually needs. A B2B SaaS product might have five power users driving 80% of feature requests while the other ninety-five users have never opened a support channel — not because they’re satisfied, but because they’ve quietly stopped logging in.

Before treating a repeated request as a real pattern, check it against three things:

• Usage overlap — are the people asking for this actually active users of the core product, or are they mostly the same handful of names across every request?
• Segment spread — does the request come from a single customer segment, acquisition channel, or cohort, or does it show up independently across different types of users?
• Silence elsewhere — what does usage data say about the quiet majority who never file a request at all? A drop in weekly active usage among non-requesters is a stronger signal than another request from someone already deeply engaged.

If a request clears all three, it’s a strong candidate. If it’s concentrated in one loud group with no independent confirmation elsewhere, treat it as one data point, not a mandate.

What This Looks Like in Practice

Consider a project management tool where new users consistently ask for “a way to import from spreadsheets” during onboarding. On its face, that’s a feature request. Read against the extend/replace lens, it’s actually feedback that the manual setup flow is too slow to get to first value — an early sign the onboarding activation moment isn’t landing, not a request for a nice-to-have import tool.

Contrast that with the same tool’s existing users asking for Slack notifications when a task is assigned. Those are people already running tasks through the product weekly, asking for the workflow to reach them where they already spend time. That’s an extend-the-core request, and it’s a far more trustworthy signal to prioritize.

The practical move is to stop treating “we got a feature request” as a single category of evidence. Split it in two before it reaches the roadmap: does this deepen something users already do, or does it try to get around something they’re currently stuck on? And separately — does this represent a pattern across the base, or one persistent voice? Only requests that pass both checks deserve to shape near-term priorities. This is also why customer feedback and feature requests need different evaluation criteria — a request is one input, not a verdict, and it needs to be weighed against actual behavior before it changes what gets built next.

Reading Requests Alongside Behavior, Not Instead of It

None of this means ignoring what users ask for. It means never treating a request as the whole picture. Pair every recurring request with the usage data around it: is the requesting cohort retained, active, and progressing through the core journey, or are they stalling and asking for a way out?

Founders who are still assessing whether their broader metrics show real traction should look at this alongside other early product-market fit signals — retention, repeat usage, and organic referrals tend to be harder to fake than a request thread, and reading them together with feature requests gives a much more reliable picture than either alone.

If the requests skew toward replacing the core, and usage among the broader base is flat or declining, that combination is one of the more reliable early signs you do not have product-market fit yet — worth investigating before adding anything new to the roadmap.

Get a Second Read on Your Product Signals

Feature requests are useful data, but they’re easy to misread when you’re close to the product and eager for good news. A founder team benefits from an outside read on whether requests reflect genuine demand or a workaround for something that isn’t working yet.

Frequently Asked Questions

Do lots of feature requests mean I have product-market fit?

Not by themselves. Feature requests only signal fit when they ask you to extend something users already rely on. If requests ask you to replace or work around your core workflow, or come from a narrow slice of users, they can just as easily mean the opposite — that the current product isn't landing.

What is the difference between an 'extend the core' request and a 'replace the core' request?

An extend-the-core request builds on a workflow the user already completes regularly, asking for more depth, automation, or reach around it. A replace-the-core request asks you to route around the main workflow entirely, often because that workflow doesn't fully solve the problem yet.

How many users need to ask for something before it counts as a real signal?

There's no fixed number, but the pattern matters more than the count. A request repeated by users across different segments, use cases, or acquisition channels is stronger evidence than the same number of requests concentrated in one vocal group or one early cohort.

Can a small group of vocal users mislead product decisions?

Yes. Highly engaged users are often overrepresented in support channels, community forums, and direct outreach, which makes their requests feel louder than their actual share of the user base. Weighing requests against usage data helps avoid building for the loudest instead of the most representative.

What should I check before building a requested feature?

Check whether the requesters are actually using the core product regularly, whether the request extends or replaces that core workflow, and whether the same request appears across independent user segments rather than one concentrated group.

Is it ever right to ignore repeated feature requests?

Sometimes, if the request is really pointing at a broken or incomplete core experience rather than a genuine extension. In that case, the right response is usually to fix or simplify what already exists rather than add another feature on top of an unstable foundation.