Code was never the bottleneck. Product managers are.
The PM role as we know it has been a big, big mistake.
There’s a recurring joke about the busy calendars of product managers. Meetings after meetings after meetings. The poor souls juggling between multiple initiatives, multiple stakeholders and 3 different teams to implement a simple feature. They are the central node everyone depends on for decisions, context, and prioritisation. They sit between the “needy” executives who want to implement solutions and push for progress, and the engineers who need to understand what they need to build in the next iteration, based on an unclear Jira ticket passed down from leadership.
Why the bottleneck?
Product managers were born for a simple reason: someone needed to give a damn about the customer. CEOs and tech managers used to own that responsibility themselves, but as companies scaled, the customer got lost in the noise. We know what happens when engineers build stuff without the customer in mind (sorry, Clippy). Intuit figured this out in the ‘80s while building Quicken, obsessing over specific users and iterating until it clicked. It worked, and the PM title started putting its roots down.
Then Agile came along, and software practitioners started to realise that (maybe) they should have also cared about the customers because most of the terrible products out there were a result of a long-term development plan, with no iteration, no feedback, and no possibility to adapt to changes. I’d love to believe that PMs and engineers started to be more collaborative in the Agile world (see Teresa Torres’ product trio, or all Marty Cagan’s books), which is true for some companies, but it generally didn’t work as we were hoping it would. PMs started to fight to own the “voice of the customer”, and developers became expert sprint planners, grooming facilitators, and poker players.
The downfall of product development started when PMs started to call themselves “CEOs of their product”, and just imagine what this can do to people with big egos. As Michele Sollecito wrote in his article “The product manager role is a mistake”:
So what’s wrong with giving control of a company to a single person? The problem is not much with the model, which can work really well, but with the who, the person you give control to.
I still remember when I worked with a PM who distinguished herself for her “cheerleading style”, great presentational skills and hyping even on improving the colour of a button. Her ego was as big as the trouble I got in when I decided not to follow (for good reasons) her grandiose plans. You can imagine I didn’t last in that company for long.
To make things even more fun, in 2008, Marty Cagan gave a boost to PMs’ egos with the book Inspired, where he started to suggest that PMs own vision and strategy instead of taking directions from execs. Marty Cagan’s books are the Agile equivalent of the product management world: a great vision, implemented by a few enlightened companies, ignored by many and distorted by most.
With their success in FAANG companies, PMs continued to gain more prominence. They began to grow like weeds outside of Big Tech, and everyone dreamed of becoming one.
But most companies copied the title without the culture. They saw Jobs, Bezos, and Pichai succeed and thought, “We need a product leader.” Companies confused “product-led” with “PM-led.” Those exceptional leaders had vision, technical depth, and obsessive craftsmanship. What most companies hired instead were career managers.
FAANG had PMs embedded in strong engineering cultures with a clear strategy. Outside of that, PMs became the catch-all for everything the org was missing: no clear strategy, no customer access for engineers, no decision-making frameworks. So PMs filled the gaps by centralising everything through themselves.
Their vanity metric becomes how many meetings their calendar has for “alignment sessions”. They’re the only ones who talk to customers, do discovery, and come up with new ideas. They become the oracle of the product, the filter through which all feedback goes, top-down and bottom-up.
What this costs engineers and products
The result is devastating: builders become mere executors. They have a backlog of features to build, most likely written by PMs or their team lead. They sit through ‘grooming sessions’ and ‘poker games’ and ‘roadmap planning’ meetings to estimate tasks with some random numbers, then start working on them in ‘sprints’.
In the best-case scenario, the code is shipped to prod, and you never hear about that feature again. In the worst case scenario, you wait for QA to review your work and hear back two weeks later with a list of problems. As Marty Cagan puts it, in these setups, the engineers are relegated to delivery:
There is often a similar frustration with the engineers. The product manager that is really a project manager is often at odds with the way the engineers believe they need to be working. Not to mention that in this model, the engineers are relegated to delivery, and as I’ve said many times, if that’s the case we’re only getting about half their real value (so again, the good ones will want to leave and join an empowered product team where they can truly practice their craft).
Everything about this approach is broken. Engineers have no context for why they’re doing what they’re doing. They are completely disconnected from the end user and never see the impact of their work on the people using it. DORA’s 2023 research found that:
Teams can deploy as fast and successfully as they’d like, but without the user in mind, it might be for naught. Teams that focus on the user have 40% higher organizational performance.
When you’re disconnected, you stop questioning whether you’re building the right thing. Why would you care? When you’re not involved in discovery, you can’t really say to the PM that this feature is a terrible idea to add right now because it’ll require weeks of refactoring, and maybe you have a simpler idea that could achieve the same result with a fraction of the effort. Engineers have been using the product for a long time while building it. They know it inside out, and they know things can be improved. They may even have ideas to test with users!
Product-minded engineers have always suffered in such environments because they know something is off, but they can’t do much about it. They have to stay in their lane because they “have to deserve their place in the product team”. F*ck off. It’s no surprise that Stack Overflow’s 2025 survey found autonomy and trust to be the #1 factor for developer job satisfaction, above competitive pay.
Other than creating unempathetic engineers and making people want to leave companies, the bottleneck caused by PMs also damages the product. Speed is jeopardised. Information is diluted when going from PMs to the engineers, and the latter often build the wrong thing because they misunderstood what the actual product problem was. Research on design-to-development handoffs shows that 62% of developers spend too much time redoing work because of communication breakdowns. Every handoff is a game of telephone.
And then there’s the decision-making. Everything becomes politics. Features are pushed not because of utility, but because PMs have to show they’re delivering something great, or because the HIPPO said so. When decisions are centralised in a single person, you lose diversity of perspective and innovation. The people closest to the code, the ones who know what’s actually possible and what’s held together with duct tape, have no seat at the table.
I know you’re thinking: this is what a bad PM would do. My friends, that’s what most of the industry has. The “CEO of the product” title promises vision and authority, but companies hand it to people without the mandate, the technical depth, or the culture to back it up. As Michele Sollecito wrote in his article, they weaponise data-driven decisions, introduce frameworks and roles for everything, and meetings explode in number. The result is predictable.
Then AI showed up. And suddenly, the bottleneck had nowhere to hide.
Code was never the constraint
LinkedIn recently replaced their Associate Product Manager program with an “Associate Product Builder” program, a full-stack builder role where people take products from conception to launch. Everyone’s saying “PMs are now builders”. They’re using AI to draft PRDs, prototype with vibe coding, and communicate intent directly.
Engineers, meanwhile, can build features way faster using AI-assisted development and spend more time on the strategic part: system design, user experience, product thinking. As Stephan Schmidt told me in our conversation on the podcast, if engineers are five times faster with AI, they need to ask their product manager five times more frequently for input and decisions. The bottleneck that was always there is now impossible to ignore. PMs are in the “finding out phase”, realising that developers smoothed over a lot of things. You write a half-baked ticket, and between that ticket and reality is a developer who fills in all the gaps. AI is not as forgiving.
Reality is messier than the narrative suggests. Speed alone is useless when it becomes the end instead of the means. If anything, it’s going to make everyone’s job miserable, if not redundant.
PMs who just work as translators between business and engineering will be automated by an agent that can do the same. And engineers aren’t safe either. Those who only care about completing a task are already outperformed by engineers who think bigger and delegate the boring parts to LLMs.
The real bottleneck was always the pace at which we learn whether what we built actually matters, not the coding itself. Spitting out code at the speed of light won’t make any difference if you’re copycatting competitors or throwing features at customers who will never use them. Is the workflow improving? Are users sticking around more or churning less? Is anyone’s life any better? Unless we can measure some kind of impact, it doesn’t matter how much code we write. It’ll just be a huge waste of tokens and energy.
The PM role fills the vacuum left by a lack of clear organisational systems.
PMs aren’t going to disappear any time soon. Not because the role is essential, but because the organisational dysfunction that created the need for them is still everywhere.
Think about why most companies hired PMs in the first place. Not because someone read Inspired and had a revelation, but because the org had no clear strategy cascading down to teams, engineers had no access to customers, there were no decision-making frameworks, and nobody knew who was supposed to decide what, so everything escalated. The PM role emerged to fill an organisational vacuum, not to solve a product problem.
This is why the “just remove PMs” take is naive. Spotify tried to decentralise product ownership with its squad model, and the result was well-documented chaos: squads with autonomy on paper but no real decision-making power, alignment meetings that replaced the old coordination meetings, and a matrix structure that nobody could navigate. As Jeremiah Lee wrote in his insider account, “Spotify doesn’t use the ‘Spotify Model’ and it never truly did.” The model looked great in a blog post, but the underlying culture didn’t change. Removing the coordination layer without replacing what it was coordinating just created a different kind of bottleneck.
The uncomfortable truth is that many companies still have departments that don’t talk to each other, leadership that won’t delegate, and builders who aren’t empowered to make their own decisions. As Cagan puts it, when you ask leaders why they don’t empower their teams, “the answer typically boils down to trust.” Someone has to manage that mess, and PMs learned to do it very well. Not because they wanted to be Jira monkeys, but because the alternative was nobody doing it at all. Politics, my friends, politics.
So before we talk about what PMs should become, we need to be honest about why they exist. Fix the system first. Then the role can evolve.
From Jira monkeys to context managers
For the PMs who survive the shakeout, the role looks nothing like what it is today.
PostHog didn’t have PMs for a long time, and I love how they frame the role: “We think of PMs as the team’s compass. They don’t decide the destination, but they provide information to let the team know if they’re headed in the right direction.” Their CEO James Hawkins, goes further: “PMs exist to empower the engineers, not control them.”
This is the shift. Having one person responsible for dozens of product initiatives, from discovery to development to measuring outcomes, is not feasible. It never was, and pretending otherwise is what created the bottleneck in the first place. As Andrew Ng recently put it, “Engineers are 10x faster. Product managers haven’t sped up at the same rate. Now they’re the bottleneck.”
Decision-making has to sit with the people building. Each builder owns a piece of the product and works towards an outcome with real autonomy. The PM’s job becomes making sure decision-makers have the right information to decide well, curating context rather than hoarding it.
And here’s where it gets uncomfortable for PMs. Even the context management work is being automated. Else van der Berg argues that off-the-shelf AI tools for PMs will soon outperform any hand-crafted system, acting “like a senior consultant” that matches frameworks to specific contexts, self-evaluates its reasoning, and crucially, does it all without human bias. As she puts it, we fall in love with ideas, over-index on recent information, and take shortcuts that compromise judgment. AI doesn’t have that problem.
The discovery work that PMs consider their core value, customer research analysis, pattern recognition across feedback, and competitive intelligence, is exactly the kind of work LLMs are built for. Humans still have the edge in collecting data, talking to users, observing behaviour, and reading the room, but that’s a much smaller job than most PMs currently hold.
Engineers aren’t the only ones automating themselves out of their jobs. But at least engineers who think about the product have somewhere to go. PMs who only knew how to manage a process are staring at a gap that’s closing fast. Gartner predicts that by 2026, 20% of organisations will use AI to flatten their structure, eliminating more than half of current middle management positions.
The bottleneck was never code
The PM role as we know it was a big mistake. Not because product management doesn’t matter, it matters more than ever, but because we handed it to a single person and called it a job. We took the most important work in product development, understanding the customer, making decisions under uncertainty, choosing what to build and what to kill, and funnelled it through one bottleneck, then wondered why everything was slow.
Code was never the constraint, and AI just made that impossible to deny. The constraint was always how fast we could learn, decide, and adapt. That can’t be one person’s job.
The PMs who get it will evolve into something more useful than they’ve ever been, context curators who make everyone around them smarter. The ones who don’t will find that AI is a more efficient Jira monkey than they ever were.
For engineers, this is the moment. The wall between “building” and “deciding what to build” is coming down. You can stay on the execution side and wait for tickets, or you can step into the fog and own the outcome. The tools are already there, and the org structures are shifting. The only question is whether you want to be the person who ships code or the person who ships products.
And if you’ve been waiting for permission to care about the product, you never needed it.
Key takeaways
The PM role emerged to fill organisational gaps (no strategy, no customer access, no decision frameworks), not to solve a product problem.
Centralising product decisions in one person created a bottleneck that slowed learning, diluted information, and turned engineers into executors.
AI didn’t create the bottleneck — it exposed it. Engineers are faster, but PMs haven’t sped up at the same rate.
Removing PMs without fixing the underlying dysfunction just creates a different kind of mess. Fix the system first.
The PMs who survive will shift from owning roadmaps to curating context. The engineers who thrive will step into product ownership.