Think back to the last time you had a new idea. It was exciting and energizing, right?
You were probably so excited that you jumped to a whiteboard to sketch the idea or shot off an email about it to a close friend. The possibilities!
But now let’s picture that idea differently. Imagine it lives in this little box.
But your idea doesn’t live in this box alone.
Instead, ideas usually have two parts: a problem you’re solving, and a solution to that problem.
What we don’t often realize is that new ideas are born out of observations rather than epiphanies. The observations have likely been building in our minds for months or years, and by the time they snowball and emerge they end up feeling like an epiphany with a clear solution.
And while this is an exciting process to experience within our own minds, it actually hampers the potential of those contributory insights. This is because when we share new ideas, we often focus on the solution rather than the problem being solved. The solution, after all, is more tangible — we can sketch it or picture it in our heads. A problem, though, is more nebulous.
If we were to represent the typical process graphically, it would look something like this:
This is straightforward: you have an idea, you implement it, and it solves a problem.
But how might we get even more out of that idea?
The answer is to take your idea as an initial insight that could be used as a springboard to discover a problem, and let the solutions flow out of that problem instead. The process would then look like this:
The resulting effect is a much more efficient use of resources and time, since the upfront work you’re doing to investigate the problem can be repackaged and tested in many different solutions.
On a practical level, you can do this through assumption definition exercises and continual validation of your understanding of the problem through data and user testing. The ultimate result is continual refining through new inputs that challenge and build on the initial idea. You can think of it as Hegelian Dialectic for product:
This re-orients the process around continual problem validation and solution refinement:
Through this helical process, the original idea is rigorously refined through the constant addition of new insights and nurtured into its most optimal form.
And this approach is beneficial from an organizational perspective, too. Though it’s happy when it happens, rarely are people on the same page about a new idea. By starting with the problem not only are you less likely to get bogged down in details about the execution, you’re also more likely inspire those you work with and get buy-in to your idea. As Facebook’s Julie Zhuo wrote in a blog post that has become a must-read on building great products:
Teams that fall in love with a problem have more successful outcomes than teams that fall in love with particular solutions. This is because knowing that a problem is worth solving continues to be motivating even when a team doesn’t come across the right solution on the first, second, or Nth try.
Admittedly, it isn’t natural to unpack your ideas — or the ideas of those around you — and trace back to the origin problem. And starting with a problem is a bit scary — it means letting go of the solution to the problem and leaving the ultimate solution up to testing and user feedback. But understanding the problem you’re solving is the key to long-term product success and building something that people find valuable. As Astro Teller of X wrote recently:
Fall in love with the problem, not the solution.
So the next time you have an idea, ask yourself: what is the problem you’re solving, and what is the solution? Then extract the problem, and focus on that first. By liberating the problem from the initial idea, you can open up your understanding of the core problem you’re trying to solve — perhaps leading you to uncover deeper, more impactful problems that you didn’t realize were there.