A light bulb and wrapped pieces of paper

How to Run Product Discovery: Process, Frameworks, and Best Practices

Let us tell you a story about an Amazon smartphone that no one needed.  The year was 2014 when Amazon launched a classy device operating on heavily customized Android. The “Fire Phone” could recognize sounds, text, and objects, and find a scanned item on Amazon. It also had weak hardware, no Google services, and $199 price tag.

Amazon Fire Phone

Amazon Fire Phone advertisement 

The phone didn’t look or work bad. The question was, who needs a phone to make purchases on Amazon?

Just a quick note: September 2014 is the release date of iPhone 6, i.e., the smartphone market wasn’t that young. But, competition didn’t kill the smartphone, Amazon did, reporting a $170 million loss associated with Fire Phone, ceasing its production a year later. Long story short, the Fire Phone became a prominent example of a product without a market.

So what is the lesson? Finding a market fit is a vital part of any product. We need to figure out what to build and who needs it before actually building it. So, product development can be divided into two phases: discovery and delivery.

The delivery process is traditionally the most time-, effort-, and budget-consuming. But wrong market assumptions are what make products fail. So, in this article, we’ll define what product discovery is and its goals. We’ll discuss the main techniques used in it, best practices, and other evolving ideas like the concept of continuous discovery.
Product Discovery Process OverviewPlayButton

Product discovery, explained in less than 10 minutes

What is a product discovery?

Product discovery is nothing new to the world, as it has always been a part of a product manager’s job. Basically, it’s an initial stage of product development, where we state a problem and a target audience in need of a solution. The goal of product discovery is the creation of a constant learning loop that provides the team with feedback to get a better read of market needs.

Discovery process comprises two big sets of activities: exploration and validation.
  1. Exploration is what most people think of when they hear the “discovery” term. It denotes all activities concerning the research stage of a product, communication with stakeholders, exploring existing problems, solutions, and customer pains. This phase includes research, ideation, and evaluation activities.
  2. Validation is a set of activities intended to check each assumption made during the exploration process. Before anything is designed, the product should pass a solid test on whether the ideas can generate value for the end-user. This is done with the help of prototyping and testing using data and customer feedback. The activities are prototyping, testing, and learning.
The validation stage is similar to user acceptance testing conducted by the QA team, but takes place long before any user stories are written. It aims at creating prototypes and tests for each idea to make sure it has to be in a backlog. The results of testing either kill the ideas or decrease the level of uncertainty.

Both exploration and validation are iterative processes that precede the delivery stage of product development. So, product discovery can be seen as a scientific method to building software, as it suggests using experiments and tests as a tool. This gives us a more solid base to create an overall product strategy and roadmap the whole development.

Now, let’s discuss the way product discovery can, or rather should be done to achieve the goals and benefits mentioned above. We’ll describe a step-by-step framework that will elaborate on process stages, its goals, techniques, and best practices.

Product discovery process preparations

Preparation for the discovery process includes forming a team, stating a purpose, and explaining to your team techniques you're going to use. Each part of a process can be limited in time, but we suggest focusing on the outcomes, rather than timeboxing the whole process.

When to run product discovery?

Product discovery should take place as early in product development as possible. For a new product, the process of problem field exploration happens prior to creating any roadmaps or strategies, so it’s basically the first thing you do.

While we may think of discovery as an isolated activity, there are no rules on when it should be done. So, we can also make it a part of the delivery process, which is called continuous discovery.

Existing products may also have a high level of uncertainty when it comes to adding new features. It presents new risks of turning the wrong way. Continuous discovery suggests making the practice of researching and validating ideas an iterative process during the delivery stage. This practice goes hand in hand with DevOps and continuous delivery, an Agile extension designed to merge developers and operations into a single team to deliver features in shorter periods of time.

Forming a team

The number of people involved is your choice. The role of discovery lead is traditionally performed by a product/project manager, CTO, CPO, or a business owner. Stakeholders and company executives also take a part in the process, sharing their understanding of the business domain.

The roster of other team members may include:
  • product designers,
  • engineers,
  • QA specialists,
  • UX researchers, and
  • market/business analysts.
For the last few years, data scientists have also become a part of the team, if an organization bases its decisions on the data.

Stating a purpose

First, you need to understand the purpose of a new feature or a product, and that is the problem it solves. The goal is determined by your specific case: It can be a feature concerning one part of functionality or the whole product. The idea is to present the team with the desired outcome, success criteria, and method to use.

Let’s imagine a travel review site similar to Tripadvisor is planning to implement a booking feature on their website, instead of giving a “View Deal” redirect link. To approach the goal statement, you must define the list of critical questions that challenge your idea and suggest initial assumptions to be tested further. For example:
  1. Does the customer need this feature? (Probably, as customers make purchase decisions on our website.)
  2. What value will it bring? Which problem does it solve? (Travelers won't have to leave the platform to complete a booking.)
  3. Do customers really experience this problem? (Yes, our partners confirmed that 94 percent of customers abandoned their cart after coming to a third-party page.)
  4. Are there enough customers to target? (15 percent of our visitors click the “View Deal” button.)
  5. How will they use it? (Clicking a book button offers an easier way to check out and purchase tickets right away.)
  6. If we remove this feature, what will change? (Customers will still book through third parties.)
  7. Will the customer pay for it? (According to research, direct bookings have more trust among travelers to make travel purchases.)
  8. Do we have the resource to build it? (Yes, we have an expertise in payment gateway integration and our suppliers have well-supported APIs to integrate direct booking.)
  9. Does it help us achieve our business goals? (If we manage to reduce the number of abandoned bookings from 94 to 70 percent by bringing the booking directly to our platform, we’ll reach positive ROI for the booking feature in two years.)
By answering these questions with assumptions and testing these hypotheses later will reduce uncertainty. But it’s important to note that discovery should result in outcomes, not features and technical solutions. In practice, these can be a value understanding, or user personas, or a KPI. In our hypothetical case, the goal is to improve conversion rate from 6 to 30 percent by bringing booking capabilities to the website.

Product discovery scheme

Product discovery scheme

Independent of a framework you choose for the discovery, it will include two main phases, exploration of a problem and its validation. So, first let’s look at the process stages to see how the process looks in practice.

Exploration phase


The research stage is a general problem overview. Here we’re looking at such aspects as:
  • market conditions,
  • market gap research,
  • existing market problems,
  • existing solutions,
  • competitor/non-competitor overview,
  • audience overview, and
  • existing monetization mechanisms.
The gathering of data should result in solid understanding of the market (customer problems), customer segmentation, and possible solutions you can build for them.

One of the best practices on how to approach problem understanding is recruiting the customer from the market. This way, you can extract valuable insights of the real problem existing in the industry and learn about the pain points. This will also give you a more realistic user persona to generate assumptions.


With a given input, now your team can gather to brainstorm the ideas for the future product. Ideas are formed from the user perspective, addressing the existing problems. Basically, we’re forming a roster of “future features.”


The evaluation process begins with the prioritization of the ideas by importance, difficulty, value, and risk factor.

We can put ideas into three categories:
  1. Copying ideas. These are ideas that seem to be nothing new to the market, as they reproduce either approved things in the industry, or present a standard solution for a known problem.
  2. Evolution ideas are those suggesting improvements for the existing solutions.
  3. Disruptive ideas describe something completely new to the market.
Every idea is based on the assumption that it will solve a certain problem for a customer.

Idea risk matrix

Ideation risk matrix

The matrix demonstrates the growth of the risk factor and feasibility for disruptive ideas, and vice versa. Considering this, we can determine which ideas we’re going to test, depending on the level of uncertainty.

The loop of exploration closes here. We can generate new ideas endlessly, while the existing ones are evaluated, tested, and weeded out.

Validation phase

The exploration of a problem field should result in the validation of a solution. Once we’ve generated the idea roster and evaluated it, it’s time to validate suggested solutions. Since product discovery process relies heavily on user feedback, it's important to engage real users from the market at this point.

Let’s say you're building an eCommerce platform. You track that users often scroll across the entire category sections to find the products they want to click on rather than using existing filters. Your idea is to add removal filters, so that users can exclude items by keywords from the category view, e.g., laptop category, with the user excluding Dell, Samsung, and Xiaomi to look at the models of other brands. How do we check to determine whether users need this feature?

First of all, we can’t be sure why users scroll through the whole category page instead of using existing filters, so we might ask them first. Maybe they don’t know which products are available and they want to explore the majority of options. But they do know for certain that they won’t buy some brands. This can be done via a user interview to reveal the motives. Second, we can build a prototype and run several tests to see if users prefer to still scroll the category or apply removal filters to narrow down the search.

To approach idea testing, we can use established techniques from product management. The most important thing we need to do to start is idea mapping. You can perform it at the ideation stage or at the validation stage. As a result, we need to outline the “risk” points that will be validated: You can create a visual representation of your ideas that will be tested. Mapping aims at better visibility of how ideas relate to each other, and how testing can be applied to validate multiple ideas. This can be done with the help of story mapping, which is a backlog prioritization technique we discussed in a separate article. Once you’ve mapped the ideas to be tested, you can start with creating prototypes.


Similar to user experience testing, we need to create prototypes for the given ideas. This can be done in a form of wireframes or sketches. The same prototype can be used to test multiple ideas. But it can also be performed through simple questions and answers.


Testing depends on the case and the risk factor. Just a few points to mention here:
  • The Nielsen Norman Group suggests running tests with not more than 5 hired customers. Test accuracy is more important than speed, but the results may differ from user to user. That’s why you should focus more on validating the core idea, rather than trying to explore audience usability preferences and peculiarities.
  • Use prototyping tools. Pen and paper could also work. But for the sake of convenience and shareability, it is better to use some of the well-known tools like Figma, UXPin, Balsamiq, or Sketch.
If you want to learn a bit of theory, here is a nice place to read about user interviews.


The results of the test then should be analyzed to answer the questions stated on the stage of purpose statement. Once a risk idea is validated, it can be further transformed into a user story or feature.

Product discovery frameworks

Now as you’ve learned the process elements in detail, let’s have a look at some of the prominent frameworks out there.

Design thinking

Design thinking became a basic concept and framework for conducting product discovery. It’s a customer-centered approach to analyzing the product requirements. Three primary elements shape the whole idea:
  • Desirability shows demand for a certain feature by a target audience.
  • Feasibility, or technical possibilities, as your company’s skills and resources.
  • Viability, or what makes sense for your business model.
Design thinking phases

Design thinking phases

Source: pdmethods.com

This diagram demonstrates the five steps in design thinking, which are similar to the process described above. The only difference is the interpretation of the exploration phase.

Jobs to be done

Jobs to be Done is a popular framework for product discovery. The idea is to look at the requirements not from the exact user persona (or customer) perspective, but from the job perspective of a target persona. In simple words, Jobs to be Done suggests analyzing ideas as a set of activities a user is trying to complete within the app.

There are five clear steps in this framework:

Market identification as a standard exploration phase, definition of the market problems, and understanding of user personas.

Jobs identification. This activity aims at understanding the actions and objectives customers are trying to complete. We’re also figuring out the motives a user is reaching while doing a “job.”

Job categorization. The identification of the main jobs and secondary jobs.

Job statement. The description of the job specifics.

Opportunity prioritization, or simply, developing solutions to the customer problem.

For example: A user of a gambling app is constantly reviewing stats. Their objective is to get the overview of how their actions impact the outcome of the game.

We can make an interface easier to use, add hundreds of filters to enhance flexibility of the app. Or we can automate the data collection of the section a user reviews the most and present them as a customizable dashboard. Both cases help the user reach their goals, but the second one requires less effort.

RAT or riskiest assumption test

Those working in software engineering or product management should be familiar with the concept of MVP. Minimum Viable Product is the required functional minimum that can bring the core product value for the end user. MVP is used to prove that a team is building the right thing.

A riskiest assumption test is a similar concept that suggests focusing on testing the assumption that seems to be… well, the riskiest, instead of building an MVP. It doesn’t mean that we no longer need to build a demo product to show and test on. Instead, RAT suggests testing those areas where we have the most uncertainty before moving to the delivery stage.

Why is product discovery that important?

Product discovery isn’t an exotic practice; it is a traditional part of any project. The way you do it makes a great difference. As a product manager, CTO, or CPO, it will be your direct responsibility to justify why the team should spend more time on the discovery process.

Each company is a unique case, but let’s look at some theoretical basis to understand why product discovery is so important. Marty Cagan, the author of Inspired, suggests four main risk types in product management:
  1. Value risk, bringing zero value to the customer.
  2. Usability risk, building something a user can’t figure out how to use.
  3. Feasibility risk, the risk of lacking technology, skills, or time for the product.
  4. Business viability risk, the risk of not achieving your business goals with the product.
The practice of product discovery first of all deals with bringing as much value as possible. Before the delivery stage, each idea tends to be validated and tested on the real user, mitigating the risk of building the wrong thing. By these means we can also improve our UX.

The idea field becomes cleaner as we sweep aside unrequired items, which facilitates feasibility of a product and more efficient resource consumption. Given the outcomes of product discovery, we can define KPIs and concentrate on the business viability instead of solving technical tasks. Among the general problems, the practice can help your team avoid opinion wars, because any assumption made will be tested to find the proof of its demand.

Attribution for icon authors used in the product discovery scheme: Icon made by Pixel perfect, Freepik, Ultimatearm, and Smashicons from www.flaticon.com.