Solving Organizational Issues like a Product Manager

Working to carve out solutions that address the problems they’re meant to solve.

Where I work, we strive to have an environment where everyone and every team feels, and is, valued/respected.

To strive towards something also means that we’re never quite satisfied with the status quo, and constantly look for ways to improve. That leads to having plenty of ideas, and no way to work on all of them at the same time! And how do we know if an idea is actually effective at solving a problem? Sounds an awful lot like the day-to-day challenges which product teams have, right? Let’s explore if a product team’s way of working can be transferred to tackling organizational issues.

1. What’s the value of solving the problem?
2. Understand the problem, before jumping to solutions
3. Build empathy and hear all sides
4. Define and measure success
5. Find solutions

What’s the value of solving the problem?

Start with deciding whether a problem is worth investigating further. All the following steps take considerable effort, and we only want to go there if the impact is high. How often was it raised in 1:1s, team meetings, postmortems, or informal chats? How badly does it affect people? Were there escalations? Does it impact company, product, or customers in a bad way?

Other than when assessing the value of solving problems within the product, we haven’t seen a strong correlation between how many people bring up an organizational issue and the value of solving it. This might be different for you, so take good care of carefully interpreting the data at hand.

Examples — High value

• Product: The API to add an item to a cart takes more than 1000 ms to reply. That is a long wait time, and the store notices a decline in sales. High value as 40% of customers abandon the site after wanting to add an item to the cart. Meaning all users of the Cart API are affected.
• Organizational: Handing over on-call duties between time zones leads to hiccups in incident handling. It doesn’t happen often — it’s been that way for many years and everybody is used to it — yet whenever it does, it leads to miscommunication with customers and longer recovery times. High value since it happens for an extended period of time, affects many people, and impacts customers.

Examples — Low value

• Product: One customer, who is using a browser that has been deprecated by the vendor, cannot use the storefront and shops somewhere else. Low value as the number of affected customers is barely noticeable.
• Organizational: Support occasionally sends a ticket to the wrong team. The affected team brought it up in a handful of retrospectives, and things typically improve. But whenever a new person joins the support team, it starts happening again. Low value as it only happens around specific events, does not impact on customers, and is solved without escalations.

2. Understand the problem, before jumping to solutions

After we decide a problem is worth looking into, we research it thoroughly. The human brain is wired to jump to solutions very early (Thinking, Fast and Slow is a good read on that topic), and it takes discipline to stay in the problem space.

The effort pays off, however, as only when a problem is understood, can we identify valid solutions. Otherwise, we’ll end up implementing an initiative that sounds like a great idea, but doesn’t perform well in solving the problem.

To understand an organizational or product problem, look at specific examples. As many as you can find: Ask colleagues, dig through meeting notes and retrospectives from the past, and recall similar situations in other companies you worked at. Be aware of your biases and challenge assumptions, and take some time to understand the size of the problem.

If the problem is defined too narrowly, you will miss out on making a fundamental improvement that would also help with other issues. It also gets a bit blame-y quickly. If the problem is defined too broadly, it is hard to find a solution that actually helps.

Example: Team Product is focused on building a new feature. Everybody is excited and things go well until Team Project tells them that they need something else, now, or they will be delayed in delivering critical functionality for a customer project.

• Narrow: “Team Project interrupts Team Product’s flow and focus, which is bad”
• Broad: “Communication between departments has to improve”
• Middle: “We lack a way of handling dependencies that is not frustrating either party”

So be sure to write down a clear problem statement!

Examples:

• “Whenever responsibilities change during the handling of an incident, we see a decline in speed and quality”
• “It is hard for new hires in support to understand which team is responsible for which functionality”
• “Product Managers are worried about the impact a new architecture will have on the product and our ability to deliver value”

3. Build empathy and hear all sides

For products, and especially in UX design, it is important to understand the situation and emotional state a user is in and design the product accordingly.

• Is the user stressed from performing a task? Make it plain and simple.
• Is the user scared, because small mistakes will have big consequences? Add review options and warnings for destructive operations, and reassurance for harmless ones.

When it comes to organizational problems, emotions play an even bigger part. The simple act of talking about problems can challenge how people see themselves or may be perceived as criticism. Understanding the emotions involved helps you to phrase problems in a way that does not call people out or triggers defensiveness. Otherwise, your attempt to solve a problem may create additional ones.

To understand the emotions and build up empathy, nothing beats observing and listening. Schedule interview sessions or group discussions with the main actors and people that came forward.

Here are two quotes about dependency handling to show the two sides of the story:

“Our team spends the vast majority of our time building something to unblock teams. We don’t make any progress on work we see as more important for the company.”

“We are blocked for weeks, as we cannot find a team to build something that we need to proceed, and don’t have the expertise in our team.”

Interestingly, both sides were frustrated about the same thing: Not being able to deliver what they perceive as most important is frustrating!

Use those learnings as input for finding a solution that works for all sides.

4. Define and measure success

Before you’re ready to think about solutions, define what success looks like and how you can measure it. And then make it a habit to look at the numbers to see if initiatives should be kept, adjusted, or stopped.

Examples:

• The number of support tickets assigned to a wrong team stays stable at a max of 5%, even when new members join the team
• Maintenance efforts are reduced to 10% within one year and stay there

5. Find solutions

When building products, we often run into constraints for solutions we find: Do we have the knowledge and skills? Do we have a team to work on this? Is the solution aligned with the product vision, compliant with laws and regulations, can we scale it?

For initiatives to solve organizational issues, the one big constraint is: Does it fit our vision of the company culture? Just like with your product vision — you’ll want to think twice before implementing something that is not aligned with it.

Example: Teams complain that they spend all their time performing maintenance, which they do not enjoy. Your product teams believe in a “you build it, you run it” culture. Consider these two solutions:

• Move maintenance to a specific team or another department. While this would make the problem go away quickly, the solution is not a good cultural match.
• Give teams the time needed to deliver high quality code in order to lower maintenance efforts in the future. While the results can only be seen in the long run, it is aligned with the culture.

Pro Tip: Don’t copy your competition

There are plenty of articles and frameworks about how to set up your teams to succeed. Spotify model, anyone? Just like in product work, it is good to be aware of what your competitors are doing, but not simply copy them. It’s even more dangerous for organizations than for products: A feature that does not fit your customer’s needs can be adopted or rolled back. Solutions to organizational problems often entail changing habits, which are a tough thing to adjust.

Does it work?

I’ve been trying the methods above for some months now, and we kicked off a handful of initiatives with clearly defined problem statements and OKRs. Those even made it on our internal quarterly roadmap, which we extended to also include organizational improvements. So far it’s looking good, but I’m sure there are plenty of other ways to approach this. I’d love to read “Solving Organizational Issues like a Presales Engineer”, “like a 3 Star Chef”, or “like the Tour Manager for a Punk Band” to discover how other teams and organizations are handling the aspects above.