What Problem Are You Trying To Solve

One of the most important lessons I’ve learned to ask during my BA career is “What problem are you trying to solve?” It’s not as straightforward as it might appear.

Often, business partners come with all sorts of preconceptions, which they present as the actual problem. Sometimes they try to be helpful. It’s the BAs job to ask more questions to determine if that’s the real problem.

For example, I had a business partner who told me that the data in an email we were sending to one of our customers was “encrypted”. It would have been easy to waste hours trying to chase that down. I started down that road, until I caught myself and asked “What’s the problem I’m trying to solve?” I asked the business partner to see a copy of the email. It was then that I realized that what she was referring to as being encrypted was actually just raw XML being presented straight to the page. The problem wasn’t that the email was encrypted, it was that it wasn’t easily readable by a human. One parameter change later, and the problem was fixed.

Donald Gause and Gerald Weinberg wrote a seminal work on discovering the real problem called “Are Your Lights On?” I reread it at least once a year, to remind myself how to ask the questions needed to determine the real problem, because sometimes what appears to be the problem at first glance isn’t the real cause.

A recent real-life example was encountered by the Dutch bike manufacturer Van Moof, who found that over 25% of their bicycles were being damaged en route to the customer, especially when being shipped to the US. The company could have invested money in improving their packaging or looking for a new shipping company. Instead, they spent time identifying what the real problem was: the people doing the shipping weren’t being careful with the product, perhaps because they perceived a bicycle as being sturdy enough to withstand rough handling. Or perhaps they didn’t perceive bicycles as being as valuable, so they didn’t feel the need to take extra care when handling them. What was the solution?

In the end, the bicycle company put a picture of a large screen TV behind the picture of the bike. They didn’t indicate that there was a TV in the box. The shippers, who apparently don’t have time to read carefully, treated the updated boxes like there was an actual big screen TV inside them. As a result, damages in transit dropped by 80%.

---

---

1. Asking the business or customer what the problem is that they are trying to solve isn’t the end of the process, it’s only the beginning. Here are some ways you can get to the real problem:
   Ask what things would look like if the problem was solved. Often, this will let you identify the real problem based on what the business sees as the desirable result. An example given in the book was a building whose tenants complained about the elevator being too slow. The desired solution wasn’t that the elevators be made faster, it was that the tenant’s stopped complaining. In the end, a mirror placed on each side of the elevator offered enough distraction that the perception of the elevator’s speed was no longer an issue.
2. Don’t accept a solution as the problem. Often in my career, the customer brings a solution that they want rather than a problem to be solved. Asking what the problem is that’s trying to be solved often allows for simpler resolutions. For example, one department is complaining that another department’s data entry isn’t accurate. The solution they presented was to add a high number of edits and validity check to the system where the data was entered. This would have required a large quantity of analysis and development time to ensure that the validations were correct and didn’t create additional follow on effects. Instead, time was spent bringing the two departments together to discuss the issues and looking for ways to improve accuracy at the front end. In the end, development wasn’t required, and the problem was solved via process improvement.
3. Spend time on root cause analysis. Sometimes the perceived problem is a symptom, not the actual malady. When I wrote software, a bug would frequently be caused by a change to a variable much removed in the stack from the code I was looking at. Doing root cause analysis will often help you identify what element is actually causing pain. This can also be a matter of overlooking something because “We’ve always done it that way.” The root cause may be the result of some process before or after the pain point that is creating the issue.

In the end, finding the real problem that needs to be solved, can be simple, complicated or somewhere in between. Taking the time to do the right level of investigation is an important part of the BA’s value in the development process.