Problem Design – Look Before You Leap

Probably the most common challenge I have come across throughout my career is the human tendency to jump to solutions. We are naturally inclined to solve problems. But sometimes we jump to solutions before we understand the problem we are solving. Problem Design is the structured approach I use to force understanding of a problem before starting to solve it. You can’t solve a problem you don’t understand. You need to look before you leap.

If you can clearly define the dream or goal, start.
-Simon Sinek

While Simon refers to dreams and goals in his quote, problems are no different. Building clarity, understanding, and alignment around what you are trying to solve is the first critical step to delivering a working solution.

Problem Design

Sometimes you are handed a challenge in the form of a new goal or target that you are trying to achieve. Sometimes that challenge comes in the form of complexity or inefficiency in an existing process. In both cases, you are just solving problems. But in both cases, it is easy to overcomplicate the act of solving the problems.

Our human tendency to jump to solutions means that we rarely spend the time to understand the problem up front. In the interest of urgency and speed, we move quickly to finding solutions, even if they are complicated and hard to execute. By skipping or rushing the problem definition, we complicate the solution which has many follow-on impacts. We deliver solutions slower, with more complexity, and with less efficiency if we don’t look before we leap.

Two Symptoms of Solution First Thinking

Most often I see two issues emerge when people skip or rush the problem design process.

1. Solving the symptom and not the problem
2. Solving multiple problems that shouldn’t be connected

If you do any reading on the topic of problem-solving, you’ll find lots of writing on the first issue. Symptoms often present themselves as problems unto themselves, and we know we need to dig beneath the surface to find the underlying causes. Your first step in any Problem Design exercise is to ensure that you are dealing with the problem, not the symptoms.

The second issue is harder to identify. You may be solving a real problem, but it is very easy to group problems together that shouldn’t be solved together. Breaking a problem down into its smallest logical components is critical so you can evaluate whether the components should be grouped or solved separately.

Solve the Problem, Not the Symptoms

To ensure that you are solving a problem and not the symptoms you can leverage the simple 5 Why’s approach. Originally developed by Sakichi Toyoda for the Toyota Motor Company, this simple exercise will force you to think about the underlying causes of the symptoms. When a symptom presents, you need to start asking why questions until you get to the root cause – the real problem.

For example:

• The vehicle will not start (looks like a problem but is really a symptom)
  1. Why? The battery is dead. (Still a symptom)
  2. Why? The alternator is not functioning. (Also a symptom)
  3. Why? The alternator belt is broken. (Looking more like a problem, but let’s keep pressing)
  4. Why? The alternator belt was well past its useful life and hadn’t been replaced. (Now we’re getting somewhere)
  5. Why? The vehicle was not maintained according to the recommended service schedule. (Finally… a PROBLEM)

All of the answers to the why questions look like problems, but until we get to the root cause we are only solving symptoms. Fixing the alternator without fixing the belt won’t help at all. Fixing the belt without understanding the service life starts to help. Understanding that the vehicle was not being maintained and solving for that will allow us to prevent not just alternator and battery problems, but proactively prevent a host of other vehicle problems in the future.

Solve One Problem At A Time

To ensure that you aren’t grouping problems that might not need to be related I use the “Jobs to be Done” approach. While the Jobs theory is targetted at innovation efforts, it can be equally helpful to break down problems. Take a look at the problem you have or the process that is creating the problem and list the jobs that it fulfils. Then look at each of those jobs and separate those that aren’t related to the same purpose.

For example:

The situation:

• In a small business, all cheques are signed by the owner of the company.
• The organization is finding that cheque signing is slow, time-consuming, effort intensive, and is preventing them from taking advantage of early payment terms from their suppliers.

The current process:

• Purchase orders are issued to suppliers, and invoices come in once products or services have been provided matching those purchase orders.
• To get a cheque signed, accounting needs to provide all the backup materials for the source of the expense including all other related costs on a work order to ensure that the job is profitable.
• If the profitability of the job doesn’t meet the expected standards, additional explanations and paperwork may be required.
• When additional information is required additional resources may be needed to provide the backup, often including 3-4 people in the process of getting a cheque signed.

The “Jobs to be Done”:

• Pay a supplier invoice
• Validate profitability of work

In this case, there are two completely separate problems being solved within a single process. Profitability validation is causing time delays and missed savings opportunities in the payment process.

Take the time to understand the jobs, and you can get clarity on the problems that need solving.

Learn and Practice Problem Design

If you want to be most effective as a leader and manager, take the time to practice these simple skills. Work the 5 Why’s to make sure you are dealing with the root problem, and leverage the jobs theory to break complex issues apart. Building your problem design skills will pay off by saving time, eliminating waste, and making problem-solving easier within your organization.