When an AI agent can turn an idea into working code, it is fair to ask: do we still need product managers?
I am a product manager with a development background, so I do not dismiss that question. I build things too. Working with AI has shown me how quickly an idea can become a prototype, and how much judgment it still takes to decide whether that idea is worth pursuing.
But that experience has pushed me toward a different conclusion.
Making software easier to build does not make choosing the right software easier.
AI is changing the PM job. It is not making the underlying work disappear. If anything, it is exposing the difference between managing activity and creating value.
The customer problem came before the agent skill
One experience captures this better than any argument about job titles.
Customers were running into a problem with coding agents: general coding ability did not reliably translate into the domain-specific guidance they needed. In database work, plausible code is not enough. The agent needs the right context and an understanding of the constraints that make a solution useful.
I did not want that to remain a feature request waiting in a backlog.
I created a proof of concept around agent skills, demonstrated the value of the approach, and handed it over to engineering to take forward.
The important part of that story is not that a PM wrote something technical. It is the sequence:
- Start with a customer problem, rather than a technology looking for a use case.
- Make the proposed solution concrete enough to examine.
- Show why it is worth pursuing, rather than relying on a persuasive document.
- Bring engineering into the next stage, with a clearer problem and evidence to work from.
A proof of concept does not settle production readiness, maintenance, or long-term customer impact. Those still need engineering work and continued validation. But it can reduce uncertainty before a team commits to a larger investment.
That is product management to me: moving from ambiguity to a decision the team can act on.
AI makes the prototype easier. It does not automatically identify the customer problem, establish its importance, or earn the team's confidence.
Building a thing and building the right thing are different
My work on DevGlobe, skill graphs, and a hackathon-winning project has given me another lens on this.
In a hackathon, a working demonstration matters. You have limited time, and turning an idea into something people can experience is a real advantage. But a winning demo is not the same as evidence of sustained product value.
With DevGlobe, the initial idea was an interactive 3D map of developers. As I described in the project write-up, the deeper problem became discovery: how do you find the right developer for a particular need, using meaningful evidence rather than popularity alone?
That changes the questions:
- Are we helping someone discover relevant expertise, or just giving them an attractive visualization?
- What evidence makes a match understandable and credible?
- How should an agent request an introduction without bypassing consent?
Those are not syntax problems. They are product decisions with architectural consequences.
The same distinction matters in professional work on the Agent Kit and MCP Toolkit. Giving an agent more capabilities is not, by itself, the outcome. The question is whether those capabilities help a developer complete a useful workflow with the right context and boundaries.
A feature can be technically impressive and still fail to solve the problem that matters.
The strongest engineers already practice product management
I agree with part of the argument that engineers are becoming more powerful in the AI era.
An engineer who understands users, exercises sound business judgment, spots a valuable opportunity, and moves it forward independently has enormous leverage. Add AI-assisted implementation, and that combination becomes even stronger.
But notice what makes that engineer effective: it is not only coding speed. It is product judgment, initiative, communication, and ownership.
Those qualities are not exclusive to PMs. They should not be.
Cory House's observation about roles collapsing captures the direction well: software engineers may increasingly act as product engineers, with responsibilities extending into design, UX, quality, and product thinking.
I read that as a reason to broaden our skills, not as proof that every specialization should disappear.
An engineer gaining product skills does not make product management unnecessary, any more than a PM building a prototype makes engineering unnecessary.
Independence is a team expectation, not a PM service
Consider a simple dependency: a feature needs information or an API change from another engineering team.
My expectation would be that the person working on it identifies the owner, starts the conversation, explains the need, and brings back options. A PM can help when priorities conflict or a decision needs broader alignment. But being the mandatory messenger for every technical conversation is not a useful operating model.
The same standard applies to me. I should not wait for engineering to make every uncertain idea tangible when I can investigate, prototype, or clarify it myself.
That does not mean never asking for help. Some blockers involve authority, resourcing, or organizational constraints that an individual cannot resolve alone. Ownership means making progress and escalating clearly, not pretending those constraints do not exist.
I would not turn this into a claim that most developers lack initiative, or that layoffs reveal who had good judgment. Neither conclusion follows from an anecdote.
The useful lesson is simpler: every role needs more ownership, and fewer unnecessary handoffs.
Product management is still its own discipline
There is a difference between having product instincts and taking sustained responsibility for product discovery, prioritization, and business viability.
A great PM can work through hundreds of customer signals and dozens of possible features, then help the team identify the two or three bets that matter.
That involves more than summarizing feedback:
- Distinguishing a widespread problem from a loud request.
- Understanding which customer segment we are choosing to serve.
- Connecting a proposed solution to a credible business outcome.
- Making trade-offs explicit, including what we will not build.
- Aligning engineering, design, data, user research, and business stakeholders.
- Revisiting the decision when evidence changes.
AI can help organize the inputs and challenge an argument. A generated prioritization table can still be wrong if its assumptions are wrong.
Someone needs to understand the context, make the trade-offs visible, and stay accountable for learning whether the decision worked.
Marty Cagan and Marily Nika's article on AI product management is especially relevant here. It explains how probabilistic behavior, acceptable error rates, user expectations, data limitations, and business risks make AI products demanding cross-functional work.
The PM is not the team's boss or the sole source of ideas. Engineers should lead architectural and implementation decisions; designers should bring deep experience judgment; data and research specialists should help establish reliable evidence. Product management connects that work to customer value and business viability.
Shared ownership should strengthen specialization, not erase it.
The hiring data challenges the replacement story
There is also a useful reality check.
In his November 10, 2026 report, State of the tech job market: late 2026, Lenny Rachitsky reports:
| Reported measure | Finding |
|---|---|
| Open PM roles compared with the March 2023 low | Up 75% |
| PM openings since the start of 2023 | Up 56%, compared with 43% for engineering |
| PM share of hiring across the five core product roles | Increased from 16% in 2021 to 21% in 2026 |
The five roles are product management, engineering, design, data, and user research. PM was the only one whose hiring share increased in that comparison.
The methodology matters. The openings data comes from TrueUp's tracking of more than 9,000 tech companies globally. The hiring data comes from Live Data Technologies, with the report's hiring figures specifically covering the United States.
Openings are not completed hires. Share of hiring is not absolute hiring growth.
The same report says actual hiring across the core product roles has been flat or declining over the past few years. A role can gain share in a shrinking market. The data also does not establish that AI caused the relative resilience of PM demand.
So I would not use these numbers to declare PMs safe or engineers obsolete. I would use them to challenge the confident claim that product management is already disappearing.
The Reddit debate makes the distinction clearer
Two older discussions in r/ProductManagement are useful alongside the newer hiring data.
In I tried to replace a PM with AI. It kinda worked., the author describes an informal experiment where AI could produce PM-like responses but struggled with pushback, conflict, and context-sensitive problem solving.
In Product Managers who build AI powered features, participants discuss fitting AI to actual workflows and recognizing when an AI solution is unnecessary.
These are practitioner anecdotes, not representative research or a benchmark of today's models. I take them as discussion prompts, not proof.
The distinction they surface still matters: producing the artifacts of a job is not the same as taking responsibility for its decisions.
My agent-skills experience fits that distinction. The point was not to generate a better-looking requirement. It was to make a real customer problem actionable and show why a solution deserved engineering attention.
What I am taking forward
For PMs, including myself:
- Become technically fluent. Understand enough about models, tools, evaluation, latency, and cost to participate in real trade-offs.
- Use AI to reduce uncertainty. Prototype to test an assumption, not just to impress a stakeholder.
- Stay close to customers. Faster synthesis is useful; it is not a substitute for understanding their workflow.
- Measure outcomes, not artifacts. A demo, PRD, or shipped feature is an intermediate result.
- Make the handoff collaborative. Share the evidence and unresolved questions, not a supposedly finished answer.
For engineers, I would emphasize user understanding, communication, prioritization, and owning dependencies alongside technical depth.
Neither list is a request for everyone to do five full-time jobs. It is a request to understand adjacent disciplines well enough to work together with less friction.
My answer: the role matters, but the bar is moving
I do not think the future belongs to PMs who only write requirements. I also do not think it belongs to engineers who only implement tickets.
It belongs to people who combine craft with judgment, take initiative, and help their teams create something valuable.
For me, that means being willing to build the proof of concept, while recognizing when engineering needs to take it forward. It means caring about the workflow behind the Agent Kit or MCP integration, not just the capability. It means asking whether DevGlobe helps people discover relevant expertise, not just whether the globe looks good.
AI can help us build more things. Product management helps us decide which things deserve to exist.
That is why I believe the work remains relevant right now.
Sources and further reading
- Lenny Rachitsky: State of the tech job market, late 2026 - source and methodology for the hiring figures above.
- Lenny's hiring-share post and follow-up on the post-2021 recovery.
- Cory House on the shift toward product engineering - commentary on broader engineering responsibilities, not a guarantee about future job titles.
- Marty Cagan and Marily Nika: AI Product Management.
- SVPG: Product in the AI Era resource guide - related reading on judgment, discovery, and team autonomy.
- Reddit: I tried to replace a PM with AI. It kinda worked. and Product Managers who build AI powered features - older, anecdotal practitioner discussions.
- My related posts: building DevGlobe and the regression tax in agent skills.