The Product Manager in the Age of Agents: A Job for Ambassadors of Common Sense

I teach on a postgraduate programme in IT product management at WSB Merito University in Gdańsk. Every time I prepare a new edition of the material, I hesitate several times over where to put the emphasis.

A few years ago the story about the work of a Product Manager and a Product Owner was stable. We talked about the process from discovery to delivery, about the triple diamond, about agile methods and frameworks, about prioritisation techniques, about organising your own work and the team's.

Then came ChatGPT, then multimodal models, and today we talk about agents, how to organise their work, and integrations such as MCP. These tools have changed the work of the PM and of everyone who builds a product. The hesitation came from a simple question: what exactly should I teach people entering the profession now?

Below are a few observations that came out of it. This is my perspective as a lecturer and a practitioner, backed by the reports I use in class.

Three stories about the PM role

Three positions collide in today's discussion about the Product Manager role. When reading the quotes, it's worth checking the context they were said in and the organisation the author comes from, because behind a statement there is often the perspective of a specific company or product.

First: the role is over. Claire Vo, founder of ChatPRD, said it loudest:

"Product management is dead or it will be soon."

Source: Claire Vo, "Product Management Is Dead, So What Are We Doing Instead?", Lenny & Friends Summit (2024)

Her argument: since tools have taken over so many tasks and processes are changing, the role as defined over the last few years is losing its meaning.

She is not alone. Nurkhon Akhmedov, who describes how much of his own PM work he has already handed to AI, cites the 2026 CPO Insights Report from Products That Count and Mighty Capital: a survey of more than 1,500 product leaders, announced by its authors under the headline that the PM role in its current shape will disappear by 2030. That is the authors' forecast, not a finding. He reaches a different conclusion himself: the profession will survive, but many PMs will not.

Second: the roles stay, only amplified. We still have the Product Manager, the Designer and the Engineer, the classic Product Trio. It doesn't matter whether that is three people or more. What matters is that three areas of responsibility work together and AI speeds up each of them. Marty Cagan's answer here is conditional: hard years await the product owner who minds the backlog and the PM on a feature team, while the PM responsible for the value and viability of the product gains. Dan Dalton of Sage put it more sharply still, on one slide of his #mtpcon London talk: product managers are being replaced, but not by AI; by people who think before they use it.

Third: the boundaries between roles blur. The PM becomes a bit of a designer, and in some organisations also a developer. Beyond discovery, they take on prototyping, usability testing and sometimes the first version of the code that the engineering team then works with. Vo calls such people "AI-powered triple threats". Cagan writes about the era of the product creator, which he defines as anyone actively shaping the product and tackling its risks, designers and engineers included; he is careful to add that he is not suggesting a single creator on most products. Bruce McCarthy goes furthest, with the Product Builder era: one accountable person who leads a small team supported by AI and answers for the business outcome.

These are no longer just declarations. LinkedIn closed its Associate Product Manager programme and replaced it with an Associate Product Builder track, which teaches product management, design and coding at the same time.

McCarthy also recalls Brian Chesky's announcement that Airbnb is moving away from the classic PM role. He notes that Chesky in fact described the job good product people always signed up for: understand the customer, understand the business and answer for growth. That is an important observation. All three stories argue about the scope of the role, not about its existence.

What the job market shows

Job posting data shows which role is actually shrinking. In Lenny Rachitsky's latest report, the number of open PM vacancies at tech companies, around 7,300 today, is 56% higher than in January 2023. There are around 1,900 product design vacancies, the lowest since measurements began, and UX research has a little over a hundred left. Today there are 3.8 PM vacancies for every design vacancy, against 1.9 at the start of 2023.

Piotr Palarczyk, commenting on these figures, sees in them the third story materialising: the "builders" are having their moment. He adds two caveats. Design is often treated as secondary today because AI does it "well enough", but against a background of widespread mediocrity the products that stand out will be the ones with an outstanding user experience, and those need very good designers. The market also follows fashion closely: the number of postings for Forward Deployed Engineers grew 4.6 times in a year, to around 1,450, although similar roles have existed in companies for a long time under other names.

Design, meanwhile, is not so much disappearing as changing shape. Aneta Kmiecik, who recruits designers for startups, points to four growing roles: design with a PM's responsibility for scope and roadmap, Design Engineer or Product Builder, Forward Deployed Designer working directly with the client, and brand. It's a mirror image of the third story: the PM absorbs design and the designer absorbs part of the PM's work. Kmiecik also goes against the grain of the "builder of everything" slogan. Since AI covers the basics, you have to be an expert in one thing: "Either you pick, or the market will".

Two caveats of my own. The report counts postings, not hires, and the postings show which titles companies are opening, not why: on their own they cannot say whether PMs are taking over designers' work or whether AI is the cause. That reading is Palarczyk's and Kmiecik's interpretation, and partly mine. What the numbers do say is that demand for PMs is there, while good ones are getting harder to find.

The weight of the work has moved left

If the role is changing, so is what the PM spends time on. Today it's easy to gather a lot of information, analyse it and decide that we'll take on not three but ten features. Everything can be quickly researched, measured and sometimes deployed straight away.

I've written about this before: the weight of product work in IT has moved to the left side of the process. Producing software is getting cheaper, and the question of what to build and how much of it is getting more expensive. Brian Balfour of Reforge describes this as a shift of the bottleneck: from whether we can build it to whether we should.

When effort stops being the constraint

This shows most clearly in prioritisation methods. In RICE, effort sits in the denominator. If effort fell by the same factor for every initiative, the ranking would not change at all; every score would simply be higher. What changes is the cut-off line: the question "what fits in the quarter" becomes a much less restrictive capacity limit, because far more fits. And effort does not fall evenly. In RICE it means the whole team's work in person-months, product, design and engineering together, as Intercom defined it, and what has become cheap is mostly the building, not the research, the rollout or the maintenance. So the ranking does shift, towards initiatives that were heavy to build and light on everything else. Jefferson Rabb of Business Insider therefore asks what replaces team capacity as the main criterion, and how much it will cost to quickly roll back what we have just cheaply built.

The risk is concrete. We can flood clients with features they themselves asked for, and the product gets heavier to use as a result. Felix Geelhaar of PandaDoc summed up the mechanism in one line: "The agent builds. Nobody asks." An engineer used to ask "why?" during the build, and that question was a free quality gate. Slow building protected us from a feature factory by accident.

The Sunday-evening demo

Paulina Grodzicka captured this change well on LinkedIn recently, returning to a slide by Piotr Michałowski from the Product Hive barcamp. She described a scene that probably every product team knows by now. A board member fires up a vibe-coding tool on Sunday evening, generates a working prototype and on Monday morning asks on Slack why it isn't in production yet.

Paulina recalls the questions that go unanswered at that point. Who will maintain this in six months? Who takes responsibility for data security, architectural consistency and the API bills? Who cleans up the technical debt that grows along with weekend creativity?

Ambassador of common sense

Paulina writes that the PM role is shifting towards being an "ambassador of common sense". I agree and add one thing: it is not about being the person who says no. Cagan distinguishes building in order to learn from building in order to earn. A prototype handles a few use cases, a commercial product hundreds. A prototype doesn't touch reliability, performance or resilience to failure.

The board's Sunday demo is therefore excellent learning material and should be treated as such: check which hypothesis it confirms and which it doesn't. Common sense here means a specific skill: saying out loud who takes long-term ownership of what came together in half an hour over coffee.

Prototype before document

The furthest-reaching version of this change was described recently by Aakash Gupta, author of the Product Growth newsletter, using the example of the Claude Code team at Anthropic. Boris Cherny, the creator of Claude Code, said his team doesn't start with a PRD or Figma mockups. Before releasing a feature it builds working prototypes instead; for agent teams, Gupta writes, they tried hundreds of versions before shipping. Cowork, a product for non-technical people, came about this way in around ten days. On that team, PMs, data analysts and researchers code too, and everyone has the same title.

Gupta calls the skill needed here "taste at speed". When a prototype takes 45 minutes instead of six weeks, nobody needs a document to get permission to explore. What's needed is someone who will look at fifteen working versions and point to the three worth shipping. The document changes its place in the process: it's written after the prototype and describes what we have already checked.

Where this model does not carry over

This is a team that builds a tool for developers and is itself its most demanding user. Gupta cautions that in large companies and mature products the PRD shouldn't disappear, because there, understanding the hypothesis and the measures of success is key. In regulated industries, with integrations and customer data, a 45-minute prototype settles very little.

Teresa Torres and Petra Wille go further and challenge the premise itself. In their conversation "Delivery Isn't Free" they note that what has become cheaper is building a single feature, not a production-quality product. Teams that treat coding agents as free end up with tangled code, a bloated product and a maintenance problem a few weeks later. They also reject the conclusion that since delivery costs nothing, all that matters now is taste, or only discovery.

"Taste" itself doesn't come from tools either. To reject most prototypes by noon, you have to understand the user, feasibility and the business model at the same time.

The trap: taking shortcuts

We already hand some tasks to tools, and that's fine, because what we hand over is mostly repetitive and boring. Instead of writing a user story or a Product Requirements Document from scratch, we take a sketch and a template, and the tool fills in the rest according to the organisation's standard and vocabulary, with the Definition of Ready and Definition of Done taken into account.

The trap begins when we hand over the thinking along with the writing. I see three typical shortcuts:

• A persona without interviews. The model will happily generate a persona with demographics and a quote. That is a proto-persona, which is to say a hypothesis. Nielsen Norman Group compared synthetic users with its own research and found their answers too flat to be treated as findings.
• A document without a decision. The PRD looks professional, but nobody has settled what we're cutting and why. The form has covered up the absence of a choice.
• An output I can't check. If I can't judge whether the result is good, I'm not automating work, I'm delegating risk.

Cagan has a bitter remark on this: a feature-team PM who automated their project management has automated the only thing they were being paid for.

Agents and ecosystems

The model makers at OpenAI, Anthropic and Google are consistently steering us towards agents. We are to manage them: specialised units that organise, carry out, execute and evaluate a process under our supervision.

From the business side, the point is to build ecosystems we get used to. The game is played on open standards (MCP and Agent Skills started at Anthropic, and competitors use them too), so the fight is not over the standard but over whose environment we spend our working day in.

For the PM, a new scope of work follows from this. The review "State of Agentic Product Manager in 2026" argues that the model has stopped being the product. The product is its surroundings: the tools we make available to the agent, the context we assemble for it, the evaluations that define what "works" means, and the limits on what it may change. That is design work which in many companies doesn't yet have an owner.

Lock-in is still ahead of us

For now, from what I see on LinkedIn, every few months some people switch from Codex to Claude, then to Gemini. Others build or use tools that connect different providers and assemble a model-agnostic ecosystem that can also use local, open-source models.

That is my bubble, not the whole profession. In this year's Product Focus survey, two thirds of those who use AI use ChatGPT (66%), followed at a distance by Microsoft Copilot and Gemini. Most product people work in whatever the company bought.

Choosing an ecosystem is also a decision about risk. A team whose entire work depends on a single model provider stands still when that access disappears for whatever reason.

AI across three diamonds

Whatever models we use today and whatever we use tomorrow, part of the Product Manager's work will consist of using their potential at every stage of the process. In Paweł Huryn's Triple Diamond framing, those are three diamonds:

• Problem discovery: from understanding the market and users to choosing the opportunity worth pursuing.
• Solution discovery: from ideas, through prototypes and experiments, to a validated solution.
• Delivery: from building, through rollout, to measurement and the lessons that feed back into discovery.

What PM skills focus on

In the best-known catalogue of PM skills I use, nearly half concern delivery and go-to-market. I checked this on Paweł Huryn's PM Skills Marketplace, which listed 68 skills when I went through it in November 2026; the repository keeps growing, so the count may differ by the time you read this. The split into stages is mine.

Three caveats before reading too much into it. A count of skills says nothing about how often they are used. One catalogue is not the market. And whether a PRD, an A/B test analysis or a GTM plan belongs only to delivery is arguable; I put them there because that is where they are used, not where they are decided.

This distribution matches how PMs actually use AI. In Atlassian's report, 60% use it for product documentation and only 23% for managing shifting priorities. In ProductPlan's report, discovery is dominated by summarising customer feedback (47.1%), while 14.3% of teams prioritise customer problems with AI's help.

So AI has gone where the output has a known format and is easy to check. The least covered part is the middle of the process: which opportunity to pursue and which solution to reject.

More people report gains in productivity than in results

The most interesting number in this year's reports is the gap between 97% and 64%. In the Product Focus survey, 97% of product people say AI has improved their personal productivity. 64% see an improvement in product results.

ProductPlan asks about the benefit itself. Time saved on repetitive tasks leads (59.8%), more time for strategic work is named by 32%, and more confidence in prioritisation decisions by 11.5%. Atlassian adds a fact about the job rather than about AI: only 3% say they have enough time for every part of their role.

These are surveys, so they show declarations, not a measurement of the market. Two things about the samples matter for what follows. Product Focus is 83% European respondents, which is worth remembering when I complain later about US-centric analyses. Atlassian surveyed 700 people at companies of 500 to 10,000 employees, with a separate AI sub-survey of 521 product managers.

What else the reports show

• Time savings do not reliably turn into strategic work. According to Atlassian, 49% of respondents don't have enough time for strategic planning, and 49% not enough for data analysis. In Product Focus, firefighting is the most frequently named problem (58%), and 71% admit they spend too little time with customers.
• The barrier isn't in the tools. Only 4% consider AI tools too complex. The most common obstacles are a lack of integration with the way people work (46%) and a lack of trust in the results (45%).
• Verification rests on a human. 85% check AI output against their own knowledge and experience. Good news, as long as that knowledge is there.
• The Product Trio is still more a model than a practice. Only 20% of teams involve engineering from the idea stage. Since a PM can now click a prototype together alone, the temptation to invite engineers even later will grow.

Jenny Wanger described the last point well after a panel on the Product Trio: AI is still a tool for one person. Everyone solves their own piece faster, but separately, and the trio stops building together.

Who actually sets priorities

What puzzles me most in these studies is one thing: the Product Manager has the final say on product priorities in only 16.4% of organisations. That is what ProductPlan's report shows.

Other questions add up to the same picture. In one organisation in four, leadership sets the priorities and the team executes them. In another one in four, the PM proposes and leadership usually backs it. Product strategy is influenced most strongly by leadership decisions (57.8%), just ahead of customer needs (54.9%). In the Polish ProductCraft survey, 69.4% of teams choose problems based on stakeholder and leadership priorities, and 47.9% based on customer data.

The final say usually sits elsewhere

So the final approval most often belongs to someone other than the PM. That does not mean decisions are made without PMs: the same report shows PMs proposing and leadership approving in a quarter of organisations, and the trio deciding jointly in 6.1%. The PM shapes the decision more often than they close it. And the person who closes it now has a tool at hand to build a prototype themselves. The Sunday demo is a natural consequence of how decision-making is distributed.

AI barely appears as an explicit criterion: AI-assisted assessment is named by 4.1% of teams. It may well feed the data and the summaries behind the other criteria, but it is not what the decision is attributed to. And perhaps that's a good thing, because this is where accountability is needed, and accountability can't be delegated to a model.

A decision architect with a mandate

Emily Andrews of McDonald's told how her team built a RACI matrix and got clearer letters, but not a better decision. She proposes moving from the role of decision owner to decision architect: someone who creates the conditions for a good choice. Since I rarely have the last word, my job is to make sure that whoever does sees the evidence, the cost of maintenance and the cost of rollback before they say "ship it".

McCarthy supplies the other half. He writes that product leaders are given a numeric target without the reasoning behind it, and sums it up in one sentence: "Judgement without authority is just stress". His advice to boards: give the PM a mission, a budget and autonomy, then hold them to the plan. Without a mandate, what remains is a role that warns but decides nothing.

So what do I teach

Back to the hesitation from the beginning. I still teach the diamonds, the Product Trio and prioritisation methods, because they describe the questions that have to be asked, not the tools used to answer them. I've shifted the emphasis.

Artur Kurasiński points to a trap that concerns the whole industry. Companies are leaning ever more heavily on the judgement of experienced people, and that judgement comes from years of manual work. If we stop letting beginners do that work, in a few years there will be nobody left to assess what the agents have built.

Over the whole year, students run one product in teams, from a user problem to market entry. The rule is simple: AI supports every stage, and a human checks and corrects what AI generated. Every number in a report has a source. A minimum of five interviews with real users and a prototype test with people, even if the prototype itself was made in Lovable or Figma Make.

Context: organisation, region, culture

I don't know which of the three stories about the PM role will turn out to be true. I suspect different visions of how a product is made will win in different organisations.

You also always have to look at the region. A large part of the analyses and the loudest opinions are based on the experience of US companies. In Europe we work with additional regulation, such as GDPR and the AI Act. In the Middle East and Asia, products are made in yet another working culture. So the environment in which we use the tools matters too: what values we hold, what culture we live in, what we want to achieve, and where the human being is in all of it.

Who serves whom

The fact that agents build faster, more and better doesn't yet mean that everyone who prepares them well will make money from it. If most of us start producing decent products, we may reach a point where supply is so large that there isn't enough demand for it.

You can already see it in the app stores. The author of Six Colors writes that his worry isn't the quality of vibe-coded apps as such, but the flood of them, which outgrows the ecosystem's ability to absorb new, good products.

This problem didn't start with agents. In many companies, large ones included, technology has been accreting in layers for years: another page, another integration, another tool for the current need. After a few years nobody quite knows what does what, because nobody is responsible for the whole. Agents don't create this mess, they just let it be built much faster.

With five apps you don't see it yet. With ten or fifty we can fall into a loop where we mostly maintain what the agents built. Then we'll be serving the agents, not they us.

Kurasiński calls the end point of this road the "dark company", by analogy with a factory where the lights are off because robots don't need them. First the company buys tokens, then agents become permanent employees with memory and permissions, and in the end people drop out of the decision loop.

It sounds a little philosophical, but it comes down to the questions I ask of any Sunday-evening demo, and the ones I want students to leave with: what hypothesis does this test, what evidence from users do we have, who owns it after launch, what will it cost to keep running, and what would make us switch it off. Agents build faster and faster. All the more reason for someone who asks.

Sources

• Nurkhon Akhmedov, "AI now does most of my product manager job. Here's what it can't do", Nurkhon's Substack, 2026.
• Emily Andrews, "The Product Purity Trap" (slides), Mind the Product Chicago, 2026.
• Atlassian and Wakefield Research, "State of Product 2026" (N=700, 3 countries; AI sub-survey N=521), 2025.
• Brian Balfour, "How AI Changes Product Management: Same Role, New Possibilities", Reforge, July 2025.
• Marty Cagan, "The Era of the Product Creator", Silicon Valley Product Group, 2025.
• Marty Cagan, "AI and the Future of the Product Role", Silicon Valley Product Group, 2026.
• Marty Cagan, "Build to Learn vs Build to Earn", Silicon Valley Product Group, 2026.
• Marty Cagan and Dan Olsen, "How AI Impacts Product Management" (video), Lean Product Meetup, 2026.
• Dan Dalton, "Product Management Needs Builders, Not Bureaucrats", #mtpcon London, 2026 (the quoted line is slide 10 of the talk deck).
• Felix Geelhaar, "Building an AI Operating System" (slides), Just Product, Munich, 2026.
• Paulina Grodzicka, LinkedIn post on the Sunday-evening prototype and the PM as an ambassador of common sense (in Polish), November 2026.
• Aakash Gupta, "There's a New PM Skill. It's Called Taste at Speed", Product Growth, March 2026.
• Paweł Huryn, "PM Skills Marketplace" (GitHub repository), 2026.
• Paweł Huryn, "How to Fix the Double Diamond of Design Thinking?", The Product Compass.
• Aneta Kmiecik, "Fewer product design roles than ever, but these 4 are growing", The Group Chat (LinkedIn newsletter), 2026.
• Artur Kurasiński, "Dark company" (in Polish), TECHNOFOBIA, 2026.
• Sean McBride, "RICE: Simple prioritization for product managers", Intercom, January 2018.
• Bruce McCarthy, "The Product Builder Era", Hit Pause, 2026.
• Gergely Orosz, "Building Claude Code with Boris Cherny", The Pragmatic Engineer, 2026.
• Dean Peters, "Product Manager Skills" (GitHub repository), 2026.
• Product Focus, "2026 Survey of the Product Management Profession" (N=677, 40 countries), 2026.
• Product Mindset, "State of Agentic Product Manager in 2026", Product Mindset's Newsletter, 2026.
• Product-Led Alliance and ProductPlan, "State of Product Management Report 2026" (N≈250), 2026.
• Products That Count and Mighty Capital, "2026 CPO Insights Report Predicts Product Managers Will Disappear by 2030" (press release), 2026.
• Jefferson Rabb, "The Speed Playbook: How to Build a High-Velocity Product Engine", ProductCon New York, 2026.
• Lenny Rachitsky, "State of the tech job market: late 2026", Lenny's Newsletter (TrueUp data), 2026.
• Maria Rosala and Kate Moran, "Synthetic Users: If, When, and How to Use AI-Generated 'Research'", Nielsen Norman Group, 2024.
• Six Colors, "Sorry, new developers, it's vibecodetown", 2026.
• The Innovation Attorney, "AI Agents Absorb Product Manager Tasks", 2026.
• Tomasz Tomaszewski, "Stan product managementu w Polsce - wyniki ankiety" (in Polish, N=121), ProductCraft, 2025.
• Teresa Torres and Petra Wille, "Delivery Isn't Free" (podcast), Product Talk, 2026.
• VentureBeat, "Anthropic launches enterprise 'Agent Skills' and opens the standard", 2025.
• Claire Vo, "Product Management Is Dead, So What Are We Doing Instead?", Lenny & Friends Summit, 2024.
• Jenny Wanger, "Building alone, faster: a panel on what AI is doing to the product trio", 2026.
• Author's own classification of the PM Skills Marketplace by stage, and the author's teaching practice.