The New Bottlenecks in Software Delivery

When code and documents get cheap, what gets scarce?

Your engineering team can now produce more software than your organization can absorb.

A product manager who'd just left a crypto-custody company said it plainly:

"The bottleneck was product definition, but then it's to the actual coding, but coding is cheap now. So now the bottleneck moved towards testing and review."

— Product manager, financial infrastructure, October 2026

That's the problem nobody planned for. For twenty years, product teams were built around the cost of making things. A PM turned discovery into requirements. Engineers turned requirements into code. QA checked it. Someone shipped it and explained what changed. Every role existed because production was expensive.

Now an agent drafts the PRD, proposes twenty tickets, builds a prototype, and writes the implementation before your old team would have finished the kickoff meeting.

And the rest of the system didn't get faster.

We went back through research and customer conversations we recorded this year and read them for one thing: where does the work pile up now? The answer came back the same way from fractional PMs, enterprise platform leads, and two-person startups. Ambiguous specs. A decision record nobody trusts. Context that lives in one person's terminal. Reviewers who can't keep up. Tools that don't talk to each other. Permissions that take a quarter. Nobody sure whether a task is actually finished.

Notice what's not on that list. Model quality. Agent capability. Which coding tool you picked. The people who've gotten past these constraints didn't buy a better generator. They changed how their organization decides, remembers, reviews, and closes.

The scarce thing used to be the ability to make the artifact. Now it's the ability to prove it's the right one.

Here are the seven bottlenecks, in the words of the people hitting them. Names and companies are withheld pending their approval. Treat this as a pattern to test, not a census.

The bottleneck moves

The old picture of delivery is a straight line. Discovery, requirements, build, QA, release. AI doesn't delete any of those stages. It changes how much each one can handle. And when one stage gets fast, the next one gets a queue.

A fractional product leader described a client she'd helped adopt AI development practices:

"We have gotten them to incredible velocity with their engineering... Their biggest bottleneck is actually discovery and being able to convert like all the needs into specs."

— Fractional product leader, September 2026

A two-person health-tech founder, two years into coding agents, called it "a complete flip of the paradigm." Engineers used to wait on product. Now product can't keep context ahead of engineers.

The question used to be "how fast can we make it?" The question now is "what happens to everything we make?"

Here's the arithmetic. Say your team can generate ten implementation candidates a week and review ten. Stable. Now AI doubles generation to twenty. Review stays at ten, because review is people. Four weeks later, forty candidates are sitting in a pile, and generation is officially twice as productive.

A product leader at a video-software company had already noticed the trap:

"Some of these tools gives us a false sense of, oh, I can now go through a lot more volume. And yes, you can, but you also need to now review a lot more volume."

— Product leader, media software, August 2026

This is why output volume is such a bad measure of productivity. Everything the agent produces has to be absorbed, corrected, integrated, and validated by somebody. Volume without that is inventory.

The chart is hypothetical. The archive isn't. The first PM at an AI startup told us his agent pipeline generated roughly 500 action items in four months. A product leader at an ad-tech company has agents watching session replays and opening 30 to 40 pull requests a day. At a legal-services company that had just been through layoffs, the CPO's worry wasn't engineering speed: "Engineering is moving so much faster. Can we continue to move fast with it? Because product and discovery takes some time."

And the volume is real. We didn't ask people which coding tools they use. They told us anyway.

Two out of three people brought up Claude or Claude Code on their own. One in four brought up Codex. The PRD, a document the industry spent a decade trying to kill, came up in more than a quarter of conversations. The agents didn't make the spec go away. They made it load-bearing.

1. Alignment: the code can be right while the product is wrong

An engineering leader at a mid-market healthcare software company has been on Cursor since 2024 and runs Claude through an internal execution harness. Feed it a detailed PRD, get features back. The harness works. The PRD is the problem.

"We can feed in a really detailed PRD, but there's a lot of iteration around like, hey, what are we talking about here?... it's that upfront part where I'm like, oh my God, this is so painful."

— Engineering leader, healthcare software, June 2026

A twenty-year product veteran described shipping a production app with Claude Code in days. Then he told us why it worked.

"We're able to like kind of vibe our way to like a production app very quickly. But that's because we had this document that... was like exhausting to make."

— Fractional product leader, July 2026

The two weeks of thinking was the work. The code was the receipt.

And the thing that used to absorb a vague spec, a senior engineer asking the right question in standup, is being removed from the loop on purpose. A product lead at a learning startup put it directly: when the team paired with one brilliant AI engineer, nobody needed detailed specs. "Now as we expand that... more of our team need to work as AI engineers... writing out these tickets and these specs are a lot more important."

A PM deploying agents in sales named the risk underneath all of this:

"My PRD is a ground truth. If whatever I provide there, it will get taken in."

— Product manager, enterprise sales technology, September 2026

The agent doesn't push back. It builds what you said. Which means the scarce work is framing: which problem matters, what evidence says so, which tradeoff you're choosing, what you are not going to build.

One more thing. A PM at Google told us AI made their PRDs shorter, from 30 or 40 pages to two or three. Then: "the doc length might have gotten shorter, but doc quantity has exploded." Cheap documents don't fix alignment. They multiply the places it can break.

Try this. Before any agent implements anything, require a short decision-ready brief: the user problem, the evidence, the desired behavior, explicit non-goals, assumptions, and one named approver. Keep customer observations, product hypotheses, and accepted decisions in separate piles.

Watch for a polished spec that quietly turned guesses into requirements.

Measure requirements that changed materially after engineering started, and rework you can trace to unclear or unsupported scope.

2. Decisions: nobody can tell what was decided

We went into these conversations with a belief: product teams aren't bottlenecked on decisions, they're bottlenecked on translating decisions into work. The transcripts corrected us. Teams decide fast enough. What's broken is the record. A week later, nobody can say what was decided, by whom, or whether it was a decision at all.

A PM at a student-discount platform:

"I had a meeting last week where it seemed very clear to me that a specific agreement was reached. When I subsequently proposed a way forward, the response from senior management was, whoa, that's not what we said at all."

— Product manager, consumer platform, October 2026

She now asks the room to confirm decisions on the record. Not because she wants to. Because she got burned.

The machines aren't better at this than the humans. A former PM at a large consumer app spent months trying to get Claude to do one thing with meeting transcripts:

"One of the things I never really succeeded at getting it to do on its own... was distinguishing between comments people made in the meeting and decisions that were made in the meeting."

— Former product manager, consumer app, September 2026

A transcript records everything at the same volume. The throwaway idea and the hard commitment look identical on the page. A PM at Google described the failure at scale: the one sentence where an approver says "actually, you're not approved" gets "drowned out by ten other transcripts from all of the planning meetings." Repetition beats authority.

So people hack it. An insurance PM at a 4,000-person company writes "we decided to do this because XYZ" into Jira comments, by hand, because "what did we decide and why did we decide on that 4 months ago?" comes up constantly. A content designer in Kyiv told us what she actually wants:

"I'd rather have a short, reliable record than a very polished long document that is filled with assumptions. And I'm curious how can AI distinguish a real decision from people we're just discussing or exploring."

— Content designer, public-sector apps, August 2026

Meanwhile, who decides at all is still an organizational choice. One product team keeps PMs on hypothesis-level PRDs and leaves ticket decomposition entirely to senior engineers: "As product managers, we are not responsible for opening tickets. The engineering teams are very senior, so they are very independent." AI didn't collapse that boundary. They decided not to let it.

Try this. Give every generated artifact a decision status: proposed, approved, superseded. Store an owner, a rationale, a date, and a link to the evidence. When an agent finds two decisions that conflict, make it raise its hand instead of picking one quietly.

Watch for draft tickets being read as approved roadmap, and the most recent thing said being treated as the thing decided.

Measure time spent waiting on a decision, decisions reopened, and work started with no accountable approver.

3. Context: the AI-native team is usually one person

Ask where the context for a decision lives. A content designer answered without pausing:

"The original reasoning in Notion, implementation details in Jira, actual experience in Figma, the latest decisions in somewhere in manager's meeting notes. And he didn't share it with me."

— Content designer, public-sector apps, August 2026

An AI product manager at a small startup confirmed the half-life of the document that's supposed to hold it all: "I don't think people are going back and updating the PRDs though. That context lives in Slack and on Jira as well as the Figma where the designs are updated."

So the most capable people build their own context layer. A growth PM at a large marketplace starts every day in a terminal:

"I built this by hand, just, it's local only through Claude Code, and every morning I just go into my terminal, I just say good morning. And it wrangles through all my Slack tasks."

— Growth product manager, consumer marketplace, September 2026

A PM in Toronto runs a cron job at four every afternoon that processes his meetings into a local graph of "everything in the business." A delivery lead at a consultancy calls hers "my vault... my context engine." A founder said flatly: "My Claude and my Codex know this company inside out."

Clever, all of them. Also individual. This is the pattern the archive shows most clearly: the AI-native product team, in 2026, is mostly an AI-native product person. A morning routine. A cron job. A vault. The organization around them is still running on Slack threads and someone's memory.

The ones who tried to lift that to team level hit the same wall. A former PM who hooked Claude Code to Granola, Jira, and Miro to automate sprint planning: "The fundamental issue was that the context it needed was not documented anywhere." The personal system works because its owner carries the missing context in their head. A team can't.

There's a second wall. More context isn't always better context. A senior product director on enterprise Claude tried rolling her 1:1 notes into one living doc:

"Claude has a tendency to get overloaded with context if you tell it too many things and it just kind of loses its place and then it starts updating things that are wrong."

— Senior director of product, legal services, September 2026

A PM at the healthcare company from section one went further. His breakthrough wasn't an LLM that remembered everything. It was a curated Confluence that an LLM could read: "to have an LLM remember everything you're doing doesn't work. It ruined your context window."

So the problem isn't "context is scattered." Context has always been scattered. The problem is the gap between the context one person has assembled for their agents and the context a team can share, trust, and keep current. A transcript tells you what was said. Working state tells you what's true now. A team needs both, and needs to know which is which.

One side effect worth watching: where this works, meetings shrink. The Toronto PM said that with institutional knowledge in his Linear agent "there's actually not that many meetings." Another product leader: "getting information shouldn't be in meeting." When context travels, people stop convening to transfer it.

Try this. Give every project a short, reviewed state file: objective, current decisions, owners, blockers, next actions, with links out to the long-lived evidence. Agents propose changes to it. A person accepts them.

Watch for stale context confidently repeating a decision that was reversed last Tuesday, and a context file that grows until the agent, or the human, loses the thread.

Measure time spent rediscovering decisions, contradictory statements about the same project, and the same question asked in three consecutive standups.

4. Review: the human becomes the verifier

A PM in Toronto runs the most automated product workflow we've seen. Claude Code, a Linear agent, a nightly cron over every meeting. We asked whether another PM or designer would help his team ship more. No.

"The engineers are already at capacity and they don't even have time to review... we have sort of more of a review bottleneck than anything else."

"I'm not the bottleneck for any of the information. I'm just the verifier."

— Product manager, B2B software, August 2026

He isn't alone. A product leader at a child-safety company built her own PM agent that turns BRDs from days into an hour. Then she described the hour: "I do not have confidence that the artifact which is generated is just, like, ready to go in the first time. I do have to spend somewhere between 30 minutes to an hour to make sure it's tightened."

And a product leader at a legal-tech company, on what Claude Code did to his week: "I'm just getting more and more features that I have to QA."

Skip the review and you find out fast. The first PM at an AI startup let an agent pipeline run unsupervised once:

"I did it once and I got slapped in my hand because I shared a product brief that was not ready."

— Product manager, AI startup, October 2026

His CMO called it slop. His agents had generated roughly 500 action items in four months.

The queue isn't just code review, either. PMs review AI-written specs. Engineers review PM-generated prototypes; one product leader told us all her PMs now "put out code so our engineering team can review it." A TPM at a large video platform stopped auto-sending meeting summaries entirely because correcting them cost more than the silence. And at one company the review itself got automated into a new bottleneck: an engineer "nitpicking every pull request and blocking progress because he's having Claude evaluate for like the most minuscule things."

Not everyone agrees review should grow. A two-person founder stopped reading code altogether: "Does it work? Yes, no. Are we secure? Yes, no. Boom. Done." A GTM contractor building with Claude Code reviews only the user experience and lets the code be whatever it is. Both moved the review up a level. Neither removed it.

Try this. Make review a real stage with three visible states: suggested, reviewed, approved. Attach the source evidence and a short change summary to every item so the reviewer checks meaning instead of rereading the transcript or the codebase. Decide, explicitly, what an agent may review and what a human must.

Watch for review fatigue, rubber-stamping, and defects that only show up after approval.

Measure reviewer time, material corrections, defects that escaped review, and the age of the review queue.

5. Integration: every tool works and the organization is still fragmented

A consulting lead who already automates her CRM from meeting notes described her actual job:

"I'm manually helping Claude stitch together all my other tools. Like even though I have APIs and MCPs and all that, I'm still like telling it like, I had this meeting, take these notes, update this tool with it."

— Client relationship lead, consulting, August 2026

That's the modern human API. A PM at a nine-person engineering team said the same thing from the other side: "A lot of tools, what I find it's missing is the connection between all these tools... I have to jump in and confirm the action plan or put the action plan into tickets."

Each step works. The seams don't. A product lead at a learning startup described what falls through them: "There's still a lot that gets lost either when I'm taking the transcription and it's being turned into a ticket or into that acceptance criteria... then you've got two duplicated things that might actually disagree with one another."

The teams that have closed the seams did it themselves. At one ed-tech company, several people independently converged on the same pattern: "We all have our little scheduled tasks to sweep across these different artifacts, prune them, generate a master list in Jira where we live. And then from there, the developers have their coding agents to pick up automatically from Jira."

An integration needs a contract: what's authoritative, what may be drafted, what may be written, and who approves the write. Without one, another connector just makes bad updates travel faster.

Try this. Pick your single worst handoff and instrument it end to end. Carry a source reference and a stable identifier from the original conversation all the way to the destination artifact. Record who approved the transfer. If the blocker is a permission, make that the project.

Watch for duplicate tickets, contradictory specs, agents with broad write access, and updates that technically landed and nobody read.

Measure manual transfer time, duplicate artifacts, failed handoffs, and corrections made in the destination system.

6. Governance: the connector exists, the permission doesn't

This one isn't in the AI-transformation decks. It was in every batch of interviews we read.

"As of two days ago, I finally got the Zoom MCP connector approved for Claude. Oh my God, it's been three months."

— Senior director of product, legal services, October 2026

For those three months she copied and pasted transcripts by hand. She is one of the most sophisticated users we talked to, at a company that pays for enterprise Claude. The technology was never the constraint.

It repeats everywhere. A product leader at a field-service software company couldn't get his call recordings connected to anything: "A lot of the progress I think is actually stymied by the organization." A PM at a data-cloud company copies Zoom transcripts into his own company's internal agent. A project manager at a Microsoft-only enterprise: "It will be easier just to copy and paste because integrations, you know." A healthcare product leader won't connect patient-adjacent systems to anything. A government contractor runs models only inside a compliance container. A biotech PM's company banned the note-taker outright.

Then there's money, which is governance by another name. One team is on a "token improvement plan" because the engineers burned through their credits. A consultant's Cursor bill hit $1,300 in a month. A large software company caps Claude at a hundred dollars a seat and tells everyone else to use Copilot. A services firm requires a procurement request to get Claude Code at all.

None of this is irrational. Attorney-client calls run on that Zoom. The patient data is real. The CUI rules are real. But it means the delivery loop in the diagram above is, for most enterprise teams, drawn in pencil. The agents can't see the systems. So a human carries the context across, and we're back to the human API.

Try this. Treat the permission as the project. Inventory which systems your agents can read and write today, who approved each, and what's waiting. Pick the one blocked connection that would remove the most copy-paste and get it through review, with the data contract written down.

Watch for shadow workflows: people exporting transcripts to personal machines because the approved path is too slow.

Measure connections requested versus approved, time to approval, and the share of handoffs still done by hand.

7. Closure: what does "done" mean when an agent says it's done?

This is the one everybody skips.

"The value stops at the meeting boundary. I still have to connect that information to tasks, documents and stakeholders."

— Content designer, public-sector apps, August 2026

An agent says it finished because it wrote the doc, opened the ticket, or passed the tests. A PM at a large retailer's data business has the tickets. That's not her problem anymore:

"My biggest pain point right now is actually getting people to remember that they are the human in the loop... Jira tickets created, etc. Now the problem is that the PM or the engineer who is responsible... they haven't been taking action."

— Product manager, retail data, October 2026

A fractional researcher said it shorter: "A list of action items, it's just a list until you actually do something with it. So help me shorten that distance."

The people who've solved this treat closure as its own job. The Toronto PM runs his pipeline backwards at the end of each day: "Did you fulfill your commitments? Check all the sources." A healthcare PM has a daily job that asks "what are the things people said they were going to do that haven't been done for the past three times." A COO who opens maybe 5% of his note-taker emails told us why: he commits to eight or ten things a day across the team, and "if I don't keep ownership over [them they] inevitably become bottlenecks like 48 to 72 hours later."

And one consultancy closes the loop all the way back to the spec: "When a PRD is implemented with all the specs are finished, are accepted. We mark that PRD as built or archived and that feeds back into the documentation."

Generated isn't approved. Approved isn't shipped. Shipped isn't successful.

One warning. Not everyone wants the loop closed for them. A fractional PM with a Microsoft and Amazon background was blunt: a "no human in the loop option of generating action items, creating Jira tickets... can potentially add noise, which I don't want to deal with." Propose, then approve. Don't auto-commit.

Try this. Define done separately for each kind of work. A ticket is done when the owning team accepts it. A code change is done when it clears merge, test, and release criteria. A product outcome is done when the intended behavior is verified with evidence. Write these down. Make the agent check against them.

Watch for agents closing tasks on weak proxies: a 200 response, a green test suite that doesn't cover the acceptance criteria.

Measure reopened work, completion claims nobody verified, time from approval to verified delivery, and post-release fixes.

What cut against the story

We'd be writing slop if we only quoted the people who agreed with us.

The most instrumented people don't feel these bottlenecks much. A fractional CPTO: "I don't know that I'm your customers because I've integrated everything." The Toronto PM called himself the "top 2% that doesn't see value in this." Their stacks work. They're also one person deep.

For some, review is shrinking, not growing. A delivery lead told us agents now implement from specs and "you don't really need user stories"; story size is set by what a reviewer can hold in their head, not what an implementer can build. A platform lead on AWS Bedrock measured his own output at "probably 10x" with a strict definition of done, and said his correction time is falling as the agents accumulate context.

Alignment, several people argued, was never about the artifact. A former CEO of a 150-person startup: "The biggest problem wasn't like the artifacts being on wrong detail level. It was more like building alignment between the teams." A former PM: "It's not a tool problem. It's a workstream problem, it's a culture problem."

And the tools themselves are a weekly variable. "Everyone moved to Claude... then everyone moved back to Codex." One team dropped Cursor over its acquisition. Another caps Claude at a hundred dollars a seat and tells everyone else to use Copilot. A founder switched note-takers "in three minutes" the day one of them shipped MCP. Lock-in is weak. The context layer underneath is what people are actually building.

A better scorecard

Your dashboard probably counts tickets created, PRs opened, commits made, docs generated. Those numbers were useful when making things was hard. Now they mostly measure how loud the generator is.

The useful numbers sit between the stages.

If an agent writes the spec in two minutes and the team spends an hour correcting, translating, and reconciling it, you didn't save fifty-eight minutes. If the agent writes a good draft and makes the handoff more reliable, you saved more than the writing time. The equation is the same. Only the honest accounting changes.

Try this for two weeks

Don't automate everything. Find the constraint AI just exposed in your process.

Pick one recurring workstream. For two weeks, track six things:

1. When was the problem clear enough to act on?

2. How long did it wait for a decision?

3. How much context had to be rebuilt or copied?

4. How long did review and correction actually take?

5. Did the result reach the right system and the right owner?

6. Who verified it was done?

Then fix the slowest transition. Only that one.

If review is the constraint, more drafts won't help. If fuzzy product decisions are causing rework, a faster coding agent will make it worse. If context lives in one person's terminal, get a shared project state before you add another autonomous step. If the agents can't see your systems, the next project is a permission, not a prompt.

The goal isn't maximum AI output. It's more verified progress per unit of your organization's attention.

The new advantage

It's tempting to think the AI-native team wins because it produces more specs, more prototypes, more code.

We think the teams that win are the ones that turn abundance into decisions, coordinated execution, and verified outcomes, with less human effort lost between each stage.

The next generation of delivery doesn't need better generators. It needs better ways to hold context as a team rather than a person, to record what was decided and not just what was said, to get its systems talking with permission, and to know when something is actually finished. Those are organizational changes. The people who've made them didn't wait for a better model.

When making work gets cheap, knowing what matters gets expensive.

How we looked. 560 recordings from Earmark's 2026 research and customer calls and titled as research sessions, feedback calls, check-ins, setup calls, or product-engineering interviews. Every quote was checked verbatim against its transcript, with obvious transcription errors ("claw code") corrected and small cuts marked with ellipses. The review-queue chart is a thought experiment, not a measurement; the tool chart counts mentions, not adoption. Recordings are not unique companies and this is not a survey. Speakers and companies are withheld pending their approval, and self-reported practices were not independently tested for outcomes.