This is a piece I am very proud of. It came “all at once” in a single sitting, but captures many strands of thinking that have been bouncing around in my head about transformation, evolution, and organizational change for years.

I am frequently asked about product operating model maturity and what good looks like. If you read my writing, you know that I am hesitant to answer these types of questions. Why? Because it is never as simple as a linear model. Even when there is a journey that makes sense on paper, you find nuances, negotiations of meaning, and competing ideas. POM, for example, is a context-free model, so I find discussions of maturity rather boring.

​What fun is the idea of maturity without context?

​That said, I talk to a lot of companies and do notice patterns. I feel the push and pull as new ideas emerge. I also notice the loops: how ideas are Trojan-horsed, become mainstream, and then are rejected. I find it all very fascinating, especially when it’s happening within the same company at the same time.

​Below, I take a journey across companies at different stages of evolution. I explore the competing mental models, what is important, and how perceptions shift. It is not an attempt at a linear model or a maturity model, but rather a narrative device.

Act 1: Delivery Predictability and WIP Reduction At Scale 1.

Act 2: Early Introduction Of Goals 1.

Act 3: Goals Come First 1.

Act 4: Emerging Value Models And Chaos 1.

Act 5: Converging On Value Models

This is not a maturity model. It is a prototypical, yet nuance-filled journey.

At first, the focus is on the work and how it rolls up. People want to figure out ways to limit work in progress and get the “flow” of delivery going. The business is harping about predictability, and they have a point.

Strong demand for insights on dependencies, how delivery is cascaded, etc. Teams “commit” to way too much work for various reasons. In this stage, any effort at prioritization is welcome as long as it helps limit work in progress and flow. Any improvement in “knowing when things will land” is important. Strong emphasis on dependency transparency, “who is working on what”.

This Act is about “intake processes” that help limit WIP and generally show where things are stage-wise. You see emphasis on delivery management and the rituals to help resolve deadlocks.

A leader might say something like, “We need to improve our Say/Do ratio here.” The work and batch sizes are “big”, even when there is continuous delivery happening on the front lines (e.g., long epics, long initiatives, etc.). Product management is essentially non-existent at the moment, and you might have product “owners” or requirements-decoders who help grease the wheels and “get the business what they asked for.”

Dominant mental model: Work is the unit of reality. Progress means moving work items through stages. Predictability comes from controlling intake, dependencies, and throughput.

Competing mental model: Some work is more valuable than other work. Flow and predictability are necessary but not sufficient. Not all commitments should exist in the first place.

Perception of tech value: In the first phase, the value of technology is equated with reliable delivery. If teams can move work through stages, reduce bottlenecks, and make commitments that hold, then technology is seen as doing its job. The dominant question is whether the organization can ship what the business asked for.

Predictability is treated as Value. Improving flow is treated as progress. There is little separation between doing work and creating value. Technology is judged solely by throughput.

Then we start to see the hints at “outcome centricity”, often in the context of introducing OKRs or similar. The decision to try OKRs might have even come from HR, or it might have been used in another part of the company. But in the early stage, goals are essentially tacked on to work, at least at lower levels of the goal hierarchy.

Someone has heard that OKRs are a best practice and feels strongly that they might start to hint at value and strategy. While goals themselves are not inherently about strategy or value, by putting numbers on things, they are making an early effort at outcome-centricity. But again, it takes the shape of saying, “OK, if we are successful at this initiative, what will happen?” There is little emphasis on the mental model of work as a “hypothesis” to achieve certain key results. Measurement rigor is low, and often the metrics used for Key Results are basically “did we do X?”

This is an odd time because the work hierarchy is still alive and well, and then you’re introducing an objective hierarchy. The two models might be conflated or overlapping. There are decisions like how “tall” to make the goal hierarchy, and the org may fall into the pattern of making it as tall as the org chart, or mashing together work hierarchy items. If you had initiatives or similar programs containing these initiatives, you might see an effort at parallelism between the two, influenced by the work hierarchy, when a single objective system, or objectives and annual KRs mixed with quarterly KRs, might be sufficient. The goal cascades are more influenced by the org chart than by any real sense of progress.

Aside, during this time, the org is intentionally addressing the core architectural issues that were likely causing the big batches, dependencies, etc., mentioned in our first phase. They’ve hired technology leaders who understand the relationship, and they are prioritizing this work. You can’t process and framework your way out of Phase 1 problems.

**Dominant mental model: **Work comes first. Goals are annotations on work. Success is delivering what was planned.

**Competing mental model: **Goals might be primary. Work might be in the service of outcomes. Delivery alone is not the point.

Perception of tech value: With the introduction of goals and OKRs, technology starts to speak the language of outcomes, but the underlying belief remains that delivering work is the main event. Goals are layered onto initiatives. Metrics are attached to projects. Reports look more sophisticated, but success is still largely defined as completing what was planned. Technology is now expected not only to deliver, but also to explain its delivery in terms of outcomes. The value model is still work-centric, just with numbers attached.

The next phase is a shift in which the objectives and key results start to COME FIRST, instead of the other way around. You begin hearing words and ideas around hypotheses, opportunities, options, and bets. Initiatives take the form of interventions to achieve a result.

This doesn’t mean that every effort needs rigorous hypotheses and is cloaked in uncertainty. As Zsolt Berend, co-author of Sooner Safer Happier, explains:

Not every objective is truly a bet. Some are predictable, some involve bounded uncertainty, and some are genuinely exploratory, and therefore volatile. It is useful to distinguish between improving known systems, choosing between viable options, and exploring the unknown.

The key point is the “mindset” that goals come first, even when you “just need to execute.”

While “big projects” persist, hopefully the batch sizes and team independence are starting to reduce the amount of premature convergence on solutions (or, on the flip side, the absolutely last-minute convergence around solutions because it suddenly becomes a hot priority). Objectives are becoming the focus of how leaders state intent, instead of work grounding the conversation, and objectives coming later.

Instead of seeing the “Oh wait, everyone, create your OKRs, create your OKRs, after months of planning”, there are efforts to solidify drafts of those objectives as a catalyst. You still hear people saying things like, “I’m not sure anyone is really using OKRs” or “The OKRs always come after the work”, but you also start hearing things like “We locked down our goals for H1 of next year, and the teams have started to work on their goals, and the work that will impact that.” It is a transitional stage. While not a strategy per se, one could start to get a decent sense of a technology/product strategy from connecting the dots between objectives.

Goals at this stage become much better articulations of problems or opportunities to chase.

**Dominant mental model: **Objectives are the main expression of intent, but still coexist with a strong work hierarchy. Work and goals are parallel rollups that must be reconciled.

Competing mental model: Intent is expressed as desired outcomes, but there is no shared value model to anchor them. Goals float without stable value nodes to ground teams, investment, or architecture.

Perception of tech value: As objectives come first, technology is increasingly valued as a way to pursue opportunities rather than simply execute plans. Initiatives become bets. Work becomes an intervention in the service of a desired result. Leaders express intent through goals, and technology is expected to organize itself around that intent. Delivery still matters, but it is no longer the only story. Technology’s value is framed as advancing declared objectives, even if the deeper structure of value is not yet well defined.

Meanwhile, something is brewing. People are talking about value as something distinct from objectives. They might be chatting about customer journeys, the North Star Framework, capability trees, “value streams” beyond operational value streams, and related topics. Re-orgs might be in the works. The pressure is on to augment strategy with different, viable models.

The early platform work planted the seeds by refactoring the big systems, so now people are saying, “Look, I like that platform work, but is it really supporting how we create value?” These conversations are not ubiquitous by any means. In fact, it is very niche. Enterprise architects with a product bent. Design. Product leaders are asking if the org chart is truly aligned around a technology and product strategy.

There is a strong focus on org design as it relates to clearing out dependencies, but, most importantly, aligning that org design around emerging ideas about product-centricity and platforms organized around a customer-facing value chain (though deeper in the stack).

This stage is confusing because, in a sense, three conversations are going on at once in a push-and-pull: work, objectives, and value (with all the related context models underpinning value).

You might be in a conversation, discussing work, goals, AND context models. Early on, you funded projects. Then delivery “lanes”. OKRs didn’t change the funding ideas much at first, but the introduction of outcome language started to shift how ROI was perceived. And now you get to this weird liminal stage where people are talking about funding projects, objectives, AND teams grounded in stable context value models at the same time. An exciting but tough place to be, because it is a mish-mash of perspectives.

It is about this time that you might see tech/product have the opportunity to articulate a distinct, understandable, “not just a list of projects”, or “not so vague they could exist anywhere” strategy.

Remember, you are still experiencing all of the motions mentioned at once. There are still remnants of centralized IT somewhere in the org. There are “super high performing customer-facing teams” doing all the things. There are old IT systems turned platforms that weren’t really platforms, morphed into “real platforms” with all the friction that entails. You have a lean portfolio management crowd, a strategy crowd, an OKR crowd, a “product operating model” crowd, and everything in between, all sorts of vying to understand their contexts, and influence the bigger picture.

**Dominant mental model: **Objectives are the highest-order abstraction. Strategy is expressed as stacked goals, and value is assumed to emerge from achieving them.

**Competing mental model: **Value models are emerging, but fragmented and contested. Multiple frames for value compete, and there is no settled way to anchor objectives, teams, and investment.

Perception of tech value: In the next phase, people begin to ask whether technology is supporting the company’s actual value creation. Conversations shift toward customer journeys, platforms, capabilities, and value chains. Technology is no longer just expected to deliver work or achieve goals, but to shape enduring structures that enable repeatable value creation. Multiple theories of value coexist. Work, goals, and value models all compete as organizing principles. Technology is pulled across these frames, and its value is actively contested.

Something starts to “win” in the soup of models. Future phases are about reinvention, shifting strategies, drifting backwards in some ways, and responding to macro trends. We start to get closer to running like a pure, digital product-first technology company that got lucky when it scaled. The important point is that the org chart, value understanding, goals, architecture, and “the work” are much more aligned around value and the long-term success of the company.

Instead of completely distinct value systems (e.g., “sales has a strategy, and product has a strategy, and they feel like they’re on different planets”), the different value models interact—acknowledging that there’s a tension between short-term results and the longer-term product strategy. The focus is onInterfaces and healthy tension, not blissful ignorance punctuated by outright conflict.

The product and tech strategy feels real, not just complementary to the business strategy but part and parcel of it.

Perception of tech value: As value models converge, technology becomes inseparable from how the business operates. Org design, team boundaries, funding models, and architecture align around shared value structures. Objectives attach to these structures. Work flows through them. Investment decisions reference them. At this point, technology is not simply supporting the business. It is part of the business model itself. The value of technology is no longer argued. It is built into the organization’s thinking and actions.

In a table, the journey might look like this:

You start to reach a level where value models underpin the org chart, independent teams, local, outcome-oriented work, funding based on “products”, thinking holistically across the value chain, and the ability to iterate on those value models.

A reminder that this is not a linear journey

It is worth restating that none of this is a linear path. It is less a progression through stages and more a stumbling forward, or a journey forward. These are not clean steps. They are overlapping periods of time, with multiple conversations happening at once. There is usually a dominant narrative about the current “problem,” reinforced by leadership messaging, frameworks, and tooling. But underneath that narrative sit many other forces, often competing, shaping where the organization actually is and offering contradictory perspectives.

Fix one problem, and new ones appear. Project accounting is relatively straightforward. You fund a scoped piece of work, track spend, and declare success if the thing ships. Move to product funding, and suddenly you have to confront causality, time horizons, attribution, sustainable growth, and vanity claims on impact.

As Felipe Castro, well-known OKR and transformation coach reminded me:

The evolution is not linear or maturity-model-like. Organizations evolve along different dimensions at different paces. It is common to see companies introduce OKRs without any real grasp of outcomes, or attempt outcome orientation without having WIP under control. These things rarely unfold in a clean sequence.

A company might reach something like the fifth act described above, only to find that a shift in strategy, market conditions, or technology pulls them backward. The platform that supported one value model now constrains the next. Progress in one dimension exposes fragility in another.

A quick detour into the product operating model. The trouble with the product operating model frame is that, depending on where you’ve entered this process, it could mean and be blocked by very different things. For teams to take an outcome-oriented approach, you can’t just install OKRs. Teams need to be independent enough and the org’s mental model sufficiently aligned to focus on objectives/opportunities/problems FIRST, then work on potential solutions.

This is as much an architectural and org-design problem as it is about “mindset” (or more, IMHO). You can’t just will your way into “funding products” if no one even has a reasonable sense of what a product, or node in the value chain, or whatever, actually is. You can’t do discovery if designers are matrixed across dozens of teams, and are only “part” of the team on paper.

I also want to point out that “super mature” product organizations tend to mash together a lot of ideas around work, goals, value, strategy, etc., into basic ideas. From the outside, it might look like they are “just using OKRs,” but that is because many of the ideas are so baked into how they think that they can shorthand.

Perfect example: say you have a group where all the teams are aligned around a customer journey. That is a model. But maybe the org chart is enough. No one needs to restate that model. It is OK if it lives in Miro somewhere. People have internalized the idea. Same with outcome-centricity. Many touted product companies are actually VERY project-focused from the outside. Why? Because they don’t bother to mention their metrics, trees, goals, etc. That is all figured out, or is more figured out, which means that it isn’t really worth repeating.

What makes it harder for other companies on the cusp or in the mish-mash between the stages here is that there’s nothing that helps with legibility. They’re running a bunch of other motions at the same time, so simply baking the product taxonomy into the org chart isn’t enough for the different groups trending in that direction who need more formality.

At Dotwork, we have the concept of the “four graphs”: Intent, Context, Collaboration, and Investment (I referenced these in the table above).

In writing about this journey, I’d add more nuance:

You can state intent in many ways: work is intent, goals are intent. And we see above a transition from the Work Only, Work First/Goals Second statement of intent to Goals First, Work Second. So, within the intent graph, there are some sub-graphs. 1.

Context is purposefully abstract, but the basic idea is that it might cover things like customer segments, value models, strategic context, etc. It isn’t intent, but it supports intent. It isn’t collaboration, but it is the stuff that shapes the org chart. It isn’t an investment, but it structures how investment and return are conceptualized.

Going back to this journey, we see that the successive evolution of context models is a critical thing to follow. You go from:

A completely implicit context model (or basically, the org is designed around the context of a system/technology), to... 1.

A very active debate around which context models should be used (e.g., stable metrics trees, North Star, customer journeys, or all of the above), and then an interesting dynamic where context models get baked into the org chart and become “just how we work”, so they might not be as explicit. 1.

Over time, across this journey, different concepts get introduced, then “overburdened” as ideas, decouple, and eventually fade as they become super integrated.

Take work as an example.

The org builds a work hierarchy that is mostly devoid of any real goals or sense of value. Then, as they introduce goals, they start mashing the concepts together. You are going from one rollup to two rollups. Are they related? Are they the same? Should one come first? Does one lead to the other? What do you do with the work that is big and messy by definition?

That goes on for a bit, and then one idea takes precedence (say, goals). But then they start calling goals the “value hierarchy”. Well, realistically, they aren’t about strategy. Again, they may convey strategy, but they aren’t strategic in isolation. But goals are what you have, so you start to burden more value ideas on them. Until that snaps, and someone comes up with a value model/hierarchy that you can hang goals off of.

You have this cycle of evolution where ideas get introduced, slowly co-opted, bifurcated, re-combined for convenience, and then split for good. And then fade away.

They build on each other. If you can’t ship anything and work in huge batches, you can’t really be outcome-oriented. If you can’t be goal-oriented, you can’t really start thinking about progress towards value and shifting investment to return.

There is none.

So what is the end of all this? What is the step after the step I mentioned?

Well, new ideas come around. There is no end-state. Take all the companies that thought they had everything figured out, and then AI came around and made their org chart look antiquated. Take all the companies that believed in going “multi-product” and hiring a bunch of GMs, and the pendulum swung back to coherent platforms.

No posts