Discovery is a process we use as product people to better understand the problems we are trying to solve for the customers we are trying to solve the problems for. It also helps us ensure that it is the right problem for us to concentrate on since there are always a million other problems we need to be solving at any given moment. My understanding of Discovery is mostly influenced by Marty Cagan, who walked me through the concept during of his “How To Create Products Customers Love” workshops. (highly recommended!).

In Discovery, we want to do two things:

1. Understand what the problem is and validate it (Problem Discovery)
2. Understand what the right solution is and validate it (Solution Discovery)

Let’s look at what these two entail:

Problem Discovery

Problem Discovery is all about understanding what the problem is, whether it’s really a problem, and why it’s a problem. But more importantly, this is probably the first time we can take a research-focused stab at answering the most important question: is this a problem worth solving now, and what is the impact going to be on our users and business goals if we decide to pursue it further?

To help us answer this question, we need to investigate the problem to help build a case. Here are some of the questions I need to be able to answer to help me decide whether we should proceed to Solution Discovery:

1. What is the exact problem?
2. What is the customer’s point of view (POV)?
   1. How does the customer explain the problem in their own words?
   2. What is the effect of the problem? What does it prevent them from doing?
   3. The frequency and criticality of the problem?
   4. How are your customers solving the problem today?
3. Are they any auxiliary/secondary/similar problems? What are they and what effect do they have on your customer and the primary problem?
4. What would the world look like to the customer is this problem did not exist? What will it look like to us? (This is the outcome you want to achieve)

To answer any of this questions, you should speak to your customers/users!

Now that we know the inner workings of the problem, the product manager has enough data to make the call here: should we continue working on this problem?

If so, we can continue to Solution Discovery.

If not, we just saved ourselves from building something that is not the most strategic thing to do right now! BOOYA

Solution Discovery

Now that we have validated that this is a problem to we should solve now rather than later, because it a major problem to our customers AND it will bring us closer to our business goals, we can jump in Solution Discovery.

In Solution Discovery, we generate multiple possible solutions that vary immensely in every possible aspect (from the most simplest to the most complicated) without limiting ourselves to constraints.

Once we feel we have done enough exploration, we can then layer in some constraints to help us choose which solution works best.

Keep in mind, when we layer in the constraints, we are talking to the engineering team for feasibility and time estimates, AND we are also showing our solutions to our users to see which ones comes closest to solving their problem and which ones they can use.

Once we have a direction that is feasible and appropriate, we can then work on refining our solution, which allows us to go into more detail by either layering more functionality/features, and doing some usability testing to ensure our users can actually use it!

 

 

At the end of the Solution Discovery phase, we should be able to answer one question: have we found the right solution that solves our customers’ pain points and can we build it in a relatively short amount of time?

If the answer is yes, we can then break up the design for the engineers so they can work on implementing.

If the answer is no, it’s probably because of one or two reasons:

1. This problem is still an important problem to solve, we haven’t found the right solution, but we believe we need a bit more time to find that solution, OR
2. This problem is an important problem, but we do not have the means of solving it at the moment. We should revisit it later.

 

I hope this blog post gives you a general understanding of what we mean by Discovery. If you’re interested in learning more, check out the following: Product Discovery in Established Companies and why you should do it,  What are Discovery Sprints,  and Google Ventures’ take on Design Sprints.