A Complete Guide to Product Discovery

Within the realm of product development, “discovery” is not the process by which users find and engage with a product - though that is another vital type of product discovery. 

Discovery refers to the process of figuring out what exactly the problem is that you are trying to solve with your product.

It involves developing a deep understanding of potential users, their needs, and pain points, in order to develop solutions that users can’t live without.

It is the discovery process that allows product teams to ensure that their solutions meet real user needs and that users will be willing to pay for them. Getting this step right is the difference between creating successful products that we can now not imagine living without, such as Google and Uber, rather than infamous flops, such a New Coke and Google Glass.

But how exactly do you go about undertaking good-quality discovery, resulting in successful products?

We’ll go through the process step by step and give you some top tips for better tackling the most challenging parts of the process.

When Does Discovery Happen?

Discovery is often referred to as a work package that happens at the initial stage of product development in order to set the direction of product development.

This is a vital and distinct work phase that should happen at the start of a project, but the discovery is also something that product teams should be doing constantly throughout the development process, during launch, and beyond.

The rapid development of technology means that the goalposts are constantly shifting. A product team that always has one eye on discovery can shift their trajectory to ensure that they are always on target.

Initial Hypothesis Development

The discovery process will normally start with a general idea of the potential user-base, market, and general solutions zone.

It may even start with a specific idea already on the table. When this is the case, the discovery process is often called Alibi-Discovery as it suggests a thesis that needs to be tested, broken and refined. The existing thesis can add limitations to the discovery process, which is why it is considered something separate from more open discovery.

It normally starts with gathering all relevant existing information. This includes general market research that is available, analysis of competitors functioning in the space, and specific data that the company might have from user surveys, customer feedback, and analytics available from existing products.

The product teams may also choose to collect new data at this stage, for example conducting surveys. But it can be challenging for these to be specific enough at this stage to justify the return on investment.

The aim of analyzing this data is to gain a clear image of who potential customers are, and what needs they have that are not being met, or at least satisfactorily met. This information is used to develop theories about who audiences are and what they need. Those theories then need to be tested.

Testing Hypotheses

Testing these theories requires moving into a more active phase of research where the team gathers and analyzes evidence with the specific purpose of proving or disproving their hypotheses.

This is when surveys, interviews, and focus groups can bear greater fruits as specific theories can guide this phase of the research.

This new data allows for theories to be refined, and then further tested through additional research, and refined again in an iterative process.

The goal of this entire hypothesis creation and testing process is to determine whether there is a problem worth solving, if there are potential solutions that the team can develop, and whether people will pay for it (or otherwise invest in it depending on the priorities of the company).

Active Research

What existing data and information may be available depends on the industry, and how many existing data the team may already have based on previous products and so forth.

There are many tools available to help make sense of this data and garner insights. You can find a list of top tools to assist with product discovery here.

When it comes to gathering new evidence, it usually involves both quantitative and qualitative data gathering.

Quantitative data analysis can involve re-analyzing existing data through a new paradigm offered by the hypothesis, or collecting new data with that in mind, for example, tracking the activity of users using specific features of existing products.

Qualitative data is generally gathered through surveys, conducted online, via email or in-person, and interviews and/or focus groups with individuals that represent key target users.

Get further advice on how to conduct this kind of research in our article on exploratory research.

Both this quantitative and qualitative data can be used to prove or disprove the assumptions that underlie the hypothesis, allowing for it to be further refined.

Research Artefacts

This discovery research should result in a number of artefacts that are then used to define the product, product requirements, and what success will look like.

They can also be used to ensure that the essential user needs that underly the product remain at the forefront throughout the product development process.

The two most important artefacts that should be created as part of the discovery process as personas and journey maps.

Personas

Creating User Personas help the product team define and understand their potential audience.

A persona is a fictional, yet realistic, description of a user that represents a typical or target user group. Target users are usually segmented into clearly defined groups, and each group should have an associated persona.

The description should be detailed and include what the person needs, what their concerns are, and what their goals are within the general context of the product. This is complemented with fictional background information, things such as age, gender, and occupation, making it easier to for the product team to put themselves in their shoes and understand things from their perspective.

It does not need to document every aspect of their life but focuses on the characteristics that impact the product that is being designed.

To be useful, personas must be based on user research, and interviews and are particularly useful for refining personas. It is never a good idea to develop personas based on “common sense”, as it is easy for inaccurate assumptions to creep into the description. As a result, the team is then creating products for users that they imagine, rather than real users.

Here are some user persona examples for SaaS businesses.

Journey Map

A journey map is a visualization of the process an individual would go through to complete a specific goal.

It should mark every touchpoint that they need to pass through in order to complete a certain task. It should mark all the tools that they currently use, and where their pain points are.

The journey map should have an actor, which can be taken from the personas, who then works through a scenario. The map should track both their actions, but also their expectations, mindset, and emotions at each stage of the journey.

Again, this should be based on specific user research, rather than assumption, so that the team can ensure that they are dealing with a real problem as it exists.

This map can then be used to identify opportunities for the product to become part of this journey and alleviate some of the pain points that the actor is experiencing. The potential product can then be mapped on top of the existing journey map, seeing how it would change the actor’s actions, align with their mindset and meet their expectations, and improve how they feel well completing the relevant task.

6 Top Tips for Better Product Discovery

While lots of factors can make the difference between mediocre and quality discovery, here are our top tips for getting it right.

1- Involve the Right People

Often user research is considered something that marketing team does.

Even in companies that do invest in user research upfront for product development, it is often siloed, sitting with the product manager and a dedicated research team. While this may mean that you have experts doing the research, you are limiting how that research is integrated into the product development process.

There is a significant difference between being given information to guide decisions, and being genuinely involved in looking at the data, putting it together, and understanding what it means. For this reason, it is valuable to also include members of the development team and key stakeholders in the discovery team.

They will have more respect for the insights garnered, and develop a deeper understanding of the users and the challenge, enabling them to better integrate this knowledge into their work.

2- Focus on Validating the Problem and not Developing Solutions

During the initial discovery phases, the focus should be kept squarely on defining the problem, and potential solutions should not be allowed to creep into the conversation. These two phases should be kept separate.

This is because, once you start talking about solutions, they can dominate the mindset and conversation around the problem. As a result, the team can fall into tunnel vision mode as they look for evidence to support their solution, rather than understanding the problem as a whole.

This is why problem validation and solution development should be kept separate, and the second phase should only begin with the first is considered complete (or as complete as these types of things ever are).

3- Work Systematically

There are many reasons why we might want to limit the time and resources invested in discovery, and it is not all about saving money.

The best way to get feedback on a product is to get it to market, so you can see how it works with genuine users in the wild.

The best way to cut down the time needed to complete discovery is to take a systematic approach by developing a list of key assumptions and turn them into questions that can be stress-tested.

This means that instead of trying to learn everything about a market and a user group, which can be time-consuming, you can focus on what matters most. In this way, you are more likely to have the information that you need when you do start developing solutions.

4- Talk to Users

While quantitative data is very compelling and should be part of any discovery research portfolio, nothing helps you understand the user better than actually speaking to them.

Also, while data can help you identify trends and issues, it cannot always tell you why they exist. You can only get the meat to put on the bones of quantitative data by talking to people.

When you do talk to users, you should always maintain an open mind, and listen to what they are really saying, rather than looking for soundbites that support what you already think. This is easier said than done, as it is always difficult to leave assumptions at the door. The practice requires active cultivation.

5- Consider Response Bias

But while you should always listen to what users say, you should also take it with a grain of salt.

People, in general, make terrible interview candidates. We are bad at reporting what we actually do, tending to share the idea that we have in our heads rather than reality. Most people also have a tendency to tell interviewers what they think they want to hear. This is not active deception, it is just human nature, and it is something that needs to be accounted for.

One way to try and balance this issue is to combine interviews with observation, watching people as they are actually trying to complete the tasks under discussion. You can garner first-person insights, and if you ask the person to explain what they are doing and thinking while they are doing it, they are better able to describe it accurately.

6- Disseminate Information Intelligently

We have already talked about having the right people involved so that key members both have a deep understanding of the discovery findings and are personally invested in it.

But there is a limit to how many people can actively work on discovery, otherwise, you end up with a case of too many cooks. But the findings of discovery should be disseminated far and wide to everyone involved in the project or linked to the product.

While the documentation produced as part of discovery will be extensive, circulating lengthy reports is no way to engage people with the findings of discovery. Put on your marketing hat and create infographics and imagery that communicate the dey data and insights at a glance - if anyone does want to dig deeper, the documentation is available.

When it comes to any controversial findings, which may go against assumed knowledge within the company, when possible, show rather than tell.

If you have video footage of someone struggling to complete the task in question or using the product in a way that is unexpected, cut this down into a short video that can be circulated. Seeing is believing.

If you do have data skeptics in the company that honestly believe that despite what the data is saying, they know what is best (we all know these people), use case studies to highlight the importance of the discovery. There are scores of examples available when discovery showed that the reason a company was failing to deliver a solution was that they were failing to understand the problem. 

You don’t have to look hard to find products that have failed. You can also always point them to the now infamous Christensen’s Milkshake example.

Conclusion

The most successful products fulfill a vital need, usually ones that people don’t even know that they have. 

Products fail when they have not understood the users or what they need. This happens when someone comes up with a great idea and goes off and makes it with a “build it and they will come” mentality, without properly considering who would use this product, for what, and why. 

We often hear movies referred to as self-indulgent when the director has clearly made the film to please themselves rather than the audience, the same can be said of many products. The best way to avoid falling into this trap is to invest in discovery at the very start of the process.

The whole point of discovery is to look at those questions of who is the potential user base and what problem would they be solving with this product. It is this process that allows you to move a product from a pet project to vital tech, that in a few years, no one will be able to imagine living without.

‍