The Origin of Product Discovery

I’ve been meaning to write this article for many years, but since it’s mainly historical in nature there have always been more pressing topics.  But every so often someone will reach out because they’re trying to track down the origin of the term, and during this pandemic, for whatever reason, I’ve been getting this question more frequently.

First, let me be clear that the concept of product discovery has been around as long as software, and certainly much longer than I’ve been around.  

We have always had, and likely always will have, two essential problems in software: we need to figure out the right product, and then we have to build the product right.

I’ve always been interested in both problems, but I think the first is harder and that’s where most innovation happens, so that’s where I focus most of my attention.

Starting around 2005 I started trying out the term “discovery” for how we figure out what to build, and in 2007, I decided to go all in on the term, and since then I have referred to the first problem as discovery, and the second as delivery.

In 2007 I was working on the first edition of INSPIRED, and I had a publication deadline approaching, and I had to decide what, if any, term to use.  

Back then, just about every product manager talked about “gathering and defining requirements,” but I considered this as one of the fundamental reasons why there were so many failed products out there.  To me, talking about defining requirements was not only misguided, but arrogant.

I could also see that in good teams, products were conceived by true collaborations between engineers, designers and product managers.  Not by some product manager declaring “these are the requirements, now go and design and build this.”

So I wanted a term that conjured up a very different image in the minds of product managers and product teams.  I wanted them to have an open mind, to know what they can’t know, and admit what they don’t know.

I wanted to emphasize that great products are the result of product, design and engineering working together to achieve an outcome, rather than just pushing requirements down the chain and shipping output.

I wanted them to think in terms of “figuring out a solution to a problem we’ve been asked to solve” rather than “dictating the requirements of a feature we’ve been asked to build.”

I found the term “discovery” from the pharmaceutical industry for the process they used to come up with a viable medication.  Unlike the software industry, the pharmaceutical industry acknowledged the risk up front.  They expected that many if not most of their medications would not end up being safe and effective enough to manufacture, distribute and sell.

I also liked the term “discovery” because it was technique agnostic.  There are any number of techniques used to help with discovery, and new ones emerge all the time.  An MVP is a discovery technique, as is design thinking, as is customer development, as is “Jobs To Be Done.”

This was very important to me because I have seen so many techniques and methods come and go, so I didn’t want to explicitly associate with any of them.

I also liked that the term “discovery” encouraged product teams to think about the risks of value, usability, feasibility and viability.

In general I’m reluctant to try to introduce new nomenclature.  It’s a hard thing to do, and even if people respond well, it takes time to spread, and you really need to pick your battles on things like that.

But today I’m happy to see so many product teams understand the concept, and have at least a reasonable understanding of how and why we do product discovery.

Now my focus is more on making sure product teams are working in an environment where they are empowered to do product discovery, rather than just given roadmaps to build.