When problem solving, look for simple solutions

Problem solving discussions on news broadcasts, in newspaper op-eds, on social media, and in political speeches have a consistent thread: “We can fix it by changing (one thing).

Most problems are not particularly simple. Societal and economic problems are incredibly complex, even in a small community. Winning a game of chess against Bobby Fischer or IBM’s Watson might be easier.

As a result, problems usually require a multi-faceted approach. Unfortunately, that often tempts us to eliminate any “one thing” strategy under the presumption that it’s ineffective, naive, or “too simple”.

Problem solving cause & effect

Rotary has for decades funded and built simple hand pump water wells in villages where there’s no dependable, convenient source of clean water. Many other organizations do similar water projects.

Does convenient access to a dependable source of water (ie: eliminating a three hour round trip hike) solve 100% of a third-world village’s problems? No. However, gaining easy access to clean, disease-free water for a village’s people is comparable to the impact of U.S. rural electrification projects of the mid 1900s. Electrification didn’t solve every rural problem, but it had a huge positive impact on rural communities.

Vilfredo Pareto was an Italian engineer, sociologist and economist of the late 1800s and early 1900s. While he “invented” modern microeconomics, many recognize his last name thanks to his “Pareto principle” – what we call “the 80/20 rule”. The principle states that 80% of effects come from 20% of causes.

Is it accurate to six decimal places? Probably not. Does it describe cause & effect in 100% of situations? Probably not. Does it describe a large percentage of cause and effect in business and society? Pretty close, I’d say.

If a single, simple strategy or tactic solves 80% of a problem, I’d call that a pretty good start. You may not have implemented a perfect solution, but you’ve made a boatload of progress.

Expectations matter

Managed expectations go a long way when solving problems.

Name the last time you solved a problem with a single solution and that solution performed perfectly 100% of the time, in every possible scenario so far – and can reasonably be expected to continue solving the problem in the foreseeable future.

A simple solution is often dismissed because it doesn’t solve the problem 100% of the time, or in 100% of scenarios where the problem can occur.

The “Do Not Call” system is a good example. Elected officials seem to agree that robocalls, cloaked and spoofed calls need to stop. Yet they’ve done nothing about it and continue to exempt themselves from existing robocall legislation.

While technology, laws, and a few vendors make it very difficult for us to solve 100% of this, you can solve 80% of it by using a Google Phone number when you don’t expect or want that party to call you. This is particularly true when the data is somewhat publicly accessible, such as voter or website domain registrations.

Google Phone will take those calls / texts, letting you avoid numerous unwanted interruptions via your cell.

Refining problem solving

Most solutions won’t resolve 100% of a problem’s scenarios. If they do, they’re often incredibly expensive, difficult to implement, hard to use, or all three. Even so, edge cases still find their way in.

Despite that, 80% isn’t always enough. Instead of looking for perfect solutions, try iteration. If your first simple solution solved 75 to 80% of the situation, look at what’s left.

What additional simple change can you make to fix the majority of the remaining situations? If you have 100 problem situations, your first 80 / 20 solution leaves 20 situations to resolve. Solving 80% of the leftovers leaves only FOUR percent.

Look at that again: Two simple solutions take you from 100% to four percent.

If you need to, refine again. At some point, the ROI of the next solution will tell you it’s time to move on to other problems.

Imagine that a single tweak to your sales process results in closing 80% of the sales you weren’t closing. Or that a single change in your manufacturing process reduces costs, in-use failure, or warranty claims by 80%. Neither are 100% solutions, but I doubt too many would object to that level of improvement.

If your approach to problem solving starts by looking for simple solutions, testing, implementing and iterating, the number of problems you face and the time and expense invested in dealing with them is going to shrink significantly.

What would you do with that newfound time and money?

Work Linear vs. Parallel

This week I traveled to Kyiv, Ukraine for meetings with a software team. The meetings went well and I will be on my way home by the time you read this, however I had some travel issues.

It’s worth noting that all of the issues I encountered were either created or they were problems that are not allowed to solve themselves because the people and systems communicate with each other at a level that forces them to work in a linear fashion.

It prompts questions we should consider for ourselves and our clients.

What do I mean when I say “Work linear vs. parallel”? Some examples from my trip provide a good illustration.

Working linear

When my plane from Missoula left Salt Lake City (SLC), it left late because the de-icing line in SLC was long. I don’t know if they had a de-icing truck out for repairs, or if they simply didn’t allocate enough trucks or drivers, or if something else was going on.

Regardless of the reason, the situation and the possible lack of fallback solutions (ie: backup trucks, drivers on call, etc) created delayed flights for many that day – creating a linear problem.

If the normal pace of takeoffs cannot be maintained, then SLC becomes a bottleneck in the West and flights to surrounding cities start struggling with schedules as a result.

This cascades into many linear problems at once since every city with a late flight potentially has stranded passengers or passengers with missed connections. Old news, but it’s important to consider how quickly this can cascade.

When my plane left Missoula, it did not de-ice. I don’t know what the protocol is for de-icing, but about 15-20 minutes into the flight, we had failed to continue our climb to cruising altitude and started to turn back. The flaps would not retract and this wasted too much fuel. Unfortunately, we were above maximum landing weight, so we circled for 20-30 minutes to burn off enough fuel to land.

The irony is that this circling was burning the same fuel and time we would have burned if we had simply continued to SLC with the flaps down, normally a 54 minute flight.

This quickly ate into the layover I had built in.

When we got to SLC, we were unable to pull into our gate right away. By the time I got to the gate for Paris, the plane door was closed and I could not board.

Five minutes matters

The big thing that hit me during this process was seeing multiple instances of seemingly insignificant two to five minute delays cascading into hours of delays. Any one of them could have been planned out of the airline’s response and it would have allowed enough time for three people on the Missoula flight make the connection to Paris, much less all the other people who were missing connections that afternoon.

The thought to consider is this: How many two to five minute delays are built in to what you do, how you serve, how you deliver, etc? How do these affect the client’s outcome? What costs do they increase when service fails? What costs will the client incur?

What happens when a few of these five minute delays push your delivery of products or services to the next business day?

What systems do you have in place to automatically tend to conditions that can create these delays?

Working parallel

Every business encounters problems. How businesses react to them and what they do to eliminate / prevent situations that are controllable is critical.

How does automated, perhaps parallel problem solving save money? What delays can be addressed without waiting for them to happen? What delays can be reacted to with automation to accelerate a response and solution?

Cost examples from a plane trip:

  1. What’s the circling fuel expense to get below max landing weight vs. the cost to continue to SLC?
  2. What’s the cost of lost seat revenue for the empty seats and hotel stays for interrupted travel?
  3. How much delay is introduced at the gate when you don’t automatically rebook travelers?
  4. On a daily basis, what does a five minute gate wait cost, in missed connections, lost seat revenue and hotels?

Look at your business. Make a list of preventable delays. Knock off one at a time.

Do your clients need a faster horse?

Back in the last century, Henry Ford is famous for saying “You can have any color Ford you want as long as it’s black.”

Today, Ford Motor Company has a different thought process, but that isn’t all that Henry said.

He also said this:

If I’d have asked my customers what they wanted, they would have told me “A faster horse”.

Doing research into customer needs is a necessary thing, just don’t confuse the customer’s stated needs with the problem they’re actually trying to solve.

When a client says they need a faster horse, don’t they really mean “I need to go faster”?

What about your clients?

How much time do you spend studying what your clients *really* need?

  • Isn’t anticipating those needs what market leaders really do?
  • Isn’t it your job to see them before anyone else?

Isn’t it your job to present those new solutions to problems clients didn’t realize they had – until you pointed them out?

One of my favorite local CEOs here in Montana says they deliver their products “just before just-in-time”… isn’t that the job of a market leader?

It takes some thought, in fact, maybe even some study of the problems your clients really have. Not just a questionnaire about the problems of today often caused – paraphrasing what Einstein said – by the thinking of yesterday.

Did any of us realize we needed a Walkman until Sony pointed it out? Or an iPod, until Apple started selling them?

So think about it: Do your clients *really* need a faster horse?

Or is that just a symptom that cloaks the real problem facing them?

Find and fight the fire before the customer does

In a recent email to senior Microsoft staff, Bill Gates had rather unflattering comments about a pre-release download and install process for Windows Moviemaker.

Every one of us can relate, right?

As for the message, Gates smiled and said, “There’s not a day that I don’t send a piece of e-mail … like that piece of e-mail. That’s my job.”


No matter how high up you are, one of your jobs is to find the problems before the customer does.

And yes, I’m sure someone will wonder aloud where he was on Microsoft Bob, or on Access 1.0, or on <whatever>. Perhaps it’s best to wonder what it would have been like otherwise:)

In the software business, we have a term called “eating our own dogfood”, which means using the software you sell to clients. Whenever possible, it’s a valuable effort because you look at things differently as an end user than as a programmer.

Eating your own dogfood can and should extend far beyond the software business.

No matter what line of work you’re in, you can find a way to…

  • Secret shop your store(s).
  • See that your friends and family have to deal with your business and your products, anonymously if at all possible.
  • Watch someone try to use your website, or listen as they call your business for help, to make a purchase, obtain service and get advice.

Find the forest fire smoldering inside your business before the client does.