Picture a product manager getting ready for backlog refinement. A year ago that session meant estimating the backlog, clarifying details with the team, and breaking coarse-grained items down into something fine enough to work on next sprint. Dragging cards. Resizing tickets. Tidying columns nobody reads.
Today that same person opens a laptop, describes a feature out loud, and has three working prototypes before lunch. The backlog barely gets touched. And somewhere online, a post has already gone up saying there is no longer any need for product managers or business analysts. I see them every week. So it is settled then. The product management function is finished. Somebody go update the org chart.
I am Lance Dacy, otherwise known as Big Agile, and I want to talk about the part of the product management role that might genuinely be disappearing, because it is not the part people are panicking about. The product managers I meet are not losing their jobs. They are losing a large chunk of their work, and it is the administrative chunk.
The administrative half is evaporating, and most of it should
Writing the first draft of a spec or a PRD. Turning a hallway conversation into tickets. Chasing status across four teams. Building the deck that explains the other deck. All of that is getting absorbed by tools, and fast. Honestly, most of it should be.
Nobody grew up dreaming of grooming a backlog. In my training sessions we talk about this constantly, because the people who would make the best Product Owners tend to run from the role, and the administrative load is why. They do not have time for it.
So for a lot of people this lands as relief and threat at the same time. Relief because the busy work is finally gone. Threat because the busy work is what filled the calendar, and a full calendar looked like a job. Everybody needed you. When it leaves, you can suddenly see how little of it was ever the point.
The replacement case deserves a fair hearing
There is a prominent camp that says the product manager is done, replaced by a new role. I have heard it called the product builder. Someone who prototypes, tests, and decides with AI tools in the loop. This is not a fringe position. The 2026 CPO Insights Report from Products That Count predicts the product manager role ceases to exist by 2030 and is replaced by the product builder, and it points at traditional product manager roles being down 30% overall and as much as 70% in SaaS. That is a real prediction made by serious people, some of whom I admire.
It is also contested, and it is not settled. Nothing here is settled. This is new to all of us, so do not let anybody tell you they have it figured out yet.
Give the replacement case its due first. When one person can research, spec, prototype, and ship, a coordination role starts to look like a middleman. And middleman roles get removed when the thing they coordinate gets cheaper. We watched that happen to Scrum Masters and Agile Coaches as recently as 2025. If your entire value was moving work between specialists, that value really is under threat. I take it seriously.
I just think it mistakes one version of the job for the whole job.
The role was never the tasks
Notice the move inside that prediction. It treats the tasks and the role as the same thing. Automate the tasks and the role retires with them. But the role was never the tasks. The tasks were how the role showed up when everything around it was slow.
The part that is disappearing is the part that was always overhead. The handoffs. The translation. The waiting between one person's output and the next person's input. The queues we talk about constantly in flow work. When building software was slow and expensive, we built entire jobs around managing that scarcity. Someone had to shepherd an idea through the relay race.
AI made a lot of that scarcity go away. The relay got short. Good. So the jobs built on top of the relay feel pressure, as they should. That part is real. But you can feel the ground move without the role dying underneath you. Same role, very different ground.
Watch the relay collapse on a real request
Say your biggest customer keeps asking for one feature. Pick something concrete, like bulk user management. They want to add and remove people on one screen, in bulk, without filing a support ticket. Self-service. It is probably the right thing to do for your users.
A few years ago that request started a relay race. You write the spec. Design picks it up and works out the flow. Engineering scopes it after that. Two weeks pass before anyone sees a single screen, and most of your week went into moving the idea along.
Now watch what happens to that relay. You describe the feature out loud, and by the afternoon you have a written spec, three prototype flows you can actually click through with real data, draft acceptance criteria, and a rough migration plan for existing accounts. In one working session.
That is genuinely new and genuinely good. The distance between an idea and something you can look at got very short. This is what we have wanted for twenty years.
The summary is free. The interpretation is not.
Now watch what AI does not do. Start with the evidence. AI can pull every support ticket that mentions the request. It can summarize them. It can chart a trend line that looks very convincing.
What it cannot do is tell you whether that pattern is a real market need or the loudest account repeating itself. Reading evidence for what it actually says, rather than what you hope it says, is your job. AI is very good at telling you what people said. It is not accountable for what happens if you believe them. You are.
Your customer is not always right
Then there is the call itself. Should we build this at all? Your biggest customer is loud, and loud is not the same as representative. We laugh about this in workshops, because business school teaches you the customer is always right, and in product management I do not think that holds. Building this might pull your roadmap away from the segment that quietly drives your retention.
That is a tradeoff, and a tradeoff is a decision about what you are willing to give up. AI does not know what you are willing to give up. That is your job in a nutshell. And those tradeoffs belong to your stakeholders too, not only to you.
Three prototypes, one decision
AI, or a team using it, hands you three prototype flows. Two of them demo beautifully. Only one fits how your customers actually work under a deadline. Knowing which one is the product manager's job, and it always was.
Prototypes are cheap now. Choosing between them is still expensive. That choice is taste, and taste is pattern plus consequence. You have shipped things and watched what they did to real people. Your model has not.
Should this feature exist at all?
Underneath everything sits the harder question. Every feature you ship is a promise to maintain it forever. It is new surface area for bugs. It is a line in the sales demo that quietly raises expectations you now have to meet.
AI can generate that feature in an afternoon. It cannot tell you whether shipping it makes the product better or just bigger and more complicated. That call needs evidence, taste, and a point of view.
And if the answer is yes, there is still a when
AI will happily schedule the rollout for next sprint. It will not read the stakeholder, and it will not read the CAB room. It does not know that sales just promised three other things, or that engineering is underwater on reliability. Sequencing a yes against everything else fighting for the same week is judgment about your organization, not about your product. That one is yours too.
The durable core: judgment, evidence, tradeoffs
Deciding which problem is worth solving. Reading whether the evidence supports the idea or merely flatters it. Choosing what to give up. None of that got cheaper this year. It got more valuable, because everything around it is moving faster.
So the shift I would make in how you hold this is simple. The product builder version of the role is not the end of product judgment. It is product management with the overhead stripped out.
Building got cheap. Being wrong did not.
When a prototype takes an afternoon instead of three weeks, you get more chances to be right. You also get more shots at being wrong, at speed. The cost of a bad decision did not go down. It went up.
When you could only ship a handful of experiments a year, a bad one cost you a quarter. When you can ship forty, a bad one still costs, and now you can make ten of them before lunch. Speed without judgment is just a faster way to be wrong.
Which is why the skill that matters is not prompting. Prompting is so 2025. It is easy and it gets easier every month. The skill is knowing which of the ten things AI just made easy are actually worth doing. That is the product builder worth becoming. A sharper decision maker who happens to have a very fast workshop around them, rather than a faster backlog administrator.
Agile Principle 10 just moved up the chain
The best product people I know are ruthless about what they will not build. We already have a principle for this, and it confuses almost everybody. The tenth principle behind the Agile Manifesto reads: simplicity, the art of maximizing the amount of work not done, is essential.
For years that principle stared engineers in the face, because engineers tend to over-engineer solutions. It confused them too. Now it has moved up the chain. Product people tend to build features our users do not need, and the art of figuring out the one feature we should do is squarely in our court.
That instinct just became the most valuable thing we own.
The real danger is quieter than replacement
The risk is not that AI replaces you. The risk is that you let it turn into a faster version of overhead. Same busy work, higher throughput. Resist that.
So where does the reclaimed time go? Not into shipping more. Into being more sure. You are the steward of a team's scarce capacity against an infinite pile of ideas everybody wants to work on. Spend the reclaimed time talking to the customers you were always too busy to call. Spend it pressure testing an assumption with your stakeholders before you make the call rather than explaining it afterward. The cost of that invisible inventory is real.
Teams that win with this do not just build faster. They decide better, because they finally have the freed capacity to do it.
The test I hold myself to is simple, and it is hard. If your calendar is fuller than ever but your product is no clearer, the tools have made you busier, not better. Clear is the goal. Busier is the trap.
Try this for one week
Take one thing on your plate that AI now does for you. A spec, a prototype, a first-pass analysis. Let it do that thing. Then stop and ask a second question: what judgment did that speed just put in front of me sooner?
Write the answer down in one sentence. That is your actual job. The rest was always overhead, and you are well rid of it if you handle it correctly.
Do that for a week and something starts clicking. You stop measuring your day by how much moved, which is output, and you start measuring it by how much of it you got right.
So is the product manager finished?
No. The role is not dying. The name might. Same as I said about Agile Coaches last year, and the Scrum Master before that.
The backlog administrator version of the product manager is dying, and we should celebrate that, because that version was never the point.
If you want to work on the judgment half of the job with a room full of people wrestling with the same question, that is what we do at Big Agile. Have a look at our upcoming classes and courses and come argue with me for a couple of days.
Tell me in the comments which part of your product role AI has changed the most. I read all of them, and they shape these episodes.