Product Discovery
A Practical Guide for Product Teams

by Tim Herbig · Updated Jan. 5, 2022

OKRs in Product Management Main Guide Cover Image

In this hands-on guide, I will show you how to go beyond cliché advice, like “just talk to users more often,” to make sure the practice of Product Discovery helps teams to make real progress.


These are the exact techniques that I use to help Product Teams around the globe to navigate the uncertainty of exploring the problem space of their user segments and to identify solutions that are worth building.


In this in-depth guide, you’ll learn:

  • What Product Discovery is and how it connects to Product Management domains like Product Strategy, Scrum, and OKRs
  • How to structure your Product Discovery without losing the ability to explore and course-correct
  • The key elements of Product Discovery and how to navigate and combine them
  • Incredible effective, yet lightweight Product Discovery techniques you can implement with your team right away
  • Lots of advanced tips, strategies, and tactics.

If you want to make sure that you’re building the right product for the right audience, you’ll love this guide.

Let’s get started.

Don’t have time to read the whole guide right now?

Product Discovery Guide eBook Opt-In Preview Image

No worries. Let me send you a copy so you can read it when it’s convenient for you. Just let me know where to send it (takes 5 seconds):

Introduction

When roadmaps for the upcoming year are crafted, you should be able to rank the themes you and your team want to work on. Most often, those topics result from epics you’ve worked on before, your Product Strategy, user feedback, or the Objectives and Key Results (OKRs) for your team.

By then, it’s pretty clear what to work on from a high-level perspective. But as a Product Manager, you might wonder exactly which problem needs to be solved next? And how can you generate the biggest impact? This is the point at which a well-prepared and insightful Product Discovery process enters the stage.

The goal of this guide is to show you how expansive Product Discovery can be and how to set up and execute your own Product Discovery process. The most effective way to start the implementation of your own process is to focus on a set of techniques and habits you want to internalize and that work for your specific environment.

Don’t treat this guide as a step-by-step blueprint for every Discovery. View it as an inspiration to structure your thinking and choose what matches your unique situation. It is designed to supplement my Adaptable Product Discovery Course, which helps you design and implement your own Product Discovery process.

Product Discovery Fundamentals to Get Started

In this chapter, I want to introduce the basic concept of Product Discovery and answer some of the fundamental questions and highlight how Product Discovery connects to some of its adjacent processes.


Your Main Takeaways From This Chapter:

  • Understand what Product Discovery is
  • How Product Discovery connects to Scrum
  • The role of the Outcome Quadrant to focus your Discovery efforts on what matters.
Tim Herbig Product Discovery Main Guide Chapter 1 Image

What Is Product Discovery and Why Is It So Important? 🔗

At its core, Product Discovery is about the data-informed reduction of uncertainty in regard to problems worth solving and solutions worth building through a series of nonlinear activities, conducted as a cross-functional team.

Product Discovery is about the data-informed reduction of uncertainty in regard to problems worth solving and solutions worth building 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 would be Product Delivery). Product Discovery can have many forms and structures, as we’ll discuss later.

Typically, Product Teams are working either on the problem space or the solution space. They’re either still trying to understand whether a problem exists for their users, customers, or stakeholders or they are focused on executing a matching solution.

Though working in both spaces is necessary to satisfy users and support the business, teams often get the allocation of time and attention wrong. Product Discovery is, or at least should be, mostly about the problem space.

Differentiating the Problem Space and Solution Space of Product Discovery

Differentiating the Problem Space and Solution Space of Product Discovery

In fact, I’m with Paul Adams, VP of Product at Intercom, when it comes to allocating time and attention:

40% of our 100 units are spent before we’ve even started designing anything. We obsess about problem prioritisation and problem definition. I drive our people crazy sometimes interrogating whether we really truly deeply understand the problem we’re attempting to solve.

So, though it might be tempting to jump straight into discussing and designing shiny solution ideas, it’s important to stay disciplined about what to work on.

Even though I’m a big supporter of individual Product Discovery paths, I believe that outlining and aligning on the problem space is a crucial activity, which you should rarely skip.

Product Discovery Effort allocation Problem Space and Solution Space

Reflect on and be mindful of how you allocate your time and efforts between the problem space and solution space of Product Discovery.

Alibi-Discovery, for those of you who are not familiar with it, describes the process of developing an existing (top-down) idea that is already set to be next in line for the feature factory. Here’s the quickest way to recognize if a team is doing Alibi-Discovery: They start their Discovery mandate with ideation sessions.

If you use the definition from above as the starting point for your Discovery activities, it should become clear why ideation shouldn’t be the activity that teams spend the majority of their time on.

Product Discovery is not necessarily about shipped features. Identifying the right problem space to explore and genuinely understanding that problem is extremely valuable for any company.

How Does Product Discovery Relate to Scrum and Product Delivery? 🔗

In general, you’re always in some Product Discovery mode as a Product Team. This is because if you’re set up as a truly customer-centric organization, you want to expose as many team members as possible to user feedback as often as possible. That will ultimately lead continuously to new insights in the user’s needs.

Most Product Managers face a scenario called Dual-Track Agile. This means that you need to simultaneously apply Agile principles (like cross-functional collaboration among Product, Design, and Engineering; user-centered thinking; and iterative improvements) to the Discovery and Delivery tracks of your product.

The activities of Delivery and Discovery (need to) overlap and play together. Both are continuous activities. But their peak efforts behave more like S curves.

Product Discovery Dua-Track Agile S-Curves Model

Dual-Track Agile should be seen as alternating S curves with continuous highs and lows, instead of a rigid and monotonous way of working.

The results from both activity tracks heavily influence each other and are, to a certain extent, happening in parallel all the time. However, I believe it’s important to acknowledge that both activities require a different dedication of time from the Product Manager, UX Designer, and Development Team. Though a Product Team should ideally start working together on a new Product Discovery mission, some team members will be more occupied with it than others.

Tip for Practice: Make Discovery part of your Product Team, instead of setting up a separate Discovery team.

Product Discovery and Product Delivery should be owned by the same team to increase the intrinsic motivation to execute and reduce knowledge silos.

It’s ok to temporarily focus more on Delivery or Discovery at a given point in time. But make sure that a Product Team has the skills and freedom to work on both aspects on their own time.

Of course, there might be specific projects that will put you in a more explicit Product Discovery mode, and it makes a lot of sense to shift your (and your team’s) focus away from Delivery for a certain period.

But the inconvenient truth is that you probably work in a mix of Discovery and Delivery modes for most of the time with just the scale tipping more to one or the other direction at certain points.

The inconvenient truth is that you probably work in a mix of Discovery and Delivery modes for most of the time with just the scale tipping more to one or the other direction at certain points.

The more uncertainty you have about which solutions your business goals need to bring to the table, the more attention you need to devote to Product Discovery. In general, I recommend changing your mindset from treating Product Discovery as a particular end and clearly defined task. Instead, Product Discovery is a combination of activities to navigate the problem space. And this combination needs to be adaptable and nonlinear. Product Teams need to adopt it as a habit.

Adjacent Product Discovery Processes 🔗

Your ability to focus on Outcomes through Discovery doesn’t depend just on your ability to talk to users or run experiments.

Instead, it requires the joint effect of something I like to call the Outcome Quadrant. The Outcome Quadrant consists of the four key pillars that influence your overall focus on Outcomes.

The Outcome Quadrant Model

Focusing on Outcomes in practice requires changes to and input from multiple Product Management domains that are part of the Outcome Quadrant.

Though Product Discovery is one of the key pillars, you also need an outcome-oriented approach to Product Strategy, Product Goals, and Product Roadmaps.

As a Product Manager, it is important that you understand what is in your power and responsibility to change and where to demand clarity. Product Discovery, Strategy, Goals, and Roadmaps are within that realm of responsibility. Chances are, that your Discovery efforts don’t feel slow just because of a lack of interviewing skills or insufficient validation. Ensure these three adjacent processes are supporting your efforts as well.

Obviously, there are lots of nuances of how each of these three domains can be approached—with varying degrees of how well they support your Product Discovery work.

How Product Discovery Relates to Product Strategy 🔗

At its very core, Product Strategy is about expressing how you plan to compete in and win in the market you have chosen. It outlines elements like your high-level user segments, the alternatives to your product, and how to differentiate from it, as well as your company’s capabilities and overarching drivers.

Product Strategy is about expressing how you plan to compete in and win in the market you have chosen.

Without going into too much detail about Product Strategy, I want to outline the cornerstone questions every (good) Product Strategy should be built on:

  1. What is the one overall problem your product is solving?
  2. Which alternatives could your users draw on to solve that problem (i.e., direct and indirect competitors)?
  3. What are the core value propositions that define your product?
  4. What makes your product unique compared to direct and indirect competitors?

I like to visualize the answers to these questions using the Product Field framework, which makes the (constantly evolving) pillars guiding Product Discovery efforts visible.

Product Strategy Gaps inform Product Discovery Priorities

The gaps of your Product Strategy are an important input for setting Product Discovery priorities.

When teams lack a starting point for Product Discovery, it’s often due to the lack of strategic context. The point is not to create a McKinsey-level company strategy, but something to refer to when you have to make trade-off decisions as you navigate through the problem space of a Discovery mission.

This, of course, requires a clear understanding of what a Product Strategy is about compared to, for example, a Product Vision. Check-out this video, where I’ll clearly differentiate Product Vision from Product Strategy and show how they relate to and benefit each other.

Click to play

How Product Discovery Relates to OKRs 🔗

Goals take the “winning plan” of Product Strategy and make it more tangible, so you can use these goals to prioritize your day-to-day activities. Ideally, they express a holistic perspective of how exactly success would look, in the form of quantifiable metrics.

Product Goals are often conflated with strategy. Neither of these terms shares a universal definition within the industry, nor do companies take the time to ensure that the understanding of these terms is universal within their organization. Strategy is the plan to achieve your goal—not the goal itself.

Product Goals are often conflated with strategy. Strategy is the plan to achieve your goal—not the goal itself.

One of the biggest challenges of using OKRs in Product Management is aligning the Discovery and Delivery cadence with goal cycles.

Connecting OKRs to Product Management Domains and Time Horizons

Connecting OKRs to Product Management Domains and Product Discovery Time Horizons

So, instead of trying to rush through Discovery, Delivery, and iterations within the same cycle, I believe that Product Teams need to lay the groundwork for upcoming Delivery-oriented OKRs and activities by making room for Discovery work through anticipating Discovery-oriented OKRs in a previous cycle. That is, as long as these are connected to an actual benefit you want to drive for your way of working—and don’t get misused as a task list to keep the Product Team busy.

An often dismissed and underestimated artifact for getting inspiration and guidance about upcoming Discovery priorities is the Product Roadmap.

Deep Dive: OKRs in Product Management

OKRs in Product Management Guide PDF Version Preview Image

If you’re asking yourself how you can connect Product Strategy and your Product Discovery/Delivery efforts through outcome-oriented goals, this guide has the answers.

How Product Discovery Connects to Product Roadmaps 🔗

The way you handle roadmaps and plan “the work” directly influences the freedom and autonomy your team has for Product Discovery. When you have the resources to understand the problem space, but your roadmap says you need to deliver the new start page feed on March 31, you’re not doing Product Discovery. Instead, you’re polishing an existing idea.

When you have the resources to understand the problem space, but your roadmap says you need to deliver the new start page feed on March 31, you’re not doing Product Discovery. You’re polishing an existing idea.

Product Roadmaps can be a helpful format to make the priorities and activities you have chosen to pursue more tangible. 

When looking ahead for, let’s say, one year, Product Teams should have high confidence in the current quarter’s areas of focus, but should assume that they will learn a lot during the current quarter and that plans for subsequent quarters may need to change. That’s why a theme-based roadmap approach with loosely defined time horizons, that degrade in granularity the more you look into the future, is more fitting.

A roadmap like this should then be updated on a rolling cycle-based cadence and aligned to the activities of Strategy and Goal iterations.

How to Structure Product Discovery Phases
and Organize Team Participation

In this chapter, I will outline some of the most important phases teams should cycle through during Product Discovery, as well as discuss how to structure these activities.


Your Main Takeaways From This Chapter:

  • Prioritizing and structuring your Product Discovery
  • Who should participate at what stage of Product Discovery
  • What are the key elements of Product Discovery.
Tim Herbig Product Discovery Main Guide Chapter 2 Image

Though every Product Discovery starts at a different stage, I find the model below helpful. The segmentation into certain phases also makes sense for structuring your thoughts and actions during continuous Discovery efforts.

Click to play

It’s important to understand that you won’t just walk through these phases one after another toward a pot of gold at the end of the rainbow. You might get stuck during one stage and need to take one or multiple steps back to pursue a different path—and that’s ok. 

Product Discovery is rarely a linear process. I’ve developed an Adaptable Product Discovery Approach that will give you the tools you need when you need them—and show you how to make them work for you and your company.

How to Prioritize Product Discovery Opportunities 🔗

Product Discovery is about reducing uncertainty and increasing the confidence to invest resources in building a specific product. This is why frameworks like simple Effort-Impact-Scoring fall short—because you don’t know what kind of solution you should rate. I prefer a different grading:

Product Discovery Impact-Uncertainty Prioritization v2

Product Discovery Priorities should be defined along the lines of Impact and Uncertainty

By evaluating the uncertainty, you get a much clearer picture about which ideas you need to further explore during Product Discovery. The area on the upper right includes your next targets to evaluate. Everything on the lower right should be looked at from a Delivery capacity perspective.

Prioritizing opportunities may seem rough to you—and that’s ok. This is not about making a 100 percent accurate prediction; it’s about a shared understanding within your team and company about which ideas to pursue.

You will gather more insights and evidence on what works and what doesn’t as you move forward. Getting started is more important than being right.

How to Set Up Your Product Discovery Process 🔗

When it comes to planning and structuring an upcoming Product Discovery, you don’t want to start with the day-to-day tactics. Instead, it makes sense to gradually zoom in.

Click to play

As mentioned earlier, the majority of Product Discovery should be spent trying to understand the problem space. Though it might be tempting to jump straight into ideation sessions discussing specific solutions, it’s important to take your time to create clarity about the problem you’re trying to solve.

Though I don’t believe in setting an artificial deadline for “completing” Product Discovery for the sake of it, I’ve seen the power of defining a timebox to set up the team for a “best effort” mission.

Process and structure are not the enemies of Product Discovery—as long as they are seen as options to choose from, depending on the context and phase of Discovery.

As a starting point, a period of six weeks has proven to work quite well. Why six weeks?

  • It doesn’t try to predict how “everything” will play out (limited risk investment).
  • It’s easily seen as a starting point, rather than a final timeline.
  • It leaves enough room to course-correct before/after and redirect actions.
  • It provides the right balance of creating predictability and embracing uncertainty.

When you can take the time to split a Discovery up into different phases, it’s important not to lose sight of the timeline you’ve committed to. Even when your project has more of an exploratory character, you shouldn’t just go along without considering how much time is reasonably spent on each phase.

Feel free to just set your best guess as the first estimate for timing. Don’t think of milestones as limitations, but instead use them as constraints that will give you as the Product Manager the best information for advancing toward concrete deliverables. It’s also a good technique to frame the scope of the project for the people you work with.

Who Should Participate in Product Discovery? 🔗

Though it might be tempting to keep the developers on your team busy with shipping code, more and more teams involve the entire group in a Product Discovery right from the beginning. That’s what true cross-functional collaboration is about.

At the same time, I don’t believe in sticking to a rigid classification of who should participate in Product Discovery. After all, who should be a permanent collaborator of Product Discovery activities should be based on the requirements and context of your challenge, instead of a one-size-fits-all definition.

Don’t get caught up in a rigid classification of who should participate in Product Discovery. Who should be permanently or temporarily involved should be based on the requirements and context of your challenge, instead of a one-size-fits-all definition.

In my experience, it’s important to be aware of people who will be permanently involved in the Product Discovery, those who will contribute temporarily, and those who are general Supporters of the Mission.

Product Discovery Collaborators Model

The Product Discovery involvement of Product Team Members and Stakeholders should depend on context, not strict rules.

The degree to which each of these groups is involved ultimately depends on your Discovery setup. Involving fellow Product Teams during the Alignment phase might be necessary due to a high degree of dependency. And whether sales reps are valuable participants in an ideation session depends on the way you typically involve this department. And please keep in mind that the definition of Product Discovery collaborators will and should change throughout your Discovery. This is not a set-in-stone categorization and should allow for context-dependent adaptations.

There are two main benefits to involving team members across domains (even thinking beyond the “typical” trio of Product, Engineering, and UX) during Product Discovery:

  1. The team can generate insights and make decisions at their own pace. By reducing the dependency to central departments, the Product Team can benefit from sharing their research or validation efforts. But ultimately, the Product Team owns the process and feels empowered and accountable for the results.
  2. To avoid confirmation bias during interviews or ideation sessions, the holistic perspective from different domains of expertise helps to keep a balance. Each of these three main domains of expertise brings a unique set of interpretations and perspectives to the table. This way, Product Discovery efforts remain an actual team effort and results are communicated in a way that works for the whole team.

What Are the Key Elements of Product Discovery? 🔗

Creating Alignment to Enable Team Autonomy 🔗

Balancing alignment to explore the problem and solution space autonomously as a Product Team is an often underestimated, yet important challenge to nail in the early phases of Discovery.

Balancing alignment to explore the problem and solution space autonomously as a Product Team is an often underestimated, yet important challenge to nail in the early phases of Discovery.

A lack of clarity around WHY you should care about this Discovery scope can lead to issues like solutioning or falling for confirmation bias down the road.

But even if you’re aware of the importance of alignment, not all alignment is created equal.

Almost every Product Manager knows the situation: Some of your stakeholders always come up with particular features they want you to build into your product (i.e.,solutions and not problems).

Unfortunately, this misconception is the result of a lack of trust: These stakeholders don’t believe that the output your team will deliver will match their expectations. The best way to resolve this issue is to focus on alignment early on in Product Discovery and commit to a particular outcome rather than features.

There are other red flags I have experienced over the years to differentiate solution-focused alignment from a true focus on the problem:

Problem vs. Solution-focused Product Discovery Alignment

Red flags to watch out for and avoid when it comes to Product Discovery Alignment

Creating alignment is more than just sending an email. It also doesn’t necessarily mean that you need to get everybody to agree. The more critical part of alignment is commitment. It’s much easier to get commitment from your stakeholders than to make them all agree.

An effective way to achieve this kind of alignment together is the Mission Briefing, which we’ll discuss later.

Understanding the Most Critical User Problems 🔗

Every effort around identifying a new product opportunity should start with the WHY. And though there’s pretty much always also a business need to justify Discovery efforts, the success of your product ultimately depends on whether it can identify and solve the most pressing problems of your target audience. So, start by understanding the struggles of your (desired) users.

Though there’s pretty much always also a business need to justify Discovery efforts, the success of your product ultimately depends on whether it can identify and solve the most pressing problems of your target audience.

When thinking of research, most teams jump immediately to interviews or send a survey. Though that isn’t necessarily wrong, there are better practices to adopt for more focused navigation of the problem space:

  1. Clearly state your research intent questions based on the biggest areas of uncertainty before choosing and executing a given technique.
  2. Make sure to collect insight from multiple angles to get to the truth that lies at the intersection of what people say and what they do.

The User Research Team at Spotify recently shared a practical insight into one of their projects. In it, Research and Data Science collaborated to look at the actual behavior of users from as many angles as possible.

To understand the truth about current behaviors and problems, you have to choose research techniques that allow you to capture the intersection of multiple perspectives.

And remember that maybe you don’t always need to engage in new research activities right away. It might make sense to turn existing sources of continuously incoming feedback into tangible evidence lockers. A convenient way to capture and structure continuously incoming customer feedback are tools like EnjoyHQ or Airfocus.

Whether you’re looking for a way to improve a product that is already in use or you’re about to build something that aims to serve an unsolved need, identifying what your users want and need is critical.

Deep Dive: Understanding Whose Problems Matter for Product Discovery

Product Discovery Course Lesson Preview Image

Learn how to identify the primary criteria for whose needs are worth exploring during Product Discovery using Impact Mapping in this free preview lesson from my Adaptable Product Discovery Course.

Collaboratively Ideating Solutions That Drive Changes in Behaviors 🔗

Once you have developed a basic understanding of which problems your users are dealing with, it’s time to start thinking about solutions. And by that, I don’t just mean to visit your CEO’s pet project bucket list. If you don’t want to stay stuck with incremental features that barely move the needle, you should at least attempt to think big.

The primary goal of the best ideation exercises is to get people out of their comfort zone and to think big(ger). Reality will catch up soon enough, but let’s reach for the stars at this stage of Product Discovery.

The primary goal of the best ideation exercises is to get people out of their comfort zone and to think big(ger). Reality will catch up soon enough, but let’s reach for the stars at this stage of Product Discovery.

Of course, with so many ideas being created during a lot of fun sessions, how should you prioritize them? As the whole point of modern Product Discovery is to not just stay within the bubble of your Product Team and instead involve temporary and supporting Discovery Collaborators, it shouldn’t be the CEO stepping into the room and pointing to the idea they like the most. Try to democratize the process.

On the highest level, you first need to bring structure to the ideas created in the ideation sessions. Dot voting is an effective and lightweight technique to go from 40 to 10 ideas.

What about all the ideas that get lost in the process because nobody voted for them? I don’t believe in idea backlogs. If you stumble upon great ideas, you should execute them, either by further exploring them or by immediately implementing them.

Great ideas will come back during future iterations and eventually find their way into the highest priority buckets. Don’t worry about saving them. Instead, focus on moving forward with the ones you have selected.

Prototyping Experiences 🔗

Putting sticky notes full of ideas into the hands of your users probably won’t help you to understand their reactions. This is why you need to find a pragmatic way to turn your most promising ideas into somewhat real prototypes.

Though prototyping tools are the “shiny objects” of Product Discovery, you should keep in mind that you don’t need to use them. Instead, focus on the challenge of simulating an experience to validate the ideas in front of you. Remember that it’s about prototyping an experience, which isn’t always defined through a UI.

For example, let’s take a look at the idea of a personality assessment test. You could prototype the experience by merely connecting several tools and creating a slim version of the product manually in the background.

You could create a basic landing page where people could start the “personality test.” From there, you could lead them to a survey tool like Typeform. The answers from the survey could get pushed into whatever tool you’d like to use through a connection established by Zapier. Assuming you won’t show your prototype to thousands of users, why not create the final “assessment” using predefined text blocks that match the incoming survey feedback? Combine it with a free, but professional-looking, email tool like MailChimp and your prototype is ready for testing.

With all the flexibility and power of modern No Code tools out there, it can be tempting to fully build out your idea instead of sticking to the experiment scope that’s required for testing the assumptions behind it. David Bland has a great piece of advice for teams that find themselves in this position:

I still advise teams that they should defer building as long as possible, and though this hasn’t changed, the sheer cost, time and capabilities needed to do a software Mashup MVP are rapidly plummeting.

Prototyping should always be a lean way to validate your hypotheses. Don’t get caught up in animations or style guides. Focus on supporting the (re-)actions you want to see from users who are exposed to your product.

Testing the Most Critical Assumptions of Discovery Ideas Through Experiments 🔗

Just like Research, Validation is not simply about ticking off boxes of showing a design prototype to customers or priding yourself on how many A/B tests are running on production. Instead, Validation is about making sure that you collect the best information possible to further commit to or dismiss a given solution based on actionable evidence.

But in order to do that, it’s important to understand how relevant the pieces of evidence you collected in the past actually are.

In general, the strength or weakness of signals generated by experiments is determined by two major factors:

  1. The Degree of User Action Commitment: the degree of commitment a user experienced/articulated through your experiment. 
  2. The Proximity to User Action: the difference between anecdotal evidence and firsthand experiment data.

These two attributes can be combined into an Evidence-Validity Matrix. Most of the signals generated by typical product experiments fall into one of these four categories.

Make sure to pick experiment that helps you to collect strong, actionable signals, without getting lost in waiting for overly sophisticated experiment setups to be ready

Make sure to choose an experiment technique that helps you to collect strong, actionable signals, without getting lost in waiting for overly sophisticated experiment setups to be ready.

When it comes to selecting the actual experiment techniques to use for testing the most critical, yet unproven assumptions behind some of your ideas, you should always shoot for a holistic perspective.

But make sure to list the explicit assumptions that must be true about an idea first, before selecting an experiment technique. Too many teams jump straight into the one technique they always use right away.

Here, this differentiation can come in handy:

  • An assumption describes a thing that is accepted as true or as certain to happen, without proof.
  • An experiment, on the other hand, is the scientific procedure undertaken and needed to test an assumption.

Later in this guide, we will discuss techniques to help you structure your validation efforts to support choosing experiments that truly help you develop data-based confidence in an idea.

Refining Validated Ideas for Focused Delivery 🔗

As I mentioned in the beginning, Product Discovery is rarely a linear process. During or after the validation phase, it’s likely that you need to take a step back. Whether it’s “only” to pick new ideas to test from your ideation sessions, or whether you return to the initial research phase, it can be painful to go backward. But going backward is more important than moving forward just for the sake of it.

Let’s say you have arrived at a set of validated assumptions and ideas that are ready for a first iteration or MVP for a real product. The work doesn’t stop here. This phase of your Product Discovery process is crucial for turning your ambitions into results: It’s time to prepare and transition the ideas into Product Delivery.

Discovery work doesn’t stop after you run experiments to (in-)validate the assumptions behind a set of ideas. Product Discovery refinement is crucial for turning ambitions into results.

The concepts you used were probably pretty scrappy. In order to have something to show just in time for your latest experiment, you probably cut some corners and didn’t exactly follow your company’s style guide. And that’s absolutely fine. But in order to avoid unnecessary conflict during the implementation of your ideas, it’s now time to polish the concept.

Another challenge during the “final” phase of a Product Discovery is to slice a concept into a prioritized list of backlog items and think about potential releases. The overall vision for your product or feature idea will guide you along the way, but it shouldn’t prevent you from shipping earlier iterations to learn from your users. The days of building and releasing a complex concept in one monolithic effort are over.

All too often, our first releases or MVPs are just crappy versions of all the initially planned features, released just to hit an artificial deadline. Instead, I advocate for a reduced scope MVP, which doesn’t compromise on quality, but prioritizes the most valuable features.

The slicing of user stories should be a collaborative effort with the UX and engineering team members because the scope of user stories should be defined not only by a user perspective, but also by the needed technical implementation steps.

After all, the refinement phase should focus on the very next increments you should deliver as a team. Utilize the most pressing user problems as your priority guidelines, instead of personal opinions about favorite feature ideas.

Understanding the Problem and Solution Space
Using Product Discovery Techniques and Frameworks

Teams need to be aware of when to intentionally use which framework. In this chapter, I want to share techniques that work well across the entire Product Discovery process and help teams execute with clarity and confidence.


Your Main Takeaways From This Chapter:

  • Using proven techniques and frameworks to structure the navigation of the problem space and solution space
  • Connecting user insights to actionable Outcomes using Actor-Jobs-Outcome-Mapping.
Tim Herbig Product Discovery Main Guide Chapter 3 Image

The Mission Briefing 🔗

The strategy consultant Stephen Bungay originally described a core alignment element called the Mission Briefing in his book The Art of Action. In it, Bungay shows how military leaders set up their subordinates for success in the field—without narrowing their choice of options.

Strategically, these leaders couldn’t micromanage their teams in the field; instead, they had to enable them to perform at their very best when their leaders were not present.

Bungay’s concept has been adopted and refined by many product organizations, but here’s a practical iteration, which I adapted slightly for Product Teams. Overall, Bungay’s version of the Mission Briefing can be summarized into three directives:

  1. Limit top-down direction to defining and communicating the intent.
  2. Give individuals 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.

The Mission Briefing consists of five parts and unfolds its true impact on alignment when co-created by the entire team:

  • The Context
  • The Higher Intent
  • The Team Intent
  • The Key Implied Tasks
  • The Boundaries

At the start, the key is to describe the current situation from an internal and external perspective without going into interpretations or solutions. Stick to the facts. Then, close the section with the kicker, describing the problem with the current situation.

To set the context, the key is to describe the current situation from an internal and external perspective without going into interpretations or solutions.

I recommend working through the Mission Briefing together section by section. It’s important to align on every section before moving on to the next one. Choices made in one section can have a dramatic impact on the other ones.

Impact Mapping 🔗

Impact Mapping is one of the most effective techniques to help Product Teams make sense of all the evidence collected and then trade-off decisions. Over the years, I’ve iterated the framework popularized by Gojko Adzic in 2012 to specifically support Product Discovery activities and outcome-thinking.

At its core, my version of Impact Mapping consists of five levels:

Impact Mapping Framework 2021 Tim Herbig adapted version

Impact Mapping helps Product Teams connect Features and Activities to overarching business goals, using user behaviors as more leading proxies.

Each of these levels is associated with one of the main elements a Product Team needs to work through during Product Discovery. This makes it easier to structure the activities of teams navigating through the problem and solution space.

I’ve seen 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 (like increasing revenue or user activity) into pursuing solutions.
  3. Facilitating tactical decisions without losing sight of the big picture of how an individual solution contributes to higher goals.

The beauty of Impact Mapping is that its levels are not just an abstract representation of an imaginary process. Instead, most of what Product Teams work through during Product Discovery finds its place on an Impact Map.

In my Adaptable Product Discovery Course, I introduce Impact Mapping as a companion guide for Product Teams to navigate through the problem space.

An Impact Map can also act as a very effective input to the OKR definition of Product Teams, as it beautifully condenses insights and connects activities (or the lack thereof) to high-level company priorities. Here’s a comprehensive overview of how Impact Mapping connects to and differentiates from some other popular product frameworks.

Deep Dive: Using Impact Mapping to
Navigate Product Discovery

Impact Mapping Product Discovery Article Header Image

Product Discovery is rarely linear, let alone foreseeable. There’s also no one-size-fits-all approach to doing it “perfectly.” As a result, Product Teams need to have high confidence in their Adaptability to pick from and execute a broad range of techniques.

The Idea Validation Grid 🔗

As mentioned earlier, the detailed work of planning and setting up experiments requires its own structure and place.

And just as with research techniques, it doesn’t make sense to jump straight to the very best validation technique your CPO has heard of. Instead, you want to build the case for why a given technique is right for the questions around an idea you’re facing.

This is not just helpful for having a clear argument when discussing your resources, but it ensures high-quality discussions with other domain experts in your company about picking the right experiment.

In order to do that, we need five key ingredients to create a more detailed view of our experiment design:

  1. A high-level description of the generated idea
  2. Some kind of objectified decision-making criteria like an ICE score we can use to express an idea’s priority and our changing confidence in it
  3. Listing and prioritizing the assumptions about an idea (meaning, we articulate which behaviors or results the idea would need to meet in order to ultimately succeed).
  4. Tying this idea back to the change in behavior we ultimately want to drive
  5. The experiment we chose to validate our assumptions, in regard to the user Outcome we want to drive, as well as any results and conclusions in the form of the next steps.

Though you are, of course, welcome to find your own format for structuring these ingredients, I have found a simple structure in the form of an Idea Validation Grid to work quite well for the teams and individuals I am working with:

Idea Validation Grid Setup Example

Structuring the testing process of Product Discovery ideas is essential for Product Teams to establish and communicate data-based confidence.

One of the key differences between the Idea Validation Grid and some other frameworks I have seen and used is a focus on the idea and the value it seeks to create, instead of an experiment focus. As mentioned earlier, we’re not validating just for the sake of doing it. We’re validating to challenge our confidence in driving user and business value through an idea.

Actor-Job-Outcome-Mapping 🔗

During our research, we get exposed to direct insights into our user’s behavior.

We hear about feature quests, and, when we do our job, we get to understand problems and underlying motivations. But though all of these are valuable insights, there’s extra work we need to do to make them actionable.

We hear about feature quests, and, when we do our job, we get to understand problems and underlying motivations. But though all of these are valuable insights, there’s extra work we need to do to make them actionable.

This is the act of interpreting the insights. And that’s precisely how we land at articulating the changes in behavior we seek to create in the form of Outcomes. Outcomes serve as the measurable proxies we can use to determine whether we have achieved both solving a real user problem and contributing to overarching business priorities.

As I mentioned before, the experiences and problems of your users won’t unfold in a linear way. So, though the components of synthesizing insights are based on a jobs-oriented approach, you might not have all the insights at hand right away. And so a different mapping of these components can help you understand the insights you do have as well as the gaps you have left to fill.

In addition to being aware of the core components (Actor, Context, Motivation, Problem, and Outcome), it’s important to understand where to place the insights you already have and how they connect.

An effective way to communicate synthesized insights and specific Outcomes that are worth focusing on, is the Actor-Job-Outcome-Mapping:

Actor-Job-Outcome-Mapping Framework Example

Connecting the Dots From Research Insights to Actionable Outcomes Worth Changing and Focusing on Through Actor-Job-Outcome-Mapping

Maybe you are aware of the particular Motivations and Problems an Actor experiences in a given situation. But what about other Problems that prevent the Actor from achieving the same Motivation?

Or are there entirely new Motivations that you have overlooked during your first attempt to dig deeper into their experiences of a specific Context?

Or maybe there’s an entirely different Context that didn’t get uncovered, but could be even more relevant for achieving your overarching Impact through this particular Actor.

Plus, there could be an entirely different string of insights and interpretations for one of the other relevant Actors, plotted on your Impact Map.

Though you might not always experience such a variety and one-to-many relationships among the different insights you collect, this way of mapping what you do know helps you to uncover what you don’t know—and, thereby, to determine how to change that with the most effective technique.

Applying Better Practices for the Reality of
Product Discovery as a Cross-Functional Product Team

Product Discovery needs to work for your team in your company and in the context of your industry. That’s why this chapter wraps things up with a focus on individual starting points and pointing out misleading “better practices.“


Your Main Takeaways From This Chapter:

  • Why interview and experiment cadence don’t tell you much about your actual progress as a team
  • How to take the first steps toward a Discovery approach that works for YOU.
Tim Herbig Product Discovery Main Guide Chapter 4 Image

The concepts and examples from this guide are aimed at giving you an idea of how to get started with Product Discovery using practical examples and a broad range of options. But your real work environment might not always be ideal—and that’s ok.

In fact, the main idea behind this guide is to help you to make progress in YOUR environment and ADAPT what you’re learning to your everyday life.

The worst thing you can do is say, “If I can’t do X, Y, or Z at exactly the right time, the whole thing is thrown off, so forget it.” ANY changes will result in a more effective Product Discovery and better products that drive customer behaviors and business results. It’s not an all-or-nothing proposition.

You Don’t Need to Talk to Customers EVERY Week 🔗

There are a couple of practices out there that get repeated so often that Product Teams adopt them without question. I think the term “invisible scripts” applies here in particular. One of them is the idea of having to talk to one user every week.

There’s nothing wrong per se with continued user interactions (in whatever form). But forcing a given cadence upon your Product Team can lead to many unintended consequences.

There’s nothing wrong per se with continued user interactions (in whatever form). But forcing a given cadence upon your Product Team can lead to many unintended consequences.

The idea of talking to one user every week is a great catchy prompt for companies that want or need to shift their overall attitude toward more customer-centricity, as opposed to self-convicted decisions. But for the practical reality of working through the problem space of Product Discovery, you might want to reconsider.

When you’re exposed to the problems of one user per week, it can be tempting to jump on what you have just heard immediately. But just because a user problem exists does not mean that you need to solve it. If you’re (too) focused on squeezing that customer interview in week after week, the chances are that you stop talking to the right users. 

What do I mean by that? You should focus your research efforts on those user segments that are relevant to your overarching strategic goals. Though every user problem represents some kind of opportunity, the big question is whether it’s the right one for you to work on right now.

Just because a user problem exists does not mean that you need to solve it.

At some point, you need to commit and move forward with a solution. Most likely, talking to users isn’t an appropriate vehicle for gaining confidence. Instead, you want to utilize quantitative techniques.

And, depending on your stakeholder and team environment, continuously incoming qualitative insights from those weekly user interviews might not actually be helpful. Instead, it could lead to questioning your choices over and over again, just because you learned something new that the latest iteration of your solution didn’t consider yet.

Again, this is not about the advice to continuously seek interactions with your customers. But blindly following a given cadence also won’t guarantee “success” in Product Discovery and doesn’t always give you the insights you need in order to make progress.

Testing in Product Discovery Needs to be Insights-Focused, not Experiment-Focused 🔗

“How does more successful Product Discovery look in your company?” is a question that I always bring up whenever I start working with a team, department, or company.

The response to that question helps me further understand where an organization stands regarding genuinely separating the problem from the solution and whether the WHY behind Product Discovery is focused on P&L improvements or on a long-term belief in a fundamentally different way of working.

A typical response to that question is “The teams should run more experiments.” Which, by itself, doesn’t sound that bad. But when you unpack the downsides behind that statement, it becomes apparent that this is the same kind of activity, just packaged differently.

Deep Dive: How to Make Product Discovery Adaptable

5 Core Ideas of Adaptable Product Discovery Header Graphic

Learn the principles and strategies that go into effective Product Discovery processes. And more importantly, discover how to use the Adaptable Product Discovery approach to make the processes work for your company and reality—right away and step by step.

When teams want to embrace Product Discovery, it’s often due to the fatigue of being in the hamster wheel of building more features (that nobody needs and that don’t contribute to business goals). But the number of experiments conducted front and center only swaps out user stories with <insert experiment technique here>. The number of experiments conducted tells you that a team worked on tasks other than “building.” But it doesn’t tell you much about whether the team chose the proper experiment techniques for the challenge, executed them in a way that generated valuable insights, and even if they (in-)validated assumptions around the most promising idea.

The number of experiments conducted tells you that a team worked on tasks other than “building.” But it doesn’t tell you much about whether the team chose the proper experiment techniques for the challenge, executed them in a way that generated valuable insights, and even if they (in-)validated assumptions around the most promising idea.

Though there’s an argument that every experiment (if set up correctly) generates some kind of insight and COULD help the team succeed, this often feels like sandbagging. 

Takeaway: Prioritize Better Practices for Your Context Over Best Practices From Others 🔗

In summary, though the choice and quality of your Discovery activities are crucial, the quantity rarely is. Remember that the goal is to collect strong pieces of evidence that help you make evidence-based decisions about  whether a problem is worth solving, and a solution is worth pursuing—it’s not about ticking off boxes from someone else’s playbook.

>