Discovery – Problem vs. Solution

To continue with the series on common misunderstandings about product discovery, in this article I’d like to discuss a very fundamental confusion that exists with a remarkably large segment of the product community.  For some people, this is even an emotional issue as it gets to the core of what a lot of product people think of as gospel, but they are paying a very high price for this mindset.

For as long as our industry has existed, people have wanted to separate the product world into “problem space” and “solution space.”  The problem your customer has, and the solution we provide to address that problem.

This is certainly logical, and for many simple situations honestly it’s not a serious issue, but I’ve always resisted being dogmatic about this, because in so many of the best products and innovations, the breakthroughs happen precisely when we break down that wall between problem and solution space.

The clearest example of this is when enabling technology opens up solutions to problems that people didn’t even realize they had.  This is what is so fundamentally different about technology powered products.  Our customers often have no idea what is just now possible.

More generally, with technology products, as you explore potential solutions, your understanding of the problem develops and deepens, often in unexpected and powerful ways.

So this is an important principle to understand about product discovery, but beyond this, one consequence of this problem vs solution space thinking is how often I find product teams that associate product discovery only with “exploring the problem space.”

These people have this overly simplistic notion that product management and product design work to define the problem, and then engineering works to build a solution.  

Such a nice, clean separation between what product and design do, and what engineering does.

Unfortunately, this overly simplistic thinking usually kills any chance for real innovation.

First, we should get out of the way, the harmless consequence of this thinking: there is no problem with making sure you understand the customer’s problem, and that it is indeed a real problem.  We have very good, fast techniques for this, including discovery framing techniques and demand validation techniques, and there’s simply no excuse not to use these if you’re unsure of the problem, or if demand is uncertain.  And I’ve written many times about the value of including at least one engineer with you every time you visit a customer, or otherwise work to understand the problem.

Few things are more wasteful and frustrating than spending a ton of energy solving a problem that customers don’t care about.

But that’s rarely where the issue is.

The vast majority of product efforts fail not because of demand, but because they can’t come up with a solution good enough to get people to switch.

Ultimately our job in product discovery is not just to validate the problem, but to come up with a solution that customers love, yet works for our business.  What this means specifically is to come up with a solution that is valuable, usable, feasible and viable.

And this is why in strong product companies, the vast majority of our product discovery work is spent – and needs to be spent – on the solution.

And hopefully it’s clear to you that this goes well beyond just engineering.  It is the collaboration of product (representing value and viability), design (representing usability) and engineering (representing feasibility) that generates great products.

It is the interplay between these three dimensions.  Technology enables better experiences and new functionality.  Good user experiences aren’t just usable, but they increase value.  And of course understanding the various legal, privacy, ethical, financial, sales, and marketing constraints informs the functionality, experience and value.  It is the intense give-and-take between these considerations that can yield a winning solution.

This is such a fundamental and important point about product, and it’s too important to not understand.  Just consider any of your favorite products: 

MP3 players existed for years, and then the iPod came along and was dramatically better.  Cell phones existed for years, and then the iPhone came along.  Search engines existed for years, and then Google came along.  We’ve watched movies for years, and then Netflix came along.  We’ve listened to music for years, and then Spotify came along.  Teams needed to communicate for years, and then Slack came along.  We’ve needed places to stay when we travel for years, and then AirBnB came along.  We had free and fair elections for years, and then Facebook came along.

It’s worth noting that if you have a crappy solution, it can look to you like the demand isn’t there.  You know you can’t sell it, and it’s tempting to blame this on demand, but this is rarely a sign that the problem isn’t real; it’s much more often a sign that your solution is not perceived by the customers as better than the alternatives, and certainly not better enough to persuade the customer to switch.

One other factor that’s worth calling out.  You need to realize that as soon as you start working on a problem, as far as your management is concerned, the clock starts ticking.  And soon enough, they will want to see results.  If you spend most of that time going deep into the problem, it can leave you with very little time for the solution.  So you need to pace yourself.

So, if you feel you must think in terms of problem space and solution space, then at least please always keep in mind two critical points: first, most of your time will need to be spent working on the solution; and second, don’t associate the problem with product management, and the solution with engineering – understanding the problem and developing the solution requires the intense collaboration of product, design and engineering.