I was watching Office Space the other night. There's this scene where the Bobs are interviewing Tom, the product manager. They're trying to understand what he does there. Tom's (frustrated) answer is that he takes the specs from the customers and brings them to the engineers.
That film is from the late 90s and it captures some of what a PM does. But it did get me wondering about how the product role evolved through the decades and reflecting on what may be coming our way.
The short of it is: the role tends to absorb whatever the organisation can't figure out where to put. Marketing coordination in the 70s. Technical translation in the 80s. Requirements docs in the 90s. Agile ceremonies in the 2000s. Outcome ownership in the 2010s. Presently PMs are expected to understand AI model capabilities, orchestration logic, etc.
The interesting thing for me though, is that role kept getting more technical because the handoff model keeps changing. In my days, agile got rid of the clean(ish) boundary between "define" and "build". When you're shipping daily (or at least intending to), you can't just write a spec and walk away. There are hundreds of micro decisions/trade-offs to be made in very tight timeframes, you've got to stay engaged.
Something had to give though, and we lost nearly all the commercial stuff PMs used to own, which quite frankly is still very exciting stuff: positioning, pricing, distribution, partnerships. All this quietly moved elsewhere. In larger companies, (product) marketing took positioning; growth teams took pricing/distribution; BD took partnerships.
Something had to give though, and we lost nearly all the commercial stuff PMs used to own, which quite frankly is still very exciting stuff: positioning, pricing, distribution, partnerships. All this quietly moved elsewhere. In larger companies, (product) marketing took positioning; growth teams took pricing/distribution; BD took partnerships.
Now with agentic AI coding, the IC-level product manager is about to profoundly change again.
If you can describe/iterate to what you want built, you can build it without waiting for someone to translate your intent. The prompt is the spec.
Here's the typical loop for an IC PM: talk to customers, write a PRD, hand it to engineering, wait, review, iterate. That loop had a very clear handoff point. You do the thinking, someone else will do the building. But if the PM can go from insight to working thing directly, why does that handoff need to exist?
That said, engineering and design won't disappear in this world but I think they shift.
Instead of being the primary builders, they become the people who define the constraints and quality gates for AI-generated outputs. Engineers write the guardrails. Designers define the interaction principles. These both become the "system prompt" if you will, for the coding agent.
And they're arguably more critical now, because output volume goes up and someone has to make sure it's good.
But the day-to-day act of translating a PM's intent into code or mockups? I think it'll be gone.
If you can describe/iterate to what you want built, you can build it without waiting for someone to translate your intent. The prompt is the spec.
Here's the typical loop for an IC PM: talk to customers, write a PRD, hand it to engineering, wait, review, iterate. That loop had a very clear handoff point. You do the thinking, someone else will do the building. But if the PM can go from insight to working thing directly, why does that handoff need to exist?
That said, engineering and design won't disappear in this world but I think they shift.
Instead of being the primary builders, they become the people who define the constraints and quality gates for AI-generated outputs. Engineers write the guardrails. Designers define the interaction principles. These both become the "system prompt" if you will, for the coding agent.
And they're arguably more critical now, because output volume goes up and someone has to make sure it's good.
But the day-to-day act of translating a PM's intent into code or mockups? I think it'll be gone.
Like many others, I'm trying to read the tea leaves here. I don't know exactly what this role looks like in 2027.
The trajectory is kind of clear though. The product manager who only coordinates, who takes specs from customers and brings them to engineers.... I think this is done.
I reckon the value will move to folks who can hold the full picture in their head (the customer problem, the technical possibilities, the commercial logic) and the ability to actually make things.
So in summary: the product role as it is today will (likely) be gone soon. Obsessing over PRDs and user stories is wasteful and that time will be better spent delivering something more durable.
The trajectory is kind of clear though. The product manager who only coordinates, who takes specs from customers and brings them to engineers.... I think this is done.
I reckon the value will move to folks who can hold the full picture in their head (the customer problem, the technical possibilities, the commercial logic) and the ability to actually make things.
So in summary: the product role as it is today will (likely) be gone soon. Obsessing over PRDs and user stories is wasteful and that time will be better spent delivering something more durable.