The viral prediction that "AI will take over product management in five years" is half right: it will dismantle the PM whose job is ticket-writing, status coordination, and backlog orchestration. My bet is that AI will replace much of the PM’s administrative work. As code becomes cheaper to generate, product judgment becomes more important: deciding what to build and setting boundaries that let a team work without constant supervision.
The Eulogy for the Product Manager: A Half-Right Diagnosis
Every few months, another article predicts that AI is about to kill the product manager. In one recent example, Freedom Preetham argues that AI can automate roughly 80% of what many PMs do all day. Once models handle that work, he argues, the remaining responsibilities can move to other disciplines. Executives set strategy, engineers build with AI, and designers handle the user experience. The PM disappears.
For a lot of product teams, I think he’s right. Corporate Agile turned much of product management into ticket management where PMs spend their weeks translating executive requests into engineering tickets and formatting status updates. If that’s you, you’re competing with software that gets faster and cheaper with every release.
But the prediction misses why products succeed or fail. Writing a Jira ticket faster doesn’t tell you whether the feature should exist. The hardest part has always been deciding what not to build. A feature can make sense on paper and still miss what customers need. Cheaper code lets teams make that mistake faster.
Granted, that judgment could sit with an engineer, designer, or business leader. It doesn’t automatically require a separate PM. But on teams where competing customer needs and business commitments require sustained attention, distributing responsibility can leave important tradeoffs unresolved. A dedicated PM is useful when someone needs to maintain and explain those decisions across the work.
Some PMs are responding by trying to become AI coordinators. I think that risks doubling down on the work AI is most likely to take over.
The Orchestration Trap: Automating Yesterday’s Rituals
When PMs see how fast a prompt can write a user story, their instinct is to build a factory around it. They chain together bots that turn customer feedback into tickets and route those tickets to coding agents. It feels proactive, but the underlying workflow is still the old Agile assembly line.
I talked about this recently with Chris Ivester, who founded Dialog to help teams connect AI agents to workspace tools and memory. Chris told me that PM after PM reaches out wanting an AI Chief of Staff to manage task queues through automated reasoning and routing. The assumption is familiar: if human teams needed someone to coordinate every handoff, agents must need that too.
But Chris also noted those handoffs introduce their own problems:
Context gets lost. Finished summaries and documents that preserve important decisions are useful context, but without more signals from less polished artifacts, like chat threads, they ultimately lose nuanced reasoning behind it. Each subsequent agent works from a narrower account of the original discussion.
The pipeline needs maintenance. A model update or an unexpected input can break a prompt that previously produced clean specs. As with the microservices problem, distributing work doesn’t remove complexity. It moves complexity into the handoffs.
Delivery coordination needs to happen, but a pipeline that fills backlogs faster still needs someone to question whether the work is worth doing.
The New Bottlenecks: Tokens, Risk, and Feature Sprawl
Historically, software teams needed to be careful about what they started building because of the cost. Generative models make building cheap, and this has become a recurring topic in influencer PM discussions. I agree, but there is still not a tangible answer for what the new bottlenecks will be.
In my view, AI encourages every member of the team to be a builder, so delivery will become constrained by the cost of running the tools and the consequences of building the wrong thing. For a personal account used for weekend ideas, token feel cheap. But inside a company the story is different because usage limits and data security requirements constrain what you can run and open-ended loops, like Ralph Wiggum, need cost limits. Spend thousands of dollars automating an untested idea and you may end up with a bigger API bill rather than something customers need.
That’s why the first rule in my AI Operating Principles for Product Managers is Start with the outcome. (These are my evolving working notes as I test workflows with teams, not an official company playbook.) Shipping an AI chatbot just because you can is a classic example of a solution looking for a problem and PMs are still best equipped to be the team member that asks if it solves a real need.
The amount of human oversight also needs to reflect risk. Exploring an idea in a sandbox doesn’t need the same accountability as code that touches payments or private customer data. Product leadership means knowing where builders can proceed independently and where human verification is necessary. Treating all work equally and approving every prompt or commit turns the PM into another unnecessary bottleneck.
The Steering Model: Boundaries, Specs, and Definitions of Done
On the best AI-assisted teams I work with, the PM no longer writes every story or controls the backlog. When an engineer can build a working prototype in twenty minutes, waiting for a PM to write a story is a waste of time. Anyone with an idea that fits the team’s goals can explore it. The team needs shared direction without a gatekeeper for every experiment.
Steering means giving AI clear context and boundaries. For implementation work, that means moving from “prompt and pray” coding to design → plan → build. The model should be instructed to ask questions when something is unclear rather than guess.
The PM is still accountable to evaluating the intent behind the work: what problem are we solving, and what must the system avoid? AI can help test that reasoning before implementation. A clear definition of done gives the builder a basis for stopping instead of generating another iteration.
On a team of AI builders, the traditional product triad transforms into a team of specialized builders with each discipline still contributing its craft:
Engineers build the testing suites and CI/CD guardrails that check agent-written code before it reaches production.
Designers build design systems with clear component rules, reducing the need to review every generated button manually.
Product managers define the problem boundaries and stopping rules, then decide where the team spends its time and tokens.
These responsibilities make independent work possible. They also give the team a way to assess that work without putting the PM in the middle of every handoff.
The Product Harness: Reasoning, Context, and Roadmaps
When building software engineers use harnesses, which describes tools and configurations that help them ship without breaking things. I argue that builder PMs need an equivalent that keeps product reasoning available as work changes. A backlog board and a monthly presentation deck can’t do that on their own.
My product harness has three parts:
A product reasoning suite: Agent skills that help test whether a proposed solution fits the problem. These support a decision before implementation; they aren’t a factory for routing tickets between bots.
A living context library: A collection of source conversations and work records connected to decision logs. It lets builders and agents retrieve what the team learned, including assumptions that remain untested, without waiting for a PM briefing.
Roadmaps that update with the code: I use
RMP.mdto make storytelling easier. The protocol instructs repository agents to sync the roadmap with delivery evidence and generate views at different horizons. It helps explain how current work connects to longer-term product direction across teams without needing to manually rebuild the document for each audience.
Where Steering Needs Human Judgment
I hear concerns pulling in opposite directions. Some people worry that AI removes humans from the craft. Others want AI to do everything without boundaries. I believe steering still requires people to practice their craft. Setting boundaries is part of that work, and those boundaries need to change when the team is still discovering the problem.
If you are at the discovery stage, you don’t yet know enough to articulate the finished product, so leaving an agent to explore indefinitely creates the cost problem I described earlier. When steering you have to balance between over-defining the outcomes and under-prescribing the constraints.
My current approach is to bound the experiment. What question are we trying to answer, and what information would be enough for us to stop? A prototype can help us discover the requirements. We don’t need to write them all in advance or jump straight to implementation planning.
That gives me a test for the spec: does it help a builder make the next decision? It should be readable by the people responsible for the work, not just usable by an agent. If a line doesn’t clarify a decision or a constraint, I’d question whether it belongs.
The Practitioner Diagnostic
Look back at how you spent your time last week. How much went to pure coordination? If most of it went to transferring outputs between tools and maintaining task queues, you’re acting as an orchestrator. That work keeps your calendar full, but models get better at it every month. If that’s where your time goes, the prediction that AI will replace you isn’t alarmist. It’s just high probability.
On Monday morning, review your highest-priority project before anyone opens an IDE or prompts an agent. Write down what the product must avoid and what “done” looks like. If you’re still exploring, define the question the prototype needs to answer. Set a cost limit and a stopping rule so the team knows when to pause rather than keep generating.
When generating software is cheap, your value as a product thinker is in helping the team decide what is worth building and when to stop. You can spend the next five years trying to orchestrate a machine that doesn’t need you. Instead, build the harness, set the rudder, and steer.