The first step of solving a problem is properly defining it
Many times, when facing a new problem, the first thing you want to do is to jump right in, and try to solve it. If it’s a simple problem, or a even a familiar problem this might work out “OK”. But if it’s one of the more interesting cases - an unknown, or complex problem, rushing in to solve it, without taking the time to fully understand and define it, might not be your best course of action (to say the least).
Unless you distill the problem to its root cause, you’ll be spending your time solving a different problem.
What happens if you don’t properly define your problem?
You see, problems, much like everything else in life, happen for a reason. And the reasons are much harder to spot by mere observation. They could be hidden from plain sight (or from your analytics / reporting tools), they could be disguised as other problems with their own seemingly unrelated reasons, they could be overlooked because of various assumptions, etc. The point is, unless you distill the problem to its root cause, you’ll be spending your time solving a different problem. That problem could be broader than your real problem which means you’ll be wasting more resources than you could. It could be narrower, in which case the solution, by definition, will be partial at best and will most likely have be replaced. Or it could be completely different, meaning you’ve basically wasted your time as the real problem persists.
But what about urgent problems with tight deadlines?
Well, as time goes by (and I learn from more mistakes), I’m starting to realise that there really is no alternative to doing the proper research. It’s like not taking a map when driving somewhere you’ve never heard of. The odds are you’ll be making a lot of mistakes along the way, and you’ll probably be late. As Albert Einstein (supposedly) once said: “If I had one hour to save the world I’d spend 55 minutes defining the problem and only 5 minutes finding the solution”. Whether dear old Albert actually said it or not, and whether he actually meant splitting the effort that drastically, or used a different ratio, I think the point being made is that defining the problem is a significant part of a good problem solving process :).
I really hope I managed to persuade at least some of you of the importance of the problem definition process. I know I always end up regretting the times I underestimated it. And like I said in my previous post, this is all part of a whole new journey toward becoming a product manager, so I’d love to hear what you girls and guys have to say about it. Your comments and follows really mean the world to me :).
P.S.
As I was writing this article, I remembered a famous cartoon I often encountered as a software developer. Its called the project management tree swing. I think it really illustrates how badly things can get when a problem (or in this case a product) is poorly defined. :)
