Product Management as System

I love a good retrospective meeting — when the team writes down what’s working, what could be improved. We scribble on sticky notes and place them firmly on a white board. (Admittedly, it’s hard to get the same satisfaction of placing a virtual sticky note, but it’s possible.)

Handled well, this meeting is good for everyone in the room: They share their challenges and their appreciation, and they see what their peers are challenged by and appreciative of.

And then, there’s the analysis. Sticky notes shared by individuals are clustered and patterns start to emerge. I find that it helps to place the clustered sticky notes in context — specifically, in the context of the organization as a system.

To do this, a system diagram helps people understand at a glance where people’s appreciation and frustration is in an organization.

Visualizing Product as a System

The first step to this is to visualize the organization as a system. (See Thinking in Systems as a way to prime yourself to do this.) In this way, every team or group is a node that interacts with every other team. Each system is going to be different, but I’ll use a sample B2B software company, and for this example, I’m using a product management team, but any team or combination of teams could be involved.

To help people visualize this, I create a build and walk people through. Start with the core teams that the Product Management team interacts with — maybe UX and Engineering.

Add the product.

Now, draw the arrows that illustrate the relationships: Product Management collaborates with Engineering and UX (two arrows to each), and Engineering builds the Product. Simple.

But what about product analytics? Doesn’t Product Management review those? Sure. Add an arrow.

And, where do those analytics come from? Customers. Let’s add them. They are interacting with the product.

And then, let’s add some customer feedback arrows.

But, what about the customer facing teams? What about Marketing? Let’s add all those teams in and their respective feedback looks.

Now, we have a version of a system diagram that we can work with. (This is just one example. Expect it to change for different organizational structures. And, if you do this with teams that are not PM, the center should change accordingly.)

Feedback in the Context of a System

Now, remember those sticky notes? We’ve done our morning exercise, and they are off to the side on a whiteboard in two columns:

• What’s working well?
• And, what could be better?

With the system diagram, we can start placing that feedback onto the diagram, and see patterns emerge. We can also see if our system diagram makes sense: If a lot of the feedback doesn’t fit, we are missing parts of the organization.

(Tactical note: keep the what’s working and what’s not working feedback separate. Use different diagrams and compare them. Trying to blend it all at once is confusing — unless you are working online and can hide / display layers.)

As an example, let’s say the following image is feedback of what’s not working well on our system diagram above. What’s the first thing you notice?

This is an organization where the feedback loop between Engineering and Product Management needs help. Things aren’t sticking (pun intended), and the interfaces between the teams need some TLC.

Now, let’s say that we spend the next few weeks or months working on our Product ⇔ Engineering processes. We establish a refined workflow system that people like, we get a good sense of rhythm, and everyone is on the same page.

We go through the whole exercise again, and it looks like this 6 months later:

Now, the challenges look to have moved to the Product ⇔ Customer Facing teams — their shared processes, feedback loops, and expectations.

But, that’s to be expected. And that shift is to be expected — as we solve our toughest problems, new issues arise. Our second toughest problems get promoted to first. Maybe the first scenario was a team struggling to get a new product out the door, and the second scenario is a team now concerned about the customer facing teams’ ability to sell to the customer. That’s an expected progression.

But, what about positive feedback? What about things that are working well. Let’s say that feedback looks like this:

And, while, that seems great on the outside, that could also be a team too introspective. It appears that Product has an admiration for UX, but what can be said for the customer feedback or the product analytics?

While it’s clear to address people’s concerns about what’s working, it’s also enlightening to see what people are appreciative of. And like any smart PM knows that not all feature requests are well articulated by customers, so too is the absence of appreciation that might indicate an area for improvement.

Continuous Improvement and Resilient, Adaptive Systems

Beyond the team goals (which are critically important), a goal of the retrospective is to make the organization a responsive, adaptive and resilient organization. It’s about giving the team the ability to identify and solve issues and respond to changes. Understanding the organization as a system helps everyone put ideas and issues in context so that they can respond and adapt not just to a single issue but to the underlying organizational systems.