How PM work is changing in the AI era: AI moves the bottlenecks of product development

Why the bottleneck moved and PM work followed it

“Our developers are a lot faster with Claude and Codex. My product managers spend the day holding it all together.” That is how a CTO in one of our conversations describes how PM work is changing in the AI era. Casey Winters interviewed product managers from startups to public companies for his newsletter Casey Accidental and reaches the same finding in one sentence: “AI removed one constraint and exposed several others.”¹

The one constraint was engineering capacity. Product managers spent years waiting on development that was slow and expensive even with the best engineers. Now code is easy to generate, and the bottleneck sits elsewhere: in design, in integrating new features with the existing product, in edge cases, in organisational alignment and in shared product principles. Organisations have not yet rebuilt their product processes around these new constraints, and the technology keeps changing faster than processes can stabilise.¹

I am a co-founder of Teklens. Before that I built Aioma and sold Localina's CRM to Swisscom, and I teach at HWZ, ZHAW and FHNW. At Teklens we have had 24 discovery conversations with product people about how their teams work with AI, and some version of that CTO's sentence comes up almost every time. This article takes Winters' interviews as the starting point and puts the measured data next to them. You will take away where the bottleneck went and how to find it in your team, why more output has so far brought little more impact, the three operating modes teams develop after their first AI mistakes, and a seven-step way to rebuild the product process around the new bottlenecks.

The thesis in one sentence: AI removed the scarcity in coding but did not replace the mechanism that scarcity enforced, prioritisation. Coding got fast. Coordination didn't. The bottleneck is no longer coding but alignment, and the judgement about what should be built at all.

Where did the bottleneck go?

From coding into the work before and after it. The product managers in Winters' interviews name five places: design, integrating new features with the broader product, managing edge cases, organisational alignment and shared product principles. None of them is new. What is new is that they now set the waiting time, because the step before them, implementation, finishes in hours instead of weeks.¹

Theory of Constraints. Eliyahu Goldratt described the pattern in 1984 in “The Goal”. His five steps: identify the constraint, exploit it, subordinate everything else to it, elevate it, and once it is broken, go back to step one so that inertia does not become the new constraint. Most product organisations completed step four with coding agents and skipped step five. They keep running processes, roles and meetings designed for scarce engineering.²

The measurement. In 2025 Faros AI analysed telemetry from more than 10,000 developers in 1,255 teams. Teams with high AI adoption complete 21 percent more tasks and merge 98 percent more pull requests. At the same time, review time per pull request rises by 91 percent and pull requests grow 154 percent larger. The queue moved from writing to reviewing and integrating. Exactly where Winters' product managers feel the bottleneck.³

In 2025 Atlassian surveyed about 3,500 developers and managers in six countries. Two thirds report saving more than ten hours a week through AI tools. Half lose more than ten hours a week to organisational friction: finding information, switching between tools, aligning across teams. What AI gives in the editor, the organisation takes back in coordination.⁴

For product managers, the waiting has changed sides. Product used to wait on engineering. Now design, review and alignment wait on decisions a product manager should have made before the agent started. The CTO from the opening calls this “holding it together”. It is the work of a bottleneck that has not been named yet.

Why does more output not mean more impact?

Because AI makes work cheap enough that used to be uneconomic. Winters describes teams producing more code, more specs, more prototypes, more bug fixes, more evals and more dashboards, and product managers who see hardly any comparable rise in business results. The unprioritised work, the work that moves no metric, the work that used to stay in the backlog, now gets done. And it eats the time in which the most impactful work would be planned.¹

The company level confirms it. In the Faros data the correlation between AI adoption and performance metrics evaporates once you look at the company: throughput, lead time and incident resolution stay flat while output per developer rises. DORA surveyed nearly 5,000 technology professionals in 2025 and calls AI an amplifier. Higher adoption goes with more throughput, but still with less stability. What gets amplified is what the organisation already has, including the disorder.^3,5

Add to that a perception gap. METR had experienced open-source developers work with and without AI tools in a randomised trial. With AI they were 19 percent slower and believed they were faster. The sample is small and the setting specific, but the finding about self-perception matches what Winters' product managers report: the feeling of speed and the measured impact drift apart.⁶

The side effect. More additions reach customers faster and cause confusion, and many of them should never have been built. Winters' conclusion: the product has become harder to understand, and so has the code base. GitClear analysed 211 million changed lines of code from 2020 to 2024: duplicated blocks of five or more lines appeared eight times as often in 2024, moved lines, the signal for refactoring, fell by around 40 percent, and in 2024 copied code exceeded moved code for the first time. Every unreviewed addition makes the next decision harder.^1,7

One question stays open, and Winters asks it honestly: if every company now works through bugs and small feature requests faster, have customer expectations risen so far that you fall behind if you don't? Nobody knows the answer today. What can be answered is whether your team does this work deliberately or because it has become cheap.¹

What happens when scarcity no longer forces prioritisation?

Teams build what is buildable instead of what matters. Winters puts it plainly: “Before AI, engineering scarcity forced prioritization. AI removed some of the scarcity without replacing the prioritization mechanism.” The old logic was simple: code was the lever, code was expensive, so you saved it for the best ideas. Everything else was not done, or done by people by hand.¹

Prioritisation had two more jobs that hardly anyone named as such. It controlled the rate of change reaching the customer. And it rejected bad ideas. Both functions disappeared with the scarcity. That is why more concepts now reach customers that should never have been built, and why product and code base are harder to understand.¹

The wrong incentives. At the same time an expectation emerges that product managers should query data themselves, prototype, change prompts, write code, build internal tools, create agents and define evals. Winters observes that the standard for product managers has over-rotated: from “understanding technology well enough to ensure good decisions are made and followed through” to “demonstrating technical ability yourself”. Product managers work harder to appear technical and AI-native, and have less time to determine whether what their teams produce should exist at all.¹

More mature organisations draw the line differently. Using AI for efficiency is table stakes there. What is valued is creating value for customers and the business with AI that was not possible before. That takes two things. Taste, knowing what good looks like, as a skill to be relearned with a technology that changes which products are possible at all. And principles, the written ground truth people and agents execute against, as a process. Winters' sentence on this carries the whole article: “AI raises the value of judgment only when PMs make their judgment understandable to others and reusable.” What that looks like in planning is in the article on the AI product roadmap; how teams manage context instead of work is in the one on the AI product operating model.¹

How do teams respond to the first AI mistakes? Three operating modes

Every organisation starts the same way: use AI, experience magic, build faster, experience mistakes. What happens next shapes the team. Winters sees three responses: protect the downside (“What if it's wrong?”), maximise the upside (“Why not try it?”) and optimise for impact (“Did it matter?”). These are not three types of company. Teams inside the same company run in different modes, and one team changes mode by phase.¹

Mode 1: protect the downside. These teams tightened their processes: approved tools for specific use cases, strong gates, a deck culture, consequences for using AI wrongly. The gain is quality control. The risk: the company defends its position while competitors discover something new that erodes that position. Innovation happens off hours in personal projects. Our AI Monitor 2026 with ETH Zurich and the University of St. Gallen shows the same pattern among 163 respondents: six in ten also reach for personal AI tools, although 87 percent are given tools by their employer. Approval lists do not prevent use. They move it out of sight.^1,9

Mode 2: maximise the upside. These teams try things by default. They accept that part of the work will be slop because they want to get more done overall and learn faster. They work harder than ever and barely grow faster. The chain “ship faster, more experiments, faster learning, faster growth” breaks as soon as the capacity to ship exceeds the capacity to learn. AI-written updates lead to AI tools that summarise the updates. Winters' definition is precise: “Organizational slop is what happens when an organization can generate work faster than it can evaluate, coordinate, or absorb it.”¹

In this mode, developer distrust is the healthiest signal. In the Stack Overflow Developer Survey 2025, with more than 49,000 responses, 84 percent use or plan to use AI tools, 46 percent distrust the accuracy of the output, and 66 percent name solutions that are “almost right, but not quite” as their biggest frustration. Almost right is cheap in a prototype and expensive in a product decision. Mode 2 confuses the two.⁸

Mode 3: optimise for impact. These teams care whether what they build moves user or business metrics. Productivity counts only if it ends up as growth or profit. They do not equate token consumption with progress, have fewer tools than mode-2 teams and trust them more. Their work lives in documents and spreadsheets, not decks, and every artefact is written for humans and agents as equal readers, often in Markdown rather than slides. Almost all mode-3 teams in Winters' interviews started in mode 2. Perhaps a team has to be overwhelmed by AI before it learns to constrain it intelligently.¹

What connects all three modes: centralising around AI does not mean trusting it. Winters' product managers work in a personal AI environment made of a favoured model, company context, personal context and the company's tools, often connected through MCP, and export the result only at the end as a deck, a document or a Slack message. The more sophisticated that environment, the less blindly they trust it. All of them have seen AI over-index on the context it was given and flatten the nuance where the best product insights live. Out of that grows a new skill with five decisions: what context the AI gets, what synthesis it may do, what it may execute, where human judgement is still required, and what a human verifies.¹

How do you rebuild the product process around the new bottlenecks?

In seven steps, in this order: find the bottleneck, reinstate prioritisation without scarcity, limit the rate of change, write principles, define the check before the build, set trust boundaries for AI, measure impact instead of output. The order follows Goldratt: identify first, then subordinate, then elevate.²

1. Find the bottleneck before you treat it. Measure where work waits today: review time per pull request, days in the design queue, approval rounds per feature, alignment meetings per initiative. In the Faros data review is the most common candidate; in your team it may be integration or design. Ask engineering where they wait on product. The answer is usually a missing decision.³

2. Reinstate prioritisation without the scarcity. An initiative has to show why it should exist, not that it is cheap. Demand an impact claim for every initiative: which customer or business metric it moves and what happens if you don't build it. A useful test: would we build this if it cost ten engineer-weeks? If not, don't build it for ten minutes either. The activity Prioritize against your objectives gives this a form.

3. Limit the rate of change reaching customers. Prioritisation used to throttle change as a side effect. Now the throttle has to be explicit: a budget of changes per release that customers can absorb, and support tickets per release as the measure. What exceeds the budget waits or gets cut.

4. Write product principles as ground truth. Principles govern how the product behaves in the cases nobody specified. They are what people and agents execute against. Write them with an example and a counter-example, versioned, in a place an agent can read. The activity Write a PRD shows how intent and principles get into the document agents and people read together.

5. Define the check before the build. The eval is becoming the core product artefact. Before anything is built, it is settled how you will know it worked: an eval set for AI features, a success metric for everything else. The PRD says what you intended to build. The eval says whether you did. The activity Define success metrics and the article on KPIs for AI products help with the choice.¹

6. Decide what AI may know and decide. Write down the five decisions per workflow: context, synthesis, execution, human judgement, verification. Some teams give the AI raw data and demand the raw data back rather than smoothed conclusions. Others never let it near raw data. Both are defensible. What is not defensible is not having decided.¹

7. Measure impact, not output. Once a quarter: of everything you shipped, what changed a customer or business metric? That share is the health metric of your process. If it is low, you are building faster what you should not have built. Then the rule is: delete work before you automate it.

So what is the product manager's job now?

To decide what should happen, why, by which principles the product behaves, and how success is evaluated. After a brief period in which product managers were expected to become engineers themselves, Winters observes engineering moving back to owning the implementation mechanics. The debate “PRD or prototype” hides the fact that the eval is becoming the core artefact. The strategy document or PRD returns as the artefact from which agents and people read what should have been built. The eval says whether it was.¹

That closes the loop to the CTO from the opening. His product managers hold everything together because the new bottleneck in his organisation has no name and no process yet. Abundance makes the old core of the job more important, not less: when everything can be built, deciding what not to build becomes more valuable. Winters' closing line: “AI made it easier for PMs to build. It did not make it easier to know what was worth building.”¹

Our work at Teklens starts at exactly this bottleneck. The Product Brain is a shared memory for people and AI agents: it keeps product decisions, customer feedback, Jira and code connected and current, so that principles, priorities and verification criteria live in one place agents and people read from. You decide. Teklens keeps the knowledge together. If you want to know where the bottleneck sits in your team today: show us in 30 minutes how your product work happens, and we will tell you honestly whether Teklens helps there.

Frequently asked questions

Recommendations

• Measure where work waits before you buy tools. Review time, design queue, approval rounds and alignment meetings per initiative, for four weeks. The largest value is your bottleneck. Treat it, not coding.
• Demand an impact claim from every initiative. Which metric does it move, and what happens if you don't build it? No answer, no ticket, however cheap the implementation.
• Write down the rejections. Rejected ideas with reasons, in a place people and agents read. That is the prioritisation mechanism scarcity used to provide for free.
• Make principles and evals the core artefacts. The PRD carries intent and principles, the eval carries the check. Both before the build, both readable by agents and people.
• Set trust boundaries for AI per workflow. Context, synthesis, execution, judgement, verification: five decisions, written down. A team that knows them is allowed to be faster.
• Judge product managers by decisions, not by demonstrated technique. In reviews, ask what the person did not build and why, and what the built things changed. Not how many prototypes, skills or agents came out.

Scope & caveats

• Casey Winters' findings come from interviews with product managers from startups to public companies, published in his newsletter Casey Accidental. Sample size and method are not published. It is a practitioner synthesis, not a study; the quotes are his wording, the reading in this article is mine.
• Faros AI analysed telemetry from more than 10,000 developers in 1,255 teams in July 2025. The relationships are correlational, the report comes from a vendor, and the longer review time can mean deferral or deeper review; the data does not distinguish between them.
• DORA 2025 rests on nearly 5,000 respondents and shows associations, not causes. Atlassian's figures are self-reports from about 3,500 developers and managers; the hour values come from the report and its coverage. The Stack Overflow Survey 2025 has more than 49,000 self-selected participants; the share that trusts AI is given as 29 to 33 percent depending on aggregation.
• METR's study is a randomised trial with a small sample in a specific setting. GitClear is a vendor and analyses its own customer data plus 25 large open-source projects; the duplication figures differ between GitClear's own pages (eightfold blocks, copy-paste share from 8.3 to 12.3 percent). Goldratt's Theory of Constraints comes from manufacturing; applying it to product organisations is an analogy.
• The AI Monitor 2026 rests on self-reports from 163 respondents and shows that personal tools are in use, not what data flows through them. The 24 discovery conversations are Teklens' own, not a study, and the CTO quote is paraphrased from them. The Teklens statements describe product capabilities, not measured customer results.

Sources

Every external figure and quote in this piece – linked so you can verify it.

1. 1.Casey Winters, «How PM Work Is Changing in the AI Era», Casey Accidental ↗ – Interviews with product managers from startups to public companies; the five new bottlenecks, the three operating modes and the quotes in this article.
2. 2.Theory of Constraints Institute, «Five Focusing Steps», nach Eliyahu M. Goldratt, «The Goal» (1984) ↗ – Identify, exploit, subordinate, elevate, go back to step one.
3. 3.Faros AI, «The AI Productivity Paradox», Juli 2025 ↗ – Telemetry from more than 10,000 developers in 1,255 teams: 21 percent more tasks, 98 percent more pull requests, 91 percent longer review time, no correlation at company level.
4. 4.Atlassian, «State of Developer Experience Report 2025», 2025 ↗ – About 3,500 developers and managers in six countries; time gained through AI and time lost to organisational friction.
5. 5.DORA, «State of AI-assisted Software Development 2025», Google Cloud, September 2025 ↗ – Nearly 5,000 professionals; AI as amplifier; more throughput, less stability.
6. 6.METR, «Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity», 10. Juli 2025 ↗ – Randomised trial: 19 percent slower while feeling faster; small sample.
7. 7.GitClear, «AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones», 2025 ↗ – 211 million changed lines 2020 to 2024; duplication rises, refactoring falls.
8. 8.Stack Overflow, «2025 Developer Survey: AI», 2025 ↗ – More than 49,000 responses; 84 percent use or plan to use AI tools, 46 percent distrust accuracy, 66 percent name “almost right” as the biggest frustration.
9. 9.Teklens mit ETH Zürich und Universität St. Gallen, «AI Monitor 2026», 2026 ↗ – 163 valid responses on tool use; 6 in 10 also use personal AI tools, 87 percent are given tools by their employer.

Keep reading in the PM Lab

Related deep dives – from the same pillar and the adjacent phases.

Matching Activities from the Playbook

From the article straight into practice: these Activities put the concepts to work with Teklens.