How to solve problems

An in-depth guide to understanding, structuring and solving any problem that comes your way

Feb 07, 2025

👋 Hi, it’s Torsten. Every week(-ish), I share actionable advice to help you grow your career and business, based on operating experience at companies like Uber, Meta and Rippling.

If you enjoyed the post, consider sharing it with a friend or colleague 📩; it would mean a lot to me. If you didn’t like it, feel free to send me hate mail.

When you read job postings, one of the most common requirements is “strong problem-solving skills”.

That seems reasonable at first glance; companies hire people because they have problems they need solved.

But what does it really mean to be good at solving problems?

In my experience, it boils down to this:

Most people can only solve problems they have encountered before. For example, you hire someone who built Marketing attribution at another company to do the same at yours (and they’ll pretty much copy/paste what they did the last time).

Very few people, however, are good at reliably solving problems they’re encountering for the first time.

After all, you can’t just do what you did last time, and there might be no guide for this exact problem.

But it’s an absolutely crucial skill, and not just for “generalists”. In high-growth companies, what got you to the current stage is not going to get you to the next level, so even if you specialize in an area like Growth Marketing, you need to deal with new challenges all the time.

The goal of this article is to help with that and give you a general purpose playbook for solving any problem that comes your way.

It will be split into at least two parts; in this post, we’re going to cover how to analyze the problem and find potential solutions.

In the second part, we will discuss how to present these options and decide on the path forward. Check it out here:

How to get decisions made

Torsten Walbaum

Feb 24

Read full story

Let’s get into it.

Why problem solving fails so often

The number one mistake people make when it comes to problem solving is to start discussing solutions before they’ve fully understood the problem.

It’s enticing; we often feel like we know already how to solve the issue and want to move forward. I’ve seen this especially in high-growth companies where “moving fast” is one of the most important principles.

But if you don’t take the time to deeply understand and define the problem first, there is a high risk you choose the wrong solution and have to re-do things later.

In other words, moving too fast can actually end up taking more time than a structured, deliberate problem-solving approach.

For example, in my previous job at a B2B SaaS startup, we wanted to put an account score in place for the Sales team. Most people immediately started talking about vendors we could work with, or brainstorming what type of ML model would be best suited for this problem if we built it in-house.

This is an example of jumping into the solution space before fully exploring the problem space. Instead of discussing what we were going to use the score for and, as a result, what it needs to look like, they were trying to go straight into execution mode.

But how can you decide if any of the options in front of you are a good fit if you don’t know exactly what your requirements are?

Assessing the nature of the problem

If you want to solve a problem, the first step is to understand that type of problem you’re dealing with.

Is it a one-way door or two-way door decision?

When you’re trying to decide whether to optimize for speed or finding the optimal solution, the key deciding factor is the cost of being wrong.

Besides the business impact of the decision, what determines the cost of being wrong is how hard (or costly) it is to reverse.

If it’s easy to reverse, you can just go ahead and try a solution. If it doesn’t work or turns out to be not an ideal fit, you just roll it back and try something else—no harm, no foul.

For example, instead of analyzing in-depth what format your team meeting should have, just try something and iterate based on feedback.

For decisions that are costly—or impossible—to reverse and have substantial business impact, however, you should put in maximum effort to find the ideal solution. The cost of being wrong is high, so you need to minimize the likelihood that you’re wrong by using a structured problem-solving approach like I’m describing in this post.

Essentially, you’re trying to minimize the expected cost of your decision:

Jeff Bezos calls these one-way door and two-way door decisions. Here’s a helpful overview of how he thinks about them at Amazon:

Can you break the problem into smaller steps?

Many problems seem impossible to tackle. There are simply too many unknowns and dependencies to make a decision that we feel comfortable with.

Luckily, we can often make things simpler by splitting one big decision into a sequence of smaller ones. Ask yourself:

Is there an initial small test you can do to gather data and decide on next steps?

For example, deciding whether you should enter the UK market and open a local office is a big decision that’s hard to unwind (you’d have to break your lease, let people go etc.). However, people in the UK speak English, so you could start reaching out to potential customers with your existing Sales reps in the US (they just have to work slightly odd hours).

If the response is good, you can start hiring your first dedicated Sales people in the UK. Then, if deal close rates and contract volumes justify further investment, you can hire management and supporting functions and build out proper local operations.

All of a sudden, instead of deciding whether to make a multi-million $ investment in a new market based on research and hypotheses, you just have to decide if it’s worth asking one or two existing employees to shift their focus for a few weeks.

What are the opportunity costs of the decision?

Decisions don’t happen in a vacuum.

Often, deciding to do one thing means not being able to do something else. As a simple example, hiring one candidate for a position means saying “No” to all other candidates.

Similarly, our future options for solving a problem might be limited based on a choice we make today.

For example, when I was at UberEats, DoorDash made some controversial pricing and UI changes in their app. We had to decide if we wanted to publicly slam them for their choices or not.

This decision had serious consequences for our own product strategy in the future. If we took a public stance that these choices were bad for couriers or end users, we would essentially commit to never implementing any of them ourselves (even if that might put us at an economical disadvantage).

Takeaway: The more downstream implications the decision has, the more effort you should put into analyzing the problem and deciding on the path forward.

Is it a recurring or one-off problem?

Recurring problems require a different approach compared to one-off decisions.

There are two types of recurring problems:

You have to deal with the exact same thing on a regular basis

For example, every week, you have to go through hundreds of customer support tickets to identify common themes.

In this case, you’ll want to automate the solution (e.g. asking an AI agent to parse the tickets and highlight important topics) so you don’t have to keep solving the same problem over and over again.

You deal with similar problems on a regular basis

For example, you might be wondering on a regular basis whether you need to get legal sign-off for a new project or feature you’re working on.

In these cases, you’ll want to develop a principle that gives you clear guidance on how to handle these things going forward. So by solving the problem comprehensively once, you solve all future instances as well.

Symptoms vs. root causes

One final thing to consider: If you’re dealing with similar problems over and over again, you should ask yourself whether you’re actually solving the underlying problem, or just fighting the symptoms.

For example, when I was at Uber, we had constant debates between the Central Operations team (which I was on) and the local City teams over pricing and incentive decisions.

In the beginning, I thought I needed to define a principle that told us when we should or shouldn’t launch additional incentives. However, after a while, I realized that this didn’t actually solve the issue and I was just playing corporate whack-a-mole.

The reason we kept having these conversations was because we hadn’t clearly defined the roles and responsibilities of the teams.

So what we really needed to do wasn’t to decide under which conditions we should run promotions in a given market, but define clear swim lanes with leadership so that one team could unilaterally make the call.

Defining the actual problem you’re trying to solve

Most of the time, people don’t throw problems your way, but instead give you tasks. In other words, they only share with you what they think the solution should be, and they don’t share the context of the underlying problem.

The issue with this:

Without deeply understanding the problem, you can’t do a good job on the solution.

For example: Somebody might ask you to pull a list of the number of businesses by country. But that’s not the actual problem they’re trying to solve.

Once you ask why they want that information, you learn that they are trying to rank countries by market size
If you ask “why?” again, you learn that they are trying to decide which market is most attractive to enter next

Only once you have that context can you start being a thought partner in solving the problem. For example, you might realize that many registered businesses are 1-person sole proprietorships—that your company wouldn’t sell to—and suggest additional filters to apply to the analysis.

Or, you might suggest a completely different framework for ranking markets altogether.

Depending on your seniority, you could even peel back another layer and argue that the true underlying problem is that the company is trying to figure out how to unlock additional growth, and entering a new market is just one of the options on the table.

But: While digging into the “why” is helpful, you should be careful not to overdo it and waste time by trying to reopen issues that have already been decided.

For example, if leadership has already decided that you’ll launch a new market, and the only question is which one, there’s no point in debating that point.

Identifying and structuring your options

In order to decide on the best path forward, you should first lay out all possible options. In a second step (which we’ll cover in the next section) you’ll then narrow things down.

The most important thing is to make sure the options you’re identifying are MECE (Mutually Exclusive and Collectively Exhaustive). This means you try to find all possible options and define them so that none of them overlap.

For example, let’s say you’re trying to decide whether to buy an AI agent from a certain vendor to automate a task, and these are the options you come up with:

These three vendors are not a MECE set of options. Instead of buying from one of them, you could:

Buy from another vendor
Build the agent in-house, or
Simply do nothing (and continue doing the work manually)

In fact, “do nothing” is an option that’s often forgotten, but it’s an important one to consider. Even if the status quo is suboptimal, it might still be better than any of the alternatives on the table.

And solving a problem always comes with opportunity costs: If you spend time and money on solving it, you’ll have to deprioritize other things you could do instead.

So how do you come up with the possible options?

To get as many alternatives on the table as possible, a brainstorming session with the team can be helpful.

In addition to identifying options you might not have thought of, you’ll make sure that everyone feels heard. This will eventually make it easier to get buy-in.

However, you’ll likely end up with a lot of half-baked and overlapping ideas, so you can’t just put them all on a page and call it a day. Instead, a single person should be in charge of cleaning up and summarizing everything in a MECE way.

For more complex problems, a great way to do this is using an issue tree. Let’s say you’re trying to figure out how to grow marketing leads for your business. This is what the results of a brainstorm and the resulting issue tree could look like:

Evaluating the options

Step 1: Developing an evaluation framework

With your options laid out neatly on paper, you need to figure out how you’re going to compare them against each other so you can eventually frame up a decision.

In the example above, you could simply say you’re going to look at:

How many leads you can get from each possible lever, and
What the expected financial efficiency of each is.

If you’re concerned about your ability to implement them, you could also consider the operational lift required. Or, if you need the leads fast, you could rate each option with regards to how long it will take to yield results.

There is no right answer here; it ultimately depends on what you care about (or rather, what you think the person who will ultimately make and own the decision will care about).

Cool. But can you pretend you do so we can rank the choices?

Step 2: Analyzing the options

Once you have your evaluation framework, you need to analyze each option across the criteria you came up with.

In many cases that means doing data analysis or modeling (e.g. estimating the number of leads and efficiency in the example above); in other cases it means doing research or talking to subject matter experts (e.g. to estimate the implementation effort).

The most important thing is to spend your time effectively. There are two considerations that can help you here:

1. 🎯 Prioritization

You should spend most of your time on the factors that will affect the decision the most.

For example, if you know that the business is struggling to hit growth targets, then the number of leads you can get from a growth lever will be the most important estimate to get right.

2. 🔢 Sequencing

If there are requirements that are non-negotiable, you should start with those.

For example, in the scenario above, you might know that the Marketing team needs to show results next quarter. As a result, any initiative that takes longer than that to show an impact can be immediately disqualified.

Similarly, if you’re selecting between different vendors, first check if any of them are missing must-have features. If so, there’s no need to evaluate them for the rest of the criteria.

Your goal should be to start with the analysis that can eliminate as many options as possible early on, so you can minimize the amount of work you have to do.

Outlook

At this point, we understand the problem, have structured it, identified our options and analyzed them. That means we’ve done most of the work.

However, without a decision on the path forward, you can’t go and implement your solution. And often, that decision isn’t up to you; instead, you need to present the options and your recommendation to an executive and get their sign-off.

In the next post of this series, we’ll cover exactly that.

How do you present the options and your recommendation to the decision maker?
How do you make the decision-making process efficient?
How can you avoid constantly reopening decisions that have already been made?

We’ll also review some of the most popular decision-making frameworks that leading companies are using.

Stay tuned! I hope to see you then. If you want to make sure you don’t miss it, subscribe below.

💼 Featured jobs

Ready for your next adventure? Here are some of my favorite open roles, brought to you by BizOps.careers (sorted from early to late stage):

Cartesia: Chief of Staff to the CEO | 🏠︎ 𝗟𝗼𝗰𝗮𝘁𝗶𝗼𝗻: San Francisco | 💼 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲: 3+ YOE | 🚀 𝗦𝘁𝗮𝗴𝗲: Seed | 🏛️ 𝗜𝗻𝘃𝗲𝘀𝘁𝗼𝗿𝘀: Lightspeed, General Catalyst

Zoox: Strategy Associate | 🏠︎ 𝗟𝗼𝗰𝗮𝘁𝗶𝗼𝗻: Foster City, CA | 💰 𝗦𝗮𝗹𝗮𝗿𝘆: $124k - $178k | 💼 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲: 3+ YOE | 🚀 𝗦𝘁𝗮𝗴𝗲: Public (acquired by Amazon)

Google: Chief of Staff, YouTube Business | 🏠︎ 𝗟𝗼𝗰𝗮𝘁𝗶𝗼𝗻: San Bruno, CA | 💰 𝗦𝗮𝗹𝗮𝗿𝘆: $174k - $261k | 💼 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲: 8+ YOE | 🚀 𝗦𝘁𝗮𝗴𝗲: Public

📚 What I enjoyed reading this week

DeepSeek: Frequently Asked Questions by
Charlie Guo
: The most common questions about DeepSeek answered in one spot
Breaking Into Data: How to Land A Job in a Competitive Market by
SeattleDataGuy
: A tactical guide on landing data jobs, just in time for the new year
The Self-Promotion Horror Show by
Hilary Gridley
: Tactical tips for creating visibility for your work (a key requirement for getting ahead)
Stop apologizing for reasonable business decisions by
Wes Kao
: A good reminder that we tend to apologize too much at work, with serious consequences
7 proven mental models for engineering managers by
Anton Zaides
/
Michał Poczwardowski
: A helpful summary of 7 mental models that anyone can use at work, not just engineers

Vishal Kataria

Feb 8

A timely article. As I read in an HBR article, people are pretty good at problem-solving. It’s at understanding and diagnosing the problem where they struggle:

“In surveys of 106 C-suite executives who represented 91 private and public-sector companies in 17 countries, I found that a full 85% strongly agreed or agreed that their organizations were bad at problem diagnosis, and 87% strongly agreed or agreed that this flaw carried significant costs.”

[Source: https://hbr.org/2017/01/are-you-solving-the-right-problems]

Expand full comment

2 replies by Torsten Walbaum and others