Should Engineers Read Raw Customer Feedback, or Only PM-Filtered Summaries?
Neither extreme works, and the two failure modes look nothing alike. Routing everything through a PM's write-up loses the customer's actual words. The difference between "this is annoying" and "this is annoying, and I've started exporting to a script because of it" disappears into a single bullet point, and that difference is often the whole signal. But dumping raw support tickets on engineers doesn't fix that either. An inbox of forty half-duplicate Zendesk threads a day doesn't get read closely; it gets skimmed, and skimming raw text loses just as much nuance as a bad summary while also costing far more engineering time.
The split that actually holds isn't "raw" versus "summarized." It's routing by volume. A small, curated slice of raw feedback, the handful of tickets that are actually relevant to what an engineer is building this week, should reach them unfiltered. Everything else needs a layer that counts and dedupes before anyone reads prose. Teams that get this wrong usually pick one lever (an escalation policy, or a "no filters, we're customer-obsessed" culture) and apply it to all feedback volume, when the right lever depends on how much of it there is.
What compression cuts from the ticket
A PM writing up feedback is doing real compression work, and compression is lossy by design. The two things that get cut first are usually the two things engineers most need:
- Exact wording. "It silently failed" and "it threw an error I had to screenshot for support" are different bugs. A summary that says "export failures" collapses both into one line item.
- Severity signal buried in tone. Customers rarely say "this is a P0." They say things like "I've had to explain this to my manager twice now," which is a severity signal a PM has to infer and often flattens into neutral language to keep the ticket professional.
Neither loss is anyone's fault. A summary that preserved every nuance wouldn't be a summary, it would be the original ticket with extra steps, and writing that for every request doesn't scale past a handful of PMs. The problem is only that engineers who never see the raw version have no way to know what was smoothed over, and no way to ask a follow-up question of the actual customer.
The problem raw access runs into at scale
The opposite failure is just as real, and PostHog has written about a version of this that works. In PostHog's own account, engineers doing support directly cuts out the "support creates a ticket, PM prioritizes, engineer implements" chain entirely. The newsletter post cites a concrete case. A customer noted PostHog's survey tool only offered a 1-5 scale instead of the industry-standard 1-7, and the engineer who read that note shipped 1-7 as an option the next day. No PM write-up, no backlog grooming, just a direct fix informed by the actual sentence a customer wrote.
That works because PostHog bounds it. It isn't every engineer reading every ticket; it's a rotation, and a support layer that absorbs the volume first. Without that structure, raw access degrades fast. Feedback arrives across a dozen tools, phrased a dozen different ways, and the same underlying request shows up as five separately worded tickets because nothing is deduping them before they reach a human. An engineer reading raw tickets at that volume isn't getting more signal than the PM-summary version, they're getting the same signal repeated five times with none of it counted, which is worse for prioritization than a summary that at least says "eight customers asked for this."
“export is broken for us”
“any update on SSO?”
“we hit the rate limit again”
Read + clusteredWhat Colin didn't get from the Jira ticket
A store manager who uses Bellwood Systems, shift-scheduling software for hourly retail teams, filed a Zendesk ticket:
Customer: I approved a time-off request for Maya on Thursday, and it just silently overwrote her shift on the schedule. No warning, no popup, nothing. She showed up to cover a shift that didn't exist anymore and I had to scramble to find someone.
Britt Sundberg, the PM handling the weekly triage pass, rolled it into that week's write-up as a single line that read, "Time-off approvals should validate against existing shift assignments before applying." Reasonable, and technically correct. Colin Petrakis, the backend engineer who picked it up, added a validation check that blocked the time-off approval when a shift existed, and shipped it as a fix.
It broke a different workflow within a week. Managers frequently do want the time-off approval to override the shift; that's the whole point of approving it, and the new validation blocked legitimate approvals along with the silent-overwrite case Colin was actually trying to fix. The PM summary had correctly identified the bug category but dropped the word that mattered most, "silently." The customer's actual complaint wasn't that the system resolved the conflict. It was that the system resolved the conflict with no warning and no popup. Reading the original ticket would have pointed Colin at a confirmation-modal fix on the first pass instead of a validation block that had to be reverted.
Neither Britt nor Colin did anything careless. The summary was accurate as a category; it just wasn't the ticket.
How PostHog actually splits it
PostHog's own handbook on handling customer issues is a useful model precisely because it isn't the pure "engineers read everything" story the newsletter post might suggest. The handbook describes a tiered structure. It tells whoever is customer-facing to "try to solve issues yourself first," and PostHog's support team, made up of technical engineers, "handle most tickets" directly, reading them in raw form. Only issues needing deep technical domain knowledge escalate further into product engineering, and when they do, the handbook asks the escalating person to attach a note explaining what they've tried and why it's being handed off.
That's the actual split in practice. Raw access sits at the front line, where the people reading tickets are engineers already, and a short context note (not a rewritten summary) covers the one hop where volume would otherwise overwhelm the specialist being looped in. Nobody at PostHog is reading a PM's paraphrase of what the customer said; they're reading the ticket, or a two-line note pointing at the ticket.
When the same request arrives three different ways
Below a few dozen support conversations a week, you can run PostHog's model by hand. That means a rotation, a habit of pasting the original ticket link (not a summary) into whatever the engineer sees, and a norm that escalation notes point at the source instead of replacing it. That's genuinely enough for a small team, and it costs nothing to set up beyond the discipline to keep doing it.
It stops working at the point where the same request starts arriving through different channels with different wording, and nobody is deduping across them before an engineer sees any of it. A Slack DM, a Zendesk ticket, and a sales call transcript can all describe the same broken workflow in three unrelated sentences, and a manual routing habit has no way to notice that. Each looks like a one-off, gets read once, and gets prioritized (or dropped) independently. This is also the point past which asking who should own the routing stops being about org charts and starts being about whether anyone is looking across sources at all.
That's the point we build for. Modem reads conversations from Slack, Discord, Zendesk, email, and sales calls, and merges repeated mentions of the same underlying request into one topic instead of leaving them as separate tickets for separate people to read. The original wording stays attached to every merged mention, so an engineer opening the filed issue sees Maya's manager's actual sentence, not a category label, while the count ("eight customers, three of them on the Retail plan") is what tells a PM it's worth prioritizing at all. It's the PostHog structure, raw text plus a count instead of raw text plus a paraphrase, applied to a volume of feedback that a rotation can no longer read by hand. The step after this one, once a request has been counted and needs to become a tracked piece of work, is covered in turning support tickets into roadmap items.
The actual rule
Read raw when the volume is low enough that reading it doesn't cost more engineering time than the summary would save, and when what an engineer is missing is wording or tone that a summary genuinely can't carry. Summarize, or better, count and cluster, once the same request is arriving from enough directions that no single raw ticket tells the whole story on its own. The mistake in both directions is applying one rule to all of it. A blanket "engineers read everything" policy drowns in duplicates, and a blanket "PMs filter everything" policy is how a validation block ships instead of a confirmation modal.
