Problem-solving is all around us at work and in our personal lives. Consulting companies make fortunes out of solving big, thorny problems for businesses and governments. Solutions Architecture, my field of expertise, is a role that is dedicated to solving customers' complex business and technical problems with technology.

Early in my career, I just used "common sense", sheer will-power, educated guesses, intuition, and lots of trial-and-error when solving complex technical and organizational problems. It wasn't a clear, organized mental process as it is for me right now. I quickly learned that brute-forcing complex problems is inefficient at best and an incredible waste at worst. I would spend a lot of time running around in circles, making little progress on complex problems. Worse, I could end up solving the wrong problem entirely, and have little impact. The more complex a problem was, the more tough it was to crack with only common sense, logical thinking, and will power.

Table of Contents

Why this guide?

In my line of work, I solve customer and organizational problems for a living. At Amazon, one of my favorite leadership principles (LPs) that's embedded in the culture is Think Big. Here is what it says:

Thinking small is a self-fulfilling prophecy. Leaders create and communicate a bold direction that inspires results. They think differently and look around corners for ways to serve customers.

To me, Think Big has always meant that if someone at Amazon has an exciting idea to delight customers or to solve a gnarly internal organizational problem, they are empowered to champion these ideas and make them a reality. But say I had a brilliant business idea or a solution for a problem. How do I champion it? How do I influence my brilliant colleagues and leadership that the opportunity or the organizational problem is real and is worth pursuing?

It all starts with what is known in Amazon as a narrative, also known as a one-pager or a six-pager. This is a document, up to 6 pages, in which the person describes the problem, the solution, and answers many other questions about their ideas. Just by sitting down and pouring their thoughts on paper, people would get more clarity on their thinking. They are able to clearly see gaps in their thought process and do better reflection. Once a first version of the document is ready, the person would share it with their manager and trusted colleagues to receive feedback. The person then listens to and applies the feedback, and schedules another review. The cycle continues until the doc had addressed major gaps and answered big questions, and is ready to be reviewed by higher-level leadership. After the doc has been approved, the employee who championed the idea would take a key role in its execution and realization.

I've read many of these documents over my ~11-year tenure at Amazon, written by brilliant people striving to solve complex customer and organizational problems. I have authored several of these myself, and went through grueling rounds of reviews and feedback. Some of my initiatives were implemented, and others turned into learning opportunities. Invariably, I worked consistently at strengthening my complex problem-solving skills over the years. This required me to draw insights from diverse topics like problem-solving research, systems thinking, operations research, consulting, change management, and more. In repeatedly doing so, I felt something was missing-- a process that covers complex problem-solving end-to-end.

That end-to-end process is my contribution in this guide, written for beginners. I draw from classic and modern works across the fields I mentioned, combining their insights and my experience into that process. It's imperfect and far from complete. My goal is not to craft the perfect end-all, be-all process, but more to provide a roadmap for beginners embarking on solving complex problems, empowering them with practical tools and mental models to beat complexity.

The benefits of having and following a complex problem-solving process are plenty. A disciplined process empowers us to stay organized, make consistent progress, and know where we get stuck and why. It allows us to sidestep more of our cognitive biases, which can and do interfere with our problem-solving. Having a process that is explicit, transparent, and documented enables better collaborative problem-solving with others. It doesn't matter if the problem is in a business, a community, a family, or even the society at large, the process remains the same.

What is a complex problem?

So, what exactly is a complex problem? A problem exists whenever there is an initial state and a goal we want to achieve, but we have no straightforward way of getting there with the knowledge, experience, and means we currently have. The initial state causes some undesirable results (or symptoms) to exist. Solving the problem and achieving the goal lead us to a future, ideal state that produces the desirable results we want instead.

In my experience, the telltale signs of a complex problem include:

High ambiguity. A complex problem is one where several of the necessary components which enable finding a solution are ill-defined [1]. The initial state, ideal state, goals, means, and constraints of the problem may be ambiguous or unknown. Upfront work has to happen to define the problem properly. There may be missing information or uncertainty surrounding these components, and the problem solver has to deploy strategies to deal with that.

Many moving parts. A complex problem involves a system of elements which interrelate and interact. In Systems Thinking, a system is an interconnected set of elements that is coherently organized in a way that achieves something. A system consists of three kinds of things: elements, interconnections, and a function or purpose [2]. In that sense, many things can fit this general definition of a system. A system can be a process spanning multiple business units, an industry, a country's economy, a society, or a complex distributed application. Systems can be dynamic, whereby their structure and behavior varies over time. To solve the problem, we have to understand the systems and elements in which the problem exists, including how they behave and interact. The many moving parts makes it harder to trace effects back to causes, and harder to predict the results a change can produce. There's an element of uncertainty.

Large scope or scale. When the scope or scale of a complex problem is large, it invariably involves one or more systems. The elements of a system may themselves be systems (we can call these 'subsystems')! For example, a company can be broken down into business units and lines of business, and those can be composed of teams with specific specializations. A micro-service in a distributed application is itself a system. You get the idea. A complex problem might span multiple such systems. Ultimately, we will have to draw a boundary that says which systems are relevant and 'in-scope' for our problem, and which systems are 'out-of-scope' and can be safely treated as black boxes or part of the systems' environment.

Multiple, often conflicting goals. Complex problems may require achieving multiple goals. The goals may be contradictory and require making trade-offs: optimizing for one goal negatively affects other, also important, goals. For example, you can improve security of an application, but at the cost of usability. Conflicting goals forces their prioritization. This prioritization doesn't guarantee we'll find satisfactory solutions. Therefore, complex problems may have multiple correct (or acceptable) solutions, or none. Conflicting goals are almost guaranteed when there are multiple groups of stakeholders. They are people or organizations who have a vested interest in solving the problem.

Consequential decisions. Complex problems involve making decisions that have high risk/reward, high uncertainty, and are difficult to reverse (or outright irreversible). They also involve some significant allocation of resources. Examples of that including setting a company's annual budget, selecting one mega investment project out of a list of ten possible ones, or committing time and money to earn a post-graduate degree in a particular field of study.

Examples of complex problems

By now, you may have a specific problem in mind that checks all or some of the above boxes. If you don't, here are a few examples. Improving the productivity of a team, increasing profitability of a company, reducing ocean pollution, reversing climate change, eliminating homelessness, or solving world hunger are all complex problems. Complex problems can come on a smaller scale, too. A few examples are planning your next career move, deciding where to relocate your family, or navigating corporate politics.

Even winning a Chess game against a competent player can be considered a complex problem, albeit a special case of one. The initial state is known, the rules (constraints) are known, and the ultimate goal is known. But to achieve that goal, there are countless moves both opponents can make. With every move, players are optimizing for multiple and sometimes contradictory goals at once: achieve strategic control of the chess board, weaken the opponent by capturing pieces, protect own key pieces, and so on. Players often have to predict how the game unfolds one, two, or three moves ahead, which involves a lot of uncertainty. Every move creates a new sub-problem with its own prioritized sub-goals, constraints, and possible solutions. Each sub-problem has countless possible solutions. A player may need to make difficult trade-offs, sacrificing a piece in the short term to gain an advantage in the long term.

A few examples of complex business problems I face myself as part of my role as a solutions architecture leader are escalations, business strategy definition, organizational design, operational rhythm design, process inefficiencies, and more. Complex technical problems include designing AWS solutions with customers to meet their requirements, especially when the business or technology strategy are ambiguous or not defined.

The Complex Problem-solving Process

No wonder complex problems can stump and overwhelm us. Where do we even start solving them? In this guide, I share the strategies and analytical tools that consistently worked for me.

A decision you have to make early on is whether you need to involve domain experts or not in your problem-solving. Know that the strategies and tools I'll share here aren't enough if you're new to the problem domain. An expert will be orders of magnitude more effective and efficient than a non-expert armed with the best process and tools. If you are a non-expert in your problem's domain, you should enlist domain experts in your complex problem-solving quests.

The high-level complex problem-solving process is:

1. Define the problem (or opportunity)
2. Identify root causes
3. Find the best solution
4. Implement the solution

This process itself is nothing special. It feels like it's common sense, and it is. The breakthrough comes not from merely knowing the process, but from internalizing it and using it to organize our problem-solving. Repeatedly applying this process is like a compounding investment. Complex problems come in all shapes and sizes, but the process is almost identical every time. We get better at it every time we practice it, and our efficiency and effectiveness increase exponentially over time.

The process we follow in reality won't be as linear and cleanly separable as you might imagine. We, the problem solvers, may have to iterate between steps or even skip steps if it makes sense. Steps 2 and 3 are where the intensive problem-solving happens. Let's say you made it to step 3. Have you ever had an experience where a problem was so challenging to solve that you had to go back to the drawing board to re-frame or re-define it? You've just gone back to step 1. What if you're an expert in the problem domain? You may immediately recognize the problem, zipping through steps 1,2, and 3 in a fraction of the time it would take a non-expert, thanks to the large repertoire of skills, knowledge, and problem-solution patterns you have. Step 4 is where we plan and implement the solution we worked so hard to find and design.

Each of the process's steps can easily be expanded into its own dedicated article to cover the strategies and tools at a decent depth. In this guide, I'll cover steps 1 to 3. I will only brush on Step 4 so that this guide doesn’t expand into a book.

Let's get started.

1. Define the problem (or opportunity)

"Some users are complaining that our application is super slow."
"Our business hasn't grown this year as it should have."
"I applied to many roles, but haven't gotten enough interviews."

Reading the above statements, are these good problem definitions? Spoiler: No, they aren't. In fact, they are not problem definitions at all. The above statements describe symptoms, the painful manifestations of one or more problems. These symptoms jolt us into action to find a remedy. They are the Undesirable Results (URs) that arise from the problem.

1.1. Frame the problem

We can frame the goal of problem-solving as to move from the existing state that produces the Undesirable Results to an 'ideal' future state that produces the Desirable Results (DRs) instead.

Here are questions we want to answer to iteratively create a robust problem definition:

1. Who are affected by the URs? These are our stakeholders.
2. What are the Undesirable Results of the problem for each stakeholder group? Can you verify these URs?
3. When did the URs start happening? For how long?
4. Where are these URs happening? Is there a particular scope that the problem is limited to? (For example, a business unit, a process, a system, or a customer segment.)
5. What DRs do our stakeholders want instead? Why? We will frame these DRs as problem-solving goals.
6. What constraints exist on our ability to eliminate URs and bring upon DRs?
7. What is the timeframe for solving the problem?
8. Why solve this problem at all? (Importance)
9. Why solve this problem now? (Urgency)

This is not an exhaustive list, but it covers the essentials of problem definition. We aim to define the existing and ideal states in as specific and measurable terms as we can, with whatever information we have. Quantitative data and hard metrics are important, and qualitative data, including anecdotes, is just as important. Talk to people who have experienced the problem firsthand. Listen to their stories. This may uncover unexpected insights that end up shaping the problem definition. It also conveys a sense of how urgent and important the problem really is.

Questions 1-4 explore the Who, What, When, and Where of the Undesirable Results as they exist at the beginning of problem-solving. A complex problem may affect multiple stakeholder groups. Each group will describe the undesirable results as a list of things they care about and that need to be improved. Let's call these things attributes. This naming will make sense later in the problem-solving process, when we discuss Multi-Attribute Decision-Making (MADM) in step 3 "Find the best solution".

For example, if the problem is lackluster business growth, an attribute a CEO may use to describe the problem can be year-over-year revenue growth rate percentage. If the problem is high air pollution in a city, an attribute that the city's government may use the Air Quality Index (AQI) attribute to describe the problem and measure improvement.

Our first task as problem solvers is to take stock of these attributes used to describe the undesirable results, grouped by stakeholder group. We should measure where we are today regarding each attribute, taking a baseline of them. That baseline will come in handy later, when we want to test our solutions and prove that they work.

1.2. Define problem-solving goals

Question 5 mentions that Desirable Results should be stated in the form of goals, so let's define what a goal means in the context of this guide. A Goal is a broad, long-term desired outcome. It expresses what we want to achieve in general terms, often qualitative, aspirational, and involve direction. For example, "Improve student learning outcomes" and "Increase market share" qualify as general goals.

General goals aren't very useful, we need to make them SMART: Specific, Measurable, Achievable, Relevant, and Time-bound (SMART). There's a chance you already know what these mean, but if you don't, have a look here [3]. So, instead of "Increase market share", we should aim for something like "Increase market share by 30 basis points within two fiscal years."

Goals sit on a spectrum with two extremes: Input goals and Output goals. Input goals are goals set on something within our control. As a simple example, the "Hours studied" is something within a student's direct control, and therefore, they can set an Input goal on it. It is less dependent on extraneous circumstances. Output goals, by contrast, are goals are set on things that are NOT within our direct control, things we can only indirectly influence. For example, "Get an A on the exam" is an output goal. The idea is that by acting to achieve Input goals, we can influence and achieve Output goals through a combination of causality and chance.

Desirable Results should be stated as SMART Output goals defined on the attributes that matter most to our stakeholders and decision makers. That will be straightforward for attributes that are readily measurable. If the attribute we care about is "Cost in dollars", a goal could be "Cut cost in dollars by 50%". If it's "Market share", a goal could be "Increase market share by 20% over 2 years". But occasionally the attributes are subjective and challenging to measure, like customer satisfaction and employee morale. There are ways to deal with these subjective attributes, but that's out of scope for this guide.

1.3. Avoid solution thinking

Sometimes, we may know enough about a problem to go beyond defining Output goals, and be able to define specific and detailed Input goals. For example, to achieve the "Increase market share" general Output goal, we may define the general input goals of "Introduce a new product line" and "Acquire competitors". This is How thinking, and how thinking is solution thinking. This is a common trap. We should avoid defining Input goals at this step. We aren't trying to solve the problem yet, solution-thinking comes later. Instead, our focus now is to set up the problem-solving process for success, avoiding common traps like solving a problem nobody cares about, solving the wrong problem, not defining what success in solving the problem looks like, solving the problem at a much wider or narrower scope than needed, or missing a critical detail that can materially change how we solve the problem.

1.4. Identify constraints

Let's apply the questions above to move from the symptom statements we started with to these potential problem definitions:

• "The sales department leaders across the country are complaining the application takes over 12 seconds to respond when producing the daily sales reports. It used to take about 3 seconds, on average. This started has happened for 2 months now, on the last business day of the month. This slows down the end of month reporting and our CFO is now upset. The ideal response time profile is that 95% of the interactions with the application take less than 2 seconds or less to complete."
• "The year-over-year sales revenue of our most profitable product line has grown by only 3%. We were projecting at least 7% growth. If this continues this year, this will shake our investors' confidence. We want to see at least 10% revenue growth by end of this year."

These are good problem statements, but can we do better? For one, each of them sets one goal to achieve. In complex problems, there are often multiple goals that are at odds with one another. For example, pushing for 10% revenue growth by end of year may require hiring hundreds more salespeople, but do we have the budget or time for it? May be we don’t.

This is where constraints come into the picture, the subject of question #6. A constraint is a special type of goal that is supposedly non-negotiable, restricting our ability to solve the problem in some way. For example, key stakeholders may set a clear budget, timeline, or scope for solving the problem. Constraints can be both a pain and a blessing. Constraints can be a blessing as they narrow down the solution search space, making finding solutions more tractable. If they are too restrictive, however, they become a pain. As we uncover constraints, we should understand why they exist, and what the tolerances associated with them. Some breakthroughs in problem solve come from questioning and eliminating zombie constraints-- ones that once existed but not anymore, and ghost constraints-- imaginary ones that never existed in the first place.

1.5. Wrapping up problem definition

By the end of this step of the problem-solving process, we should have a clear problem definition including a list of initial SMART Output goals and constraints. To make things easier, we can simply treat constraints as goals to achieve. For example, "We can't spend more than $5 million on solving this problem" becomes the hard, non-negotiable (Input) goal of "Do not exceed a $1MM budget". It is likely that we discover more goals and constraints throughout the problem-solving process, revising our list.

To illustrate the concepts in this guide, let's stick to the "sales revenue decline" toy example and work it out step by step. Let's assume we arrived at the following problem definition and goals list.

"The year-over-year sales revenue of our most profitable product line has grown by only 3% last year. We were projecting at least 7% growth. If this continues this year, this will rattle investors' confidence. We want to see at least 10% revenue growth (~$16MM) by end of this year. This gives us about 8 months of runway to achieve this growth. Whatever plan we come up with, we have a $1MM investment budget to work with. Unfortunately, we cannot change our product roadmap for this year."

Based on this definition, our goals are:

• G1: 10% revenue growth by by December 31st (Attribute: Revenue growth in $)
• G2: Solve problem within $1MM budget (Attribute: Budget in $)
• G3: Achieve goals within 8 months timeline (Attribute: Timeline in months)
• G4: Only minor product roadmap changes allowed this year (Attribute: Number of minor roadmap changes required)

As a practice exercise, consider a complex problem you're facing at work or at home, how can you better define it and the goals surrounding it?

2. Identify root causes

Why is this problem happening? That is the single question that drives all work in this stage. Our ability to solve the problem hinges on getting its answer mostly correct. The answer is simply a list of one or more root causes of the problem in which we have high confidence. What we'll do in this stage is systematic abductive reasoning [4], which is a logical process of forming the most likely explanation from an incomplete set of observations.

As soon as we have a rich definition of the problem, our brains are wired to immediately start thinking through what its causes might be. For simple problems, it's straightforward to trace cause and effect from the undesirable results to the root causes. It might be even easy to identify the best solution right away.

In complex problems, tracing cause and effect is much more difficult. Remember how complex problems involve systems of interacting elements which interrelate and interact? That is where the difficulty comes from. For example, to trace cause and effect from declining sales revenue back to the root causes, we need to study the sales processes, how the sales employees are executing them, the sales department, and the company. We also have to study the customers and their purchasing trends, the state of the industry in which the company operates, and even the conditions of the local and global economy. The sales department is a system in itself, and also an element within a larger system -the company- which itself is an element in an even larger system -the industry vertical- which itself operates in the context of the economy. The sales process cuts across all these systems and is influenced by them.

All these dynamic, interacting systems and elements make establishing cause and effect links difficult. One effect may have several root causes scattered in different parts of the system, each exerting a different degree of influence. Effect X may be caused by causes A, B, and C in different elements of the system, each contributing to the effect. The causal chains themselves might be deep. Effect X could be caused by A that is an effect of B, which is in turn triggered by a completely unexpected cause C. The causal links may be transient, meaning they are triggered in certain conditions. There is also the trap of confusing correlation with causation. Does A happen because of B? Or is it that A and B are both happening due to a hidden cause C?

As a result, with complex problems, we need to resist our tendency to jump to conclusions about root causes. Instead, we should acknowledge our gut feelings, take note of them, and treat them as they really are: tentative possibilities, or hypotheses. The dictionary definition of a hypothesis is a supposition or proposed explanation made based on limited evidence as a starting point for further investigation. In other words, hypotheses are just our best educated guesses.

2.1. Generate root cause hypotheses

To generate root cause hypotheses, we start by understanding the problem's context. That includes the systems in which the problem exists. We first need to understand both the structure and the behavior of these systems. Then, we do our best tracing cause and effect across the systems and generating strong, plausible hypotheses about the root causes producing the URs.

There are many techniques we can use to understand systems structure and behavior. Here are some of my favorites.

Visualize the in-scope systems. We can visualize the structures problem's in-scope systems using diagrams and trace cause and effect through these structures. Mere visualization of a complex system can lead to profound insights if it's never been done before. For example, if the problem is with a business process, we can draw a business process diagram that shows steps of the process, how different departments contribute to the process, and the different inputs and outputs of the process. A problem where a goal is to "Increase profits by 30%" requires us to look at the systems and processes that generate revenue and those that generate expenses. A problem that lies in a complex distributed application, it helps to visualize the dynamic behavior of the application's components.

Use proven models and theories as 'lenses'. "There is nothing more practical than a good theory." -Kurt Lewin
Another strategy is to use a proven model or a theory as a 'lens' through which to view the problem. In every domain like management, economics, marketing, finance, and so on, there are models and theories that we can use as "lenses" through which we interpret the complex problem. Models can be descriptive, explanatory, or prescriptive or a combination of the three. Descriptive models help us overlay a structure on the problem. Explanatory ones give us insights on cause and effect, providing us clues on how to solve the problem. Prescriptive models tell us what we should do. A model may combine any of these characteristics, the most useful combine all three.

Applying a model to a problem can give us a fresh perspective on the problem and its potential solutions. It also reduces the cognitive burden in reasoning about the problem by focusing our attention on particular key characteristics of it and temporarily tuning out other details. The Eisenhower Matrix, as a simple example, is a 2x2 task prioritization model that is both descriptive and prescriptive. Looking through its lens, we classify tasks along two dimensions as "Urgent or "Not Urgent" and "Import" or "Not Important". Depending on the quadrant in which the task lands, we either Do, Delegate, Decide, or Delete it. When I look only at the urgency and importance attributes of a task, I can decide what to do now, what to delegate, what to schedule later, what to delete off my list.

Models are a simplification of reality, and thus they make assumptions about the problem and the world. The Eisenhower Matrix model assumes the problem of time management is caused by tasks being all treated equally and executed without much thought about prioritization. Is that assumption true? We should ensure we understand a model's assumptions and verify that they hold for our problem. I like to keep in mind the quote of George Box, the known statistician, said that "All models are wrong, some are useful."

When deciding which models to apply, one should give priority to domain-specific tools and models. For example, in solving a problem in a manufacturing setting, the Lean philosophy provides us with a method and tools to continuously eliminate seven types of waste: overproduction, waiting, transport, extra processing, inventory, motion, and defects. In interpreting and evaluating a business strategy, one might use Porter's Five Forces model. And so on.

If domain-specific models don't provide insights or breakthroughs in understanding a problem and providing solution clues, I would consider generic models and tools. For example, a complex problem typically involves one or more systems, and therefore models like Systems Thinking [2] and the Theory of Constraints [5] apply. Another example is that it's time to implement a solution, and if the solution involves changing people's behavior, there are numerous change management models and theories that we can apply to drive execution planning and decision-making.

Use logic trees. Finally, another versatile tool in our toolbox for analyzing a problem's in-scope systems are logic trees [6]. Logic trees are versatile because they can be used to break down any concept into its constituents. We can use them to successively break the problem's system into its elements to understand that system. We can also use logic trees to trace cause and effect across the problem's in-scope systems, and ultimately create and organize our hypotheses. In a later stage, we can use logic trees as well to organize our thinking about possible solutions.

As an example, let's say we want to understand why sales revenue is declining. First we need to understand the sales process and how it works. Here's a simple, example sales process description. In a real process, a textual description may not be enough to understand it, so you may resort to visualization.

"Salespeople prospect for customers interested in our Complex Problem Solver business-to-business (B2B) SaaS software. They reach out to customers to build relationships, understand their needs, and pitch our product. Once there is interest, the salesperson logs an opportunity in our Customer Relationship Management system. Our product is licensed by user, so the more users a customer signs up, the larger the opportunity and the higher our sales revenue. The salesperson and the sales engineer then work together to help "close the sale", and enable the customer to create an account in our software, sign up for a plan, and get value out of it. An opportunity is "closed" successfully when that happens. If the customer loses interest or decides to not use our software for any reason, the opportunity is considered lost. Customers needs to renew their subscription plans every year to keep using our product. We offer multiple subscription plans for our product with different feature sets."

Armed with a basic understanding of the process, and can generate some hypothesis to explain why sales declined. Let's try building a logic tree.

Sales Revenue Decline
├─ 1. Existing‑Customer Decline
│   ├─ 1.1 Fewer/Smaller Purchases per Customer
│   │   ├─ 1.1.1 License‑count reduction
│   │   └─ 1.1.2 Upsell/Cross‑sell shortfall
│   └─ 1.2 Higher Customer Attrition
│       ├─ 1.2.1 Plan Cancellations
│       │   ├─ New product experience dissatisfaction
│       │   ├─ Pricing dissatisfaction
│       │   └─ Support/service gaps
│       └─ 1.2.2 Plan Downgrades
│           ├─ Feature‑set mismatch
│           └─ Competitive lower‑tier offerings
└─ 2. New‑Customer Decline
	├─ 2.1 Fewer Opportunities Created
	│   ├─ 2.1.1 Market‑Demand Weakness
	│   │   ├─ Value‑proposition erosion
	│   │   │─ Brand/awareness decline
	│   │   └─ Market-wide economic slowdown
	│   ├─ 2.1.2 Marketing effectiveness decline
	│   └─ 2.1.3 Sales prospecting effectiveness decline
	├─ 2.2 Longer Opportunity Cycle
	│   ├─ 2.2.1 Product‑side delays
	│   ├─ 2.2.2 Sales‑process delays
	│   ├─ 2.2.3 Sales‑people delays
	│   ├─ 2.2.4 Customer‑side delays
	│   └─ 2.2.5 Delays by unknown/external factors
	└─ 2.3 Lower Opportunity Value / Higher Losses
	    ├─ 2.3.1 Discount pressure
	    ├─ 2.3.2 Scope‑trimmed deals
	    └─ 2.3.3 Competitive losses

Building useful logic trees requires experience in the domain of the problem and in using logic trees. An expert in the problem domain is able to easily categorize hypotheses of causes. It also requires a conscious effort to make the elements in the tree at each level MECE - Mutually Exclusive and Collectively Exhaustive. Items on each level should not 'overlap' semantically, and hence be mutually exclusive. The items should also be collectively exhaustive, representing all possible causes. For example, notice how at the highest level in the example tree, we broke down causes into one of two large buckets - new customers or existing customers. There is no third category. If we were selling a physical product, like cars for example, perhaps we can add 'past customers' as well because there would be a pre-owned car market which may affect sales revenue.

As we'll see in more detail later, we make our tree levels MECE to be able to collect evidence or design experiments where exactly one of the items on a particular level would be true.

Our goal is to build a tree (or several trees) which represents our best attempt at tracing cause and effect across the problem's in-scope systems. At each level, we ask "What could be causing this?" and then we create a MECE list of potential causes. Then, we move on one level deeper. We recursively repeat these steps until we run out of possible causes to explain the problem's undesirable results, and until we have reached enough 'depth' in the tree where the possible causes are specific and actionable. This can be viewed as a more structured and organized version of the 5 Whys [7] technique to uncover root causes.

Mind-mapping tools, available as SaaS or apps, are my go-to for building logic trees. You may also use AI chatbots like ChatGPT or Claude to accelerate building MECE trees and reduce the cognitive burden involved.

2.2. Eliminate false root cause hypotheses

We have a list of strong root cause hypotheses. Now what? After we have curated a hypotheses list (or a tree) of potential causes, we work on narrowing the list of hypotheses down, eliminating as many hypotheses as we can, until we have one left that most strongly associated with the undesirable results. That is our root cause!

In reality, however, this will rarely be the case as it's common for complex problems to have multiple causes contributing to the undesirable results, as you saw in the example logic tree. If that is the case, there are heuristics we can use to focus on the most important causes. For example, we can apply the Pareto principle [8] to assert that 80% of the undesirable results we're seeing may be caused by only 20% of the contributing causes. That may not hold true in the end, but it's an hypothesis we can start with and seek to prove or disprove.

To eliminate root cause hypotheses from our list or tree, we must apply the logic of the scientific method. Briefly, after we have developed a list (or a tree) of potential causes, we collect evidence to contradict and disprove as many of these as we could. This strategy has a name: Analysis of Competing Hypothesis [9]. It's a methodology that's been used by CIA intelligence analysts to explain observed events.

This is when we go and collect data and anecdotes that could serve as evidence for or against our hypotheses. We want to systematically reduce our uncertainty about the root causes. The data can come from internal sources like internal reporting systems, or external ones like reputable industry reports. The questions we should carefully reflect on is: What data would lead to the highest reduction in uncertainty? What data would eliminate as many of these root cause hypotheses in one shot?

Data is powerful and should be handled with caution. In my experience, data almost always had quality issues requiring cleaning and preparation to be useful. If one is not well versed in data analysis, it's easy to draw inaccurate or plain wrong conclusions. Consider enlisting the support of someone with strong data analysis skills throughout the complex problem-solving process.

What if we don't have enough existing evidence? What if the data we need is not readily available? Then, we would have to design one or more experiments to rule out as many of the hypotheses as we can. An experiment should either conclusively support or exclude one or more hypotheses. Designing experiments is out of scope for this guide. It’s a heavy topic grounded in statistics. If you're a brave heart who is interested in exploring this further, I recommend reading [10]. In the end, hypotheses that ultimately survive this process are the winners. If none of the hypotheses survive, then we go back and think of more.

Back to our sales revenue decline example. Let's say our in-depth analysis confirmed several root causes, with these specific ones having the highest contribution:

• RC1: Recent product update introduced complexity.
• RC2: Target customer segment preferences have shifted.
• RC3: Market‑wide decline in demand due to the emergence of Generative AI.

Congratulations! We have made it more than half-way through the complex problem-solving process. It's said that a problem well-defined is a problem half-solved. Not only have we defined the problem, but also we have identified the root causes and have all the data and analysis to back it up.

3. Find the best solution

The burning question we want to answer now is What should we do to solve this problem? This is when we'll use our expertise, creativity, and problem-solving skills coupled with analytical tools and models to find the 'best' solution. Remember that complex problems often have multiple, conflicting goals. As a result, such problems may have one or more correct solutions, or none at all.

Solution-finding is a three-step iterative process:

1. Formulate two or more solution hypotheses
2. Design your solutions
3. Decide the best solution

As you see, we're not quite done yet with hypotheses-making. Just like we started out with a range of possible root causes and worked our way to the actual ones, we'll do the same with solutions. The reason is simple: we can only guess about them. By following the above steps, we avoid prematurely jumping to conclusions about what the best solution is.

The process is iterative because it's unlikely that we arrive at the best solution in just one iteration. Rather, we are searching across the solution space for a solution that works. So, we brainstorm, hypothesize, decide, validate, and repeat until we find the best solution.

3.1. Formulate two or more solutions hypotheses

"For every complex problem there is an answer that is clear, simple, and wrong" -H.L.Mencken

A common pitfall in solution-finding is satisficing, or simply accepting the first solution that we can think of because it's good enough. Our cognitive biases play a big role in nudging us towards that one silver-bullet solution that is 'obvious' to us. We can avoid that trap by persisting and setting a goal of creating at least two solution hypotheses.

In the first iteration of solution search, we shouldn't spend too much time hypothesizing about solutions. There is a real risk of analysis paralysis, where a lot of time is spent meticulously crafting the perfect solutions. I recommend time-boxing the effort spent upfront on formulating the very first solutions hypotheses, and then moving on quickly to test these initial hypotheses. Spoiler: there's a good chance they aren't the best solutions, or even wrong and plain won't work.

The good news is there is a relatively inexpensive test for our initial solutions hypotheses - the history of the problem and attempts to solve it. We should first step back and understand where past efforts to solve the problem have landed. Talk to people familiar with the problem, including domain experts and stakeholders who are affected by the problem or have vested interest in solving it. Ask them, what are the potential solutions from their perspective? What solutions have been tried? What worked and what didn't?

Depending on the answers you get, here are the possible starting points for your solution-finding journey.

1. No solutions identified. No one has ever tried solving this specific problem before, maybe because the stakeholders have no idea how to, or the problem domain is new, or no one cared enough, or something else. Whatever the reason, you have the honor of being first to try to solve the problem. To achieve that, you need to go through the three solution-finding steps from scratch. This is a hard position to be in, as you don't have the benefit of lessons learned through previous attempts to solve the problem. It's unlikely, however, that you find yourself in this situation. With complex problems that matter, it is likely that someone, at some point, recognized the problem and can even point out possible solutions. It's more likely that your journey starts from one of the following points.
2. Several solutions identified. You or the stakeholders are already aware of one or more potential solutions to the problem. None of these solutions was analyzed to any depth, however, and a potential best solution hasn't been identified.
3. Potential best solution identified, but not tried. A potential best solution has been identified out of several candidates, but it hasn't been tested and validated. It's important to understand the thought process behind why that solution was considered best, and why it wasn't tried.
4. Potential best solution identified and tried, but did not work. A potential best solution has been identified and tried, but then it didn't work for some reason. Again, it's key to understand the history of this experiment, and build on that experience in your problem-solving effort.
5. Several solutions identified and tried, but none worked. Stakeholders tried to solve this problem multiple times, with a different idea each time, but none of them worked. There's a lot of history to learn and build upon here. Use that history to inform your solutions hypotheses.

The history of attempts to solve the problem provides us with rich evidence that we can use in an analysis of competing solutions hypotheses to test and rule out those that won't work at the outset. It may also inspire us with more solutions ideas to consider and validate.

3.2. Design your solutions

Solutions for complex problems are likely to be complex themselves, too. They are planned and executed over multiple steps, each changing something about the problem's in-scope systems, bringing them further from the initial state, and closer to the final, ideal state that produces the desirable results we want.

The cognitive burden in designing such solutions is high. We have to build an accurate mental model of how the in-scope systems work and the levers we can use to influence them. Then, we need to envision and plan an end-to-end sequence of steps that would bring about the change we want to see. For each step, we need to correctly predict what would change, when, and by how much. The sequence of solution steps can be arbitrarily complex. Ultimately, for a solution to be successful, it must eliminate most or all the undesirable results, replacing them with the desirable ones, meeting the goals we've set in the problem definition stage.

So, how do we reduce the cognitive burden of solution design? To answer that, we'd have to venture into how to design solutions. This is an inherently creative activity and every problem is different, so it's difficult to be prescriptive about it. Instead, I'll share some principles of solution design that I apply myself. This incomplete, non-MECE list of principles help me not only reduce the cognitive burden of sound solution design, but also reduce the risk of failed solutions. They will not suit every problem or every situation, but they have proven themselves as useful guidelines to keep in mind while designing solutions.

1. Keep the solution simple. The simpler the solution, the higher the chances of its success. A simple solution means making the least necessary changes to the problem's in-scope systems, avoiding complicated solution step sequences, minimizing the solution's moving parts, and thus reducing risks.
2. Avoid premature optimization. The best solutions are effective at meeting goals and efficient in doing so. With complex problems, it is unlikely that the first solution will be neither. The phrase "premature optimization is the root of all evil" is a well-known saying in programming that cautions against optimizing code before it's necessary and before the performance bottlenecks are identified. This principle can be applied to problem-solving in general. Premature solution optimization is wasteful and leads to unnecessary complexity.
3. Break down a complex solution into manageable, testable steps. The idea is to be able to manage scope, cost, duration, and risks, allowing for consistent progress in solving the problem. For example, you can break down the plan to achieve goal into smaller objectives and divide the execution into phases or milestones. You can tackle one root cause at a time, and then change one 'big' thing at a time.
4. Tackle one root cause at a time. A solution that tackles multiple root causes at once is likely to be a tangled web of steps that may interfere, or even contradict, one another. Address one root cause at a time, test solution effectiveness, and then move on to the next.
5. Change one 'big' thing at a time. Once you decide the root cause you want to tackle, design your solution so that each step changes one big thing at a time, and that you can observe and test the results of the change. Conduct A/B experiments, when possible. But what in the world is 'big'? These are key leverage points in a system that can drastically change how it behaves and the outcomes it produces. That includes things like rules, constraints, goals, and processes. If you change incentive structures, goals, and the processes for a team all at once, how do you know which led to the observed improvement in productivity? Is it one of them or all of them? Making several big changes simultaneously makes it difficult to trace a result you're observing back to the change that caused it.
6. Keep uncovering as many constraints as you can, and question them. As you go through the problem-solving process, you will keep uncovering constraints that determine which solutions are acceptable or even feasible, and which aren't. They narrow down the solution search space and can make finding solutions more tractable. We should apply the same scrutiny to solution constraints as we did during problem definition, questioning why they exist and what tolerances stakeholders have around them.
7. Align solutions with key stakeholder values. Stakeholder values are important constraints in designing solutions. They not only narrow down the solution search space, but also help us compare solutions and make trade-offs. A customer who values cost-effectiveness will value a cheaper solution over a more expensive one. Customers who value luxury will prefer a high-end, meticulously designed product over a cheaper one. Key stakeholder values are non-negotiable, like integrity and fairness. Solutions that don't align with key stakeholders values can be eliminated outright. The higher a solution's alignment with stakeholder values, the more preferred it will be. Identify and rank stakeholder values before you hypothesize about and design solutions. Find ways to quantify these values, so you can measure and rank solutions against them.
8. Recognize and clarify your assumptions. When we predict a certain solution we designed will work in a certain way, we must make assumptions. Like constraints, assumptions need to be made explicit and questioned to ensure that our solution reasoning is sound.
9. Consider existing problem-solution patterns first. If the problem's domain is not new, there are likely established problem-solution patterns that can be used right away. A pattern may fully solve the problem, or be part of a bigger solution. In systems design, for example, there are well-known patterns to improve a system's quality attributes, such as stateless architecture for improving scalability, multi-factor authentication for increasing security, and caching for improving performance. Many of the patterns are already established, and it's straightforward for the domain expert to recognize the solution pattern based on the problem's root causes.
10. Use proven models and theories. If we have found and used proven models and theories to understand the problem, they can also provide us with strong clues as to what the solutions may be. Prescriptive models and theories make our job much easier. One example I like is the Thinking in Systems list of leverage points to change a complex system, ranked by effectiveness [2].
11. Consider incremental solutions first. Solutions for complex problems can be incremental changes to the in-scope systems, meaning building on and changing what exists. Alternatively, the gap between the current and ideal state can be large enough to warrant revolutionary, step changes that fundamentally alters, or even replaces, in-scope systems. Incremental solutions should be our default starting point when hypothesizing about solutions as they tend to be less costly and risky.
12. Use proven models and theories to reframe the problem and to brainstorm possible solutions. If we apply to a problem a model that has a prescriptive element to it, the model would give us clues as to how to solve the problem.
13. Seek diverse perspectives. Seek opinions of others on the problem. They keyword here is 'diverse'. Seek the opinions of those impacted by the problem, those who've tried to solve it before, and domain experts. Intentionally seek people of different backgrounds. Share your problem definition, root cause analysis, and solution ideas. Engaging and collaborating with stakeholders in problem-solving inspires a sense of ownership in them, turning them into potential allies come time to implement a solution. It may also uncover opportunities, risks, and constraints you may have not considered.
14. Balance the short term and long term. Whatever solution you devise to your problem, is it optimizing for the short term alone? or is it balancing short-term desirable results with long-term ones? There is no good or bad, only trade-offs.
15. Understand the trade-offs of every solution. Because complex problems often have conflicting goals, solutions to complex problems often involve trade-offs. What are the trade-offs a solution is making? Solution A meets goals X and Y, but falls short on Z. Solution B falls short on goal X, but overachieves on Y and Z. Which of the desirable results goals will a solution achieve, and which it won't? What about the elimination of undesirable results? Making these trade-offs explicit helps us

By applying these principles using our best judgement, we increase the odds of producing successful solution designs. There are certainly more principles than I can think of and list here, and perhaps I'll add more in later revisions of this guide. Now, it's your turn. Which principles do you apply in designing solutions to complex problems?

By the end of this step, we should have a short list of two or more solution alternatives. We should also know how each solution performs against the attributes on which we defined our goals.

Let's carry on with the sales revenue decline problem example. Here's a recap of the problem definition, goals, root causes, and solutions we designed.

Problem definition:

"The year-over-year sales revenue of our most profitable product line has grown by only 3% last year. We were projecting at least 7% growth. If this continues this year, this will rattle investors' confidence. We want to see at least 10% revenue growth (~$16MM) by end of this year. This gives us about 8 months of runway to achieve this growth. Whatever plan we come up with, we have a $1MM investment budget to work with. Unfortunately, we cannot change our product roadmap for this year."

Based on this definition, our goals are:

• G1: 10% revenue growth by December 31st (Attribute: Revenue growth in $)
• G2: Solve problem within $1MM budget (Attribute: Budget in $)
• G3: Achieve goals within 8 months timeline (Attribute: Timeline in months)
• G4: Only minor product roadmap changes allowed this year (Attribute: Number of minor roadmap changes required)

We completed our root cause analysis, identifying the highest-contributing root causes as:

• RC1: Recent product update introduced complexity, slowing down sales.
• RC2: Target customer segment preferences have shifted.
• RC3: Market‑wide decline in demand due to the emergence of Generative AI.

For brevity, let's focus on only RC1 for now. Say we applied the solution design principles to create the following solution alternatives:

• S1: Reduce the complexity. Simplify the product by reworking complex functionality.
• S2: Reduce the complexity. Simplify the product by creating a "Simple Mode" without the complex functionality.
• S3: Reframe the complexity. Improve marketing and sales collateral to showcase how complexity is in fact more control and flexibility.
• S4: Accept the complexity. Enhance product support and docs to help stuck and confused customers.
• S5: Accept the complexity. Provide free on-demand training with every product sale.

Each of these solutions will include an elaborate plan of what to improve, how to improve it, and how it satisfies our goals and (partially or fully) solve our complex problem. Now it's possible that all the solutions we come up with satisfy all of our goals. In reality, however, you know that's unlikely to be the case. Each solution will perform differently across the various attributes on which we specified our goals. A solution may crush, meet, or fail to meet a subset of the goals.

How can we compare these solutions' effectiveness? Which solution should we implement first? That is the topic of the next section.

3.3. Decide the best solution

Let's quickly recap our progress so far. We worked our way from problem symptoms to a proper and comprehensive definition of our problem. We identified the undesirable results we want to improve and took a baseline measurement of them. We specified the desirable results we want to see when the problem is solved as a list of SMART Output goals set on a set of attributes our stakeholders and decision makers care most about. We also identified constraints that restrict our ability to solve the problem, and reframed these as Input goals. We came out of this step with a clear problem definition and a list of goals.

We then dove into root cause analysis. We applied techniques like logic trees and model-as-a-lens to dissect and understand the systems in which the problem exists, including their structure and behavior. We generated hypotheses of what is causing our problem, and eliminated as many of them as we can, leaving us with the most likely root causes. We ranked our root causes by their contribution to the problem.

Subsequently, we switched into solution thinking. We applied the principles of solution design and our best creative thinking and judgement to design solutions that have higher odds of success. Our solutions are grounded in our understanding of the problem's history and context. We defined the steps and the high-level plan for each solution. We worked to ensure our solutions align with key stakeholder values as much as possible. We are intimately familiar with the trade-offs each solution makes (e.g., optimize output goal A at the expense of goal B), and how effective each solution is at achieving our different SMART Output goals.

If we had done our work right, we'd have two or more strong solution alternatives that solve our problem with varying degrees of effectiveness.

Now comes the time to work with stakeholders to compare solutions and decide which solution is best. Solutions for complex problems are often costly, time-consuming, and resource-intensive. Not only that, but also feedback from implementing solutions can be delayed by weeks or months, making rapid experimentation unfeasible. As a result, we need to do a good job of analyzing, comparing, and contrasting our solutions "on paper".

To do the on-paper analysis, we need a structured process by which we can compare and rank our solutions. There is a discipline under the field of Operations Research that is dedicated to formalizing this process: Multi Criteria Decision Analysis (MCDA). Under MCDA, there is a sub-discipline called Multi-Attribute Decision-Making (MADM) which addresses problems with a finite, pre-determined set of alternatives. The goal is to evaluate, rank, or select the best choice from this discrete set. In our case, our solutions are the alternatives we're comparing.

You may recall that in the problem definition step, we defined the meaning of "attribute" as something a stakeholder group cares about and that needs to be improved. We defined our problem-solving goals on these attributes. Attributes don't have to be restricted to goals. We can add as many attributes we care about as needed when compare solution alternatives.

The premise of MADM is that you can use mathematical models to assign utility scores to alternatives. The scores can then be used to rank alternatives, with the highest-scoring being the best. The models take in many inputs to produce the scores. The inputs include attributes, the relative importance or weights of each attribute from the decision maker's perspective (called 'preferences'), how alternatives perform on each attribute (called 'performances'), and even the degree of uncertainty of performances.

MADM methods go all the way from the simple and intuitive to the elaborate and complicated. Simple methods include computing the utility score for each alternative as a weighted sum or product of scores on each attribute. The scores can then be used for ranking solutions. More complicated methods include outranking methods (ELECTRE and PROMETHEE families), distance-based/ideal-point methods (TOPSIS, VIKOR), and others.

To me, the value of using MADM methods isn't in a model deciding on my behalf. Rather, it’s in going through the process of clearly defining solutions and attributes, deciding weights and trade-offs between attributes, and analyzing and comparing the solutions across then attributes, and putting it all in one place (be it Excel or paper). That makes it so much easier to reason about the alternatives and conduct what-if analyses.

I consider myself too new a student of OR/MADM to educate others on it. So, for this guide, I'll just share a simple and intuitive MADM method called Even Swaps [11] that I've used successfully for comparing alternatives, making trade-offs, and ultimately choosing the best.

Even Swaps

The Even Swaps method simplifies the task of deciding between multiple solutions alternatives across many attributes. Our goal is to decide on one alternative to implement. It's best to explain how it works using our "sales revenue decline" example problem.

The Even Swaps method is as follows:

1. Build a Consequence Table
2. Eliminate dominated alternatives
3. Make even swaps to eliminate attributes
4. Choose the obvious best alternative

Step One: Build a Consequence Table
The first step of applying Even Swaps is to build a consequence table. A consequence table has the solutions alternatives as the columns and the attributes as the rows, as shown below. It's called a consequence table because every cell shows the consequence of selecting a particular alternative (solution) for a particular attribute.

The columns represent the solution alternatives we came up with, S1 to S5. The first four rows represent the attributes on which defined goals G1 to G4. We also added one extra attribute our stakeholders care about: the reduction in customers' perceived product complexity as a result of implementing each solution. Remember, the attributes can come not only from our problem-solving goals, but also from any other aspect our stakeholders care about comparing.

Building a consequence table has some immediate benefits. It gives us a succinct and condensed view of how each alternative performs with respect to each attribute, and how they compare to one another.

Step Two: Eliminate dominated alternatives
Next, we work to eliminate as many solution alternatives as we can. After all, the less alternatives we have to compare, the easier the decision problem! But which alternatives should we eliminate? Dominated ones. An alternative is dominated when it performs worse on every attribute than one of the other alternative. In our case, S5 for example, is dominated by S4, as it's worse in every aspect. So, we eliminate S5 from consideration, along with any other dominated alternative.

In a large consequence table, it might be difficult to spot which alternatives are dominated by which. To make things easier, we can build a consequence ranking table. We don't need to build that table for our example, but if you are keen on learning how it's done, review the original article on Even Swaps.

Step Three: Make even swaps to eliminate attributes
Now that we've eliminated as many alternatives as we can, it's time to do something similar to attributes. Again, our goal is to simplify the decision problem.

In this step, we eliminate all irrelevant attributes. You may be scratching your head now and asking "What do you mean? All my attributes are very relevant". They are, but we will work now to intentionally make as many of them as we can irrelevant to our decision problem. Bear with me.

Let's consider attribute "A3: Timeline to Implement". Say we want to make this attribute irrelevant to our decision. To accomplish that, we need the consequence to be equal across all alternatives. All solution alternatives must have the same value for A3, and only then it becomes irrelevant.

Now, imagine we think to ourselves: "For every 1 month of reduction in timeline, we'd be willing to trade an incremental $50K in cost". We have just traded a reduction in timeline for an increase in cost. We made a trade-off between two different attributes. Using that value exchange rate we've just established, we can go over our alternatives one by one, making even swaps between timeline and cost consequences, with the goal of making A3 equal to 2 months (the best A3 consequence) across all alternatives.

The final consequence table for A2 and A3 will look as follows. We can now eliminate alternative A3, since now the dollar cost to implement compensates for it.

Just like what we did for A3, we repeat the process for other attributes. We make more even swaps, eliminating more attributes, and further simplifying our decision problem.

The challenge in this step is deciding on these value exchange rates between attributes. It involves subjectivity and uncertainty, and our biases may result in irrational trade-offs. Nevertheless, persisting and overcoming this challenge helps us be more transparent and explicit about the trade-offs we are making with ourselves and others. By being explicit about the trade-offs, we're able to review and validate them with others, including subject-matter experts.

Step Four: Choose the obvious best alternative

That is the easiest step of them all. By the time we're done with this process, a winning alternative will likely be obvious.

Parting thoughts on MADM
Beyond Even Swaps, MADM techniques are heavy, requiring expertise in the field and a significant effort and time investment to apply correctly. The more consequential a solution decision is, however, the more MADM rigor may be justified. If you're interested in learning more about MADM, have a look at the references section of this guide.

4. Implement the solution

We decided the best solution in the previous step, now it's time to make it a reality. In this step, we put together an implementation plan for our solution and execute it.

It's challenging to prescribe how to build such a plan, as much of it depends on the nature of the problem and the solution. So, what I'll do in this section is share three practices I found useful in implementation planning. It goes without saying that these practices won't apply to every situation.

1. Test on a small scale first
   It's unlikely that the first version of our solution will be the final, successful one. No matter how much careful thought we put into our solution design, we will almost always make implicit assumptions about reality that are inaccurate or plain wrong. Unexpected events or concerns would pop up foiling our best designs and changing our problem-solving goals. By testing on a small scale, we create a safe space where the risks and costs of failure are low. We can then test our solution, collect data and feedback, learn, refine, and iterate until we have confidence in increasing our solution's scope and scale.

In that safe space, we will run experiments to test the biggest and riskiest assumptions our solution makes. The experiments can take many shapes and forms-- from the simple, low-cost, short-duration like surveys and wireframe application prototypes, to the complex, high-cost, long-duration like randomized controlled trials (RCTs) and pilot programs.

1. Manage your solution implementation as a project (or a program)
   Apply project or program management best practices like defining and managing scope, duration, resources, and budget. If the solution takes months to implement, break it down into phases with milestones to validate results, manage risks, and change direction if needed.
2. Leverage Change Management models and best practices
   Whenever our solutions involve changing people, we'd be remiss if we don't use the wealth of theories and best practices under the change management discipline. There are old-school autocratic, top-down approaches and more bottom-up ones that value the participation and involvement of those who are subject to the change. The latter approaches are more modern and effective, often labeled as "organization development" approaches. There are approaches that aim go beyond incentives to make change fun or rewarding, like gamification. Every solution should involve conscious choice of change management strategies that are tailored to the organization and the problem/solution if the solution is to succeed and the change is to stick.

Where to go from here?

Congratulations, you have made it through the full complex problem-solving process, from vague symptoms to a robust solution implementation.

If this is all new to you, you have been exposed to quite a lot of topics. Take it easy, and read and re-read as needed. I intended this guide to be a handy reference you can bookmark and revisit as you work through complex problems. I also intended it as a springboard for you to dive deeper into the many exciting topics it touches.

There are many interesting, unanswered questions across every step of the complex problem-solving process. For example, how do we measure and account for uncertainty and risks throughout the process? What are the human biases that interfere with rational problem-solving and how can we counteract them? Complex problem-solving is rarely done in isolation. How do we collaborate effectively with others throughout the process? Why are certain theories like Systems Thinking and the Theory of Constraints especially important for every complex problem-solver to understand? How do we design proper experiments to help us with hypotheses testing? How can AI accelerate the process overall? How do we put our analysis on paper, so we can communicate it effectively? And, if you're in solutions architecture like me, how do we apply this process to common complex problems we face?

All of these are great topics for future posts. If you're super curious, though, you can go down the rabbit hole and try answering them yourself by exploring the references below or chatting with your favorite AI. We can also have a conversation about them. Drop your questions in the comments section.

Until next post!
-Moataz

References

Note: Book references include affiliate links.

1. Robertson, S. Ian. Problem Solving: Perspectives from Cognition and Neuroscience. Psychology Press, 2016. Amazon, https://amzn.to/48eRzdq
2. Meadows, Donella H. Thinking in Systems: International Bestseller. Edited by Diana Wright, Chelsea Green, 2011. Amazon,https://amzn.to/49eepD3
3. “SMART Criteria.” Wikipedia, 24 Oct. 2025. Wikipedia, https://en.wikipedia.org/w/index.php?title=SMART_criteria
4. “Abductive Reasoning.” Wikipedia, 16 Aug. 2025. Wikipedia, https://en.wikipedia.org/w/index.php?title=Abductive_reasoning.
5. Goldratt, Eliyahu M. Theory of Constraints. North River Press, 1990. Amazon, https://amzn.to/3WYerrn
6. Logic Tree Basics: Complete Guide Creating a Logic Tree. 15 Oct. 2020, https://reliability.com/resources/articles/logic-tree-basics/.
7. “Five Whys.” Wikipedia, 9 Nov. 2025. Wikipedia, https://en.wikipedia.org/w/index.php?title=Five_whys.
8. “Pareto Principle.” Wikipedia, 3 Oct. 2025. Wikipedia, https://en.wikipedia.org/w/index.php?title=Pareto_principle.
9. “Analysis of Competing Hypotheses.” Wikipedia, 24 May 2025. Wikipedia, https://en.wikipedia.org/w/index.php?title=Analysis_of_competing_hypotheses.
10. Montgomery, Douglas C. Design and Analysis of Experiments. Wiley, 2020. Amazon, https://amzn.to/4hXS4fc
11. “Even Swaps: A Rational Method for Making Trade-Offs.” Harvard Business Review, 1 Mar. 1998. hbr.org, https://hbr.org/1998/03/even-swaps-a-rational-method-for-making-trade-offs.