The Product Operating Model Was Written for a Company You Don't Have

Sometime in the last couple of weeks you told somebody on your team that they own this.

You meant it. You weren't managing them; you were handing something over because that is what you're supposed to do, and it felt like the right sentence to say out loud. Then a couple of weeks later you found yourself asking for an update. Not heavily. Just checking in, and then checking in again, and by the end of the month the decision was sitting back on your desk, where it had started. Neither of you ever said out loud that it had moved.

That sentence is three words long. It is also, more or less, the entire content of a system that thousands of people have spent their careers on.

What it costs to do this deliberately

JP Morgan's markets division decided to move to the product operating model. The executive who runs that transformation for the markets division laid out the numbers in a session published by JCURV, the consultancy that supported the work: about 8,000 developers, 18 months in, a dedicated team, a standardized sprint cadence, and a coaching council built to support the people learning it.

That is what it took them to get a version of the thing you attempted in three words on a Tuesday. The gap between those two efforts is the subject of this piece, and nothing I read about the model addressed it.

The model, taught straight

The model comes mostly from Marty Cagan and the Silicon Valley Product Group. If you have heard anyone talk about empowered product teams in the last decade, this is where it came from, directly or secondhand. It organizes the work along three dimensions: how you build, how you solve problems, and how you decide which problems are worth solving at all. That third one is the same territory this series has been walking since part one.

Underneath those dimensions sit five concepts, and they are worth naming carefully because the rest of this series uses them as vocabulary.

Product culture is what your company rewards when nobody is writing it down. Whether you would rather be predictable or right. Whether the person who ran a careful experiment and came back with a disappointing answer had a good week or a bad one. You cannot read it off a values poster; you read it off who got promoted last.

Product strategy is choosing what you're going to be good at, and therefore what you're going to be bad at, and then saying so somewhere your team can hear you. The saying-so is not decoration. If you asked six engineers what the company is betting on and got six answers, you don't have a strategy problem to solve later; you have one now.

Product teams describes the shape of the group doing the work, and we'll come back to it. Product delivery is your ability to get software into a customer's hands often and safely, without it turning into an event every time.

Product discovery is the one people find hardest to picture, so here it is concretely. It's a week of talking to eight customers while holding a clickable prototype that does nothing, so you find out on a Thursday in February what you'd otherwise have learned in March, after four people spent the winter building it.

The unit those five concepts assemble into is a small team that stays together, with an engineer, a designer and a product manager in it, and you give it a problem instead of a specification. Not build the export button by June. Something closer to our customers can't get their data out and they're calling support about it, and we need that to stop.

The field's name for the other kind is a feature team: handed the answer and asked to build it, the thinking happened somewhere else and arrived as a list. Both kinds have engineers, designers, standups and a board full of tickets, and from the outside on any given morning you cannot tell them apart. What separates them is where the thinking happened.

And the empowered team is accountable for something different: not for shipping the thing, but for whether the thing worked. Swapping that one word changes the job. If you're accountable for output you're finished when it ships. If you're accountable for outcomes, shipping is the middle, and you aren't done until you know whether the support calls went down.

Which changes the leader's job too. You stop handing out solutions and start handing out context, and the published version of that has three parts: lead with context instead of control, build the team's competence by coaching them, and make sure the people on the team can solve the problem you gave them.

Hold on to that third part.

So why didn't your three words work?

What you did was the model. You gave somebody a problem instead of a solution, you stepped back, and you trusted them. That is the whole idea, executed for free in about a second and a half, with no coaching council in sight. And it didn't take.

It didn't take because empowerment isn't something you hand over. It only becomes possible once two other things are already true.

The first is clarity. Does that person know where the product is going? Not the quarterly goal, the direction: what you're trying to become, and what you've decided you're not. The second is competence. Can they solve the problem you just handed them? Have they done this before? Do they know how to talk to a customer without leading the witness, or how to tell a real signal from three loud emails? That is the third part I asked you to hold on to, and the coaching sitting beside it on the published list is simply how you build it.

Those two are the pillars everything else stands on, and if either is missing, the sentence you said doesn't create autonomy. It creates a person alone in a room with a problem they can't size and no idea which way is north.

What happens next is consistent enough to watch for. They go quiet, because they aren't sure what's worth bringing you. You get uneasy, because you aren't hearing anything. So you ask for an update, then ask again, and somewhere in there you make a decision that was supposed to be theirs. Nobody announces it. It just quietly comes home, and both of you are slightly embarrassed about it. The lesson each of you draws is the wrong one. The founder decides the person wasn't ready, the person decides they were never trusted, and both of them are looking at character when the cause was structural.

The field already knows this

A product coach named Marcus Castenfors wrote a field guide on exactly this: ten ways companies get it wrong when they adopt the model. Silicon Valley Product Group put him on their own podcast to walk through all ten. The first item, ahead of the other nine, is giving teams too much autonomy too soon, and his fix is the two pillars above.

So the field has this right and it's written down where anyone can read it. Which is a reasonable moment to say that the people who publish this model, and the people who wrote the warnings about it, sell transformation services for a living.

Meridian, scored against the five

Meridian is the composite company this series has been carrying: forty people, six engineers, one designer, about sixty customers, and a founder who is also the chief executive and has held product from the beginning because there was never anybody else to hold it.

Put Meridian against the five concepts and the picture is uneven, not bad. Delivery is strong: six engineers who ship every week, almost never break anything, and can put a fix in front of a customer the same afternoon. A lot of much larger companies would take that trade. Discovery is at zero, and I mean absent, not weak. In four years nobody has run a single test to find out whether something was worth building, which costs them things like the payroll integration that reached 80% finished and stopped. Strategy isn't written down anywhere. The founder could tell you what it is over lunch and be broadly right, but ask the six engineers and you'd get six answers, none of them quite his. Nobody there knows that, because nobody has ever put the answers next to each other. Teams doesn't apply yet: what they have is a good team by most measures and simply not the unit this model has in mind. And the culture is trusting, unafraid, and has never once been asked to make a decision explicitly, which means nobody knows what it does under pressure. So what does the model tell Meridian's founder to do?

What I was actually reading

Go back to Castenfors' ten ways this goes wrong. I read all ten expecting a list of mistakes.

Number two is running the change inside the product and technology bubble and leaving the rest of the business in the dark; Meridian's whole business fits in one room. Number four is unmanaged dependencies between teams, and Meridian has one team, so there is nothing to have a dependency with. Number five wants a chief product officer and a chief technology officer who have failed to build a partnership, and Meridian employs neither of them. Seven is about bringing design in after the decisions are made, except Meridian's one designer sits in every conversation there is. And to commit number eight, going all in instead of starting with pilot teams, you would need teams to spare.

By the time I reached the end I had worked out what I was actually reading. That isn't a list of mistakes. It's a list of prerequisites, wearing a warning label.

That's five of the ten, and not one of them describes something Meridian is doing wrong. The pieces those five warnings worry about were never in the building. The five that remain are a different matter. They cover autonomy arriving too early, never balancing new work against keeping the lights on, letting the change stall unseen, answering the what and never the why, and leading without changing how you lead. Every one is available to you at forty people, and the first is the thing this essay opened by describing you doing.

So the assumption runs deeper than the advice does. The people warning you about this model are describing failures that only occur in companies that already have a product organization. The warnings were written by people looking at those companies, which is not a criticism of them and is a problem for you. The model is fine. Nobody ever wrote down how to read it at your size.

One of mine

I have been on the other side of this, which is why I recognize it. I started working on the internet in 1989 and worked on the standards development for the OSI model, seven layers describing how networks should talk to each other, and I gave keynotes about it at trade shows. It is a beautiful model. It's careful and complete, and it's still in textbooks today. The thing running the internet you are reading this on is the other one, the messier one that people assembled out of what worked.

The OSI model won the textbooks and lost the network, and I was one of the people selling it. So when I say a model can be excellent and still not describe your building, I'm not being clever about somebody else's work.

There is also what I couldn't find out. No independent evidence exists that this model works. Not that it doesn't, but no controlled study of it turned up anywhere, and the people publishing it sell the transition to it. Nor can I tell you how many companies operate this way, or what fraction of these transformations succeed. I found several numbers and couldn't check any of them, so they aren't in this piece.

The ideas and the machinery

Nobody separates this model into two piles, so let me do it here. It isn't one thing. There are the ideas and there's the machinery, and they carry completely different price tags.

The machinery is what a company at that scale has to buy: pilot teams, a coaching council to support them, an office to run the change, and a chief product officer and a chief technology officer who agree with each other. All of it needs an organization you don't have, and all of it costs money. So shelve it. Not forever, and not because it's wrong, but because it answers a question about coordinating hundreds of teams, and you have one.

The ideas cost nothing, and you can start on Monday. Hand somebody a problem instead of a solution: one conversation, and the discipline to stop talking before you describe how you'd have done it, which is the hard half. Find out something is a bad idea before you build it. That costs a week of somebody's time and a prototype that doesn't work, set against four people and a winter. And say out loud what you expect to happen when a thing ships, write it where you'll find it again, then go back in six weeks and look. Twenty minutes, twice, and the going back is what turns a guess into knowledge.

And build the two pillars, because everything else stands on them. Write the direction down so all six engineers would say the same sentence. Then be honest about which problems each person can take, and coach the gap instead of pretending it isn't there. That last one is slower than it sounds, because competence is built in the ordinary business of leaving a decision where you put it.

None of that is a compromise or a small-company consolation prize. The model's own advocates have landed in the same place. John Cutler, who has spent years looking at how companies actually work, watched the industry take these models off the shelf and try to install them whole, and watched the fallout; what he sees working is companies that start from a model and then decide deliberately what to take and what to change. That's a real shift, and the teaching hasn't caught up with it. What I read still teaches this as a system you adopt, while the people who know it best talk about borrowing from it instead.

Back to the three words

So: you own this.

The sentence was right. It just arrived before the two things that hold it up, and so it found its way back to you, and neither of you ever worked out why.

Go and find the last decision you handed somebody and then quietly took back. Not to apologize for it. Just work out which of the two was missing, the clarity or the competence.

Dave Saunders is the founder of Base Reality Group and a Fractional CPO for product companies. He was a founder and operator at Galen Robotics, where the surgical-robotics platform earned FDA De Novo authorization in 2023, and he managed a 35-patent portfolio licensed from Johns Hopkins. He wrote Founders Who Finish and publishes The Build. More about Dave →