Root Cause Reasoning: An inside look at how Zoom makes important decisions

Explore

Gallery

Root Cause Reasoning: An inside look at how Zoom makes important decisions

How to identify, communicate, and solve tough problems.

Ross Mayfield

Video communication that just works is one of the hardest problems to solve. So why is Zoom successful? Because at Zoom, we have a decision-making ritual that’s part of our culture — specifically, Root Cause Reasoning (RCR).

⁠

⁠

At Zoom, we care deeply about working on the right problems, and being rigorous in our understanding and analysis of the problem, before we work on the solution.

Causal clarity is one of the reasons why we have been so successful at tackling the immensely challenging problem of video communication on a global scale. Every decision or strategic proposal at Zoom presents a RCR analysis up front and begins discussions with a shared understanding of the Problem, Root Cause, and Solution.

Digging deep for the Root Cause.

Throughout my career as a product manager and entrepreneur, I was conditioned to frame proposals with problems, solutions, and benefits. I thought I was pretty darn good at problem discovery, definition, and prioritization. But something was missing.

When I joined Zoom, I quickly found our Chief Product Officer, Oded Gal, pausing the conversation in a feature review on the first slide to dive deep into problem, Root Cause, and solution with three key questions:

Problem — what is the problem that needs to be solved, and why?

Root Cause — what is the fundamental reason there is a problem?

Solution — what are potential solutions to the problem?

Problem, Root Cause, and Solution are always the first slide. Sometimes a meeting won’t proceed until the definition is agreed upon. The Solution may need further explanation and discussion, but not until there’s a shared understanding of the Problem and Root Cause. And I’ve found a rigorous discussion of the RCR yields better teamwork.

Three optional questions can accompany this slide:

Additional Context — what additional details are important to understand in this situation?

Owner — who is the directly responsible individual for implementing the solution?

Next steps — what needs to happen next to implement the solution?

At first, the practice of defining the Root Cause was challenging for me. But, by asking the right questions you can unearth the Root Cause—the fundamental reason why a problem exists. And if you are defining Problems without a Root Cause, it’s likely that the problem isn’t well defined, you’re solving the wrong problem, and creating subpar solutions. If you find your product team shipping solutions that don’t create the outcome of customer happiness, the root cause can literally be the lack of Root Cause Reasoning.

We’ve used this process thousands of times to identify the Root Cause before building a solution. For a deeper dive on Zoom’s RCR ritual, listen to this podcast with our CTO Brendan Ittelson.

⁠

An RCR example with Zoom Rooms.

⁠

Zoom Rooms⁠

are integrated hardware and software for conference rooms that make it easy to run or join video meetings with a tap of a button.

Zoom Rooms is a good example that illustrates the steps we use with RCR to land on the best solution.

Problem: In the early days of the Zoom Rooms product, customers liked the simplicity, reliability, and overall management of the product. But some customers didn’t want to deploy it because it lacked Calendar and Digital Signage functionality. Customers requested we integrate third party applications.

Root Cause: If the Zoom Rooms product doesn’t own the steady and idle states of the integrated hardware and software, it loses reliability and overall management.

Solution: A CIO needs to come into the room, click a button and have it just work. Since reliability and management were critical, the Zoom Rooms team built the two apps themselves. Making Calendar and Signage native to the Zoom Rooms product at no additional cost. The apps were initially a basic set of features, which helped simplicity and usability.

In this example, if the Zoom Rooms team just responded to the customer defined problem of a lack of integrations, without the Root Cause, the solution would not have met other highly valued customer requirements.

Seven discovery methods Zoom uses to uncover the Root Cause.

Simply asking about the Root Cause when defining a problem is better than nothing. Discovering and defining the root cause can take advantage of methodologies to question, probe, and visualize. Here are seven methods we use to uncover the Root Cause:

Customer Happiness. Part of Zoom’s culture is how we actively listen when customers describe problems or ideas for solutions. PMs only spend 5% of their time talking with customers, so get out there.

Five Whys. We start by asking why does this problem exist? Then ask “Why” to the answer and repeat five times.

Socratic Method.

Six types of questions⁠

guide us to dig deeper for the fundamental truth through probing questions that challenge viewpoints.

Iceberg Model. We explore many

layers of abstraction⁠

through the problems, patterns, and structures happening beneath the surface.

The Ishikawa Diagram. This

visual method⁠

helps us define a problem, branch out into the factors that may have caused the problem, and the Root Causes of those factors.

Double Diamond Design Process. As we converge on what problem is the priority, it’s easier to

narrow the definition⁠

of the problem, including its Root Cause.

First Principles. We use this

physics-based approach⁠

to help “boil things down to the most fundamental truths and reasoning up from there.”

These methods also reinforce and help us practice our team problem solving ritual. While sometimes we go back to the drawing board, the result is always a better analysis and outcome. By collaborating as a team, involving our customers, and asking why a lot, we can reach the Root Cause and define it with causal clarity. The key is drilling down to discover the Root Cause, because without it you may be only solving the symptom of a problem.

Applying RCR to process.

For the PMs, Designers and Engineers executing this process — the RCR is more than a reasoning framework. It is a practice that guides the process from discovery to execution.

After the “groan-moment” when you converge to define the problem to be solved, the Root Cause is reasoned. The Feature Review presents the RCR. After diverging on possible solutions, the Solution Review leverages and checks against the RCR, as does the Final Design Review. You can get an idea of the process from the image below.

⁠

⁠

You can learn more in a forthcoming post from Matt Johnston, Head of Design at Zoom, who will describe and share templates for how we execute a Double Diamond Design Process with RCR.

Bring Zoom’s RCR ritual into your company with our templates.

To put the focus on not just the problem being solved, but the Root Cause of the problem, Product Managers should consider adapting RCR to work with their existing 1-pager or PRD template, like the one I’m sharing here. Here’s how each step works:

⁠

Template: RCR Writeup⁠

- Copy this page for each RCR writeup you create. The writeup is

two-way⁠

, meaning it’s a place to both share your thoughts and gather your team's feedback and questions. I recommend sharing your RCR writeup before a meeting, then spending the meeting discussing the top-voted questions.

⁠

Template: RCR Brainstorm (optional)⁠

- Where there is one problem, there can be many. Brainstorming with colleagues can be a useful divergence to explore issues from many angles in an effort to reach a ranked list of solutions that can be pursued.

⁠

Template: RCR Library⁠

- Once your team starts using the RCR framework, you’ll need a place to store them all. Copy this page to set up a central RCR repository to make it easy for anyone in the company to find past RCR writeups.

When you share this framework with your team, remember that the smallest changes lead to the biggest outcomes. You don’t need to get buy-in from the entire company; it’s ready to go now. I believe you’ll be surprised at how fast the quality of your team’s decisions will improve by consistently pointing them to this template.

To get started, use the button below to copy the template. I’d love to hear how it goes! You can find me on Twitter

@ross⁠

Ready to use Zoom’s RCR framework?

Start by copying this doc, then head to

Template: RCR Writeup⁠

⁠

Copy this doc

⁠

Thanks to the following for their help and feedback: Oded Gal, Jodi Rabinowitz, Kim Gaertner, Lenny Rachitsky, John Cutler, Colin Bryar, Yuhki Yamashita, Eyal Manor, Rushabh Doshi, Shiva Rajaraman, Mads Johnsen, Oji Udezue, Vinod Suresh, Surojit Chaterjee, Shishir Mehrotra, Nicole Stoltenberg, Taylor Pipes, Erin Dame, and Justin Hales.

⁠

Gallery

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.