The purpose of product discovery is to address these critical risks:
And it's not enough that it's just the product manager's opinion on these questions. We need to collect evidence.
When it comes to how we do product discovery, there are a set of core principles that drive how we work. If you understand these, you will understand not only how to work well today but also how to easily incorporate new techniques as they emerge in the future.
We know we can't count on our customers (or our executives or stakeholders) to tell us what to build.
Customers don't know what's possible, and with technology products, none of us know what we really want until we actually see it. It's not that customers or our executives are necessarily wrong; it's just that it's our job to make sure the solution we deliver solves the underlying problem. This is probably the most fundamental principle in all of modern product. Historically, in the vast majority of innovations in our industry, the customers had no idea that what they now love was even a possibility. This is only becoming truer with time.
Customers don't know what's possible, and with technology products, none of us know what we really want until we actually see it.
The most important thing is to establish compelling value.
It's all hard, but the hardest part of all is creating the necessary value so that customers ultimately choose to buy or to use. We can survive for a while with usability issues or performance issues, but without the core value, we really have nothing. As a result, this is generally where we'll need to spend most of our discovery time.
As hard and important as the engineering is, coming up with a good user experience is usually even harder, and more critical to success.
While every product team has engineers, not every team has the necessary product design skills, and even when they do, are they being used the way we need to use them?
Functionality, design, and technology are inherently intertwined.
In the old waterfall model, the market drove the functionality (aka the requirements), which drove the design, which drove the implementation.
Today, we know that the technology drives (and enables) the functionality as much as the other way around. We know that technology drives (and enables) design. We know that design drives (and enables) functionality. You don't have to look further than your own phone to see numerous examples of both. The point is that all three of these are completely intertwined. This is the single biggest reason we push so hard for the product manager, product designer, and tech lead to sit physically adjacent to each other.
We expect that many of our ideas won't work out, and the ones that do will require several iterations.
“The most important thing is to know what you can't know.”
To quote Marc Andreessen, “The most important thing is to know what you can't know,” and we can't know in advance which of our ideas will work with customers and which won't. So, we approach discovery with the mindset that many, if not most, of our ideas won't work out. The most common reason for this is value, but sometimes the design is too complicated, and sometimes it would take far too long to build, and sometimes there turn out to be legal or privacy issues. The point is we need to be open to solving the underlying problem in different ways if necessary.
We must validate our ideas on real users and customers.
One of the most common traps in product is to believe that we can anticipate our customer's actual response to our products. We might be basing that on actual customer research or on our own experiences, but in any case, we know today that we must validate our actual ideas on real users and customers. We need to do this before we spend the time and expense to build an actual product, and not after.
Our goal in discovery is to validate our ideas the fastest, cheapest way possible.
Discovery is about the need for speed. This lets us try out many ideas, and for the promising ideas, try out multiple approaches. There are many different types of ideas, many different types of products, and a variety of different risks that we need to address (value risk, usability risk, feasibility risk, and business risk). So, we have a wide range of techniques, each suitable to different situations.
We need to validate the feasibility of our ideas during discovery, not after.
If the first time your developers see an idea is at sprint planning, you have failed. We need to ensure the feasibility before we decide to build, not after. Not only does this end up saving a lot of wasted time, but it turns out that getting the engineer's perspective earlier also tends to improve the solution itself, and it's critical for shared learning.
We need to validate the business viability of our ideas during discovery, not after.
Similarly, it is absolutely critical to ensure that the solution we build will meet the needs of our business—before we take the time and expense to build out that product. Business viability includes financial considerations, marketing (both brand and go‐to‐market considerations), sales, legal, business development, and senior executives. Few things destroy morale or confidence in the product manager more than finding out after a product has been built that the product manager did not understand some essential aspect of the business.
It's about shared learning.
One of the keys to having a team of missionaries rather than a team of mercenaries is that the team has learned together. They have seen the customer's pain together, they have watched together as some ideas failed and others worked, and they all understand the context for why this is important and what needs to be done.
Everything that follows is based on these core principles.
In general, product discovery is about tackling risks around value, usability, feasibility, and business viability. However, in some cases, there's an additional risk: ethics.
I know this is a sensitive topic, and I don't want to sound like I'm preaching or condescending in the least, but I personally encourage the teams I work with to also consider the question, “Should we build it?”
I encourage product teams to consider the ethical implications of their solutions, too.
You may think this is a matter of doing something illegal, but in the vast majority of cases where ethics is an issue, it's not usually a matter of law. Rather, just because we have the technology to build something, and even if it otherwise works to accomplish the specific business objective, this does not necessarily mean that we should build it.
More commonly, the issue is that our technology and design skills are such that we might come up with a solution that meets our business objectives (for example, around engagement, growth, or monetization) but can end up with a side effect of causing harm to users or the environment.
So, I encourage product teams to consider the ethical implications of their solutions, too. When a significant ethical risk is identified, see if you can find alternative solutions that solve the problem in a way that doesn't have negative consequences.
I have one final, but critically important, note about raising ethics issues with senior management. You absolutely need to have a strong understanding of your business, especially how you make money. You need to use good judgment and be sensitive in your discussion. You are not there to try to police the organization but, rather, to identify issues and bring potential solutions.
Most product teams normally think of an iteration as a delivery activity. If you release weekly, you think in terms of one‐week iterations.
But we also have the concept of an iteration in discovery. We loosely define an iteration in discovery as trying out at least one new idea or approach. It's true that ideas come in all shapes and sizes, and some are much riskier than others, but the purpose of discovery is to do this much faster and cheaper than we can do in delivery.
To set your expectations, teams competent in modern discovery techniques can generally test on the order of 10–20 iterations per week. This may sound like a lot to you, but you'll soon see that's not so hard at all with modern discovery techniques.
To set your expectations, teams competent in modern discovery techniques can generally test on the order of 10–20 iterations per week.
Also, realize that many iterations never make it beyond just you, your designer, and your tech lead. The very act of creating a prototype often exposes problems that cause you to change your mind. As a rule of thumb, an iteration in discovery should be at least an order of magnitude less time and effort than an iteration in delivery.