Somebody Has to Steer: The CPO Now Owns the Operating Model

Atlassian tried the obvious thing. It picked about ten software projects and staffed them with hand-picked AI builders, people whose primary job is shipping code with AI tools. For a few weeks they flew. Then they slowed down.

Sherif Mansour runs AI across Atlassian's portfolio and owns the product management craft for 450 PMs. In Jason Lemkin's write-up of his SaaStr talk last week, his description of what went wrong is one line: everyone was rowing and no one was steering.

I've read a lot about the CPO role this year. That's the most useful sentence in all of it.

This is part 1 of The CPO Transition, a series for chief product officers and for the CEOs and boards who hire them. It's the executive sibling of The FDE Transition. Every part is written against that week's findings, and this one starts with Atlassian's.

The short version

The roadmap was a rationing device. Engineering was the scarce thing, so the CPO's most visible job was deciding what to spend it on and publishing the answer. When a working prototype costs a day, rationing stops being the hard part, and Atlassian just showed what happens when you remove the constraint without replacing the steering: speed, then a stall. The CPO's job is now the operating model that turns customer outcomes into shipped software. That has five parts: the substrate engineering builds so anyone can ship safely, the listening loop, the eval bar, the org shape with the Product Builder as its unit, and the margin. Whether the seat is a CPO, a CPTO, or a founder doesn't change this. Somebody has to own the loop, and the CEO should know who.

What the roadmap was buying

Think about what a roadmap did for a CEO in 2019. It turned a scarce, expensive resource into a public plan. Sales could sell against it. The board could ask about it. And the CPO's authority came from being the person who decided what made the cut.

That's gone, or going. SC Moatti's 2026 CPO Insights Report, a survey of more than 1,500 CPOs, says AI has shortened product cycles from months to days and that the bottleneck has moved downstream, to go-to-market and adoption. The same report puts the drop in traditional PM roles at 30 percent, and 70 percent in SaaS. That's the survey's figure, not mine, but the direction matches everything I see.

If the constraint isn't engineering anymore, the roadmap is rationing something that isn't scarce. I made the full case for retiring it in Kill the Roadmap. The short version for a CPO: if your authority still comes from deciding what makes the cut, it's draining away whether you notice or not.

What's scarce now is judgment about what should exist, proof that it worked, and a business model under it that holds. Atlassian's projects didn't stall for lack of builders. They had the best builders the company could find. They stalled for lack of someone making the calls.

The five parts of the operating model

Here's what I think the CPO owns instead. None of it is new on this site. What's new is putting all of it in one seat.

The substrate. Engineering's highest-leverage work is no longer features. It's the platform that lets a PM, a designer, or a forward deployed engineer ship a change safely: guardrails, an eval harness, isolated deploys, a way to roll back. The CPO doesn't build it. The CPO makes the case that it gets funded ahead of features, and that's a different conversation with the CTO than the one about roadmap capacity. The handbook chapter is Engineering Builds the Substrate, Not Features.

The listening loop. Mansour's PMs who had started coding drifted back to customer context, because supplying it and making decisions was the most useful thing they could do. That's the tell. When everyone can build, the person with the customer evidence is the one who unblocks the team. A CPO who owns the loop makes sure every builder has that evidence daily, not at the quarterly review. See Continuous Listening.

The eval bar. If building is cheap, "done" has to be defined somewhere other than a spec. I think it's the test set. The Eval Is the Spec has the mechanics. For the CPO the point is ownership: the bar a feature has to clear before it reaches a customer is a product decision, and if product doesn't set it, nobody does.

The org shape. Atlassian runs about one PM and designer per ten engineers on product teams. With engineers shipping so much more, Lemkin reports, the PMs say it feels like one to thirty or one to forty. And Mansour's own advice was to build for a 10x team over a 10x individual. I agree with him, and I'd go further. The unit of that team is the Product Builder, the person who holds customer context and decision rights and builds when building settles the argument faster than talking does. I laid that out from the services side in part 1 of the FDE series, and why it's more than a PM who uses AI in A Product Builder Is Not a PM Who Uses AI.

The margin. Every AI feature has a variable cost of goods now. The person who decides what ships is deciding gross margin, whether they look at it or not. Gross Margin Is Your Job Now is the chapter, and the board slide is in The CPO Mandate 2026.

Steering isn't a ratio

The tempting response to Atlassian's numbers is to argue about ratios. Should it be 1 to 10 or 1 to 20? How many PMs do we cut?

Craig Unsworth wrote the best answer to that a month ago in There's No New Magic Product Ratio. AI changes the capacity of each role by a different amount, so the old benchmarks don't transfer. His line: "It's perfectly possible to make everybody faster and somehow make the company no faster at all." That's Atlassian's stall, described in advance.

So the CPO's question isn't how many PMs. It's where decisions get made, by whom, and how fast the evidence reaches them. Get that right and the ratio falls out. Get it wrong and no ratio saves you. Atlassian is adding an AI builder role, and Mansour said it won't cover most PMs or designers at a company of that size. Fair. But what a large org needs is a clear answer to who steers each boat, and that's a design problem for the CPO, not a headcount problem for HR.

CPO, CPTO, or neither

The same week, two companies drew the seat in opposite ways.

On October 6, Dayforce named Jake Varghese chief product and technology officer, promoted from senior vice president of product and technology, where he led application engineering. One seat over both. A day earlier, Guidewire named Dan Brown chief product officer, from the same seat at Celonis and before that 15 years at Microsoft, with Diego Devalle continuing as chief product development officer over engineering and product development. Two seats.

I don't think either is the right answer in general. A merged seat removes a handoff and puts the substrate and the decisions under one person. A split seat keeps a product voice that isn't also accountable for the platform's uptime. What matters is that one person, in either shape, plainly owns the path from customer outcome to shipped software. If a CEO can't say who that is, the title doesn't matter. The last part of this series is about what to do when the seat merges or goes away, because for some CPOs reading this, it will.

For the CEOs and boards reading: stop asking your CPO for the roadmap. Ask them to show you the loop. Who decided the last five things existed, what evidence they had, what bar they cleared, and what they cost to run. A CPO who can answer that is running an operating model. One who answers with a Gantt chart is still rationing.

What's coming

Two parts a week. Next is the CPO and the CEO, telling the AI story without a roadmap and what the CEO should hold the CPO to. After that the CTO and the substrate, org shape and ratios, margin, the loop from FDEs and customer success back into product, the board scorecard, the kill list, design, hiring, the board narrative, trust and governance, and the merged seat. If you're new to the seat, The CPO 30/60/90 and The AI Product Operating Model are the handbook chapters underneath all of it.

One thing to try this week

Take the last five things your team shipped. For each one, write down who decided it should exist, what customer evidence they had when they decided, and what told you it worked. One line each. If you can't name the decider for three of the five, you have a team that rows. Fix that before you reorg anything, because a reorg of rowers is still a boat without a cox.

Sources: Jason Lemkin, "Atlassian's Head of AI: We Bolted AI Onto 20+ Apps, Almost Didn't Ship Chat, and Flipped Our Hiring Toward Juniors," SaaStr, October 10, 2026, saastr.com. Dayforce, "Dayforce Appoints Jake Varghese as Chief Product and Technology Officer," GlobeNewswire, October 6, 2026, globenewswire.com. "Guidewire Names Dan Brown Chief Product Officer," Insurance Innovation Reporter, October 5, 2026, iireporter.com. Craig Unsworth, "There's No New Magic Product Ratio," Chiefly Product, September 15, 2026, chieflyproduct.substack.com. SC Moatti, "What 1,500 CPOs say about their future," Products That Count, May 27, 2026, newsletter.productsthatcount.org.

Part of the running argument on Product Leadership: the product org chart was calibrated to a build cost that collapsed, and the CPO's job is now the system that decides what gets built, not the list of what will be.

Related answer: What does a CPO own when prototypes are cheap?