A PM at a massive legacy company has been waiting two months for a copy change. No end in sight.
I’m currently a PM in a massive legacy company and a very simple copy change has been taking almost 2 months with no end in sight
A UX consultant tracked a broken export button at a SaaS company. Four hours of work. Three months later, nothing.
The export button? Top of the list. Maybe 4 hours to fix. Three months later I followed up. ‘We’ve been really busy with CS initiatives.’
I’ve been reading hundreds of these stories across Reddit, Hacker News, and industry blogs over the past few months. PMs, support leads, CS managers, non-technical founders. Different companies, different industries, same problem.
The person who sees the problem can’t fix it. The person who can fix it doesn’t see the problem.
Small fix, big queue
The pattern that shows up most is small fixes stuck behind big roadmaps. A two-line bug fix waiting behind a feature launch. A copy change behind a migration.
A developer discovers a bug… The product manager asks: ‘Will this affect our roadmap?’ Unless the bug is actively preventing a feature launch… the answer is almost always no. The bug gets a ticket, tagged as ‘tech debt,’ and joins hundreds of other tickets in the backlog hotel, where it will remain indefinitely.
Engineering teams are incentivized to ship features. Bug fixes don’t show up in OKR reviews. This isn’t about bad engineers. It’s about incentive structures that make small fixes invisible.
Design files are done, feedback is in, customer interviews are clear — and still, features sit in the backlog while engineers juggle debt, migrations and release trains.
The fix isn’t complicated. Getting it prioritized is.
Support as human band-aids
While those fixes wait, support teams manually cover the gaps.
Can’t load data? Support will do it. Can’t update a field? Ask support. Approval didn’t map right? Support’s got it. This worked — for a while.
Support becomes the runtime workaround for product bugs. Every manual fix is a human being doing what a 4-line code change should do.
We often face severe delays in implementation and fixes… I struggle to get ETAs… we blow right past those… ‘well shit, I don’t know, let me check with the team.’
And the shielding makes it worse. When support absorbs the pain, engineering never sees the true volume. The bug stays deprioritized because the customer impact looks manageable from the outside.
Over the years I’ve talked to so many support teams that see engineering as where bug reports go to die — very rarely do any resolutions come back.
Accountability without authority
CS and support own the customer relationship but have no control over the product.
Customer success has no influence on the product roadmap.
— Customer Success Collective Survey, September 2025
Hundreds of CS professionals surveyed, and that’s the consensus.
CS helps escalate… nobody actually does anything or tracks anything… then it comes back on the CSM… ‘why didn’t you escalate FURTHER?’
The dynamic is always the same. Support is asking for help. Engineering is doing them a favor.
A lot of support teams historically have seen themselves as customers of engineering teams and often are frustratingly begging for help.
Support sells the customer’s pain twice. Once to the customer: “we’re working on it.” Once to the PM: “please prioritize this.” Both conversations go nowhere.
It’s awful being the person all of our users are complaining to about issues but without the ability to fix them myself
What people actually do about it
When you can’t get engineering time, you get creative. Here’s what I’ve seen, ordered from most common to most extreme:
- Spreadsheets and manual processes. One company’s support team did data loads by hand. A founder on HN built entire app logic in Excel.
- Social escalation choreography. CC’ing executives into customer threads. “Churn risk” messages in Slack. Dragging VPs of Engineering onto calls.
- Career change. A CS specialist at a SaaS company literally became a software engineer because she got tired of waiting.
That last one is the most telling. The fix was so simple that a non-engineer learned to code rather than wait for it.
None of these workarounds fix the underlying problem. The codebase is still right there, and nobody who sees the problem can touch it.
What would actually fix this
A support lead pastes a Sentry link in Slack. An AI coding agent clones the repo into a sandbox, traces the bug, writes a fix, runs the tests. Three minutes later there’s a PR with a null check and a regression test. An engineer reviews it like any other PR.
The support lead didn’t touch the codebase. The engineer didn’t get pulled off their sprint. The customer got a fix instead of “we’re tracking this internally.”
That’s ChivesBot. Anyone on your team triggers AI coding agents from Slack to investigate issues, fix bugs, or automate tasks. Nothing touches production without an engineer approving it.
If you want early access, drop your email.