Discovery – Learning vs. Insights

I introduced the term product discovery about 15 years ago, and I’ve loved watching the industry gradually broaden its mind from the concept of someone – either an old-school business analyst or a product manager – defining requirements, to the concept of a product manager, product designer and lead engineer working collaboratively to discover a successful solution.

I’m especially happy to see so many smart people contributing discovery techniques, and helping others learn how to do effective product discovery work.

However, as happens in every industry, there’s also people out there that have simply rebranded their tired old product thoughts as product discovery, which of course can confuse new product people. And this is why I recently wrote Product Management – Start Here.

But even without bad actors, as with any complex concept, there is a lot of nuance and especially in the age of Twitter sound bites, it’s easy to get confused.

So I find I spend a good amount of time working to clarify common misconceptions.

In this and the next several articles, I will be discussing the most common confusions I find out there.

The subject of this first article is the difference between learning and insights.  

Of course, learning is good, so I’m not suggesting that learning isn’t valuable.

Similarly, insights are a type of learning.  The point is that they are learnings that we can leverage.  One leader I know likes to say “insights are learnings we can take to the bank.”

We generally learn every day we are working on product discovery activities, but what we’re really searching for are insights.

Mostly what we learn is that our solution does not work as well as we had hoped.  But occasionally what we learn provides an insight into how to fix it.  These insights change how we approach the problem we’ve been asked to solve.  When that insight leads to an effective solution, we declare victory.

Sometimes an insight is important enough that we realize that the impact goes beyond the problem we’re working on, and is perhaps even important enough to be leveraged in our product strategy.  Strong product leaders are always on the lookout for these sorts of insights.

And very occasionally, the insight is so profound that it causes us to revisit everything, possibly even changing the course of the company.  This is called a vision pivot.

Now nothing I’ve just said should really be a surprise.  If you’ve had any meaningful training on product discovery, this should all sound very familiar.

The reason for this article is a bit more nuanced.

Many product teams talk a lot about the importance of learning.  And I do too, although I’ve tried to be more careful with my words on this for the past year or so.

Here’s the problem: 

The purpose of a product team is not to learn.  

The purpose of a product team is to solve hard problems in ways our customers love yet work for the business.

Now, learning helps us do that, but it’s critical to never lose sight of the fact that learning is the means not the ends. 

In other words, you can be a product team that’s great at learning, but if your team doesn’t know how to close the deal and solve the problem for the customer, you are not a strong product team.

For many years I’ve seen the same issue play out with many different techniques.  Teams get so excited about their personas that they obsess over the technique, and don’t turn the technique into successful products. Or they get so excited about design thinking. Or jobs-to-be-done.  Or their use of Agile.  The list goes on. 

All of these techniques can provide real value, but only if you stay focused on solving the problem you’ve been asked to solve.

One last pointed example of this problem:

One of the most common questions I get about OKRs, is whether the team should have an OKR to measure their learning in product discovery?  

While I do encourage teams to make sure they’re practicing the techniques necessary to do effective product discovery, I push them to keep their key results as business results, and not fall into the trap of confusing the means with the ends.

So in your product discovery work, and especially in your discussions with stakeholders and senior leadership, be sure to keep the focus and discussion on the insights and the results.