The future of Product Managers
A take on the future of PMs from people deep in agentic engineering
A product leader we know has 15 years of experience shipping developer tools. He spent a decade at a household name. He is, genuinely, one of the best product minds we’ve encountered in this industry.
He can’t get a conversation for a group PM role.
That is a signal, not a market blip.
We’ve spent a lot of time talking about what AI is doing to engineers – how one developer with the right tools now ships what used to require a team of five. But we had an adjacent question: what happens to product managers?
Shipping isn’t a funnel anymore
For years, software development worked like a funnel. PMs turned customer insights into specs. Engineers turned specs into code. The funnel created a natural place for the PM to sit – upstream, owning the translation layer.
Shipping was expensive. So you needed someone to decide what was worth shipping.
That’s no longer true. Shipping is close to free now. So what is a PM’s role now that the funnel has collapsed and PMs aren’t filtering a very costly resource (engineering time)? Is there still a place for PMs in this new world?
As former PMs ourselves, we’re watching this shift from two very different vantage points. At Kilo, there are about 40 people and one PM. We operate with a WAUzer (Weekly Active User) model – every engineer owns a single product area and is accountable for the weekly active users in that area. Every Monday, Evgeny would stand up for two minutes: here’s what I did on cloud agents, here are the numbers, here’s my target for next week. He was fast. He was accountable. And across those product areas, we saw roughly 10% week-over-week growth.
The product hat shifted to engineers. And it worked.
But, it didn’t work everywhere – the VS Code extension had too much surface area for one engineer to own clearly. So we brought in Josh. He runs a pod. He decides what gets built. Traditional PM model.
At Solo (Asher’s company), it’s just two people – one developer – moving at a pace that would have required a team of 10 three years ago. No PM at all. No coordination layer. The product question and the building question sit with the same person.
Two different experiments. Same conclusion forming.
It’s always been vibe coding
“PMs were the original vibe coders. We wrote the spec, and the engineers were our LLMs.”
That framing came out of a conversation between us. Because if the spec-to-code handoff is getting absorbed by AI tooling – if engineers can hold the product context and build without a translation layer – then the PM role has to move. The question is where.
We see two paths forward.
Path one: shift left toward go-to-market.The thing that’s genuinely hard, even in an AI-native company, is knowing what to build. Not technically – but commercially. What will people pay for? What problem are we actually solving? Who is the buyer, and do we have them before we build?
That’s where PMs might land. Not writing specs, but sitting closer to sales, customer research, and market discovery to orchestrate the product strategy and business rational for building a feature. A big portion of the PM’s role will be saying no to features to prevent bloat and identify customers who are willing to pay for features before building it.
Path two: the long thin layer – engineers who wear the product hat. Each engineer owns their area completely. Customer conversations, support, metrics, roadmap decisions – all of it. No handoff, no telephone game.
The upside is accountability. The downside is that it requires people who can go wide – technically sharp AND commercially minded AND customer-facing. That’s a rare profile. And at some point, a customer doesn’t want your one thin area. They want the whole package.
Both paths are real. You’ll see companies betting on each.
The traditional shipping funnel is gone. It’s dead in startups now and will die in F100s over the next 5 years. The people who figure out the new shape of product ownership – whether that’s engineers, PMs who’ve shifted left, or something we don’t have a name for yet – are the ones who’ll be standing in three years.
The senior product leader we mentioned will land somewhere. His experience is real. But the role he’s looking for may not look like what it used to. The best thing any PM can do right now is stop waiting for the old model to come back and start experimenting with new models.
Developers are working in the future. PMs need to join them.
 | A guest post by
|
"With great speed comes great responsibility ... or something"
It's now so much faster to build garbage features that no one needs or can even find in the product. Your path 1 is where PMs have lived for years. PMs are intentional friction to make sure you are building the right thing aligned to your company business goals.
Yes the cost to build has gone down, so that means you can use some of that regained time to focus on quality. This is your differentiator because your product probably doesn't need the 100 different things people have asked you for this week. Plus there is still a complexity cost down the road to building all of these frivolous features. Don't get fooled into thinking you aren't just baking in the tech debt.
Use your new speed to lean into quality outcomes, not speedy output.
“PMs were the original vibe coders. We wrote the spec, and the engineers were our LLMs.” I love that line, however I know a few engineers that would scoff at that. I had retired just before my company started converting Business Analysts into PMs, and right before AI took off. Back then, it felt like the funnel was already squeezing out BAs who focused solely on requirements.
As a BA, I treated requirements written clearly enough to stand alone, sometimes almost executable. When PMs moved toward strategy and engineers absorbed more product ownership, that standalone requirement's role seemed to be fading into product management. But with LLMs now turning well-formed specs directly into working systems, I wonder if this actually revives the BA craft. If AI can build from clear intent, then producing precise, validated requirements may become more valuable again not less.