LO
Product manager
Decides what gets built and what does not, gets three teams to act on that decision, and carries it when it turns out wrong.
This is not a probability of losing your job. It combines how much of the role's task load is exposed to automation with how far adoption has actually gone — useful for comparing occupations on one consistent basis, and for nothing else.
Written for product managers in software companies — the people who decide what a team builds next. Product marketing, project management with no say over scope, and founder-led product work are different jobs with different exposure. Design is a separate occupation on this site.
The evidence base holds verified records for other occupations, but not one for this one yet. Until it does, the analysis below is reasoning about task structure and known technical capability — for this job in particular it is not backed by traceable sources, and we would rather say so than cite things we have not verified. An empty section here is a gap in our coverage, not a finding about the work.
What is actually changing#
The unit of analysis is the task, not the job title. A role is not replaced — its task mix shifts.
Is this your job? Say so and this page narrows to your share of it.
A job title is a bundle of tasks bought together, and no two people hold the same bundle. Nothing is sent anywhere — it stays in this browser.
Writing the requirement down
Automating≈ Platform inferenceSpecs, tickets, acceptance criteria, the document that goes to engineering and the deck that goes upward.
This is the most visible output of the role and the one generation handles most convincingly — a structured document produced from a description is close to the ideal case. It is also a large share of how the job is judged from outside, which is why the exposure feels larger than it is.
A well-written spec for the wrong thing is worse than a rough one for the right thing. Producing the document was never the scarce part; knowing which document to write is.
Deciding what not to build
Still human-led≈ Platform inferenceSaying no to a customer, an executive and an engineer in the same week, with a reason each of them can repeat.
A model can rank a backlog against stated criteria. It cannot absorb the political cost of a refusal, and the refusal is the decision — everything a team does not do is decided by whoever is willing to be the person who said no.
This is a judgement about the nature of the work rather than a measured one. Nothing here says organisations value it correctly, and many measure product managers on output rather than on what they prevented.
Finding out what is actually wrong
Still human-led≈ Platform inferenceTalking to people who use the thing, and working out which of what they said is true, which is polite, and which is a solution in disguise.
Tools now summarise interviews and cluster feedback competently, which helps. The part that does not transfer is the live judgement in the room — noticing the hesitation, asking the follow-up that was not on the list, and knowing that what someone does contradicts what they just said.
Says nothing about how many product managers actually do this. In a great many companies the role never talks to a user, and for those roles this task is theoretical.
Getting three teams to move together
Still human-led≈ Platform inferenceEngineering, design, sales, legal and support all acting on the same decision, none of whom report to you.
This is influence without authority, conducted in meetings and corridors, and it is most of what the job actually consists of. There is nothing here for a tool to take, because the medium is other people's willingness.
A description of where the work sits, not a measurement. It also does not say this is done well — coordination failure is among the most common reasons products ship late.
Being wrong in public
Still human-led≈ Platform inferenceThe feature shipped, the number did not move, and somebody has to say so and decide what happens next.
Accountability for a bet is the core of this role and it cannot be delegated to a system, because the point of it is that a person's judgement is on the line. Where organisations remove this, the role degrades into writing tickets — which is the half that is exposed.
Whether this is real depends entirely on the company. Many product managers have responsibility without the authority that would make it meaningful, and this page cannot tell you which kind a given job is.
Specifying what a generative feature may do to a user
New task≈ Platform inferenceDeciding what the feature is allowed to get wrong, what it must show its working for, what it must refuse, and what happens when it fails in front of a customer.
This is new work with no settled practice, and it is landing on product rather than engineering because the questions are about acceptable harm and user expectation rather than about the model. In several markets it is also becoming a documented obligation rather than a preference.
New work appearing is not new headcount, and nothing here says companies are staffing it. In most teams it is currently absorbed by whoever owns the feature.
Which technologies matter here#
Four separate signals. They are deliberately not added together — a job exposed to two technologies is not twice as exposed.
How it got here#
The index is not a static number. This is where it would have sat at each capability checkpoint since ChatGPT — reconstructed, and labelled as such.
A low start: before 2022 the documents were written by hand and there was no cheap way to shorten them. The climb through 2024 is generation handling the role's most visible output — specs, tickets, decks — convincingly. It stops rising in 2025 and the flattening carries the page's argument: cheap building makes the deciding more consequential, not less, because a team that can ship five things in the time it used to ship one pays five times over for choosing the wrong five. What remains is refusal, coordination without authority, and being answerable for a bet. Note the honest caveat in the shape: where an organisation has stripped the decision out of the role, the job really is the documents, and that version sits much closer to the automating half.
A flat line is not a forecast of safety. It says which tasks automation has reached so far — the occupations that moved least here are the ones where the constraint is physical or regulatory, and both of those can change.
Recent changes#
No verified events recorded yet.
This section will fill from the monitoring pipeline as events are collected, de-duplicated, graded and linked to the tasks above. An empty list here means we have not verified anything — it does not mean nothing is happening.
"We found no news" is not the same as "you are safe."
What this means for you#
The work you will be given first — writing tickets and specs — is the exposed half, and doing it well will not by itself make you a product manager. What converts the role into a career is being trusted to decide what does not get built, and that trust is earned by being right in public about small things first.
If your week is mostly documents and status, that is the configuration under pressure, and it is also the configuration many companies have quietly created. If your week is mostly refusals you can defend and decisions you own, the exposure is low. The difference is not seniority, it is whether the role carries a decision.
Your options#
Four directions, each with its real constraints and one thing you can test this week. Continuing as you are is a legitimate choice — it just has to be a chosen one.
Make sure the role carries a decision
The exposed version of this job is the one that writes down decisions other people made. The durable version makes them. Which one you hold is usually a function of the company, not of your skill.
Sometimes the honest conclusion is that the decision is not available in your current organisation, and the move is out rather than up.
List the last five things your team shipped and write, honestly, who decided each. If your name is not on any of them, that is the finding.
Own what AI features are allowed to do
Every product with a generative feature needs someone who decides what it may get wrong and what it must refuse. That is a product decision, it is currently unowned in most teams, and in several markets it is becoming documented obligation.
It requires being specific about acceptable harm, which is uncomfortable and which many organisations would rather leave vague.
Take one AI feature in your product and write down what it is allowed to get wrong. Show it to whoever owns support and see whether they agree.
Move to where the constraint is real
Regulated products, hardware, payments — domains where the cost of shipping the wrong thing is concrete rather than reputational, and where the decision therefore has to be held by someone.
Slower cycles and more documentation, which some people experience as the work becoming real and others as it becoming tedious.
Find a product in a regulated domain and read one of its public compliance documents. Notice how many decisions had to be written down.
Common questions#
The wrong question for this role, because the exposure depends on which version of the job you hold rather than on time. Writing specs and tickets is already substantially machine work. Deciding what does not get built, and answering for a bet that failed, has not moved at all. A signal you can check yourself: of the last five things your team shipped, how many did you decide rather than document.
Yes, and well — that is precisely why the document was never the job. A specification is a record of a decision, and the value was always in the deciding: which customer to disappoint, which quarter to spend, which problem is actually the problem. If the document is the deliverable your organisation measures you on, that is worth knowing about your organisation.
Enough to tell an estimate from a guess, and that bar has moved rather than risen. When generation makes a prototype cheap, the useful technical skill shifts from knowing what is hard to build toward knowing what is hard to operate and what is hard to undo — those are the costs that no longer show up in how long the first version takes.
Cheap building makes the deciding more consequential, not less: when a team can ship five things in the time it used to ship one, the cost of building the wrong five is five times larger. What it does change is that the role can no longer be justified by coordinating the build. It has to be justified by the quality of the choices, which is a higher bar and a more honest one.
Method and sources#
- Assessment date
- 2026-09-12
- Basis of the task judgements
- 0 evidence-backed · 6 platform inference · 0 not enough evidence
- Verified events
- 0