TBM 409: Minimally Viable Consistency (Part 2)

Help needed! I have to do some discovery for the PM day job with enterprises that sell non-digital products (consumer, cars, toys, media, etc.) and have 1000+ people across product, engineering, design, data, etc. Specifically I am looking to chat with people working at companies in the middle of some sort of “product operating model” transformation. And AI, of course. Because that’s everyone it seems. Ideally, manager or senior manager level, currently at the company or very recently left, and tasked with enablement, product operations, or strategic finance.

I’m looking for about 20 minutes of discovery, and I’d be happy to spend the other 25 minutes chatting about anything to return the favor. My goal is 30 calls over the next couple of weeks. Not sales oriented in any way. Though I’d be happy to show you what I’m working on.

Grab some time here!

---

I’ve been thinking more and more about the challenge of defining “minimally viable consistency“ across a company’s operating system. From that post:

The general idea, in the context of how I’m using this, is that when you’re designing your company’s operating system, you should strive to have the fewest number of consistent concepts, terms, and phrases possible that still allow you to operate the way you need to.

In workshops, and in customer conversations, the idea has legs. It sparks great discussions about common interfaces, cognitive load, and the benefits of local variation. But it can be devilishly hard to get right.

Model Market Fit

You often can’t plan what things will take hold in a company. Perfect plans, glossaries, and frameworks fall apart, and then suddenly the idea you least expected to take hold at a global level catapults to the front. I think of this as Model Market Fit (MMF).

For example, I have a friend who has been gung-ho on the North Star Framework for years and couldn’t get it to stick. Meanwhile, their design leader peer was heavily involved in journey mapping. For some reason, journey maps took hold in the company. You couldn’t make them (journey maps) go away as a “consistent” idea, even if you wanted to. Everyone was talking about journeys.

I kept telling him, “Look, turn that driver tree on its side and lay it alongside the journey map, and you’re done. Stop being dogmatic!” He didn’t listen. And that played out predictably. (X, if you’re reading this, I told you so 🙂).

But this pattern holds in countless conversations. Ideas spread across companies in unexpected ways. Ask someone about the founding story behind key rituals or ideas in your company, and you’ll often be surprised to learn about what “won”.

Shifts in Strategy and Structure

I think one of the hardest situations is when strategy shifts, but the structure in your company hasn’t yet caught up. The strategy is changing. The structure hasn’t caught up, or you’re experiencing a temporary hit-and-shift. These are the moments when people become desperate for consistency, because they suddenly need to work across boundaries.

Working across boundaries benefits from consistency. Before, when things were less coupled, teams could get away with aligning on a couple of key things. Now there’s more demand.

I don’t have the answers here, except to say that it is largely cultural.

For example, do you start codifying a “dependency object” more consistently in your tool of choice? Do you start holding meetings around those dependencies? Or does that actually encourage the very thing you’re trying to stop? Are you willing to keep things ambiguous for a bit?

Many dependency management practices encourage premature convergence on solutions, over-reliance on estimates and guesses, and generally prevent leaders from resolving their priority differences. At the same time, treating dependencies consistently can be very helpful for overloaded, centralized teams. It can also become a weapon for over-eager teams that have the favor of leadership and want to command everyone’s time.

This is where things get tricky. You have to step back and think about the behavior you actually want.

In many cases, dependencies aren’t the real problem. Prioritization at a more global level is the problem. So you could decide on a graceful prioritization heuristic at the leadership level that doesn’t create too many negative downstream effects and resolves many of the dependency deadlocks.

But that is hard, so people don’t do it. And then suddenly, you are debating the common definition of a dependency.

Action Item: Be especially careful during a big strategic shift. You may introduce some “temporary consistency” to stabilize the situation, but don’t get too used to the new reality.

The Myth of the Standard Framework

One trap is assuming that because a framework is well known, teams are actually doing the same thing. Take OKRs. They feel extremely standardized. Everyone knows the terms. The books exist. The templates exist. The slide decks look similar. It creates the impression that companies are running the same operating model.

In reality, the implementations vary wildly.

Some organizations treat OKRs as a strict hierarchy. Others connect them loosely through shared metrics. Some anchor everything on quarterly objectives. Others build driver trees underneath. In some places, OKRs are deeply tied to financial planning. In others they function more like directional bets.

In Dotwork, we’ve started cataloging the different patterns we see in customer environments. The diagrams above are all “OKRs,” but the structures are fundamentally different.

The other trap is assuming that this variation is a bad thing. And maybe this is the beauty of the “consistency” of OKRs. The language is consistent enough that people can recognize it, but flexible enough that teams can bend it to their context.

Or maybe that’s the problem. You have to be the judge in your company.

Avoid The Pyramid

The further away ideas get from teams, the more ambiguous they seem to become. “Pillars,” “Vision,” “The CTO 5,” “Strategic Opportunities.” This makes perfect sense because these objects tend to do a lot of work. There is an optics component. There is a basic grouping element (”There’s so much going on, I need these in buckets”). You’ve got Slideware. You’ve got overlaps with the org chart (”portfolio”), which start eating into the actual meaning of a portfolio.

The unfortunate reality is that these are often the things people point to as the “consistent” ideas in their company, yet they are far from actionable. They are roll-up mechanisms.

All of which is to say there are better places to spend your time: on key, consistent fractal rituals, on your approach to framing bets, on new language around the unique, quirky habits you have as a company, on consistent kickoff formats, or a special document you use.

For example, a consistent culture around a certain quirky-named one-pager format will go a very long way. A “pillar” on the Parthenon slide will not.

Viability

The obvious problem is “viable for whom?” The CTO who believes everyone should work in two-week sprints so that they can generate a certain report likely believes that getting everyone working in two-week sprints is both viable and valuable. They probably don’t see a downside.

They may even see a looming existential threat that no one else sees (like someone with even more sway who believes they need a report). I’ve met leaders in this situation who know the downside, but rationalize that the people who really care will work around the rules anyway, and that the benefits of outward legibility and consistency outweigh the downside and the mild inconvenience of going through the motions of running sprints.

And I have to admit, sometimes I don’t fault their logic. They have a point.

The people gluing an organization together see the cracks formed by poor interfaces (they literally absorb the friction and cognitive load). Still, the people on the other ends of those interfaces might feel very differently. Finance needs to fit things in certain buckets. That’s how financial reporting works, and unless you figure out how to play that game in a more product-like way, you’ll have to play along with their “viable” game.

Building shared understanding around viability is hard.

Permanent Scaffold

The next challenge is to strategically use consistency as a scaffold when people are less experienced. It is a teaching aid. Before they go off freestyling, it can be helpful to have somewhere consistent to start. But then that gets old. Slowly, the guardrails come off, and you start to expect people to forge their own path.

The trouble is that companies are littered with these scaffolds. They represent the baggage of long-lost change and upskilling efforts, and as long as they are just a mild inconvenience, no one minds checking the boxes. But they can drag an organization down.

For example, say a team is learning new product discovery skills. It might be important to put a label on that, and maybe even tool-ify it. But as those product discovery skills become ingrained, you no longer need the formalization. Lo and behold, years later, there is still a checkbox in some system for “discovery complete”.

All to say that tread lightly when the goal is up-leveling and/or norming. Write down an expiration date, or at least a date to reassess the constraint.

Some Questions:

If this wasn’t consistent, what is the worst thing that could happen?

What actual risk are you trying to reduce? Confusion, coordination failures, reporting gaps, regulatory risk, something else? Be specific. If the worst outcome is mild inconvenience or cosmetic inconsistency, the consistency requirement may be overkill.

Does this idea make people’s lives easier or harder?

If it makes things harder, is the hardship justified by a real long-term benefit? Would customers actually pay for the outcome this consistency produces? Or is it primarily benefiting one group (leadership, reporting, governance) at the expense of everyone else doing the work?

Is the idea graceful? Does the idea bend well to local variability?

Is it strategically simplifying the situation? Or oversimplifying? Like any model, it will be wrong, but is it still useful? Does it clarify the system and help people reason about their work, or does it add more conceptual clutter?

Can teams adapt it where local conditions genuinely differ? Some variability is beneficial. If the idea breaks the moment a team operates differently, the consistency may be too rigid.

Are there cheaper ways to achieve the consistency you want?

If the goal is consistent behavior around something, could you nudge people in that direction without a heavy rule? Examples include examples, defaults, templates, visibility, or shared artifacts instead of mandates.

Does this consistency have an expiration date?

Is this a scaffold for learning, onboarding, or stabilizing something new? If so, when should it be revisited or removed?

What would it take to remove this later?

Once consistency mechanisms get embedded, they rarely disappear. If you needed to retire this rule or structure in two years, would it be easy or painful?