"Taking feedback directly from a customer and actually improving the product for them, without a game of telephone in between."
That's Julianna, our Head of Customer Success, describing what it felt like to ship her first two Pull Requests at Pyn last week. No ticket threads. No backlog. No sprint planning. Customer says the button doesn't work, CS fixes the button.
First the codebase had to be made legible enough that a single prompt could move it forward[1]. Then we ran everything through a #for-claude Slack channel — prompts in, engineers refining, changes going out as a direct feedback loop. That calibrated what "good" looked like. We then paired end-to-end on changes to iterate and educate the team.
Finally, Julianna went solo with Claude Code: raised the PR and asked for a review. Both were approved and deployed with no changes required.
The obvious pushback is "won't the product turn into a mess?" So far, it's the opposite. The vast majority of changes your team crave are bugs and quality-of-life improvements — the button that doesn't work, the typo in the docs, the back button that goes to the wrong place, the dashboard that's missing a filter. These are things that should get fixed but rarely bubble up from deep in the backlog. The quality of the product has gone up[2].
It goes further than bug fixes and polish. If CS can modify and improve their own superuser tools, they can perform their roles with less Engineering input. This is genuine leverage.
What surprised me is how much it changed the conversation between Engineering and CS. Instead of back-and-forth on "could it do this?", our CS team can now ask "what if it worked like this?". Sometimes the answer might be "no, here's why" — but even those exchanges are richer than a Jira comment thread (and frankly, more enjoyable).
We start speaking the same language a little more with each exchange[3]. We are collaborating directly on the product.
There's a practical angle too. Pyn's Engineering is based in Australia, our CS team is in the US. We're starting to see a future where the Engineers wake up to a set of Pull Requests to review, rather than a set of tickets to triage. Ditch the backlog, keep the audit trail.
Two PRs is not a trend. But the thing I keep coming back to is how collaborative and fun it's been. CS is overjoyed to be able to deliver for their customers. Engineering gets that extra bit of input and polish that's always hard to stretch to. The next PRs are already in the pipe.