Feature Request

A feature request is a suggestion from a customer or user asking for a specific new feature or piece of functionality. It's the most common shape User Feedback takes and also the most misleading, because the request itself is rarely the thing you should build.

Productboard's own guidance to teams processing incoming feedback is to teach contributors to "always ask why, seeking the underlying need instead of a bare feature request." A user asking for a CSV export might actually want to get data into their own BI tool. A user asking for dark mode might actually be working at night and struggling to read the screen. The request names a solution the user invented on the spot. It rarely names the problem.

Marty Cagan at the Silicon Valley Product Group has spent years arguing against treating feature requests as a roadmap input at all. His recommendation is to take "for each feature or project, to determine what the underlying problem to solve is, and what the logical way to measure success would be," shifting teams from roadmaps of features to roadmaps of outcomes. In Cagan's framing, a list of prioritized feature requests is a symptom of a feature team, not an empowered product team.

Why it matters for product-market fit

Feature requests are where most teams' feedback process breaks down, and it's the first place Produck's loop earns its keep. In the Listen stage, feature requests pour in from support tickets, sales calls, in-app widgets and Slack channels, usually phrased as "can you add X." If you stop there and just tally votes, you end up building whatever the loudest or most recent customer asked for, in whatever words they happened to use.

Diagnose is the stage where the request gets reopened. Instead of logging "add CSV export" as a ticket, the question is what job the user was trying to do when they hit the wall that made them ask for it. Two feature requests with different wording can turn out to be the same underlying problem, and one feature request can turn out to bundle three unrelated problems. Skipping this step is exactly the failure mode we described in The PMF Stack Is Broken: tools that store feedback without ever forcing someone to ask why it was said.

Once the underlying problem is clear, Decide is where a Prioritization Framework compares problems, not requests, against each other. A problem shared by twenty accounts and blocking renewal outranks a feature request from one vocal user, even if the second request came with a longer email. Ship then closes the loop back to the people who raised it, so they see their problem addressed, whether or not the shipped solution matches the feature they originally named.

Produck is not a bug tracker and a feature request is not a bug. Treating it as one, a ticket to close, is how teams end up with a backlog full of shipped features nobody adopted.

When it works, and when it doesn't

It works when

• The request comes with enough context (a workflow, a screenshot, a "here's what I was trying to do") that the underlying problem is recoverable without a follow-up call.
• Multiple requests independently point at the same friction, which is a stronger signal than the polish of any single request.

It falls short when

• The team builds directly off the words in the ticket instead of talking to the user who filed it.
• A single loud account's request skips triage and lands straight on the roadmap because it's easy to say yes to.

How to apply it

1. Capture the raw request verbatim, including the words the user used and the context around when they said it.
2. Before logging it as a feature, write down the job the user was trying to complete when they hit the wall.
3. Check whether other requests, in different words, point at the same underlying problem.
4. Score the underlying problem, not the request, against your prioritization criteria.
5. If you build something, tell the requester what shipped and why, even if it isn't the literal feature they asked for.
6. Archive the original request text next to the shipped outcome so you can see, months later, whether the underlying problem actually went away.