TBM 338: 4 Core Product OS Design Competencies

As a follow-up to TBM 336: Product OS Design Tips and Principles, I want to address a question that came up from a TBM paid subscriber:

What skills and experience do companies have that are thoughtful about this stuff? All these principles make sense, but not many companies have the right skills and mindset to make it worth and be intentional.

Over the last two months at Dotwork, I have talked with many product and operations leaders about how they work—their detailed rituals, names for things, artifacts, rhythms, norms, tools, and tactics for making things work. It has been a wonderful deep dive into all sorts of inspiring (and quirky, and opinionated) design decisions. I'm learning every day!

Here is my current thinking based on what I've learned.

In companies that do this, you tend to have strengths in all four of the following areas:

1. Leadership and influence

2. Domain experience.

3. Systems thinking

4. General operations and tooling

Leadership and influence

A product operating system means nothing without key leaders' full support and participation. In the past, I've fallen into the trap of catering to the needs of the front lines without paying enough attention to influencing key leaders and gradually swaying their perspectives. Influencing is a skill. Leading people through changing conditions is a skill—you must be comfortable discussing uncertainty in ways that don't freak people out. There's a good chance that some leaders in the company are low on systems thinking and domain knowledge (see below), in which case you'll need to be skilled at storytelling, persuasion, and "simplifying things so they don't seem too scary."

An anti-pattern is when product operations leaders are left to do the dirty, messy work while other leaders inadvertently (or sometimes intentionally) undermine things as a way to hedge. You need to have the chops to make sure this doesn't happen.

Domain experience

It helps to have done "the thing" or at least be able to internalize the nature of the thing deeply. If, for example, you've only done FinOps or RevOps, you may have a tough time jumping into a product operations role. People with deep experience working on product teams will have evolved their intuition for how the work works, assumptions that fall flat, and when and how collaboration needs to happen. They'll better understand what should (and can) be automated and what should be high-touch. They'll realize when "simple requests" might become time-consuming and disruptive.

If someone is very strong in systems thinking and can operate from first principles—or if they're extremely good at learning quickly from the doers—they may not need firsthand experience. An additional layer of complexity is that, since product work is so diverse, having firsthand experience in one context (say, massive fintech B2C) may not prepare you to fully understand the nature of work in another environment (like B2B SaaS).

I'm amazed by how many organizations follow a system designed in haste by chiefs of staff far removed from day-to-day work. It isn't their fault—they were probably handed the task in haste—but it impacts the team nonetheless.

Systems thinking

Designing a product operating system involves a mix of systems, service design, behavioral, human factors, game, ecosystem, and—well, you get the idea—lots of thinking, awareness, and design. Some people have an intuitive knack for all this stuff, while others run in the opposite direction the second things get "complex."

While experienced leaders often have a finely tuned understanding of certain human behaviors, it isn't a given that they're skilled at thinking holistically about human behavior and psychology. What got them there—drive, steadfastness, ambition—often predisposes and biases them toward views of the world that don't represent the full cross-section of how people think about work. That's OK! It's unreasonable to expect everyone to be good at everything, but it's important to rope in people with systems thinking and design toolkits when necessary.

General operations and tooling

Operations is a domain unto itself. You have to be good at understanding stakeholder needs, mapping workflows, stitching together systems, modeling data, and rolling out change. You build a knack for looking at how things work and surfacing opportunities to make them more effective and efficient. A good operations person doesn't love or hate tools—tools are just one part of the puzzle. When something works, that's great. When something doesn't work, they figure out a path forward.

Operations people don't balk at a huge Miro board, Lucidchart diagram, spreadsheet filled with messy data, or the challenge of linking multiple tools. They don't balk at the prospect of getting hundreds of people to fill out a form manually but are always asking whether there's a way to save people the burden. Part of being good at operations is also building a sixth sense for when the operations toolkit isn't the right toolkit for the job.

Gaps and Overlaps

To recap, we have leaders and influence, General operations and tooling, systems thinking/design, and domain awareness. I don't want to overwhelm you with a four-circle Venn diagram, but using this model, we might explore some traps:

• Operations without domain experience leaves you with efficient processes that miss the real needs.

• Systems thinking without leadership leaves you with brilliant designs no one follows.

• Operations without leadership influence leaves you with optimized processes no one adopts.

• Operations without systems thinking and design leaves you with well-oiled processes that break under pressure.

• Systems thinking without operational follow-through leaves you with frameworks that never come to life.

• Leadership without domain awareness leaves you with confident decisions built on shaky assumptions.

With this in mind—and given that no one is strong at everything—you can consider how to combine the diverse skills necessary to design and evolve a product operating system.

Based on my research, in companies that get super nerdy and intentional about designing a purpose-built OS, you tend to have a strong history of leaders who care about this. Not all do! They were more likely than not to write things down and solicit feedback. They were less likely to say things like, "Ugh, let's not reinvent the wheel, just come up with something, and let's go!"

Experience doing product (and the power to set norms) also made them stubborn. They challenged things like story points, administrative tasks that encourage premature convergence, and performative rituals that don't add value. A leader distanced from the work without the will or support to push back on their bosses doesn't take a stand like this.

Check out this fun example from Chase Warrington of Doist of a company digging into their quirks and putting together a tailored way of working.

It it completely unique? No! Is it customized and personalized? Yes!

I hope this helps!