Is product the bottleneck now?
For years, the default complaint in software was simple: product had more ideas than engineering could build.
You could sketch a feature in a meeting, put it in a roadmap, add a few acceptance criteria, and then wait. Weeks if you were lucky. Months if the work touched the wrong service, needed design polish, or got dragged into the usual queue of bugs, tech debt, meetings, dependencies, holidays, and "we just need to refactor this bit first."
Engineering was the obvious bottleneck because the feedback loop was expensive. Product could imagine ten things before engineering had shipped one of them.
AI has made that feel strangely upside down.
Now a decent engineer with Cursor, Claude Code, Copilot, Codex, or an internal agent can get from idea to working prototype very quickly. Not always production ready. Not always correct. But quick enough that the old rhythm feels broken. The question is no longer, "Can we build this?" as often as it is, "Should we build this, what exactly should it be, and how will we know if it helped?"
That moves the bottleneck away from typing code and toward product judgement.
I think that is mostly a good thing. But only if we resist the temptation to replace one bad habit with a faster one.
The bottleneck moved, it did not disappear
The mistake is thinking AI removes bottlenecks. It usually moves them.
When implementation gets cheaper, ambiguity gets more expensive. A vague ticket used to be slowed down by the natural drag of engineering time. Someone would eventually ask, "What are we really doing here?" because nobody wanted to waste a sprint.
Now the same vague ticket can turn into a branch, a demo, three variants, a half-working feature flag, and a pile of token spend before the team has answered the basic question.
Who is this for?
What problem are we solving?
What behavior are we trying to change?
What would make us kill it?
Those questions were always important. AI just makes the cost of avoiding them show up in a different place. Less waiting. More churn.
The research is already more mixed than the hype
The current evidence does not support a clean "AI makes software teams faster, therefore ship more" story.
GitHub's 2024 survey found that AI coding tools are now common inside software teams, with more than 97% of respondents saying they had used them at some point. Respondents also said the saved time helped them design systems, collaborate more, and meet customer requirements better.
That sounds like the optimistic version of the shift: engineering gets leverage, and the team spends more time on higher-value work.
But Stack Overflow's 2025 Developer Survey tells the other side. 84% of respondents are using or planning to use AI tools, and 51% of professional developers use them daily. Yet positive sentiment dropped to 60%, and more developers distrust AI output accuracy than trust it. The survey also found strong resistance to using AI for high-responsibility work: 69% do not plan to use it for project planning, and 76% do not plan to use it for deployment and monitoring.
In other words: people are using the tools. They are also still nervous about handing them judgement.
METR's 2025 study is an even better caution sign. It looked at experienced open source developers working on real issues in large repositories. Developers expected AI to make them 24% faster. Instead, when allowed to use AI tools, they took 19% longer. METR is careful about what the study does and does not prove, but that gap between perceived speed and measured speed matters.
Then there is DORA's 2024 report, which is probably the most useful lens for teams. It found that AI adoption can improve individual productivity, flow, and job satisfaction, but it can also hurt software delivery stability and throughput. DORA also found that user-centricity and stable priorities are major drivers of product quality and organizational success.
That last point is the one product teams should sit with.
If AI makes individuals feel faster but the system ships less stable work, the bottleneck was never just coding. It was clarity, sequencing, quality control, and learning.
Product work becomes more important, not less
A lot of teams still treat product as the group that feeds requirements into engineering. That model was already weak. In an AI-assisted team, it becomes dangerous.
If product turns into a prompt factory, the company gets a faster backlog machine. More tickets. More prototypes. More internal demos. More "look what we built in an afternoon" moments.
Some of those will be useful. A lot will be slop.
The better version is product as a filter.
Product should slow the team down at the points where speed is cheap and mistakes compound:
- before an idea becomes a build task
- before a prototype becomes a roadmap item
- before a demo becomes a promise
- before a local win becomes a pattern copied across the product
That does not mean endless discovery theatre. It means doing the small amount of thinking that prevents a large amount of waste.
A good product person in this world is not the person with the biggest backlog. It is the person with the nerve to say:
"No, that is not the problem."
"No, we do not need the polished version yet."
"No, a generated demo is not evidence."
"No, we are not adding another workflow until we know why the current one fails."
That kind of product judgement used to save engineering weeks. Now it might save the company a thousand tiny wrong turns.
Design is part of the same bottleneck
Design has a similar problem.
If engineering can produce more UI faster, weak design systems get exposed. Every edge case becomes a screen. Every prompt becomes a modal. Every internal idea becomes another setting, toggle, sidebar, or wizard.
The product starts to feel like nobody is saying no.
This is where design cannot just be "make it look better." Design has to protect coherence. It has to decide what belongs, what can be reused, what should be removed, and where the user should not have to think.
AI can generate five interface options. It cannot tell you which one feels inevitable for your product, your customers, and your business unless you have already given it a strong taste model to work from.
Taste becomes leverage.
So does restraint.
Should we slow down?
Yes. But not everywhere.
We should not slow down typing code, spinning up prototypes, writing tests, refactoring boring bits, or exploring throwaway ideas. AI is genuinely useful there. Making those loops faster is good.
We should slow down the moments where a team converts uncertainty into commitment.
Slow down before turning a hunch into a roadmap item.
Slow down before mistaking a working prototype for a validated product.
Slow down before accepting generated code nobody understands.
Slow down before shipping something that adds surface area without adding value.
The goal is not to build less. It is to stop confusing motion with progress.
A simple rule for AI-era product teams
Before building, answer five questions:
- Who is this for?
- What painful thing changes for them?
- What is the smallest version that proves the point?
- What evidence would make us stop?
- What quality bar must not drop just because the code was cheap?
If those questions are answered, build fast. Use the agents. Burn the tokens. Try three versions. Let engineering move.
If those questions are not answered, speed is a trap.
You are not accelerating product development. You are accelerating ambiguity.
The bottleneck we actually want
Maybe product and design becoming the bottleneck is not a failure. Maybe it is the correction software needed.
For a long time, engineering scarcity forced teams to prioritize. It was frustrating, but it created a useful pressure. You had to choose. You had to make a case. You had to care, at least a little, about whether the thing was worth building.
AI weakens that pressure. That is exciting. It is also risky.
If everything is easier to build, the scarce thing becomes taste. Clear thinking. Customer understanding. The ability to cut. The ability to protect the product from becoming a landfill of half-good ideas.
So yes, product might be the bottleneck now.
Good.
Let's make it a better bottleneck than engineering ever was.