There is no one perfect taxonomy for discovery techniques because several of the techniques are helpful for multiple different situations. Regardless, following are the key techniques in the framework that I personally use and find helpful.
Framing techniques help us to quickly identify the underlying issues that must be tackled during product discovery. If we're handed a potential solution, we need to clarify the underlying problem to be solved. We need to tease out the risks and determine where it makes sense to focus our time. We also need to ensure that we understand how our work fits in with the work of other teams.
There are a few techniques that are useful throughout the product discovery effort and help with identifying the bigger challenges and planning how you'll attack this work. We'll discuss these here.
There are, of course, any number of ways to come up with ideas. But some sources are better than others in their potential for keeping us focused on the most important problems. Ideation techniques are designed to provide the product team with a wealth of promising solutions aimed at the problems we're focused on now.
Our go‐to tool for product discovery is typically a prototype. We'll discuss the four main types of prototypes and highlight what each type is best suited for.
Product discovery is mostly about quickly trying out an idea. We are essentially trying to separate the good ideas from the bad. Here we are defining a good idea as one that solves the underlying problem in a way that customers will buy, they can figure out how to use, we have the time and skills and technology on the team to build, and that works for the various aspects of our business.
It's important to recognize that many ideas don't have that much risk associated with them. They may be very straightforward. Or they might just have one area that's a risk, such as our legal department's concern about a potential privacy issue.
Occasionally, however, we need to tackle much tougher problems, and we may in fact have significant risks in most or even all these areas.
So, the way to think about discovery is that we only validate what we need to, and then we pick the right technique based on the particular situation.
These techniques are designed for the engineers to address areas where they identify concerns. The solution being tested might require some piece of technology that the team has no experience with. There may be significant scale or performance challenges. Or there might be third‐party components that need to be evaluated.
These techniques are designed for the product designers to address areas where they have identified concerns. Many of our products have complex workflows and the designers need to ensure their interaction designs make sense to the user and potential sources of confusion are identified and pre‐empted.
Much of our time in product discovery is spent validating value or working to increase the perceived value. If it's a new product, we need to ensure that customers will buy it, at the price we need to charge, and that they'll switch from whatever they're using today. If it's an existing product, and we are improving that product (such as with a new feature or a new design), where the customer has already bought the product, we need to ensure the customers will choose to use the new feature or new design.
Sadly, it's not enough to create a product or solution that our customers love, that is usable, and that our engineers can deliver. The product also must work for our business. This is what it means to be viable. This means that we can afford the cost of building and provisioning the product and the costs to market and sell the product. It needs to be something our sales force is capable of selling. It means that the solution needs to also work for our business development partners. It needs to work for our legal colleagues. It needs to be consistent with our company's brand promise. These techniques are about validating these types of risks.
When working to migrate your organization from working the way you do today to working the way you believe you need to, there are a set of techniques that have proved to be helpful for transforming how you work.
I am sharing the techniques here that I believe are essential for any modern product team.
So, as you can see, we need quite a range of techniques. Some of the techniques are quantitative, and some are qualitative. Some of the techniques are designed to collect proof (or at least statistically significant results), and some are designed to collect evidence. All are designed to help us learn quickly.
To be clear, I am sharing the techniques here that I believe are essential for any modern product team. Over the course of a year or two, you will probably use each of the techniques at least several times. There are, as you might imagine, many other useful techniques based on specific types of products or situations, and new techniques are always emerging. But, these are your go‐to techniques.