We got it all wrong! This is what the double Dimond actually illustrates
Can we use it to make sense of our product organisation?
Ok, so I read Transformed by Marty Cagan - it got me thinking.
Here’s my thinking:
The core essens Martin spells out through out this book is pretty simple.
Change how you build - ship fast. Otherwise you wast time and learnings.
Change how you solve problems.
Change how you decide on what problem to solve.
Strategy = identifying what problem to solve
operations = solve the problem however you like
This is the product operating model that Marty argues is the way to organize to build great products
That’s the core message in five lines of text. (The book is better than my summary and still worth reading if you haven’t yet!)
Now, for my reflections.
Do you remember this little visualization of a process?
Yeah, me too. The good old Double Diamond.
I’ve lived this process for the past decade—in long projects, in PIs, in sprints, in design sprints, and in one-hour workshops. I’ve been running from left to right as a designer, as a product owner, and as a strategist. Exploring problems, pinpointing problems, writing “How Might We”s, exploring solutions, and drilling down solutions to a “low effort, high impact, winning, ship-it-fast” next thing.
I’ve come to realised something.
Being involved in both sides of this diamond works great in small autonomous product teams with few dependencies - Sort out what to do and do it.
It works very poorly in a big organisation.
With hundreds of product temas. Alignment is hard. When it comes to clarity around who is solving what problem and how close are we to actually solving it. Hundreds of teams running back and forth in these diamonds trying to convince each other what problems to solve. Some are exploring solutions to a problem that others solved.
This so called double Dimond Is often referred to as a way to describe a design process.
What if:
It’s also a way of describing a Product Operating Model - a way that all types of designers and product people already know by heart and preach, we just read it the wrong way.
Can we use this diamond to make sense of our organizational chart?
Instead of this:
We do this:
The important difference is Who is doing what tied to this model.
According to Marty Cagan, product leaders should serve the operations org with problems. Not just any problems—well-articulated problems that are critical for the business to solve, complete with a business case and an idea of what output we are aiming for.
The operations teams’ mission is to solve these problems.
This is a very simple way of describing a well-working product organization.
What if product leaders across an organization:
Agreed they all work in the problem space.
Agreed that their main mission is to define and prioritize problems.
Left the operations teams to solve these problems.
“Isn’t that what we’re doing?” you product leaders ask. well... I see a solution hidden in the direction defined by product leaders far too often.
“Grow in this area” — It’s not a problem.
“Improve customer experience” — It’s not a problem.
“Have the best product on the market” — It’s not a problem.
“Move this server to the cloud” — That is a solution, not a problem.
Operations teams have a very hard time acting on this. The result: they identify their own problems and try their best to tie them toward a strategic direction.
What if operations (product teams):
Agreed that they all work in the solution space.
Addressed defined problems with multiple solutions to decide on the best one themselves.
Left the problem space to product leaders.
My point is:
We all need to be super clear about who is working with strategy and who is operating. Who is within the problem space and who is within the solution space.
And what each side can expect from the other.
Maybe this good old diamond can help us illustrate that.
Keep shipping,
Gunnar
Thanks for reading Always Be Shipping! Subscribe for free to receive new posts and support our work.