To understand why we should organize our business according to the Product Operating Model, let’s first take a step back and examine the reality we operate in. We live, work, and conduct business in a complex environment, often referred to as VUCA—Volatile, Uncertain, Complex, and Ambiguous. Just looking at the sheer number of possibilities around us, it becomes clear how difficult it can be to make the right choices.
My understanding of complexity aligns closely with this definition from Wikipedia:
“Complexity is the level of unpredictability within a context. A context made up of a large number of components, especially when these components have different characteristics, and when the characteristics are interdependent, is perceived as complex. Contexts that involve random or poorly explored characteristics often become complex.”
In my world—developing tech products for customers across the globe—uncertainty and possibilities are endless, making many of the challenges I face inherently complex.
To address complex problems, I often turn to Dave Snowden’s Cynefin Framework. If you’re unfamiliar with it, I highly recommend exploring it, but a fair warning—it took me a few years to grasp the basics and a few more before I could begin teaching it. Despite some name changes over the years, I often refer to three key domains: Simple, Complicated, and Complex. Here’s a breakdown of how I explain these:
Simple: A simple problem has a repeatable solution, often based on best practices. Manufacturing on an assembly line is an example. In my analogy, painting a single wall in the room you’re in is a simple problem. You gather paint, brushes, cover the floor, and get started. For the next wall, you can repeat the same steps with consistent results.
Complicated: A complicated problem doesn’t have an obvious solution, but there are several possible approaches. You can solve it with the right expertise and planning. In my metaphor, painting all the walls on an entire floor of a building is complicated. There are multiple rooms, furniture to move, and people to accommodate. With analysis and planning, however, you can break this into smaller, manageable tasks and get it done efficiently.
Complex: A complex problem is entirely different. In the Complex domain, you can’t predict the outcome of a solution beforehand. You need to experiment, observe the effects, and then build on that knowledge. In my analogy, this would be creating a painting that sells for over a million at auction. There are countless unknowns, and success requires trial and error. You must adopt an experimental mindset.
Most of the challenges we face in today’s world fall into the Complex domain. For instance, how do we build the best possible product for diverse customers, outshine competitors, and launch at the right time? These are complex problems.
Solving Complex problems
In the Complex domain, the key is to find potential solutions (which may themselves be complicated), test them, and see if they work. Given the many possibilities, it’s crucial to keep your experiments small to avoid wasting time on dead ends. Equally important is the ability to get quick feedback to assess whether you’re moving in the right direction. It exemplifies the Build-Measure-Learn loop.
Another critical aspect of solving complex problems is data. The more high-quality data you have, the better your chances of finding an effective solution. Tackling these problems in a team, with multiple perspectives and skillsets, is far more effective than working in isolation. Think of it like AI—the more data it trains on and the more processing power it has, the better the results.
In the discovery phase (which I’ll elaborate on in a future post), we aim to open up as many potential solutions as possible before narrowing down and deciding which to implement.
In Conclusion
To solve complex problems, you need diverse teams working together in an experimental way. And yes, our world presents us with plenty of complex challenges. This is why teams, not individuals, are crucial to problem-solving in the Product Operating Model.
One key difference between teams in the Product Operating Model and those in other models is that these teams are responsible for solving complex problems themselves. They aren’t handed solutions by others. Instead, they take full ownership of identifying, exploring, and implementing potential solutions.
In my next post (coming soon), I’ll dive into why teams in the Product Operating Model tend to outperform others and explore the patterns that lead to their success.
This was my second brain dump into posts around the product operating model. This time it was about the Why, if you need to know the basics start here