Often the most difficult discussions I have had in my professional career is to get a clear definition of what the problem actually is, not what my client thinks the problem is.  This is not to say that clients don’t know what they want, it is just that they usually frame problems in the form of a solution.  Kind of like a perverse form of Jeopardy.

What is a Problem?

The first thing we need to recognize is how we understand the word “problem”. What if we define a problem as “a difference between what we perceive to be and what we want it to be.” This a more general problem definition. One that does not specify a solution but rather one that describes what you want something to be. This is often why you sometimes hear the phrase “is it a problem or an opportunity?”  For any problem (not what they want), there is a potential solution or opportunity to give them what they want. 

People are usually very good at identifying problems. But, somewhere in the back of our heads, people tend to try and come up with solutions to that problem.  This unfortunately is often communicated as the problem itself. For example, if a store owner needs to know if they are making money, they may come to you and say they want a report that shows all the transactions that happened during the month, so they can see if they have a cash flow issue. In this case, the store owner has given you a solution, not the problem. The issue they are trying to convey is that “I currently do not know if we made any money during the month”. In this case a much simpler report could be made, just adding up the transactions (credits/debits) and give you the result. Individual details of each transaction do not directly answer the problem.

The Knowns, Known Unknowns, and The Unknown Unknowns

Individuals have two types of knowledge. Things that they know, and things they know that they do not know. But, there is a huge amount that individuals don’t know that they don’t know (Unknown/Unknowns).  This leads individuals to come up with solutions that only encompass two of the three pieces of the knowable solutions. 

So the best part is we can start by throwing out the solution we are given.  It may be right, it may be wrong, but let’s first start be defining the problem.  Throwing out the solution to start with leaves us without any constraints, allowing us full freedom to make any choices.  Since imagination and thoughts are free (although time is not), we have so much more we can do.  The first is to dive into what is the value we are proposing to get out of solving the problem.  Is this value measurable in some way, i.e. we get x amount of revenue, or I feel happier at work?

Learn to State a Problem

So let us set up a scenario where we are a general contractor that is finishing a basement. The owner gives us this as a requirement “I want a light in the basement”. Seems straightforward. Who doesn’t want a light in a dark place?

Even in this simple example (taken to the extreme admittedly), I try to answer these three questions:

1. Who is this providing value for
2. How do we show value for solving the problem
3. How would we define success after solving the problem

For those of you that have had some agile training you will see this as a variation of the Given/When/Then acceptance criteria.

“I cannot see inside my basement when it is dark outside, I want to be able to see the items in my basement when it is dark when I use a switch”

Not once did I say anything about HOW to solve the problem besides how I want to initiate the action. This was just trying to identify what are the constraints that any solution must satisfy. 

1) The person needs to see the items in the basement and
2) the person wants to use a switch to be able to see the items

If the solution falls within the constraints and fulfills the success criteria, we have a successful solution.

This leaves the person solving the problem with everything they need to solve the problem right? They know what the constraints are, and they know what would make a solution successful. I would argue that we have a much better chance at solving the problem when it is stated this way.

Even in this simple example, there are unknowns that couldn’t be known when stating the problem. However, since the problem was framed with what the outcome was intended to be and the constraints some unknowns do not necessarily doom the final solution. Maybe we can’t run electrical wire from the switch to the light. Then we could decide to use wireless switches, or maybe using WiFi to control the light. Since our problem statement did not define HOW to solve the problem, we can think of many different solutions.

Inevitably, you will know more about the actual solution at the end of the process, than you did at the beginning of the process. This is gaining experience, this is gaining knowledge.

Being able to define a problem better will make you a more effective problem solver