How to simplify complex issues
Help people understand you without losing important parts of your message
A few years ago, a friend asked me if I recommended a certain restaurant in New York City. I started explaining the pros and cons of that place and comparing it to other similar restaurants I had been to when she interrupted me and asked:
“So, recommend or nah?”
I was a bit annoyed at this. I wanted to give her all the relevant information so she could make an informed decision, but she wasn’t interested. Instead, she wanted me to do the heavy lifting and distill everything down to a simple “Thumbs Up 👍” or “Thumbs Down 👎”.
My initial takeaway was that this friend didn’t approach the search for the perfect restaurant with enough rigor. But I also had a sense of déjà vu; I had lived through almost the exact situation before, and after a while I remembered when and where:
Every time I talked to an executive.
Executives want their teams to bring them recommendations, not explanations. But early in my career, when an executive asked me to make a call, my reflex was to say “It’s not that simple, you see; here are all the complicating factors.”
I felt like they didn’t understand the complexity of the situation and it was on me to educate them. It took me a while to realize that it wasn’t my job to highlight complexity, but cut through it and simplify issues to help make decisions.
Bringing complexity into a discussion is not a sign of intellectual horsepower, but rather a sign that you haven’t put in the effort to simplify the issue to the parts that really matter.
But there are risks to simplification as well; if you simplify an issue or your message too much, you risk being misunderstood. Take image compression as an example:
If you can compress the file size of a RAW image by 10x by turning it into a JPEG and, with the naked eye, it still looks the same, great!
But if you compress it further, at a certain point it becomes a pixelated mess. The fact that it’s only a few kilobyte in size doesn’t help if you can’t tell what’s on the picture.
The same applies when simplifying complex issues at work. But how do you know which information you can safely “cut out”? That’s what this post is for.
I will cover:
What it means to cut through complexity
9 techniques for simplifying without distorting your message (+ real-life examples)
What it means to cut through complexity
In Business Operations, Data Science, Marketing or Product Management, the work we do is complex, but the decisions we are ultimately trying to arrive at are simple:
Do we roll out or roll back this feature?
Do we scale this campaign?
Do we go with vendor A or vendor B?
The decisions we have to make are typically binary choices (Yes/No) or choices between a limited set of options.
The complexity comes from all the factors influencing the decision. We need to analyze all the relevant dimensions and decide how much weight we place on each.
For example, if we are trying to choose between different software vendors, we have to consider price, features, which other software the tool integrates with, customer support, etc.
But not all information is important to the decision at hand, and it matters how we present it.
The key is to simplify by 1) reducing an issue to the essential information and 2) organize information so that it’s easy to understand.
Why don’t we just always do this?
First of all, it’s difficult. We need to distinguish between what’s critical information and what can be “safely” ignored, and the difference is not always obvious.
But we’re also scared of consequences. There’s safety in providing information overload; we’re worried we’re making the wrong recommendation or decision, and if we mention every single consideration and caveat, we are covering our asses.
Unfortunately, this prevents us from moving forward.
➡️ Because most people increase complexity rather than reducing it, you will immediately stand out if you simplify well.
9 techniques for simplifying without distorting the message
So how do you simplify without risking to be misunderstood? Here are 9 techniques I regularly use and that have worked well, especially when dealing with executives.
Techniques 1 - 8 will help you simplify an issue by getting rid of non-essential information, while technique 9 will provide you with two ways of organizing information to make it easier to digest.
Technique #1: Leave out the how, focus on the what and “So what?”
For almost any decision you’re trying to make, it’s irrelevant how you arrived at your conclusion.
Even if you’re proud of the analysis you ran or the experiment you designed; when you’re trying to drive a decision, this background context is just a distraction.
Real-life example
❌ “We designed an experiment with New York, Los Angeles and San Diego in the treatment group and Washington D.C., Seattle, Houston and Chicago in the synthetic control group. We picked the synthetic control markets by looking at…”
The methodology of your analysis can go into the appendix; if someone wants to go deeper or challenge the validity of the conclusions, you can get into the technical details.
In your initial communication, however, you should focus on the takeaways instead of burying them under technical details:
✅ “We saw a 15% lift in traffic in the treatment group, as well as a 5% lift in leads. Despite lower-than-average conversion of the traffic, the cost-per-lead is still within our guardrails and we recommend rolling the campaign out nation-wide.’
Technique #2: Leave out the boilerplate disclaimer
Nothing is ever certain, and no analysis is perfect. While it’s understandable to feel the need to explain yourself, giving generic caveats is not helpful.
For example, everyone knows that your projection for a new product or market launch is an informed guess; there’s no need to highlight all the things you don’t know for certain.
Instead of listing our every unknown, focus on the variables that affect the decision.
Real-life example
Over the years, I have been part of more forecasting and planning efforts than I can count. Even at large companies like Meta, our forecasts were usually much less robust than we would have liked.
Sometimes we were forecasting new business lines that we didn’t have enough historical data for, other times there were external factors like the iOS privacy changes or COVID with massive, but hard-to-predict impact.
Still, repeating the generic caveats didn’t help anyone:
❌ “The forecast is based on limited historical data and the numbers might change as we get actuals. Assumptions are based on an extrapolation of current macroeconomic recovery; a further deterioration of the macro environment would put the plan at risk.”
If you do want to give an idea of the risk in the plan, you can show the range of expected outcomes and show how they affect the decision you are trying to frame.
For example, if you are trying to decide how many Sales people to hire and you are forecasting lead volume to inform this decision, you could show the following table:
Technique #3: Apply the 80/20 rule
When you are trying to explain something, focus on the handful of things that moved the needle the most.
Let’s say you miss your alarm, get up half an hour late and miss your train. You could talk about the fact that your drive to the train station took 3 minutes longer than usual due to traffic or that the train left 1 minute earlier than scheduled.
But in the grand scheme of things, these are negligible factors and would just distract from the core reason you were late.
Real-life example
One of the most common tasks at work is to explain a change in a metric or the differences between two versions of a deliverable:
Why did revenue drop by 20% compared to last week?
Why is the new budget proposal $20M higher?
❌ I’ve seen many comparisons that look like this (and have produced a few myself over the years). It takes a moment to make sense of all the information and figure out what matters:
✅ If you focus on the key drivers, instead, the message is immediately clear:
Technique #4: Use simple language
Technical jargon makes it harder to understand you, especially if your audience does’t have the same background as you.
Sometimes, people are worried that by not using the “correct” technical terms, the message and the resulting conclusions become inaccurate. However, most of the time, if you think you cannot say what you need to say in plain English, it’s because you haven’t understood the topic deeply enough yourself.
Reciting the text from the Wikipedia page minimizes the risk that we say something “wrong”, but it also makes us harder to understand, so try to say things in your own words.
Real-life example
Technical functions are typically the most guilty of this.
Over the years, I’ve seen Data Scientists provide a lot of summaries like this:
❌ “We updated the churn model by tweaking thresholds based on the ROC curve and were able to lift Recall to 0.65.”
Business stakeholders will have trouble understanding this. Instead, you can simply explain what it means:
✅ “We made the model more sensitive so we pick up more cases where users will actually churn. We are now able to detect 65% of these cases.”
Technique #5: Make things apples-to-apples
We often make comparisons between things that are not directly comparable.
When you’re comparing numbers in different currencies, across different time horizons (e.g. daily vs. monthly), absolute numbers vs. percentages, engagement lifts vs. revenue etc., your audience has to do the work of translating the information to make it “apples-to-apples”.
Real-life example
When people size the impact of initiatives, they often quote whatever number is easiest to calculate. You then get a table like this as a result:
Which initiative has the best expected ROI? If you express the impact of every initiative in terms of the same metric instead, it becomes much easier to compare.
Technique #6: Avoid excessive detail
Just because we have access to hyper-granular data doesn’t mean we have to use it.
Looking at user-/transaction-/vendor-/product-level data can be helpful for investigations, but when you’re trying to frame a recommendation or decision, it typically just adds noise. Aggregates make it much easier to digest information while still maintaining the relevant high-level trends.
Similarly, there are very few cases where hyper-exact numbers are needed.
✅ “Option A saves 10% (roughly $0.5M) compared to Option B”
is sufficient.
❌ “Option A saves 9.79% ($488,920) compared to Option B”
just makes the information harder to digest without adding anything important.
Real-life example
At UberEats, there were some legitimate reasons why we looked at restaurant-level information. For example, a restaurant chain might have complained about the reliability of certain locations and we wanted to deploy highly targeted fixes.
But most of the time, super granular data just made it hard to grasp what was going on:
If you look at aggregate data, instead, trends become more clear:
Technique #7: Avoid variants at all cost
Most issues are complex enough if you are keeping track of just one version. If you create multiple versions, you will lose track and cause confusion sooner or later.
Real-life example
This issue happens a lot with plans and goals.
You start with one version of the plan, but then teams want to understand a few different scenarios (“What if we don’t invest as much in International?”).
Then, you go through reviews and iterations and soon you have the original version you discussed with the CEO, the one you showed to the board, and the final version you’re locking. And naturally people want to keep track of all of them.
And once you start tracking performance against the plan, of course, you start adjusting the actuals as well (“Can we just see what performance would be if we take out that one-off item?”).
This always ends up in confusion and sleepless nights trying to reconcile numbers. Fight as hard as you can to keep the number of variants as small as possible.
Technique #8: “Cancel out” common issues
If you are trying to decide between multiple options, the only thing that matters are the differences between them.
Anything that they have in common can be ignored to simplify the situation. This is similar to a math equation where common terms and factors on both sides of the equation can be removed through the right operations, making things much simpler:
Real-life example
Coming out of COVID, a lot of metrics reverted to pre-pandemic levels.
This recovery was happening regardless of what initiatives we were launching as it was driven by external factors like shelter-in-place mandates being lifted.
So when we were comparing different project proposals and their projected performance in one of my previous jobs, adding the COVID recovery impact into each scenario made things more complex without adding any value.
What mattered was just the incremental growth in each scenario on top of the organic recovery that was happening across the board.
Technique #9: Organize Information
Even if you have simplified an issue with the techniques above, it can still be difficult to get your point across.
To show your reasoning and avoid misunderstandings, organize the information in a way that makes it easy for your audience to follow along.
Frameworks
Frameworks help make sense of complex issues by forcing them into a streamlined structure.
Here are a few commonly used frameworks and the situations in which they are most helpful, inspired by Tessa Xie’s recent post; if you’re a Data Scientist or just work with data a lot, check out her newsletter for highly actionable advice.
Issue Trees
What: Issue trees allow you to break down a complex issue that you are analyzing into subcomponents that are easier to grasp. They follow a hierarchical structure with the key issue or question at the top and supporting considerations below.
When: Issue trees are helpful when you want to take your audience through the problem solving approach.
How: Consider the following (abbreviated) example where we are trying to figure out why revenue dropped:
Decision Matrix (“Traffic Light Approach”)
What: A decision matrix lists out the alternative options on one axis, and the decision criteria on the other axis. In the so-called “Traffic Light” approach from Meta, each cell in the matrix is colored Green, Yellow or Red depending on how an option ranks for the criteria in question.
When: If you are evaluating a few alternatives and you don’t have an agreed-upon weighting of the different criteria, the (color-coded) decision matrix makes it easy to see the pros and cons of each option.
How: Check out this (made-up) example of a planned international expansion:
2x2 Matrix
What: A 2x2 matrix boils a problem down to a simple grid with four buckets, defined by two dimensions.
When: This is a great framework if you want to drastically simplify an issue. For example, if there are a lot of potential factors to consider but you think only two really matter, a 2x2 can get the point across and focus your audience.
How: Consider this example from my recent post on how to pick the right projects to get promoted:
Visuals
Visuals are great for explaining processes or systems; describing all of the steps and relationships in text is cumbersome, but a diagram makes them easy to grasp.
For example, let’s say you want to explain how your Marketing attribution works. A pure description is hard to follow:
❌ “When an opportunity gets created in Salesforce, we check whether there was SDR activity against the lead in the last 14 days. If yes, we attribute the lead to “Sales Outbound”. If not, we look if there are UTM parameters from a Paid campaign. If yes, …”
Instead, you can visualize the information in a flow chart:
Closing Thoughts
Simplifying things might seem easy. Everyone can dumb things down by just eliminating all nuance from an issue. But as a result, the message often gets distorted to a point where misunderstandings or bad decisions follow.
The trick is to simplify where it doesn’t cause harm; hopefully this post gives you some pointers on how to do that.
Excellent lessons, Torsten!
Reminds me of a story:
A senior Coast Guard Captain, sitting at his desk, was presented with the summary of a situation by one of his new subordinates, a young Ensign.
The Ensign asked the Captain what he should do about the situation. The Captain took a deep breath, looked down at the floor, and bit his lower lip. He was clearly discomfited.
The Ensign stood by, mystified at what he could have said to upset his Captain.
Finally the Captain looked up, held his hands open, and said, "John, if I tell you what to do...well then I'm doing your job."
The Captain explained:
"In the future, when you bring me something, always bring a recommendation. That way, if I agree, I will OK it and the decision will have been made as efficiently as possible.
If I don't agree I will tell you why, and we have a solid basis on which to discuss the proposal."
The Captain was the best boss the Ensign ever worked for.
Hi, can I translate part of this article into Spanish with links to you and a descripción of your newsletter?