When Building is Easy

#145 - Why product decisions, and not execution, are the new bottleneck

Hello friends! I hope you had a great week!

Last week I was scrolling through twitter and as often happens to me I stumbled on this tweet (and youtube video) that got me in a rabbit whole about a topic that’s very relevant for my work: what is the future of the Product Manager, in tech companies?

A couple years ago, the talk in tech circles was clear: Product Managers were on their way out. The argument was simple: engineering tools were improving fast, AI was starting to automate repetitive tasks, and “full-stack ownership” meant developers would handle everything—from customer insights to launch. PMs were framed as a coordination tax.

I wrote a post back then to push back against that view. My argument was that the PM role wasn’t disappearing—it was just changing. The best PMs weren’t schedulers. They were business people. Owners. Translators of ambiguity into direction. What looked like redundancy was often misidentified judgment.

Now, in 2025, the landscape has shifted again. But not how most people expected.

Engineering speed has exploded thanks to AI. Prototypes that used to take weeks now take days—or hours. AI coding assistants are changing the pace of what teams can ship. But product thinking hasn’t sped up in the same way. If anything, it’s become more central—and more exposed. The bottleneck isn’t execution but rather clarity.

The coordination-tax PM might be gone. But the judgment-driven PM (the one who owns the problem, understands the user, defines the bet) might be the last useful layer of abstraction left.

What happened to the old prediction?

In 2021–2022, it seemed obvious: the Product Manager role was on its way out. No-code tools were gaining traction, engineers were becoming more “product-minded,” and AI was starting to automate repetitive planning tasks. The coordination layer, already viewed by some as overhead, looked ripe for elimination.

Engineers, empowered by better tools and faster feedback loops, would handle everything—from customer insights to production code. PMs were framed as a workaround for organizational friction. Once the friction disappeared, so would the role.

And yet, that’s not what happened.

Yes, prototyping has become faster. Shipping has become cheaper. Tools like ChatGPT and Canva have shrunk the gap between idea and demo. But the effect wasn’t to make product management disappear. It was to reveal what the job actually is.

It turns out that moving fast only helps if you’re pointed in the right direction.

And pointing teams in the right direction is still hard. You still need to make tradeoffs, read weak signals, and explain why building X matters more than building Y even if both could be shipped tomorrow.

Andrew Ng noted this in his recent talk, observing how team structures have flipped: from 1 PM per 4 engineers to, in some cases, 2 PMs per engineer. Not because PMs are slow. But because engineers are now so fast that choosing what to build, and why, has become the actual bottleneck.

Speed Kills, But in One Direction Only

Engineering velocity has broken out of the old loop. AI tools like Copilot, Cursor, and Claude can now turn vague prompts into working prototypes within hours.

When shipping becomes cheap, the instinct is to try more things. More tests, more variations, more parallel bets. That’s great in theory, but only if the rest of the system can keep up.

While engineering scaled horizontally, product work didn’t. A single PM still has to do the slow parts: synthesize feedback, evaluate tradeoffs, decide what not to build, and write things down in a way that keeps a growing team aligned. The result is a weird dynamic inside teams: execution is accelerating, but clarity is under strain.

Most of what a PM does (defining problems, aligning incentives, reasoning about user behavior) isn’t parallelizable. It doesn’t get 10x faster just because the code does. If anything, the faster the builders move, the more exposed the thinking becomes.

The old assumption was that engineering was the constraint. And when it was, PMs could stay upstream debating positioning, shaping strategy, doing customer discovery. But now, with engineers waiting on decisions instead of blockers, PMs are being dragged downstream into triage.

Why Product Is Still a Human Job

AI made the boundary between engineering and product more obvious.

Before, it was easy to conflate shipping with thinking. You could assume the person writing the code probably understood the user, or that the person writing the spec was mostly just feeding requirements into a machine. But now that AI can do both (generate working code and spit out plausible specs) it’s easier to see what those things actually aren’t.

They aren’t decisions. They aren’t tradeoffs. They aren’t bets.

This is why product work hasn’t been absorbed by engineering and why it likely won’t be. Because even as PMs gain hands-on tools (building prototypes, writing prompts, querying data without help), the core of the job hasn’t moved. The challenge isn’t getting a first version out. It’s deciding what matters in the first place.

Also in a world of AI, infinite resources and zero marginal cost, frugality is still the core. Deciding where to invest, what to build, where to focus is the key task that is still highly human and hard to automate.

That work sits upstream of AI’s strengths. It’s often vague, slow, and highly contextual. It involves conversations that aren’t logged, incentives that aren’t written down, and constraints that aren’t documented. AI can assist in the process, but it can’t hold the whole picture.

This doesn’t mean PMs are safe by default. If anything, the baseline has risen. The “mechanical” side of product is now trivial to automate. What’s left is harder to fake: synthesis, communication, ownership.

The Return of the Full-Stack PM

There’s a popular image of PMs as connectors linking design, engineering, and business. That version of the role made sense when communication moved slowly and execution was the bottleneck. But now that teams can build faster than ever, what PMs are really doing is holding the narrative together.

Because speed without alignment breaks things. Teams move in slightly different directions, assumptions drift, and two months later you’re launching something nobody asked for.

This is where PMs matter most: not in writing the specs, but in defining the story. What problem are we solving? Who cares about it? What will success look like?

In the video Andrew Ng argues that the job of a PM is to communicate relentlessly this narrative. To engineers. To designers. To marketing, legal, finance, customer service. The faster the team, the tighter that message needs to be.

It’s not glamorous work. It’s not always visible. But it’s foundational. AI can help you mock up the feature, run the experiment, and write the copy. But it can’t unify the team behind a clear point of view. It can’t resolve internal tension with a well-timed conversation. It can’t align ambition with execution.

The PMs who thrive in this environment aren’t the ones who do a bit of everything. They’re the ones who make sure everyone else is doing the right thing, in sync, without confusion. Communication becomes the architecture that holds velocity together.

Direction Over Speed

The rise of AI has changed how teams work and, potentially even more importantly, where the leverage sits. When building is fast and cheap, value shifts to the upstream layer: the decisions about what to build and why.

That shift isn’t limited to tech. It shows up anywhere execution has been commoditized. In media, content production is near-instant, but distribution and relevance still require judgment. In consumer goods, it’s easy to launch a new DTC brand, but hard to make one that people care about. Even in finance, capital is abundant, but finding high-quality opportunities to deploy it isn’t.

The same pattern repeats: speed and scale increase downstream, while the upstream decision layer becomes the choke point.

That’s the layer PMs operate in. Or at least, the good ones do.

Their job isn’t to keep things moving but to make sure what’s moving is worth doing. It’s to define the problem clearly, surface the tradeoffs early, and ensure that what gets shipped works for the right reason.

Ultimately this is a form of capital allocation. One that also requires taste and judgement.

In a world where anyone can build faster, the advantage belongs to those who can choose what’s worth building at all.

Have a great weekend!
Giovanni