Everyone's running. Nobody's going in the same direction. That's what a business without a designed operating model looks like.
There's been a lot of conversation lately about product operating models, and most of it is good. How should product teams be organized, how does work move from discovery to delivery, what does decision-making look like inside the product function. Real questions that deserve real answers.
But here's what I keep running into. Organizations redesign their product operating model, get the product side running well, and then wonder why the business as a whole still feels stuck. Decisions still take forever, the customer experience feels fragmented, and strategy doesn't land the way everyone expected it would.
That's because the product operating model was never designed to solve those problems. It handles how you build things inside one function. It says nothing about how the business works across functions. And that cross-functional piece is the part almost nobody designs, because it's literally nobody's job.
POM solves real problems, but only at the function level
Let me be clear: I'm not against product operating models. When an organization is struggling with how their product function works, redesigning it helps. Better discovery, clearer ownership, faster delivery loops. Those are real improvements and I've seen them make a genuine difference.
The problem starts when people treat "operating model" and "product operating model" as the same thing. A product operating model describes how one function operates. The business has a much bigger operating model that determines whether the whole thing actually works together or just looks like it should on a slide.
That bigger model? In most organizations, nobody ever sat down and designed it. It grew organically over years. Shaped by who happened to be hired when, which manager was loudest in which meeting, and which temporary workarounds quietly became permanent. Nobody planned it. It just accumulated.
What falls between the cracks
When I map how work actually moves through an organization, not the org chart version but what really happens day to day, the friction almost never sits inside a single function. It lives in the spaces between them.
Leadership announces a strategic priority. Product picks it up and reorients. But sales keeps selling what they were selling because nobody translated the new direction into their context, and operations doesn't change anything because they never got a brief that made sense for their work. Three months go by. The CEO asks why the strategy isn't landing. Everyone was busy the whole time. The problem wasn't effort. It was that nobody connected the dots between teams.
Or take customer feedback. A support team spots a clear pattern in complaints, something the product team would want to know about. But the path from that feedback to a product decision to an operational adjustment has so many broken links that by the time anyone acts, the signal is old news. Product thinks they're building the right things because their own discovery process works fine. What they don't see is everything that gets lost before it reaches them.
Or product ships a feature and marketing promotes it, but onboarding hasn't been updated, the help articles are outdated, and the service team learns about the feature from a confused customer. The feature technically exists but the experience of using it is broken because nobody coordinated the full chain.
None of these are product problems. They're business operating model problems. And the faster the product team moves, the more visible they become. Speed without alignment just amplifies every gap that was already there.
Introducing SBOM: Systemic Business Operating Model
I've started calling this the SBOM, Systemic Business Operating Model. I haven't found an existing term that captures what I mean, so I named it.
A POM describes how one function builds things. An SBOM describes how the entire organization creates, delivers, and captures value, across every function, from customer need to customer outcome to business result.
It covers the questions POM doesn't touch. How do strategic priorities actually translate into what each function does differently on a Monday morning? Not just product, but sales, service, operations, marketing. When leadership says "we're going customer-centric," what specifically changes for whom, and how quickly does that actually happen in practice?
How does information move between functions? When support sees a problem, what's the real path to that becoming a product input, a marketing adjustment, an operational change? In most organizations there is no designed path. Things travel through informal channels, hallway conversations, and Slack threads, or they don't travel at all.
And who resolves cross-functional trade-offs? When product wants to go one direction and sales needs something different, who decides, and how long does it take? In most companies the honest answer is that it escalates upward until someone senior enough makes a call, and that process alone can eat weeks. That's not governance. It's just escalation dressed up as process.
Why nobody builds this
Here's the structural reason most organizations don't have an SBOM: it falls between everyone's responsibilities.
The CPO owns product. The CRO owns revenue. The COO owns operations. Each of them has a clear mandate to make their function run well. But none of them has a mandate to design how the functions work together. The CEO technically owns the whole thing, but in practice they're managing the leadership team, not sitting down to design the connective tissue between departments.
So that connective tissue stays undesigned. Year after year. It's probably the most consequential piece of organizational architecture in the company, and nobody is accountable for it.
That's exactly why I keep seeing organizations with individually strong functions and a mediocre business overall. Each piece works on its own. The whole doesn't, because the spaces between the pieces were never built with any intention.
What changes when you design one
I've seen what happens when an organization steps back and designs how the whole system fits together, and the shift is real.
The recurring frustration of "everything takes too long" often disappears once you look at it closely, because it turns out the slowness wasn't inside any function. It was in the handovers and escalation loops between them. Design those intentionally and work moves at a completely different pace.
Strategic priorities actually land, because there's a real mechanism for translating a leadership decision into function-specific changes across the business. Not a slide that says "be more customer-centric" but actual concrete shifts in how teams prioritize, measure, and coordinate.
Customer feedback stops dying in transit. When there's a designed path from signal to response, a pattern spotted by support can reach the product roadmap and the operations playbook within the same quarter instead of never.
And the product team's improvements suddenly compound instead of creating friction, because the rest of the system can absorb and act on what a fast product team produces.
Where to start
You don't need a massive program to begin. Pick one customer journey, the real one, and trace it from first contact all the way through delivery. Mark every handover between functions and every decision point where information needs to cross a team boundary. What you find is your actual operating model, regardless of what the slides say.
Then look at where decisions get stuck. Most organizations have a small number of recurring bottlenecks that drag everything down. A feature that needs sign-offs from four people. A pricing change that requires alignment across three departments. A customer escalation that bounces for a week before someone takes ownership. These aren't process problems you can solve with a better workflow tool. They're governance gaps in the business operating model.
The organizations that consistently execute well aren't the ones with the most polished product function. They're the ones that designed how the whole business works as a connected system. That's what SBOM is about. Not replacing POM, but putting it in context, so the part you've improved actually connects to everything around it.
