It’s human nature, when faced with a problem or a dilemma to jump to a conclusion or in this case a solution. In the short term it might work out but issues will pop up sooner or later. I see this a lot happening when working on new features or products. And its really important to take a step back and consider every possible angle before you take that plunge.
I really like the image above, I saw it months ago published in an article on medium (author twitter handle in image) and it made me think of the phases at that time, but now I look at it to remind me to always scale it back.
Whether adding on a new feature or starting on a product from scratch I think it’s easy for us to forget the problem we’re trying to solve and fast forward to all the upsides and successes that we’ll achieve.
We immediately start thinking of the utility phase, and plan roadmaps, specs and worst of all skewing customer feedback to fit that mentality. We stop thinking of the problem we’re trying to solve and we’re jumping straight to solutions.
I’ve been in many meetings where the discussion veered way off track, that solutions were being thrown around for entirely different problems! And herein lies the, well, problem. Our brains are too quick to jump to solutions even without any slight shred of data. To make it worse we lose sight of the problem, and in such meetings the following quote always pops up in mind:
“The problem is we don’t understand the problem” – Paul McCready
And even if we think we do, we go completely off tangent and start solving for another one because we all like the two birds, one stone thing.
At the end of the day, you want to build a product that really answers a need, solves a solution or just gets the job done.
So when you ever find yourself in that situation:
- own up to it,
- take a step back,
- and try to truly understand the core of the problem you’re trying to solve
I’ll leave you with this cool 5min video I’ve recently watched from Clayton Christensen, professor at Harvard Business School talking about the milkshake problem using the jobs to be done technique: