When I started as a business analyst at BizStream, I was advised that my primary responsibility was to identify the problems while the developers would focus on finding the solutions. Although I acknowledged the developer’s crucial role in resolving issues, I found myself resisting this notion. After all, problem-solving was a skill I enjoyed and believed I excelled at. Wasn’t this a primary reason I was hired in the first place? Despite myself, this line of thinking led me to contemplate the nature of problems and how we go about identifying them.
It became apparent that one cannot arrive at the correct solution without fully comprehending the problem at hand. Attempting to fix a car without diagnosing the issue or prescribing medication without understanding the ailment would likely exacerbate the problem rather than improve it. Similarly, when building projects at BizStream, it is imperative to grasp the client’s challenges thoroughly to create effective solutions.
Albert Einstein once said, “If I had an hour to solve a problem, I would spend 55 minutes trying to understand the problem and 5 minutes solving it.” This raises a fundamental question: How do we differentiate the true problem from mere symptoms or predetermined solutions?
Here is a story I believe demonstrates this well:
One day, while walking through a forest, a young man came across a river. Thrashing about in the waves was a child, struggling to stay afloat. Immediately, the young man dove into the water and pulled the child to safety.
At first glance, the problem seems straightforward—the child needs to be rescued, and the immediate solution is to jump in and save them.
As soon as the child was on shore, the young man looked up and, to his horror, saw two more children floating down river. Jumping back into the water, he grabbed one, then the other, pulling them ashore. A second later, another came struggling down the river. Without having the time to understand what was happening, the man continued rescuing the children as they floated down the river.
Thankfully, at that moment, a woman was walking by and saw all the chaos happening in the river. Grabbing a long stick, she jumped out onto a rock situated in the river, and extended it to those she could reach as they floated by.
At this point, someone else is confronted with the same problem but offers another solution. Oftentimes we find a solution to a problem and immediately quit looking for other potential solutions that may work even better.
The more the pair rescued, the more children that seemed to come down the river. The woman, reaching multiple children at a time as they floated within reach, and the man all the children that were farther out. Even still, they were quickly becoming tired and overwhelmed.
Another woman heard the commotion and came running. Seeing all the children in the water and the many more exhausted on the shore, she turned and began running upstream. The man and woman who were still actively trying to save children yelled to her, “Where are you going? We need help!” As she was still running she yelled over her shoulder, “To find out who’s throwing all these children in the water and stop them!”
In this scenario, we uncover the underlying problem—why are children being thrown into the river in the first place? Initially, rescuing the drowning children may appear to be the problem, but it is, in fact, a symptom of a more profound issue. While treating symptoms is essential in emergencies, consistently treating symptoms as the primary problem leads to trouble.
For instance, if a client has a major bug that needs to be fixed that is caused by an aging technology stack, the best approach isn’t to leave the bug while we figure out how to update the entire website. First, take care of the emergency, then take care of the underlying problem. However, we get into trouble when we continuously treat symptoms as If they were the underlying problem.
This takes us back to the original question: How do we know what the true problem is instead of a symptom of the problem? One question I like to ask that helps me identify the root issue is, “How would we ideally want such and such to function?”
Asking questions to the client that helps enlighten where we are headed is neither prompting a solution nor asking what the problem is. In fact, as said before, we cannot determine the solution before knowing the problem, and we cannot know the problem without knowing where we are trying to get to.
To take the above story as an example again, if you asked the first two who arrived on the scene what they would like to see happen or what is an ideal state considering the situation, having better recuse equipment or being a stronger swimmer would not really address the problem. It would address the immediate symptoms of the problem and may prove to be very helpful. However, they do not solve the problem. The answer is to not have children floating down the river.
Let me take an example from building a website. Let’s say a content admin has received frustrations from their website users that their homepage is too busy with links. The content admin comes to BizStream and requests we figure out a way for the homepage to be redesigned so that it looks less cluttered while still giving users the same amount of links to choose from so that users can still get to where they want to go.
In this situation, you may notice the client already has a solution in mind, that is, to redesign the homepage. But what is the problem? The users of the site feel that the homepage is too cluttered and the content admins feel the homepage needs all that information to support their many audiences.
Instead of asking for the problem, let’s ask the question, what do we ideally want to happen? In this case, I would argue that ideally, the user would land on the homepage and could immediately find what they are looking for without showing anything superfluous. This may seem at first impossible. After all, how can we know what the user wants to see on page load? But if we start with the end in mind, it can help us determine what the real problem is: Users aren’t able to quickly and conveniently get to where they want to go. This problem statement opens up many more potential solutions than “The homepage is too cluttered”.
Stating the problem more openly and based on an ideal ending, we can only now determine what a potential solution would look like. For example, we may suggest adding a more robust search with search ahead capabilities. Or, we might suggest personalization, an often underutilized feature of Kentico that tracks users’ preferences and places them as part of a group set by the content admins. Content could then be displayed based on a user’s history on the site. We could even simply allow users to set their own “favorited” links, allowing them to always quickly get to where they want and remove the rest.
By beginning with an ideal end in mind, it allows us to help uncover the root of the problem, rather than symptoms of a larger problem. And while symptoms do sometimes need to be dealt with, a holistic and effective solution can only be designed after the problem has correctly been identified. So even though solutioning is a technological challenge that often should be approached by the developers, it turns out that problem-finding needs quite a bit of solutioning itself.
We love to make cool things with cool people. Have a project you’d like to collaborate on? Let’s chat!
Stay up to date on what BizStream is doing and keep in the loop on the latest in marketing & technology.
