Where product management is going
AI changes work one task at a time. Sort a real product manager’s week that way and very little of it stays untouched.
Four things that happen to a task
A week, task by task
One product manager’s week: the tasks on the calendar and the ones that never make it there.
AI changes work at this level. It helps with a task, takes it, or leaves it alone, and the answer is different for each one.
In the order a week runs
Left to right: listen to customers, decide what is worth solving, define it, build it, learn from what shipped. Then round again.
One job title covers all of it and says nothing about which tasks are changing.
The list has always moved
Nobody tallies survey results by hand any more, chases status once a tool shows it, or retypes tickets between two systems. Software took those over 15 years, and nobody called it a crisis.
Session replay and A/B tests arrived in the same period. They are routine now.
Most tasks now have help
Reading got cheap. Everything said in calls and tickets can be read, grouped, and traced to the account that said it. A problem gets framed from all of it, not the 3 examples someone remembered.
Someone still frames it and writes the PRD. The document looks the same, so the change shows in your hours, never in your delivery metrics.
Some tasks are taken over
Interview summaries, first-pass bug triage, release notes, the list of accounts behind a request. Each ends in a document nobody argues with.
None needed an opinion. That is what made them the first to go.
AI adds tasks of its own
Reviewing what the model drafted before a customer sees it. Writing the check that lets an agent call a draft done. Deciding what an agent may do without asking. Keeping the product context current, because an agent with the whole repo still cannot see why the settings flow is split in two.
None of it is in a capacity plan yet, so it falls to whoever notices.
What stays yours
Almost nothing came through untouched. What did is where someone has to be accountable: the no to your biggest account, and owning the call that turned out wrong.
Neither gets cheaper as models improve. Staff for them.
A better model does more
More drafts an hour, a longer backlog pass, a wider triage sweep, and more to review at the end of each.
The tasks it already helps with get more help. The ones it left alone stay yours.
Help only counts when used
The gain arrives where something uses it: permission to try, a habit of trying, a review step people trust, and context the model can read.
Model quality is the vendor’s problem. Permission, habit, review and context are yours.
Sort your own week
Unchanged you protect and staff. Augmented pays for itself if the model knows what you know. Automated needs a test and an undo first. Created by AI is the checking work the rest of the week made.
Then sort your customers’ week the same way. What is worth taking off their hands is a roadmap, in order.
A model can write your PRD. It cannot know why you killed the last one.
The constraint is context
Ask a frontier model for a specification and you get a competent specification. Ask for yours, and it cannot write it. The migration you are half way through, the account that churns if permissions change, the approach engineering rejected in April. All of it existed. It lived in a Slack thread, a call recording, and one person’s memory.
What the model gets
A ticket title and a label
What it needs
The evidence underneath it
The calls, tickets and research that made this worth solving, and which accounts they came from.
The decision and what lost
What the team chose, what it rejected, and the reason. The part that never survives the trip into a backlog.
The constraints that still bind
Product rules, prior commitments, and the parts of the system that are not up for negotiation this quarter.
What already failed here
The approach engineering tried in April, and why a model proposing it again costs the team a week.
Drafting got cheap. Reasoning did not.
Nobody needs to file a specification a model rewrites in 9 seconds. The reasoning it was supposed to carry does not come back that way: why this, why now, on whose evidence, and what the team said no to. Product teams have always produced that reasoning and mostly never stored it.
Evidence arrives unsorted
A quarter’s customer contact: tickets, sales calls, a research session, 3 Slack complaints, a churn note, one long email from your largest account.
None of it is a decision yet. Some of it is not a problem yet.
Most of it goes nowhere
It stays in a recording nobody reopens and a document nobody links to.
It never shows up as a miss, because nobody knew there was a decision to make.
Grouping gives it a name
11 customers saying the same thing is a different fact from one customer saying it 11 times.
Grouped, it becomes something a team can name and disagree about, and which accounts said it matters as much as how often.
Where the decision happens
Bigger than a ticket, smaller than a roadmap theme, and still carrying the evidence underneath.
This is the level where a team can say no and mean it.
Ideas compete
Each problem attracts several ways to solve it, and most of them lose.
Teams that start here, instead of with the evidence, ship things nobody needed.
Committing comes last
Scoped, sequenced, agreed. The ideas that lost stay attached to the problem they answered, so next quarter nobody works them out again.
The path back
Pull an initiative and the trail is still there: which ideas competed, which problem it solves, which insights support it, which evidence started it.
An engineer needs that on day one. An executive asks for it in the QBR. An AI builder has to be handed it before it writes anything.
We keep the part that cannot be regenerated
Zentrik reads demand from the source, so calls, tickets, research and your Jira history become opportunities your team can inspect. You make the call once, with the evidence already attached. The decision then travels into specifications, into Jira, and into the AI builders your team already uses, carrying the customer story and the product rules rather than a ticket title.
AI helps structure the evidence and prepare the work. People own the judgment. That line is the whole product.
Questions teams ask
Will AI replace product managers?
The role is the wrong unit to argue about. AI takes on tasks, and a product manager runs about 20 of them in a week. Sort a real week into unchanged, augmented, automated and newly created work and very little lands in the first column. What does is where a person has to be accountable rather than capable: telling a large account no, owning a call that turned out wrong. Everything else now has help, including framing the problem.
Why has AI not made our product team faster yet?
Usually because the constraint is context. A frontier model writes a competent specification and cannot write yours, because the migration you are half way through, the account that churns if permissions change, and the approach engineering rejected in April are not written anywhere it can reach.
What replaces the PRD once drafting is cheap?
A decision with its evidence still attached. A document a model regenerates in 9 seconds is worth less than the reasoning it was supposed to carry: why this, why now, on whose evidence, and what the team said no to.
The four states used here (unchanged, augmented, automated, created by AI) follow the task-level framing in Anthropic’s Economic Index work. Which tasks land in which column is our own read, and the argument for it is the page.