The bottleneck moved

The best engineers I've worked with always wanted more.

More customer problems to solve. More feedback to read. A bigger backlog — not a smaller one. They didn't want to be handed a ticket and told to build. They wanted to understand what the customer was experiencing and figure out the best way to solve it. The sexy problems and the quality-of-life ones. Both.

I spent twenty years on the other side of that dynamic. As a product manager, I was trained to do the opposite — to filter. To take the infinite stream of customer signal and compress it into the top three things worth building. To protect engineering from the noise. To be ruthless.

That ruthlessness was necessary. Engineering was finite. You couldn't build everything, so you had to choose. The PM existed to make that choice — to be the translation layer between what customers needed and what engineering could deliver.

It was also, honestly, one of the most disheartening parts of the job.

Because every time you made the top three list, you knew what was sitting below it. Real problems. Real friction. Things customers had told you, in their own words, mattered to them. Things you believed in. And you'd deprioritised them anyway — not because they weren't worth solving, but because the system required it. Finite resources. Finite time. The discipline of saying no.

That system made sense. Until it didn't.

What the engineering side was actually asking for

Here's the thing about those engineers who wanted more customer signal: they weren't being idealistic. They were being practical.

The engineers who asked for customer problems — not just tickets — built better things. They made better tradeoffs when they understood who they were building for. They caught edge cases the PM hadn't thought of. They suggested approaches that turned out to be simpler and more elegant because they understood the actual goal, not just the stated requirement.

The demand for better signal was always there. On both sides. Customers had problems they wanted solved. Engineers wanted to understand those problems. The PM was in the middle, doing the best they could with a translation process that was manual, slow and structurally lossy.

The system wasn't broken because people weren't trying. It was broken because the middle step — the interpretation, the prioritisation, the spec — was a human bottleneck in a process that generated more signal than any human could process. Feedback management was the bottleneck even before building got fast. Customer feedback management as a discipline was structurally lossy: one person's interpretation of another person's problem.

And for a long time, that was fine. Because the constraint was engineering, not product decisions. Features took weeks to build. A slow translation process was survivable — the whole system ran at roughly the same speed.

Then the build side got fast.

When AI coding tools moved the constraint upstream

AI coding tools didn't just make engineers faster. They changed the shape of the problem. AI-assisted development moved the constraint upstream — from engineering capacity to product decisions.

When Cursor or Claude Code can turn a well-written spec into working code in hours, the question stops being can we build this? and starts being should we build this, and what exactly should it be? The Claude Code feedback flow runs through the spec, not the ticket. The decision layer — the translation from customer signal to engineering work — is suddenly the thing that determines how fast a team can move.

The bottleneck moved. From engineering to product decisions.

For the first time, product development has a different shape:

Customers → AI system → Engineers

Not:

Customers → Product manager → Engineers

The system doesn't replace judgment. It removes the manual translation work — the interpretation, the prioritisation, the spec-writing — that used to sit between customer signal and engineering. What moved is the translation layer. The step where signal either gets preserved or lost.

This matters more than it sounds. The PM discipline of prioritising the top three things was built for a world where engineering was the constraint. Every feature prioritisation framework I learned was built for finite engineering. Finite is no longer the assumption. Be ruthless, protect the team's time, say no to everything that isn't essential. That was good advice when building took months.

When building takes hours, ruthlessly limiting yourself to three priorities means leaving engineering capacity idle while the decision-making catches up. The instinct to filter — which was the right instinct for decades — becomes the thing that slows you down.

The mental model broke. Not because PMs are doing anything wrong. But because the world they were trained for no longer exists.

The real opportunity: the backlog you stopped building from

Most of the conversation about AI and product development focuses on speed. Build faster. Ship more. Move quicker. Backlog management used to mean ruthless prioritisation. With faster building, it can mean something else. Most backlog software assumes you're filtering down to three. Product backlog software was built for a world where engineering was the scarce resource. The constraint changed; the tools haven't.

That's real, but it's not the most interesting part.

The most interesting part is what becomes possible when the constraint on what you can build is no longer engineering capacity.

For the first time, teams can think seriously about the things that used to sit below the top three. The quality-of-life improvements. The small friction points that customers mentioned but that never made the cut. The features that weren't urgent enough or strategic enough or impactful enough to justify the engineering time — when engineering time was the scarce resource.

That scarcity has shifted. What was too small to build before might now take hours, not weeks. The ruthless filter that kept the backlog manageable was also, quietly, keeping customer experience at a certain floor.

The opportunity right now isn't just to build faster. It's to raise that floor.

Every product has a layer of known, documented customer friction that never gets addressed — not because nobody cares, but because the economics didn't justify it. With AI coding tools changing the build economics, the question changes too. Not just what are the top three things? but what's everything we know customers want that we've been deprioritising for years?

That list exists. In every team's backlog. In the feedback that got collected and never processed. In the tickets that were closed as "won't do" when they probably should have been "can't do yet."

You know what's on that list. The onboarding friction that shows up in every third support ticket. The small UX inconsistency that five different users mentioned in five different ways across five different conversations. The workflow improvement that wasn't strategic enough to make the top three — but that your customers keep working around, quietly, every day.

Those things didn't make the cut because the economics didn't justify it. The economics changed.

But faster building doesn't fix the translation problem

Here's where most teams will get stuck.

You can give engineers the fastest coding tools in the world, but if the signal they're working from is still filtered through a manual human process, the bottleneck just moves somewhere else. The translation layer — the step where customer signal becomes engineering work — doesn't get faster just because building does.

The pattern I've seen across every team I've worked with:

Feedback arrives. It sits in Slack, in support tickets, in interview notes, in a spreadsheet someone built two years ago and stopped maintaining. A PM periodically reviews it, forms a view, writes some tickets. By the time those tickets reach engineering, the original customer language is gone. What remains is one person's interpretation of another person's problem — compressed, filtered and weeks or months old.

The engineers who wanted customer problems to solve? They're still getting tickets. The signal is still degrading in transit. The process is just as manual as it was before — it's running alongside faster tools, not integrated with them.

The build side got an upgrade. The decision layer didn't. The translation step is the work before the work — and it never got the upgrade engineering did.

What fast customer feedback loops actually look like

The shift I've been watching happen in the teams doing this well isn't primarily about tools. It's about closing the distance between customer signal and engineering work. Customer feedback prioritisation stops being a quarterly meeting and becomes a continuous score. How to prioritise customer feedback when the bottleneck is decisions, not builds, becomes the question.

Feedback arrives. It gets processed immediately — classified, clustered, scored. Priorities update in real time as new signal comes in. Specs are generated with enough context that an engineer can start building without a lengthy briefing. Here's the full pipeline → The original customer voice is preserved in the spec, not paraphrased out of existence.

The PM doesn't disappear from this picture. But their role changes. AI for product managers isn't about replacing judgement. It's about removing the manual translation work that judgement was buried under. AI product management changes the role from translator to interpreter. Instead of being the translator — the human converting raw signal into structured work — they become the interpreter. The person who looks at what the system has surfaced and asks: what does this actually mean? What are we optimising for? What's the call?

That's a better use of twenty years of product instinct than manually synthesising Slack messages into Jira tickets. Product roadmap prioritisation was a discipline of scarcity. The scarcity moved.

And the engineers? They get what the best ones always asked for. Customer problems. Real context. A backlog that reflects what customers actually said, not what a PM remembered them saying three weeks later.

Raising the floor

The disheartening part of being a PM — the ruthlessness, the things left on the floor — was always a symptom of constraint, not a virtue in itself.

The teams I most admired weren't the ones who said no the most aggressively. They were the ones who managed to address more of what customers actually needed. Who found ways to make the quality-of-life improvements alongside the strategic bets. Who didn't leave their users living with known friction because the economics never justified fixing it.

That kind of team was rare, because the constraints were real.

The constraints changed.

The teams that figure this out first won't just ship faster. They'll raise the floor of their product — systematically, continuously, based on what customers actually said. Not just the top three things on the roadmap. Everything customers told you they needed that you've been carrying in your backlog for years.

The bottleneck moved — into the translation layer. What you do next determines whether you move with it.

---

Catherine Williams-Treloar is the founder of Circuit — the AI product system that turns customer feedback into scored priorities and build-ready specs for Cursor and Claude Code. She has 20+ years leading product, insights, strategy and GTM at scale-ups and enterprises. Circuit was founded in Sydney in November 2025 and launched in February 2026.