The Next Version of Product Management

Image: “Vibrant Cyberpunk Hacker Art” by Easy-Peasy.AI, licensed under CC BY 4.0

I think a lot of product managers are going to struggle in the next few years. Not because they’re not smart or hardworking (most PMs I know are both), but because the thing that made them valuable is quietly being automated away, and what replaces it requires a fundamentally different mindset.

I’ve been thinking about this a lot lately. As someone who came up through the technical side before moving into product, I have a particular view on where this is all heading. I’ll admit my perspective is shaped by where I sit, but I reckon the patterns are pretty clear if you’re willing to look honestly at them.

The Busy Work Is Going Away

Let’s start with the uncomfortable truth. A huge chunk of what PMs have historically done, user research synthesis, data sifting, writing PRDs, compiling competitive analysis decks, tracking metrics, is either already being automated or will be within the next couple of years.

I’m not being dramatic here. When I look at what AI tools are doing to the research and analysis layer of product work, it’s genuinely striking. The manual hours that used to justify a PM’s week are disappearing fast. Dhanji R. Prasanna, CTO at Block, talked on Lenny’s Podcast recently about what his engineering teams are already seeing:

“Eight to ten hours saved per week… trending towards 20 to 25% of manual hours saved.”

— Dhanji R. Prasanna, CTO at Block, Lenny’s Podcast

That’s engineering, the people we’ve always considered the most technically irreplaceable. If it’s happening there, it’s absolutely happening in product.

Tomer Cohen, LinkedIn’s CPO, put it well when he talked about what it actually means to lead product in an AI-first world:

“You’re used to deciding every part of the dish. You’re deciding everything from the ambiance to the temperature of the broccoli and then this new technology comes in and says, just give me the ingredients, give me the guidelines of how you cook and now I’ll take care of it.”

— Tomer Cohen, CPO at LinkedIn, Lenny’s Podcast

That changes everything about where a PM actually adds value.

So if the busy work goes away, what’s left? Judgement. Taste. Conviction. And the ability to actually build.

The Builder Mindset Is the Only Mindset That Matters

The PMs who will flourish in this next era are the ones who’ve always wanted to build things, the ones who came from engineering, design, or data backgrounds and moved into product because they wanted a broader canvas, not because they wanted to manage stakeholders and run stand-ups.

Boris Cherny, who created Claude Code at Anthropic, made a point recently that I think will age very well:

“Today coding is practically solved… We’re going to start to see the title of ‘software engineer’ go away. It’s just going to be ‘builder’ or ‘product manager.’”

— Boris Cherny, Anthropic, SF Standard

That’s a significant shift in how we think about roles. And Aneesh Raman, LinkedIn’s Chief Economic Opportunity Officer, described what it looks like in practice:

“The full stack builder takes what would’ve been days or weeks as a conveyor belt between design, product, engineering… and gives it to an individual with these [AI] tools.”

— Aneesh Raman, LinkedIn, SF Standard

Elena Verna, who now leads growth at Lovable, has been talking openly about how vibe coding has transformed how she works:

“It’s taking me on a product development lifecycle so much further down. And then it creates a much better communication vehicle with my engineers too, because I then can tell them exactly what’s important and whatnot… it calibrates me really quickly.”

— Elena Verna, Head of Growth at Lovable, Lenny’s Podcast

That’s the point. A PM who can prototype, who can get their hands dirty, who understands the technical trade-offs, that person is suddenly not just a conduit between design and engineering. They make everyone around them sharper.

I’m not saying every PM needs to be able to write production code. But the builder mindset, the instinct to make something rather than just describe it, to validate ideas through doing rather than decks, that matters enormously now. Tomer Cohen again:

“When I look at great builders, they’re all very distinct, they’re all different.”

— Tomer Cohen, CPO at LinkedIn, Lenny’s Podcast

It’s not one formula. But there’s a common thread of people who care about the craft of making things.

The natural pipeline for this? Engineers who move into PM roles. Designers who expand their scope. Data scientists who develop product intuition. These folks have always existed, but their moment has well and truly arrived. If you’re a PM who’s never been close to the technical work, never built anything yourself, never had to understand why something was hard to implement, I’d genuinely encourage you to close that gap while you still can.

You Can’t Automate Judgement

Here’s what gets glossed over in a lot of the “AI will replace PMs” conversation. Even if you’ve got a flood of AI-generated insights, prototypes spun up in minutes, and data analysis that used to take a week now taking an afternoon, you still need someone to decide what to do with all of it.

That’s where the real scarcity is. Not research capacity. Not execution capacity. Judgement.

Sal Khan, founder of Khan Academy, framed it well:

“The people who are just waiting to get the spec… they’re going to have trouble. But the people who are like, ‘I’m going to go meet with the customer, and I can build it,’ I think they’re going to do great.”

— Sal Khan, Khan Academy, SF Standard

Aishwarya Naresh Reganti, who works in AI at OpenAI, made a related point on Lenny’s Podcast about where successful people focus:

“Folks that are successful are incredibly obsessed about understanding their workflows very well and augmenting parts that could be ripe for AI versus the ones that might need human in the loop somewhere.”

— Aishwarya Naresh Reganti, OpenAI, Lenny’s Podcast

Knowing where to apply the tool versus where to apply the human, that’s a kind of wisdom that doesn’t come from a prompt.

And Molly Graham, who built planning systems at Meta and Google, was characteristically direct about what strategy actually requires:

“Strategy should hurt. If you’re not making trade-offs that are painful, you are not actually helping people prioritise their time.”

— Molly Graham, former Meta/Google, Lenny’s Podcast

That’s not something AI solves for you. That’s the hard, uncomfortable, deeply human work of saying no to things that are also good.

You Can’t Throw Experiments at Your Customers Forever

This brings me to something I feel strongly about and don’t hear said enough: the era of endless experimentation has real limits, and we’re approaching them.

I’ve seen it at Elastic. I’ve seen it at companies I admire. When you lower the cost of shipping features to near zero (and AI is very much doing this), there’s a temptation to just ship everything and let the data decide. Run the experiment. See what makes a difference. Iterate. Repeat.

The problem is your customers aren’t lab rats. At some point, the constant churn of changes, the relentless A/B testing, the features that appear and disappear, it erodes trust. It degrades the coherence of your product. And it quietly damages your brand in ways that don’t show up in your short-term metrics.

Matt MacInnis, CPO at Rippling, talks about the discipline of deliberate constraint:

“It is really important to me that we feel that we’ve deliberately understaffed every project at the company. If you overstaff, you get politics, you get people working on things that are further down the priority list than necessary. That is poison.”

— Matt MacInnis, CPO at Rippling, Lenny’s Podcast

There’s a wisdom there that applies beyond headcount. If you can do everything, you have to work harder to decide what you should do.

Dylan Field, CEO of Figma, made the point even more sharply when talking about quality in the AI era:

“If you lose the art and you’re just solving the problem, it’s totally utilitarian and it lacks soul.”

— Dylan Field, CEO of Figma, Lenny’s Podcast

I think about this a lot. In a world where software is cheap to produce and experiments are cheap to run, the differentiation moves upstream, to taste, to coherence, to the deliberate choices you make about what your product stands for.

The winners in the next wave won’t be the teams that ship the most experiments. They’ll be the teams that invest their engineers’ time on the right things and have the conviction to hold the line on everything else.

What This Means Practically

If I had to distil this into something useful for PMs trying to navigate the next few years, it’d be this.

Get closer to the build. Not just in meetings with engineers, but in your own understanding of how things work. Learn to prototype. Understand the technical constraints. Close the gap between what you imagine and what’s actually possible.

Obsess about judgement, not process. The process is increasingly automatable. What isn’t is knowing which insight matters, which trade-off is worth making, which customer pain actually matters to the business. That takes deliberate work to develop.

Treat your customers’ attention as finite and precious. You can ship faster than ever. That doesn’t mean you should change more than ever. Coherence is a product value. Trust is a long-term asset. Don’t gamble it on the wrong experiments.

Develop real conviction. Nicole Forsgren, who created the DORA metrics framework, put it bluntly:

“Most productivity metrics are a lie… it’s just too easy to game that system and then introduce complexity and technical debt into all of the work that you’re doing.”

— Nicole Forsgren, Lenny’s Podcast

The same is true of product metrics. Having the confidence to back a decision based on genuine understanding of your customers, rather than chasing the metric that moves easiest, is increasingly rare and increasingly valuable.

I don’t think product management is going away. But the version of PM that survives will look quite different from what it looked like five years ago. Less coordination, less synthesis, less process management. A lot more building, judging, and deciding.

The best PMs I’ve worked with have always had that quality. They’re people who genuinely want to make things. Builders who happened to move into product, not administrators who learned to talk to engineers.

That’s the PM who thrives from here on in. And honestly? I think it’s a better version of the role anyway.