All you need to know about implementing a strong product discovery process in your company

Product discovery is a hot topic in almost every company with an existing Product organization. 

It has its origin traced back to somewhere between the 90s and the 00s when the foundations of most of what we see as common product management were built by content like The Lean Startup and The Agile Manifesto. 

These concepts preconized a faster product development cycle rather than spending a lot of money in building a product – just to later discover that wasn’t what customers wanted. By doing so, the product development process started to be divided into two major building blocks: product discovery and product delivery.

But what is Product Discovery and how can you implement a product discovery process in your company? Let’s jump right into it.

What is Product Discovery?

Product Discovery is, simply put, the science of reducing uncertainty to make good decisions about what to build next. 

When done right, a great product discovery process can highly increase the chances of a successful deliverable. Or, as Tim Herbig defines it, “Product Discovery is about the data-informed reduction of uncertainty in regard to problems worth solving and solutions worth building”.

The product discovery process requires a deep understanding of your users’ problems, needs, and expectations, the definition of assumptions to address these needs, and the validation of these assumptions. Once it all happens, you’re ready to move to product delivery.

Product discovery is key to ensuring that your company is focused on building the right things rather than only building things right (even if they are the wrong thing to do). For that, it is mandatory that the user is included in that process so that their need is addressed – something we will talk about later.

Why is Product Discovery important?

To understand why Product Discovery is so necessary, it is important that we understand the cost of delivering the wrong product or feature: in some cases, it can mean millions of dollars and, most importantly, a lot of time spent that you can’t get back.

Product Discovery allows you to reduce the chances that you’re investing time and money in the wrong things, playing a critical role in helping a product manager decide whether and what exactly to prioritize and build to be successful.

It also means truly uncovering your users’ most painful problems and most desired solutions, moving your product from a “nice to have” to an “oxygen” type of solution that adds true value to your customers, setting the stage for getting to product excellence.

Who leads product discovery?

Product Discovery is a cross-functional effort that should involve different teams, always led by a Product Manager.

This team normally needs to have at least what we know as the product trio  (product manager, a UX designer, and a software engineer), as the product discovery process normally involves skillsets such as market research, user interviews, and prototyping of what to build. 

That said, the profile of the team that participates can vary depending on the specifics of your organizational challenge and context at the time, or even on your Product Discovery phases. 
Another great concept from Tim Herbig is one of the permanent members, temporary members, and supporters of a product discovery process: it shows different levels of participation from different stakeholders and helps you to understand when and how to involve each one of them.

You can, for example, have someone from sales or customer success participate in the ideation phase to help you have a more clear understanding of the customer, a less biased perspective, or even an easier buy-in of a key area in the success of that product.

Key Steps in the Product Discovery Process

There is no one-size-fits-all solution to be followed when it comes to doing a great product discovery process. 

Even though each product manager has their own recommended best practices and product discovery templates to adopt, there are some common elements to the process that you should be aware of – no matter how you name them, which methodology you choose or how long you spend on each step.

These are the key product discovery phases and the most important things you need to know about them:

Understanding the user and their problems

Product Management is all about delivering value to your users and to the business. So it’s not a surprise that the first stage of product discovery – and probably the most critical one – is related to understanding your target audience – current or prospective users and customers.

A deep understanding of a user’s context, their jobs to be done, and what are the pressing problems that are keeping them up at night is the fuel for any successful product discovery process. 

This might seem like an obvious and easy task, but truth is that a lot of people fail in two aspects here:

1. They don’t ask the right questions

It’s important that you have a clear idea of what exactly you want to discover, otherwise you will just be talking to people randomly and might be led to wrong and biased conclusions.

2. They don’t gather enough volume of feedback to make a decision

To avoid bias is also critical that you are able to identify a pressing problem that is common among a relevant group of people from your target audience, ideally collecting data from multiple points of view. Otherwise, there is a risk that you’ll end up building a feature for only a handful of people.

To address both of these issues, a good option is to access existing sources of customer feedback. 

User opinions from your customer support tickets, insights from sales meetings and win/loss analyses that are logged in your CRM, user reviews posted about competitors on G2 or Capterra, and NPS surveys data are only a few examples of sources that can be explored in order to give you both volume and an idea of what are the things people are either missing or looking for.

Ideating & prioritizing solutions

Now that you have enough data gathered to give you a clear understanding of the user, it’s time to move to the next of the product discovery phases and start ideating how you could address the problems and expectations arising from your customers’ feedback.

Ideating solutions is all about being creative: it’s OK to come up with crazy ideas of how to solve or address an issue, going beyond evolutive ideas. This will give you good material to discuss and the opportunity to come up with breakthrough solutions. 

Once the solution options are listed, it’s time to prioritize. There are several product prioritization frameworks that can be used for this, but the end goal is the same: having a list of the most relevant ideas that arose.

This is a very important step, as these are the assumptions that will be worked on and put in front of the client. Choosing the most relevant hypotheses is key, so ideally you will want to do it with different people voting or collaborating to define what are the ones with the highest impact, risk, and complexity – with no bias or HIPPO (Highest Paid Person’s Opinion).

Prototyping & testing

In order to understand the feasibility and match of the selected ideas, it’s important to put them to the test. That means building and putting them in front of the user. That’s where prototyping enters. 

Prototyping doesn’t mean building an MVP or anything close to that. It can be as simple as writing a value proposition, setting up a form, or drafting a workflow. That piece of the product discovery process is even easier nowadays with no-code tools such as Airtable and Bubble.

The important thing here is: just like when understanding the user, do not get tempted here to start building things or add too much complexity, as the goal is to quickly prototype experiences that can be shown to customers in order to get more feedback and see how they perceive that experience versus the problem they brought before.

It’s also important to define what exactly you’re testing with the experiment (what is your expected response or outcome) and how you will measure your results to identify whether that specific solution addresses the original problem. There are several product discovery testing techniques that can be handy here, such as user interviews, surveys, A/B testing, and more. 

Refining ideas for delivery

Once you got your test results, you have two possible outcomes: either you validated the assumption or you didn’t. And in most cases, truth is that you didn’t – at least 100%. Getting to a final solution will likely take several iterations, with you going back one or two steps in your product discovery process to hone assumptions or prototypes until you get your wow! from the client.

When you get to that point, it might seem that your work is done, but there is still a lot to do. The refinement of the validated experiment in order to build it (the Product Delivery stage) is a necessary step, especially if you did good work in the previous stage – which means creating a pretty simple prototype.

Now it’s time to transform that into a scope with product features, backlog, and releases, always taking into consideration that you should aim for quick releases with fast interaction than complex, feature-loaded deliveries. 

It’s also time to think about how to communicate that launch. That is a great moment to go back to the data registered on phase 1 and look at the exact verbatim that users used to communicate a pain or a benefit they expected from your product. 

That will help guide you on the product narrative and language used in your marketing and communications efforts. This can be much more complicated if you haven’t organized and categorized all the feedback previously collected because it might require you to review endless hours of conversations and data. Setting up a feedback analytics tool right at the beginning can help you with that. 

A very important piece of this stage that is not mentioned enough is earning buy-in and support from the organization. It’s recommended that the product discovery team presents the validated solution to stakeholders (the contributors and supporters previously mentioned) with evidence to support it, making it easier to get full alignment. 

One important thing to keep in mind is that these product discovery phases are not always linear: you will sometimes have to get back one or a few steps when you come across an unexpected result, or even re-start the whole process, and that’s fine. 

That’s the beauty of product discovery; it helps you identify critical things that otherwise you would have missed – and spent months and thousands of dollars building the wrong thing. Remember: it’s less painful to take one step back now than to move forward just to later confirm that you built something that didn’t solve a real problem. 

After some time, you will notice that you need to enter product discovery again, creating a cycle in which discovery feeds delivery and vice-versa – and that’s when the concept of continuous discovery starts to make sense.