AI Is Turning Product Managers Into Architects. Nobody Asked Them.
Six months ago, you were a product manager.
You interviewed customers, analysed cohorts, argued about priorities, and spent an unreasonable amount of time convincing people that the feature they desperately wanted wasn't needed. You wrote specifications, worked with designers, and negotiated with engineering about what could realistically ship this quarter.
You understood your job.
Then someone gave you Claude. Now you can analyse customer data in minutes, generate specifications in seconds and build a working prototype before lunch. Wonderful. Except your CEO has noticed too, and suddenly you're expected to produce prototypes by the dozen. The one you built on Tuesday is apparently going into production, and it's only Thursday.
Congratulations, you're almost a developer now.
When building gets cheap, deciding gets expensive
For decades, product management was organised around one constraint: engineering capacity. Building was expensive, so deciding what deserved to be built mattered. When an idea becomes a working prototype in hours instead of weeks, the question changes. It's no longer what your team has time to build. It's what is worth building. (I hear what you are thinking "That should have always been the question!")
AI can generate twenty prototypes. It can't produce twenty validated customer needs in the same time span.
When execution becomes abundant, judgment becomes scarce. I made the same case about code in Coding was never the real work.
Design the space, not the screen
Traditionally a PM defines a feature, a designer shapes the experience, developers implement it, and the customer uses something we imagined in advance. Even personalisation works this way. Spotify recommends music and Amazon suggests products, but the objective is fixed beforehand.
Now imagine telling a music service: “I'm driving to Turin with my daughter tomorrow. I'd love to find something we can both enjoy listening to.”
You grew up on Pink Floyd and Dire Straits. She likes Billie Eilish and Olivia Rodrigo. A generative system could hear that you're not asking for a recommendation. You're asking for something to share, and compose a playlist that bridges the two. Nobody designed a parent-and-daughter road-trip feature. The system made one.
Then the AI might get a little too enthusiastic. It finds an artist you'd both love, performing in Las Vegas, and books two tickets. Very thoughtful... But you wanted something for the car.
That's where I believe product management is heading: away from specifying every screen and journey, towards defining the boundaries inside which useful experiences can emerge. What problems should the product solve? What can it access? What can it do? What needs explicit permission? How do we know the result created value? Those boundaries have to be real architectural constraints, not optimistic instructions in a prompt.
The product manager becomes the architect of possibility. The AI can improvise. We decide where the stage ends.
Sounds exciting. Unless you liked being a PM.
I talk about this move towards abstract, strategic work as though it were automatically a promotion. But think about why many people became product managers. They loved understanding customers. They enjoyed discovering unexpected needs and working out why something brilliant in a meeting made no sense to the people using it. Now their future is defining agent capabilities, designing guardrails and reviewing generated prototypes. Some will love it. Others will hate it. Many will miss the job they had. I wrote about the same thing happening to developers in We Turned All Developers Into Managers. Now What?
And there's a cruel irony. AI can summarise hundreds of customer interviews and surface the patterns. But if the time saved goes into more prototypes instead of more time with customers, what exactly did we improve? We risk making product development more automated and product managers less connected to the people they exist to understand.
Build strengths, don't repair weaknesses
On my mentoring page I write: build strengths, don't repair weaknesses. AI transformation can push an organisation to do exactly the opposite: abandon the strengths that made someone good at this job and build a different professional identity, quickly.
Good PMs aren't short on curiosity or comfort with ambiguity. The problem is pace. Someone who spent years becoming excellent at discovery, strategy and prioritisation is now expected to become fluent in AI-assisted development and autonomous systems. Just as they get comfortable, the next generation of tools arrives. Leadership celebrates the acceleration, more prototypes, more experiments, more features, as if generating software faster meant people could understand and learn from it faster. They can't. And the pressure to keep producing eats the very time people need to build the judgment we're now telling them matters most.
There's a tension on the other side too: your users. They can't absorb that much change in that little time either. So the PM's job, in a sense, stays the same: deciding what not to build. Only the reason is different. It used to be a delivery constraint. Now it's an absorption constraint on the end user's side.
Some PMs will become exceptional at designing generative systems. Others will thrive on rapid experimentation. Some will stay invaluable because they understand customers better than anyone. You need all of them. The leader's job is to understand what makes each person valuable and how that strength fits what you're building, not to announce that the profession they loved no longer exists.
You can redesign the role around whatever AI makes possible this month, but it only works if the person in it would have chosen it.