Table of Contents
I keep hearing this story: “The PM can’t keep up with the developer. As soon as they land on an idea, the engineer implements it in a day. Product is growing exponentially.“
Sounds great. Engineers are 10x faster, shipping at a rate that was science fiction two years ago.
I’ve watched this exact pattern play out. A team starts shipping twice as fast. The PM can’t keep up with what’s landing. Features pile up with no spec behind them. Six months later, you’re maintaining a product nobody planned.
But here’s what nobody’s asking: can you keep adding features forever?
The Salesforce Trap
I might be wrong, but I think one of the reasons Salesforce grew into a juggernaut is that they never stopped shipping features.
They never took the time to redesign, re-architect, or migrate to modern stacks — at least not as often as they should have. But they kept adding. If you had a custom request, Salesforce could bend to fit it.
That works when you’re selling to thousands of companies with thousands of needs. But it doesn’t work inside your own product.
If you keep adding features just because they’re basically free to build, you create three kinds of debt: friction for existing users, training debt for new ones, and technical debt when the architecture starts to crumble under the weight of features nobody asked to coordinate.
The Gap That Used to Protect You
The lean startup thesis was simple: have a process to figure out what to build next. You could afford that process because there was a healthy delay between planning, designing, and developing.
That gap is gone.
The time to think about a feature is becoming asymmetrically different than the time to implement it. What’s the ratio now? 5:1? For every five minutes you spend thinking a feature, it takes one minute for an AI agent to build it.
That sounds like a dream. It’s actually a trap.
We’re not moving faster as a process. We’re moving faster in development only, which pushes the bottleneck to product.
It used to be the other way around: while PMs waited for developers to finish, there was time to reset and think about what comes next.
That thinking time is gone. And nobody replaced it.
“Let the Machine Think”
I know the next question: why not use AI to figure out what to build? Resolve the bottleneck with the same technology that created it.
That’s not wrong, but it’s incomplete.
An AI agent could figure out what to build next — it’s intelligent enough to come up with something. But only if it has a process to follow. A workflow.
You can have a PM working with an AI agent to produce specs. But how helpful is that if the agent doesn’t have the company’s context, the product’s current state, or what customers are actually saying?
There are techniques to inject context, as simple as attaching a PRD, as sophisticated as building pipelines that pull the data automatically.
But the real question isn’t “can AI help product?” It’s: what is the workflow we need to automate next to resolve the product bottleneck?
Workflows, Not Chatbots
A chatbot — even one with all your company data — is just an external consultant. It can answer questions, propose frameworks, and diagnose your situation.
It won’t resolve it.
It needs specific tools, built for your specific case, and wired into a process that runs without prompting.
You could build those tools. But then you’re in a new trap: building the tools to produce the tools. Scope creep at the infrastructure level.
As I wrote in Stop Building AI Agents, the agent isn’t the product. The workflow is. And as I wrote in AI Moved the Bottleneck to Your Head, when building is free, thinking is expensive.
Fake velocity is what happens when you skip the thinking.
The valuable thing isn’t building faster. It’s building a process where product can move as fast as development.
That’s not a chatbot. It’s not an agent. It’s a workflow — and one that can be built.
- Your Team Is Shipping Fast. That’s the Problem. - 02/21/26
- AI Moved the Bottleneck to Your Head - 02/19/26
- Stop Building AI Agents - 02/17/26