Reframing the PMO's Role in a Product Operating Model

I've spent twenty years in PMO roles, and two months in this particular one, leading a PMO through a shift to a Product Operating Model. I want to write about it now, mid-transition, because the honest version of this story is more useful than the tidy one I could tell later.

For most of my career, the PMO's job was clear and, frankly, comfortable. We ran the intake process. We owned the stage gates. We kept the RAID log and made sure nothing moved from one phase to the next without the right sign-off. We produced the status report that told leadership whether a project was green, yellow, or red. It was control, exercised at the level of individual projects.

A Product Operating Model, or POM, changes the unit of work entirely. Instead of temporary teams assembled around a project scope, you have persistent teams, product, design, and engineering together, who own an outcome over time rather than a deliverable with an end date. Funding follows the team and the problem they're solving, not a fixed project plan. Success is measured by whether the outcome moved, not whether the original scope shipped on schedule.

When I first sat with that definition, my honest reaction was that it sounded like the PMO's job description with everything crossed out. No more gates. No more phase-based sign-off. No more single owner of the master project plan. If you strip away the old tools, what's left for a PMO to do?

Two months in, I don't think the answer is nothing. I think the answer is that the PMO's job moves from controlling individual projects to building the organizational muscle that lets persistent teams actually work well. That's a real function, it's just not the one I was trained to do for the first fifteen years of my career, and I'm learning it in public right now rather than after the fact.

Take triads. In the old model, the PMO ran the meeting cadence: status calls, steering committees, checkpoints where a project manager reported progress upward. In a product model, the operating unit is the triad, product, design, and engineering, working together continuously rather than reporting to each other periodically. Right now, we're figuring out what a healthy triad even looks like. Some default to product talking and engineering listening. Others leave design out of the room entirely. This is squarely PMO work, just aimed differently than before. The same instinct that used to drive a steering committee, get the right people talking regularly, surface conflict early, keep decisions moving, is exactly what's needed to help a triad find its rhythm. I'm just applying it to a standing team instead of a project timeline.

Then there's the epic and feature work in JIRA, which is where the tension I most want to name shows up. Engineering needs epics and features detailed enough to size and build well. Getting there means raising the maturity of our backlog, and that's raised a real fear on the product side: if POM's whole premise is protecting space for experimentation, doesn't asking for more structured, better defined epics work against that?

This is exactly the kind of tension the old PMO discipline is built to resolve, even though the old PMO never framed it this way. The RAID log habit, the instinct to map dependencies and risks before they become expensive, doesn't disappear in a product model, it just moves earlier and gets aimed at discovery instead of delivery. My argument to product, and I'll admit I'm still testing it in real conversations, is that the space for experimentation belongs in discovery, before something becomes a committed epic, not inside the epic itself once engineering is building it. A vague epic isn't protecting experimentation, it's usually just an epic that skipped discovery. The PMO's job here is coaching that distinction into existence: helping product build the discovery habits that make early ambiguity productive, so that by the time work reaches engineering, rigor and speed are working together instead of against each other. That's a direct descendant of the same skill that used to make me good at keeping a RAID log honest. I'm just using it earlier in the process and calling it something different.

The third piece is IT Ops and InfoSec. In the old model, the PMO often sat between delivery teams and those functions, routing approvals, translating requirements, owning the checkpoint where security or operations signed off before something moved forward. In a product model, that partnership has to live inside the team, continuously, not at a gate near the end. Product is still building that muscle, and so, frankly, are Ops and InfoSec, who are used to being consulted at a milestone rather than embedded in an ongoing conversation. Brokering that shift, helping both sides find a working rhythm without the old checkpoint to lean on, is squarely a PMO function too. It's just relationship infrastructure now instead of an approval gate.

I don't have a resolved story here. I'm two months into a role that's still finding its shape, inside an organization still finding its shape around a new model. What I do believe, more now than when I started, is that the PMO doesn't disappear in a product operating model. It stops owning the gate and starts owning the muscle building: healthy triads, backlog discipline that protects rather than kills experimentation, and functional partnerships that used to run through a PMO checkpoint and now need to run directly between teams, with PMO support rather than PMO control.

If you've led a PMO through this shift, particularly the backlog rigor versus experimentation tension, I'd like to hear how you framed it, because I suspect I'm not the only one working through it in real time.