Learning Loop Playbooks Learning Loop

Product management, Engineering, User experience

Product Discovery

The process of identifying and validating a product idea to ensure it meets customer needs. performs better.

Also called: Product Exploration, Product Search, and Product Research

See also: Product Metrics, Continuous Discovery

Relevant metrics: Product Impact, Business Value, Evidence Strength, Cycle Time, Quality of User Experience, User Engagement, Customer Satisfaction, and Average Revenue per User

In this article

What is Product Discovery?

Product discovery is the process of identifying and understanding customer needs and preferences in order to develop products and services that meet those needs. It involves researching customer behavior, analyzing market trends, and testing new ideas. Product discovery is an important part of the product development process, as it helps companies create products that are tailored to their customers’ needs and wants.

Where did Product Discovery come from?

The concept of “Product Discovery” has its roots in the Lean Startup methodology, which emphasizes the importance of validating assumptions about a product’s market and customer base through a process of experimentation and feedback.

The term itself was popularized by Marty Cagan in his book “Inspired: How to Create Tech Products Customers Love.”

Why is Product Discovery an important concept for Product Teams?

At its core, Product Discovery is the evidence-informed process of reducing uncertainty as you find problems worth solving and solutions worth building. It emerges through a series of nonlinear activities, conducted as a cross-functional team. Product Discovery typically describes a flexible period during which you and your team focus on building the right thing as opposed to building the thing right, which happens during Product Delivery. Teams often get the allocation of time and attention between the problem space and the solution space wrong. Product Discovery is, or at least should be, mostly about the problem space.

Differentiating the Problem Space and Solution Space of Product Discovery

Although it may be tempting to jump straight into discussing and designing shiny solution ideas, it’s important to stay disciplined about what to work on. Instead, Product Discovery should turn generic, company-level impacts into tangible outcomes for Product Teams to focus on. Identifying the right problem space to explore and genuinely understanding that problem can happen in many shapes and forms. If you only switch the number of shipped features for the number of user interviews, your team will just end up on a different hamster wheel, instead of focusing on the right uncertainty-reducing activities at a given point in time.

Separating the problem space and solution space

The problem space is the realm of understanding the user’s needs, pain points, and goals. It involves researching and analyzing the user’s behavior, preferences, and motivations to identify the problems that they face and opportunities for improvement.

The solution space, on the other hand, is the realm of ideation and testing potential solutions to address the problems identified in the problem space. It involves brainstorming, prototyping, and testing solutions to see if they meet the user’s needs and solve their problems.

By separating the problem space and solution space, product managers and user experience researchers can ensure that they are not jumping to conclusions about solutions before they fully understand the problem. They can focus on understanding the user’s needs and problems first, and then use that knowledge to generate and test potential solutions. This approach can lead to more effective and innovative solutions that truly address the user’s needs.

Don’t just research the next feature in line

A common anti-pattern of product teams is focusing their product discovery efforts on developing an existing idea that is already set to be next in line for the feature factory. If your team starts their Discovery mandate with ideation sessions (solution space), you are most likely going down the wrong path. A better place to start is in investigating the problem space.

Product Discovery is not necessarily about the number of interviewed users or how many experiments you ran. Identifying the right problem space to explore and genuinely understanding that problem can happen in many shapes and forms.

Connecting Product Discovery to Scrum and Product Delivery

Product teams are always in some Product Discovery mode because, if set up as a truly customer-centric organization, they want to expose as many team members as possible to user feedback as often as possible. Dual-Track Agile is when you need to simultaneously apply Agile principles to the Discovery and Delivery tracks of your product. Delivery and Discovery activities need to overlap and play together. Both are continuous activities, but their peak efforts behave more like S curves. The results from both activity tracks heavily influence each other and are, to a certain extent, happening in parallel all the time.

Cycling through the phases of Product Discovery

Phases is perhaps a bad word in regards to product discovery. Iterative might be better, as the phases are not always consecutive, and you may need to take one or more steps back to pursue a different path when you get stuck in a particular phase.

The success of your product discovery efforts depend more on your cycle time of rephrasing the question your are looking to get answers to.

“Our success at Amazon is a function of how many experiments we do per year, per month, per week, per day”

  • Jeff Bezos, CEO of Amazon

Reducing the time between customer touchpoints

The success of this process depends on how effectively you can reduce the time between customer touchpoints - how often you get input from customers. This is also called the cycle time. Any structured search for evidence can be called experimentation.

To maximize the number of experiments you can do in a given time, you need to keep your cycle time low. Reframing the question using the double diamond process can help you achieve this. It involves going through a disciplined process of framing the question, generating options, evaluating them, and reframing the question again. By going through this loop more frequently, you can reduce the cycle time and get feedback faster.

One way to reduce cycle time is by eliminating hand-offs, which can slow down the process. Instead, build a shared understanding and collaborate with your team to achieve the common goal of experimentation. Keep your eyes on the prize, which is to achieve the desired outcome, and do not get distracted by the process.

One common problem with experimentation is that it tends to favor optimization over innovation. To avoid this, you need to be disciplined in your approach to experimentation. While innovation without a disciplined approach may fail, following a structured process can lead to breakthroughs.

High-performance teams go around the loop more frequently and reframe more often than average teams. Therefore, it is essential to be rigid and disciplined about your reframing process to achieve the desired results. By reducing the cycle time of experimentation, you can test more ideas, validate assumptions, and increase the chances of success in product discovery.

Prioritizing Product Discovery Opportunities

Product Discovery is aimed at reducing uncertainty and increasing confidence in investing resources in a particular product based on evidence collected by the product team. Hence, frameworks such as the simple Effort-Impact-Scoring may fall short because you are unsure of the kind of solution to rate. Rather, the priorities of Product Discovery should be based on the Impact and Uncertainty of the opportunity.

Getting started is more critical than being right

Evaluating uncertainty provides clarity about which ideas to explore further during Product Discovery. Prioritizing opportunities may seem challenging, but this is not about making an accurate prediction. Instead, it is about a shared understanding which ideas to pursue within your team and company. You will gather more insights and evidence as you move forward, so getting started is more critical than being right.

Setting Up Your Product Discovery Process

When planning and structuring a Product Discovery process, it is wise to avoid starting with day-to-day tactics but gradually zoom in. It is crucial to take your time to clarify the problem you are trying to solve, although it may be tempting to jump straight into ideation sessions discussing specific solutions.

Try to avoid setting artificial deadlines for completing Product Discovery. It’s not something that has to be “done”, but a constant state of search. Having said that, defining a timebox to set up the team for a “best effort” mission is always a good way to avoid ending up in analysis paralysis. A period of six weeks for larger discovery projects seems to be a norm as it provides the right balance of predictability and embracing uncertainty. It does not predict how everything will play out, and it is easily seen as a starting point rather than a final timeline. It leaves enough room to course-correct before/after and redirect actions.

When you split a Discovery into different phases, do not lose sight of the timeline you have committed to. Even when your project has more of an exploratory character, you should not proceed without considering how much time is reasonably spent on each phase. Feel free to set your best guess as the first estimate for timings, and use check-ins as constraints that will give you the best information for advancing toward concrete deliverables. It is also useful to frame the scope of the project for the people you work with.

Avoid Prioritizing the Time to Get Started

One of the biggest pitfalls that teams run into when planning Discovery activities is prioritizing the time to get started over the time it takes to get to a valid insight. For instance, while it may seem faster to “talk to users” by stepping out on the streets or into a local Starbucks to pick up insights, the chances of talking to users from your specific target audience are pretty low, and it may take several attempts to get insights from a relevant user.

Effective research processes should get you access to any target audience within 1-2 weeks, although it may take a longer time before you can start your first interview. You might want to consider over-scheduling interviews with a specific target audience upfront, so you have a tight cadence for iterating and executing problem-oriented interviews or solution-testing sessions.

Product Discovery Techniques and Frameworks

To make the Product Discovery process more efficient and effective, product teams use a variety of techniques and frameworks that help them generate, prioritize, and validate ideas. In this section, we will explore some of the most popular and effective product discovery techniques and frameworks used by product teams today.

Assessing the Solution Space

To ensure a successful product outcome, the quality of tested assumptions and implemented ideas is equally important as understanding the problem space. Consider using these question to navigate the solution space:

  1. Which feature ideas have the most significant potential to create the changes in user behavior that will contribute to overarching business goals?
  2. Which assumptions behind your three most promising ideas are most crucial for the eventual success of the idea?
  3. Which assumptions are not based on data (yet)?
  4. How can you test assumptions through experiments to shorten the lead time into an idea’s desirability, usability, and feasibility?
  5. What could you do within the next ten days to gain data-based confidence in the validity of an idea? Use as little written code as possible. Bonus points for not using any.

The Mission Briefing

The concept of the Mission Briefing was originally described by Stephen Bungay, a strategy consultant, in his book, “The Art of Action.” Bungay showed how military leaders could set up their subordinates for success in the field without limiting their options. The Mission Briefing can be summarized into three directives:

  1. Limit top-down direction to defining and communicating the intent.
  2. Give individuals the freedom to adjust their actions in line with that intent.
  3. Allow each level to determine how they will achieve the intent of the next level up and “back brief,” so all involved parties are aware of any new changes.

If we adapt Bungay’s mission briefing to the world of Product Teams, it could look like this:

  1. The Context
  2. The Higher Intent
  3. The Team Intent
  4. The Key Implied Tasks
  5. The Boundaries

It is essential to describe the current situation without going into interpretations or solutions. Stick to the facts. Then, close the section by describing the problem with the current situation. Working through the Mission Briefing together section by section helps ensure alignment on every section before moving to the next.

Assumptions mapping

Assumptions Mapping is an exercise that involves explicit and prioritized hypotheses of desirability, viability, and feasibility. This exercise was first practised by Jeff Gothelf and Josh Seiden, co-authors of Lean UX, and later tested with numerous teams while applying the principles of design thinking by David Bland.

To fully comprehend the risk and uncertainty of your business idea, you must inquire about all the factors that need to be true for the idea to work. This will enable you to identify all four types of hypotheses underlying a business idea: desirability, feasibility, viability, and adaptability.

Every new product or service has leap of faith assumptions hidden behind it. If proven false, these vital and unknown assumptions can either make or break your initiative. The Assumptions Mapping method is designed to break down these assumptions as a team, allowing for a more specific focus on experimentation. You can also use Precoil’s Assumptions Mapping Worksheet and Mapping Template to structure assumptions questions listed below with your team.

Exploring Assumptions

  • Desirable - Do they want this? Before scaling to a million customers, it is crucial to have evidence that even a hundred customers are facing this problem. The proof is found outside of the building, making the role of designers and user researchers crucial in identifying desirability hypotheses.
  • Viable - Should we do this?. In addition to uncovering the problem, you must ask yourselves if this idea is viable and provide evidence to support your claim. Questions like, “How can you reach customers?” and “What is your business model?” are essential in determining viability hypotheses. Product managers, product owners, and business stakeholders play critical roles in the viability aspect of assumptions mapping.
  • Feasible - Can we do this?. This is the stage where teams spend most of their time proving that an idea is possible. Experimenting with code and hardware is just the tip of the iceberg as teams must also navigate any legal or regulatory hurdles. The roles of engineering, development, and legal are paramount in identifying feasible hypotheses.

Mapping Your Hypotheses

The first step is to write your hypotheses using the “We believe that…” format, which helps you mentally shift to the idea of testing. The second step is to draw your 2x2 diagram using the labels of “have evidence” and “no evidence” on the x-axis and “important” and “unimportant” on the y-axis. By asking yourself “which hypothesis, if proven wrong, will cause our business idea to fail,” you can determine which hypotheses are the most critical.

Once you have a few hypotheses mapped, you can quickly determine which ones are more important or have a greater amount of evidence. The hypotheses in the top right quadrant are the most critical and have the least amount of evidence to support them. It is crucial to focus on this area for experimentation, instead of working on hypotheses that are unimportant and already have evidence. This is how you can help your team focus on experiments that matter.

Impact Mapping

Impact Mapping is a technique that helps Product Teams connect features and activities to overarching business goals, using user behaviors as more leading proxies. It is one of the most effective techniques to help Product Teams make sense of all the evidence they collected and trade-off decisions. The framework was popularized by Gojko Adzic in 2012 and has been iterated over the years to specifically support Product Discovery activities and outcome-thinking.

There are three main benefits of Impact Mapping for teams:

  1. Being able to put strategic guidance, research evidence, ideation outputs, and experiment results into context to make data-informed decisions.
  2. Working level-by-level, so teams (and executives) can avoid jumping straight from high-level company impacts into pursuing solutions.
  3. Facilitating tactical decisions without losing sight of how an individual solution contributes to higher goals.

The levels of Impact Mapping are not just an abstract representation of an imaginary process. Instead, most of a team’s Product Discovery work finds its place on an Impact Map.

Using Impact Mapping as a lens emphasizes how the different dots of Discovery are connected. The Impact Map can act as an effective input to the OKR definition of Product Teams. It beautifully condenses insights and connects activities (or the lack thereof) to high-level company priorities.

Opportunity Solution Trees

An Opportunity Solution Tree (OST) is a discovery visualization tool that has been designed to assist product teams in finding the most effective path to attain a desired result. The OST provides a structured approach to determine user problems or product vision, identify potential obstacles that impede progress towards the desired outcome, and finally establish effective strategies to overcome such obstacles.

The primary aim of the OST is to create a link between the desired outcome and the issues that prevent the product team from reaching it. Additionally, it outlines experiments that can help validate whether the solution is working or not.

Teresa Torres, a product discovery coach, created the Opportunity Solution Tree (OST) in 2016 as a way of streamlining the product discovery process and monitoring the team’s continuous discovery journey. Torres describes OSTs as “a simple way of visually representing how you plan to reach the desired outcome.

Streamlining Ideation Using Opportunity Solution Tree

To stay focused and organized while ideating, it is important to link every team idea back to the business goal. This helps the team to stay focused on the outcome, which is framed around the product vision and strategy.

During product discovery sessions that involve the use of an OST, a designer, an engineer, and a product manager are typically in attendance. Each role proposes solutions for opportunities.

The product manager typically links the idea back to the outcome and product strategy. The designer explains the idea from the user experience perspective and shares some qualitative user insights about it. Finally, the engineer shares more in-depth cases with the team and estimates the technical feasibility of the desired outcome.

This process helps the team to shortlist and prioritize only the most feasible ideas for the validation stage and, ultimately, execution.

Every solution prioritized using an OST must be validated and researched before advancing to the execution stage. This means that when conducting research, a research backlog should be full of tasks that will eventually help reach the outcome faster.

Using the OST’s top-down approach, the team is driven by the business outcome, discovering opportunities, and ideating features with the team using qualitative and quantitative data insights.

The OST cycle provides the context the team needs to ensure that each developed feature has a logical story that stakeholders can align with.

The Idea Validation Grid

As previously stated, the intricate work of planning and setting up experiments necessitates its own system and framework. As with research methodologies, it is unwise to immediately adopt the best validation technique proposed by your CPO. Instead, the ideal approach would be to construct a solid case for why a particular technique is most appropriate for the specific queries raised by your idea.

Not only does this help in presenting a clear argument when deliberating on your resources, but it also ensures that fruitful discussions are held with other experts within your organization concerning selecting the ideal experiment.

To accomplish this, there are five fundamental requirements for creating a more detailed perspective of our experiment design:

  1. A high-level overview of the concept generated.
  2. An objectified decision-making criteria, such as an ICE score, to assess an idea’s priority and our evolving confidence in it.
  3. A prioritized list of assumptions regarding an idea, articulating which behaviours or outcomes the idea must meet to ultimately succeed.
  4. A description of how the idea will bring about a desirable change in behaviour.
  5. The selected experiment for testing our assumptions regarding user outcomes and any further actions.

Actor-Job-Outcome-Mapping

When conducting research, we gain valuable insights into the behavior of our users, including their feature requests and underlying motivations. However, these insights alone are not sufficient to make informed decisions. To make insights actionable, we must interpret them and articulate the desired changes in behavior in the form of Outcomes. These Outcomes act as measurable proxies to determine if we have solved a real user problem while contributing to overall business priorities.

While the process of synthesizing insights is based on a jobs-oriented approach, the components of this process do not necessarily unfold in a linear manner. Therefore, a different mapping of these components can help us understand the insights we have and the gaps we need to fill. Additionally, it is important to know where to place the insights we already have and how they connect to the core components (Actor, Context, Motivation, Problem, and Outcome).

To effectively communicate synthesized insights and specific Outcomes worth focusing on, we can use the Actor-Job-Outcome-Mapping framework. This framework helps us connect the dots from research insights to actionable Outcomes. However, it is possible that we are only aware of the specific Motivations and Problems that an Actor experiences in a given situation. Therefore, we need to consider other Problems that prevent the Actor from achieving the same Motivation, as well as new Motivations that we may have overlooked.

The Actor-Job-Outcome-Mapping framework helps us to uncover what we do not know and determine the most effective techniques to use next. By mapping the insights we do have, we can identify gaps in our knowledge and gain a more comprehensive understanding of the needs and behaviors of our users. While this mapping process may not always reveal a variety of relationships among different insights, it is a helpful technique for connecting research insights to actionable Outcomes.

Embrace a pragmatic approach to harvest the power of good Product Discovery

Product Discovery is essential for any team looking to develop better products and drive customer behaviors that result in improved business outcomes. However, it’s important to recognize that it must be tailored to your team’s specific needs and adapted to the context of your industry.

Avoiding All-or-Nothing Thinking

It’s crucial to avoid the trap of thinking that if you can’t perform all the necessary steps at precisely the right time, the entire process is useless. In fact, even small changes can lead to a more effective Product Discovery process and drive better product outcomes, so it’s important not to view it as an all-or-nothing proposition.

Talking to Customers: Quality Over Quantity

While the idea of talking to a user every week may seem like an effective approach to improving your team’s customer focus, it’s important to consider the practical reality of working through the Product Discovery problem space. Continuously forcing your team to engage in user interactions may lead to unintended consequences, such as focusing on the wrong user segments or being too narrowly focused on problems without a clear strategic goal.

Instead, it’s important to focus your research efforts on the user segments that are relevant to your overarching strategic goals. You shouldn’t feel pressured to solve every problem that arises; just because a user problem exists doesn’t necessarily mean that it’s the right one to work on at the moment. Additionally, in some cases, qualitative insights from weekly user interviews may not be helpful, and you may want to utilize quantitative techniques to gain more confidence in your approach.

Testing for Valuable Insights

It’s easy to become preoccupied with the number of experiments you run, but this doesn’t necessarily mean that you’re making progress in Product Discovery. The real goal is to collect strong evidence that helps you make informed decisions about whether a problem is worth solving or a solution is worth pursuing. Therefore, it’s crucial to choose the right experiment techniques and execute them in a way that generates valuable insights, rather than simply focusing on the number of experiments.

Chasing for too much evidence

In the process of Discovery, teams often get confused about what evidence to act on. For instance, should a team change the order of their marketing website because some users asked customer support about their favorite feature? Does an A/B test result mean that the team should fix the churn of all mobile users? Should the team introduce the same feature as their competitors? To answer such questions, teams must differentiate their Discovery evidence into four categories based on proximity to the source and degree of commitment.

The Four Categories of Evidence

  1. First-Hand and Serious Commitment Evidence. This category represents the most reliable evidence for decision-making. It includes evidence from activities that the team ran itself and results from real decisions that users or customers had to make. For instance, if a team recommends a product via LinkedIn DMs to five peers after they say they “like it” in an interview, it can be considered as first-hand and serious commitment evidence.
  2. First-Hand and Lip Service Evidence. This kind of evidence is often mistaken for a serious commitment. Every time the observed or recorded action doesn’t come with consequences for the user or customer, it can be categorized as first-hand and lip service evidence. Leaving a review or feature request without any follow-up can be an example of lip service evidence. However, enforcing more serious commitments from loose statements like “I would buy that” can help teams turn lip service into more reliable serious commitment evidence.
  3. Second-Hand and Serious Commitment Evidence. This category includes competitor moves, which are commonly misused pieces of evidence. It takes serious commitment from a competitor to ship something, but one can never know the basis of this move. It could be driven by a top-down HiPPO idea, n=1 user insights, or poorly interpreted quantitative data.
  4. Second-Hand and Lip Service Evidence. This category should be avoided as it provides no useful insights for decision-making. Insights in this category have often been watered down through proxies and reflect off-the-cuff comments about what users think “would be nice” or don’t even represent a relevant segment of the audience.

To make the evidence more usable and relevant, teams should think about shifting it towards first-hand and serious commitment evidence. Instead of dropping the experiment altogether, the team can increase the commitment from the participants. By enforcing more serious commitments from users, teams can turn first-hand and lip service evidence into reliable serious commitment evidence.

Adapt your Product Discovery to your context

In order to create a successful Product Discovery process, it’s important to understand the principles and strategies that underpin it. Moreover, you must understand how to apply these principles to make the process work for your unique context and reality, step by step.

While it’s important to consider the best practices of others, it’s even more important to prioritize your unique context. The goal is to collect valuable pieces of evidence that help you make informed decisions about whether to pursue a solution or a problem, not simply to tick off boxes from someone else’s playbook.f

Relevant questions to ask
  • What is the purpose of the product?
    Hint The purpose of the product is to create a solution to a problem or need that the target audience has.
  • What problem does the product solve?
    Hint The product solves a problem or need that the target audience has.
  • Who is the target audience for the product?
    Hint The target audience for the product is the group of people who have the problem or need that the product is designed to solve.
  • What features should the product have?
    Hint The features of the product should be based on the needs of the target audience and should be designed to solve the problem or need.
  • What is the timeline for the product discovery process?
    Hint The timeline for the product discovery process will depend on the complexity of the product and the resources available.
  • What resources are available to support the product discovery process?
    Hint Resources available to support the product discovery process include market research, customer feedback, user testing, and prototyping.
  • What is the budget for the product discovery process?
    Hint The budget for the product discovery process will depend on the complexity of the product and the resources available.
  • What is the expected outcome of the product discovery process?
    Hint The expected outcome of the product discovery process is a product that meets the needs of the target audience and solves the problem or need.
  • What are the risks associated with the product discovery process?
    Hint The risks associated with the product discovery process include the potential for the product to not meet the needs of the target audience or to not solve the problem or need.
  • How will the product discovery process be evaluated?
    Hint The product discovery process will be evaluated based on the success of the product in meeting the needs of the target audience and solving the problem or need.

You might also be interested in reading up on:

People who talk about the topic of Product Discovery on Twitter
Relevant books on the topic of Product Discovery
  • The Lean Startup: How Constant Innovation Creates Radically Successful Businesses by Eric Ries (2011)
  • Inspired: How to Create Products Customers Love by Marty Cagan (2008)
  • The Four Steps to the Epiphany: Successful Strategies for Products That Win by Steve Blank (2013)
  • It's Our Research: Getting Stakeholder Buyin for User Experience Research Projects by Tomer Sharon (2012)
  • Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback by Tristan Kromer (2015)
  • Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value by Teresa Torres (2021)
  • Empowered: Ordinary People, Extraordinary Products by Marty Cagan (2020)
  • Escaping the Build Trap: How Effective Product Management Creates Real Value by Melissa Perri (2018)

Want to learn more?

Receive a hand picked list of the best reads on building products that matter every week. Curated by Anders Toxboe. Published every Tuesday.

No spam! Unsubscribe with a single click at any time.

Community events
Product Loop

Product Loop provides an opportunity for Product professionals and their peers to exchange ideas and experiences about Product Design, Development and Management, Business Modelling, Metrics, User Experience and all the other things that get us excited.

Join our community

Made with in Copenhagen, Denmark

Want to learn more about about good product development, then browse our product playbooks.