Who Should Own Feature Requests: Support or Product?

Neither team owns the whole thing, and that's the source of most of the confusion. Support (or CS) should own capturing the request and closing the loop with the person who asked, because they hold the relationship. Product should own triaging it against everything else and deciding whether and when it gets built, because that's a roadmap call support isn't positioned to make. The request has one owner at each stage, not one owner overall.

Ambiguity shows up when a team tries to make one group own all three jobs (logging, triaging, and following up), or when nobody is told which job is theirs. Support without a triage partner logs everything into a spreadsheet nobody prioritizes. Product without a support handoff hears requests secondhand, months late, stripped of the account and urgency context that made them worth acting on in the first place. Both failure modes look identical from the outside. A customer asked once, heard nothing, and is now asking a competitor's sales rep instead.

The three jobs, split by who's actually positioned to do them

Break "own feature requests" into its actual parts and the split gets obvious:

• Logging: capturing the request, who asked, and why, at the moment it happens. This has to happen where the conversation already is, which means support, sales, or whoever is on the call. Product is rarely in the room.
• Triage: classifying, deduping against existing requests, and deciding relative priority. This needs visibility across the whole backlog and the roadmap, which support doesn't have and shouldn't be expected to build.
• Follow-up: telling the requester when it ships, or when it's been decided against. This needs the original relationship, which routes back to whoever logged it, not to product.

PostHog's own engineering handbook makes this kind of split explicit rather than assuming it. Every feature has a named engineering owner who is "responsible for maintaining the feature" and fields the incoming asks against it. The point generalizes past PostHog's specific structure. If you don't write down who does what with an incoming request, the org will improvise an answer, and the improvised answer is usually "whoever heard about it last."

What breaks when the seam isn't owned

A few concrete failure modes, all traceable to the same root cause:

• Requests get logged with no destination. A support rep tags a ticket "feature request" and closes it. Nobody on product ever sees the tag exists, so the request dies in a system product doesn't check.
• Product hears about requests too late to act cheaply. By the time a pattern reaches product secondhand, usually at renewal time from a CSM in a panic, the account is already at risk instead of being a normal backlog item with three months of lead time.
• The same request gets logged five times as five different things. Without a shared triage step, "can we get SSO" from support, "SSO came up on the call" from sales, and "SSO blocking security review" from a CSM become three untethered tickets instead of one counted theme.
• Nobody closes the loop, so nobody trusts the process next time. If product ships the thing and support never finds out, the requester never hears back, and the next time they have a request, they don't bother routing it through the official channel. They just complain in the renewal call instead.

Sales-sourced requests are their own version of this same problem. A frequent complaint from the product-management side is that sales-led asks get waved through without real evaluation, or waved off without real consideration. Neither response treats the request as data worth checking against the rest of the backlog. One argument worth taking seriously is that product's job in that exchange isn't to approve or reject the specific ask. It's to own the discovery underneath it, talking to the rep, the prospect, and similar accounts, then deciding what to build based on the pattern rather than the deal. That's a triage job, and it only works if product actually gets the request instead of hearing about it from a Slack thread three weeks after the close.

How Sparrowbridge split it after getting burned once

Sparrowbridge builds bookkeeping software for small accounting firms, twenty-two people, no dedicated PM until Theo Whitfield moved into the head-of-product role last year, after four years as a backend engineer. Callie Nakamura runs support. In the year before that promotion, the two teams had no formal split for handling requests, and it produced exactly the gap you'd expect.

Callie, in a retro after losing a renewal: I tagged the reconciliation-export request in Zendesk in February. It's tagged on eleven tickets now. Did anyone on product ever see it?

Theo: Not until this week, when the account escalated. I didn't know eleven people had asked. I thought it was one or two.

They fixed it with a written rule, not a tool change. Support logs every request in a shared field the moment it comes up, with the requester and account attached. Product reviews the queue every Friday and moves anything worth building into the actual backlog with a priority. Whoever built the fix tells support it shipped, and support tells the requester by name. Nothing exotic, and it only took a half-page doc to write down. What changed wasn't the process complexity, it was that both sides finally knew which half was theirs.

Theo, three months later: The count on reconciliation-export hit fourteen before we shipped it. I would've built it around request four if I'd seen the number in real time instead of finding out at renewal.

Where the manual split stops working

The Callie-and-Theo version scales fine at a few dozen requests a month, one product, one support queue. It stops working somewhere past that, for reasons that are structural rather than a discipline problem:

• The Friday review can't outpace the intake. Once requests arrive from support, sales calls, and a public board simultaneously, a weekly human pass falls permanently behind, and "behind" quietly becomes "untriaged."
• Dedupe by memory fails first. Callie recognizing "that's the same as the export thing" works at low volume and stops working the moment two teammates are tagging independently. The same request gets logged as two different themes.
• The handoff itself is manual and lossy. A shared field is still something a human has to remember to fill in accurately, on every ticket, forever.

This is usually the point where a team stops trying to out-discipline the problem and adds something that automates the intake, dedupe, and handoff instead. Modem is built for exactly that seam. It reads support tickets, Slack, and sales calls, folds the same request wherever it surfaces into one counted topic with every requester attached, and files it into product's tracker without anyone having to remember to tag it. Because the requester list travels with the topic, the follow-up job happens automatically once the fix ships, instead of depending on someone remembering to close the loop. Worth saying plainly since we build Modem, our Zendesk integration is the common starting point for support teams doing this, and it's one option among several competing for that job, not the only one. Below the volume where a weekly human review genuinely keeps up, the manual split above is enough on its own.

Two related guides worth reading next: how to run a feedback triage process without a dedicated PM covers the triage half in more depth, and what is a customer context graph explains the data structure that keeps a request tied to its requester across the handoff.

A one-paragraph rule you can ship this week

Write one paragraph. Support logs every request with the requester attached, product reviews the queue on a fixed day and sets priority, and whoever ships the fix tells support so support can tell the customer. Put it somewhere both teams will actually see it. The rule matters more than the tooling. Sparrowbridge ran theirs in a shared spreadsheet field for months before touching anything automated.