Finding that One Problem
“If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and five minutes thinking about solutions.” — Albert Einstein
In the world of product development, finding a problem to solve is part of the job, regardless of the role someone is filling. Arguing which problem to solve, differentiating between 2 closely related problems, figuring out which to be taken care of first, are things that you can find in a product team discussion. However, one part that I think can be beneficial to any product team, is going deep into understanding what is the actual problem. Here, people often mistaken observation with a problem.
Take for example this case. En route to my way home, I often experience a long queue in a central bus station. And in several occurrences, this long queue leads to a very packed station. If I jump into problem statement creation a la Design Thinking, I’ll probably write this statement
How might we reduce queue in central bus station during peak hour, so that the bus station is more comfortable for commuters
Now think about that for a second, a long bus queue is an observation. It may looks like a problem, but I have to validate whether or not it really is a problem. What I can derive, after some time, is that a long bus queue is an effect of a more fundamental problem: capacity of the incoming bus is less than the influx of commuters during peak hour. Moreover, a long bus queue for a commuter, may not be an issue, they can endure it. What irritates them is the effect of this queue: unpredicted time to reach home. Hey, after all, the reason they go to a bus station after working for 8–9 hours, is to reach home.
Therefore, the above observation, could results in 2 more fundamental, or dare I say, exciting problem statements
How might we increase the number of bus serving during peak hours so that more passengers from busy points can be served
or
How might we help commuters to arrive home in a predictable time, during peak hours, so that they can feel relaxed even in a packed station
I don’t say that the very first problem statement above is invalid or bad. It’s just if you think deeper, you can encounter a more fundamental problem to solve, something closer to achievable solution. After all, identifying problem is only part of building solution. Also in spirit of iteration, the last 2 problem statements are definitely still open for another round of exploration to pinpoint a more fundamental problems.
To conclude, if you’re a practicing product manager, user researcher, designer, or software engineer, looking for a problem to solve, I strongly urge you to rethink of what is the observation at hand and try to see the actual problem there. No need to rush. The quality of the solution you build, hinges on your ability to pinpoint the actual problem.
And yes, do not write solution under the disguise of a problem statement.
How might we build a dashboard to display time for a bus to reach a station
Is not a problem statement.
