SC Moatti posted the blunt version this week: product managers won't exist by 2030. That comes out of the fifth annual CPO Insights Report from Products That Count and Mighty Capital, built on more than 1,500 product leaders. Larry English covered it in Forbes. Renee Niemi added the line I keep chewing on: the Product Builder isn't a smaller job, it's a bigger one.
I have been writing the product builder thesis for a while, so I am not going to argue with the conclusion. I want to argue with where people are aiming it.
The short version
The 2026 CPO Insights Report says product managers disappear by 2030 and product builders take their place. The role is real, and the numbers behind it are real: PM roles down 30% across industries and up to 70% inside SaaS, builder roles up 10x in a year. But the framing points at building, at exactly the moment building stopped being the constraint. Buried in the same report is the finding that undoes the headline: speed to market is now the number one internal challenge CPOs report, and the bottleneck moved from building to launching. Twelve builders delivering twelve products is only a win if twelve products can land. The scarce skills now are judgment about what should exist, evals written before code, downside sized honestly, and adoption. None of them come with a title change. If your builders still need three approvals to reach a customer, you renamed a role, you did not change your operating model.
Read the second half of the report
The numbers everyone is quoting: product builder roles up 10x in a year, traditional PM roles down 30% across industries and as much as 70% inside SaaS companies, three out of four product leaders now using AI for prototyping and exploration. The headline stat is the one about team math. Where it used to take twelve people to build one product, twelve product builders can deliver twelve products.
Then there is the finding almost nobody quoted. Speed to market is now the number one internal challenge CPOs report, up from 14% in 2025 to 22% in 2026. The report is explicit that the bottleneck moved from building to launching. Go-to-market execution, customer adoption, and organizational alignment are where products now get stuck.
Both of those are in the same document. The second one takes the air out of the first. Twelve products is a win only if twelve products can land. Otherwise it is twelve times the surface area, twelve onboarding flows nobody finished, and twelve dashboards that go quiet in month two. That is not a hypothetical. It is the prototype graveyard at company scale.
Building stopped being the constraint. Choosing did not.
I feel this every week building Heidi. I can stand up more working surface area in a few days than I used to get through a single roadmap review. The wall I hit is never the code anymore. It is deciding what actually deserves to exist, and then being on the hook for it once real people are using it.
That is the shift the title debate keeps skipping. When building was expensive, prioritization was arithmetic. You had eight engineer-weeks, you had a stack rank, you drew a line. Everyone above the line got built and everyone below it got the "next quarter" email. The scarcity did the deciding for you, and it also gave you cover. Nobody blamed a PM for a feature that never got engineering capacity.
When building is cheap, the line disappears and the cover disappears with it. What is left is taste and accountability, and neither one comes with a title change.
The efficiency play is the wrong trade
SC's sharpest point is that AI removed the execution constraint and most companies answered with an efficiency play. Ship more and burn people out, or hold output flat and cut 20% of the team. I agree, and I would put it harder: doing the same work with fewer people is the only use of a new capability that is guaranteed to create no new value. It is a cost line, not a strategy. You bank the 20% once and then you are the same company with a more tired staff.
The alternative is not "ship more." It is spend the freed capacity on the questions you used to defer because they were too expensive to answer. Build the throwaway version of the risky idea. Run the experiment you have been arguing about in a doc since March. Kill three things because you now have evidence instead of opinion.
What a builder actually needs
Four things, none of which a job req can hand you.
Judgment about what should exist. With abundance, prioritization stops being a math problem and becomes a taste problem. The builders I trust can tell me why the obvious feature is a trap.
Evals before code. My spec collapsed into a much smaller set of artifacts once I started writing down how I would know the thing works before I built it. For anything AI-shaped, the eval is the spec. If you cannot describe what a good output looks like well enough to grade one, you are not ready to generate a thousand of them.
Downside exposure, sized honestly. The question is not what happens when this works. It is what happens when it is wrong, how often, and how bad. In Heidi I gate autonomy on confidence combined with reversibility, because a cheap mistake that undoes itself and an expensive mistake that does not are not the same risk, even at the same error rate.
Landing, not launching. Adoption is the job now. If your builders can produce twelve products and your company can absorb one, you did not remove a constraint. You moved it downstream onto people who did not get a 10x tool.
Where I am skeptical
A 10x jump in a job title over twelve months is partly real and partly relabeling. This is a self-reported survey, and a fund that invests on product signals has a stake in the story being big. That does not make the direction wrong. The work is genuinely changing, and titles always lag the work. But some companies will rename PMs to Product Builders and keep the same intake queue, the same three approvals before an experiment, and the same quarterly planning ritual that assumes engineering capacity is the scarce input.
If your builders still need permission from three people to put something in front of a customer, you renamed a role. You did not change one. The 2030 headline is not really about titles anyway. It is about whether your operating model still assumes a constraint that stopped being true.
Try this week
Take one thing already sitting on your roadmap and get a working version in front of a real user without writing the doc first. Then write down what actually blocked you. Approvals, brand review, a data access request, a legal question nobody owns.
That list is your operating model problem. It is the same list whether the PM title survives to 2030 or not, and it is the only part of this you can fix on Monday.
Sources: 2026 CPO Insights Report announcement, Products That Count and Mighty Capital, May 27, 2026. The Rise of the AI Product Builder, Larry English, Forbes, July 30, 2026. The first AI-native role in business, Products That Count newsletter.
Frequently asked
Will product managers really disappear by 2030?+
The 2026 CPO Insights Report from Products That Count and Mighty Capital predicts the title goes away and the Product Builder replaces it, on a survey of more than 1,500 product leaders. The direction is real: traditional PM roles are down 30% across industries and up to 70% inside SaaS, while builder roles are up 10x in a year. But a title change is not an operating-model change. Some companies will rename PMs and keep the same intake queue and approval gates, which changes nothing.
What is a product builder?+
A person who uses AI to turn a customer outcome into working software directly, instead of writing a spec and handing it to engineers. The same report says where it used to take twelve people to build one product, twelve product builders can deliver twelve. It is a bigger job than PM, not a smaller one, because building is no longer the hard part. Choosing what should exist and getting it adopted is.
If building is cheap now, what is the new constraint?+
Landing, not building. The same report shows speed to market became the number one internal challenge CPOs report, up from 14% in 2025 to 22% in 2026, and says the bottleneck moved from building to launching. Go-to-market execution, customer adoption, and organizational alignment are where products now get stuck. Twelve products is a win only if twelve products can land.
Why is using AI to cut headcount the wrong move?+
Doing the same work with fewer people is the one use of a new capability guaranteed to create no new value. It is a cost line, not a strategy. You bank the savings once and become the same company with a more tired staff. The alternative is to spend the freed capacity on the risky questions you used to defer because they were too expensive to answer.
What does a product builder actually need to succeed?+
Four things a job req cannot hand you: judgment about what should exist when prioritization stops being a math problem, evals written before code so you can grade outputs before generating a thousand of them, downside exposure sized honestly by gating autonomy on confidence combined with reversibility, and a focus on landing rather than launching, because adoption is the job now.
How do I tell a real builder shift from a relabel?+
Look at the operating model, not the title. If your builders still need permission from three people to put something in front of a customer, you renamed a role, you did not change one. Take one roadmap item, get a working version in front of a real user without writing the doc first, and write down what actually blocked you. That list is your operating-model problem.
Comments (0)
Sign in with LinkedIn to leave a comment.
Sign in with LinkedIn