This is my complete guide to Product Discovery in 2020.
In this all-new guide you’ll learn:
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.
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):
When roadmaps for the year ahead get 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 (OKR) for your team.
By then, it's mostly clear what to work on from a high-level perspective. But as a Product Manager you might wonder which problem exactly 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. See it as an inspiration to structure your thinking and pick 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.
In this Chapter I want to introduce the basic concept of Product Discovery and answer some of the fundamental questions around when to do it and who should participate.
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.
Product Discovery Definition
Product Discovery describes the iterative process of reducing uncertainty around a problem or idea to make sure that the right product gets built for the right audience. Product Discovery offers Product Teams higher confidence in their path forward. It is also the foundation for a successful implementation and launch phase later on.
Typically, Product Teams are either working 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 focussed on executing a matching solution.
While working in both spaces is necessary to satisfy your 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.
If you look at the "typical" phases of a Product Discovery, it quickly becomes clear that both spaces have their place throughout the process. Roughly speaking, you could map the phases like this:
But make no mistake. Just because there might be more phases dedicated to iterating through solution ideas that doesn't mean that's where you should spend most of your time.
Alignment and Research are focussed on prioritizing, defining, and understanding the problem space. It's the necessary groundwork before you can move forward into the solution space. The visualization is not a representation of the "required" time for those areas.
"40% of our 100 units are spent before we’ve even started designing anything. We obsess about problem prioritisation and problem definition. I mean obsess. I drive our people crazy sometimes interrogating whether we really truly deeply understand the problem we’re attempting to solve. It is highly encouraged for our PMs to openly share and debate early definitions of the problems we’re defining."
So, while 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.
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 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.
The short answer is: It depends. The even more concise answer is: Always.
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 user's needs.
Most product managers face a scenario called Dual-Track Agile. This means that you have to simultaneously apply Agile principles like cross-functional collaboration between Product, Design, and Engineering, user-centered thinking, and iterative improvements to the discovery and delivery track of your product.
Often, Dual-Track Agile is visualized as two parallel running streams. Based on my own experience and the teams I've worked with, this looks nice, but is detached from reality. Instead, the activities of Delivery and Discovery (need to) have an 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 both 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. While a Product Team should ideally start working on a new Product Discovery mission together, some team members will be more occupied with it than others.
It's ok to temporarily focus more on Delivery or Discovery at a given time. But make sure that a Product Team has the skills and freedom to work on both aspects on their own time.
"Product Discovery and Product Delivery should be owned by the same team to increase the intrinsic motivation to execute and reduce knowledge silos."
Of course, there might be specific projects which 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.
The more uncertainty you have about which solution your business goals need to bring to the table, the more attention you need to devote to Product Discovery. But 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 non-linear. Product Teams need to adopt it as a habit.
While 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.
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.
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 a valuable participant in an ideation session depends on the way you typically involve this department.
Make sure to be clear about who needs to be directly involved from the beginning. This way, you can block time in their calendars for synchronous sessions early on and avoid being stuck.
Ultimately, the number of people you need to keep in the loop during your discovery depends on the size of your company. But it's useful to differentiate between the actual (value-producing) core team, key stakeholders (owning the budget), and certain individuals who hold mission-critical assets. You should always be clear about the participation of each group, such as Product, Design, or Engineering. Nobody should expect equal involvement in every phase.
There are two main benefits to involving team members across domains during Product Discovery:
Product Discovery is by no means an isolated activity. Even though most companies only add it gradually to the list of requirements of product teams, Product Strategy and Product Roadmaps are closely related.
Without going into too much detail about Product Strategy, I want to outline the cornerstone questions every (good) Product Strategy should be built on:
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.
When teams lack a starting point for Product Discovery, it's often due to the lack of strategic context. But Product Teams shouldn't blame it on their manager or the C-level if this context is lacking. Instead, I encourage them to create clarity about their strategic direction themselves. By utilizing collaborative frameworks like the Product Field, you can outline the strategic direction of your product and identify blind spots pretty easily.
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.
The way you handle roadmaps and plan "the work" directly influences the freedom and autonomy you have for Product Discovery. When you have the resources to understand the problem space, but your roadmap says you have to deliver the new start page feed on March 31st, you're not doing Product Discovery. Instead, you're polishing an existing idea.
Sadly, most businesses still rely on time-based roadmaps following a Gantt chart style visualization for planning product development up to 12 months into the future. While this approach may have worked for the static waterfall planning we used to do 'back in the days,' it's hardly suited for agile and iterative methods, which embrace uncertainty instead of trying to fight it with deadlines.
A more fitting approach for planning your efforts is based on so-called theme-based roadmaps. They enable you to prioritize broader initiatives, rather than fixed feature sets and acknowledge increasing uncertainty the further you look into the future.
You can also compare themes as the parent element of specific epics. A “theme” is defined as a more significant user or business problem you want to solve to reach your goals.
A typical theme-based roadmap can be broken down into three categories:
NOW - What you are currently working on.
NEXT - What you will work on soon.
LATER - What you’d like to work on in the future, but need to do a bit more research before you move on.
Examples of themes include 'User Growth', 'Revenue', 'Churn', or 'Enterprise'. Corresponding epics could then be 'Referral Mechanism', 'Free Trial' or 'Single Sign On'.
The themes collected in the NEXT column can act as a parking lot for your next Product Discovery opportunities.
In this Chapter, I will outline some of the most important phases teams should cycle through during Product Discovery,.ranging from creating shared context to breaking-down validated concepts into user stories.
While every Product Discovery starts at a different stage, I find the mental model below helpful. The segmentation into certain phases also makes sense for structuring your thoughts and actions during continuous discovery efforts.
It's important to understand that you won't just walk through these phases one after another towards a pot of gold at the end of the rainbow. You might get stuck during one stage and have 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.
Generating and keeping product management aligned across all levels of an organization—from C-level to the single engineer—is one of the most important (and often most challenging) tasks for a Product Manager. It is essential to create clarity about your Product Discovery right from the beginning.
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 (ie. solutions and not problems).
While some of them may have learned and agreed with the concept of building an MVP first, they insist on storing product/feature/ideas in the backlog. Here's why that's not an approach to pursue.
Unfortunately, this misconception is the result of a lack of trust: these stakeholders don’t believe that the output your team delivers 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.
Creating alignment is more than just sending an email. It also doesn't necessarily mean that you have 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.
Every effort around identifying a new product opportunity should start with the why. And while there's pretty much always also a business need to justify discovery efforts, the success of your product ultimately depends on whether it can solve your user's problems. So, start by understanding the struggles of your (desired) users.
While I'm not a fan of building up a research backlog, 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 Receptive.
Whether you're looking for a way to improve an existing product which 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.
In general, there are four categories of research:
Depending on which research question you're trying to answer, you want to look at research techniques from one or the other quadrant. And while it can be tempting to get too excited after your first quantitative or qualitative research effort, product teams need to keep in mind that only the combination of multiple research efforts reveals the "truth".
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.
Here's what, Colette Kolenda, the lead User Researcher for the project, had to say about their setup and choice of methods:
"This discrepancy [between what people were saying and what they were doing] was discovered because we were passing learnings between teammates: from Data Science with the A/B test to User Research with the user interviews. This is the typical way of working together, but in reality, the two disciplines were not truly collaborating. Although we used complementary methods in this project, they yielded contradictory insights.
We needed to take collaboration to the next level, to simultaneously triangulate User Research and Data Science by pointing different methodologies at the same group of listeners at the same time."
This complexity of (actual) research efforts is what informs my own belief that Product Teams need to invest in their own Product Discovery Toolbox. Only by knowing about a broad range of techniques, can they know where to look for the right technique for the right problem.
An effective way to tie together research insights is a framework called Impact Mapping, which I have used and refined over the years. We will discuss it in more detail in the Product Discovery Techniques chapter.
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 problem with typical brainstorming approaches for thinking about solutions is that people are lazy and tend to stick with what they know. When people only collaborate synchronously on finding new ideas, group dynamics kick in.
As soon as an "ok" idea is raised, everybody agrees and suggests to roll with it. Thinking about different (and maybe better) ways to solve a problem gets shut down. That's why I encourage teams to embrace a "together alone" working mode when running workshops. By giving individuals the time to think clearly, group discussion will mirror an holistic perspective from everybody involved.
This is why the primary goal of the best ideation exercises is to get people out of their comfort zone and thinking big(ger). Reality will catch up soon enough, but let's reach for the stars at this stage of the 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 and continuous Product Discovery is to involve the entire team in the process, it shouldn't be the CEO stepping into the room and pointing to the idea she or he likes 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. For that, affinity mapping or clustering ideas is perfect. Encourage the participants to locate similar or identical ideas next to each other. Every cluster should get a name or description. You can get goofy here as well and use fun names.
Then, it's time to vote. The most fun (and familiar) way to do that is to dot vote. By using round stickers or simply handing out colorful markers, every participant can vote on the clusters he or she thinks are the best in terms of solving the framed challenge. To decide how to distribute the votes, divide the number of available clusters by two. So, if there are ten clusters to vote on, every participant has five votes.
What about all the ideas which 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 on 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 and instead focus on moving forward with the ones you have selected.
Putting sticky notes full of ideas into the hands of your users probably won't help you to understand their reaction to it. This is why you need to find a pragmatic way to turn your most promising ideas into somewhat real prototypes.
While prototyping tools are the "shiny objects" of Product Discovery, you should keep in mind that you don't have 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 how to test the idea of a personality assessment test. You could prototype the experience by merely connecting several tools and create a slim version of the product manually in the background (more on that later in this guide). 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 pre-defined 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.
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.
Just like most actions in an agile environment, the process of building a prototype should consist of constant converging and diverging. The cross-functional discovery team gets together to discuss the next steps, separates to execute the tasks, and comes back together to review progress, learnings, and potential adoptions.
Don't expect your prototype to nail it in the first attempt. Allow for it to grow and develop over time.
There's a simple reason why you need to prove hypotheses and ideas before starting to deploy your team.This is due to a shift in how resources within companies (of every size) are allocated.
The old way of thinking about resource allocation: "This sounds like a great feature idea to spend time, people, and money on!"
The new way of thinking about it: "Where’s the proof that this is a good opportunity to spend time, people, and money on?"
So while you have spent time and money on the efforts of this Product Discovery, now's the time to check if you have been running into the right direction. Everything up until this point was "only" the ramp-up. And while your discovery efforts are iterative and continuous anyway, entering the validation stage always carries extra weight.
Here are the four most common validation mistakes:
In my talk at Productized 2017, I outlined validation approaches product teams can utilize during this Product Discovery phase:
There are quite a few similarities between the research phase in Product Discovery and the validation phase. During both phases, teams need to clarify the core questions they seek to answer, before picking a validation method from their toolbox. For example, do you want to observe people (quantitative and behavioral) or hear from them (qualitative and attitudinal)?
Just as with research, it's important to validate an idea from as many angles as possible. A pragmatic way of structuring your thinking around validation is the Validation Field, a technique we will discuss in the following chapters in more detail. It encourages you to not jump straight into A/B test setup, right after ideation.
Instead, it's important to differentiate between Validation and Experiments.
Validation is about increasing the confidence in your ideas so you can ultimately build or discard them. By using Impact Mapping as a lens, the goal is to further narrow down our Impact Map items on the WHAT level.
While it can feel daunting to validate without a high amount of traffic or tons of engaged users, I encourage teams to focus on the validation signals they have at hand. If your environment doesn't allow for high-traffic experiments, run with the tests you can create instead of dwelling on the ones you can't.
But when communicating the results, make sure to be transparent about the signal strength of an insight. The two main dimensions to consider here are how close the experiment was to the user and how serious the users had to get.
As I mentioned in the beginning, Product Discovery is rarely a linear process. During or after the validation phase, it's likely that you have 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 it's more important than moving forward 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.
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.
Just like the other parts of your discovery, the polishing phase shouldn't happen in an ivory tower. Sure, the product designer on the team can now get into the nitty-gritty of perfecting layouts and animations, but it should still be a collaborative effort. This should happen in a facilitated way. A Design Critique is a proven format for navigating through this phase.
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.
An effective way to tackle your backlog creation is User Story Mapping. User Story Mapping helps to establish the activities and needs of your users, in contrast to the visual design.
All too often, our first releases or MVPs are just shitty versions of all the initially planned features, 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 not only be defined 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. Use the most pressing user problems as your priority guidelines, instead of personal opinions about favorite feature ideas.
With clarity around the most important phases of Product Discovery, it's important to understand how teams can build the individual approach that works for them. Instead of thinking in linear blueprints, the main goal is to create a flexible system that is built for non-linearity. In the next chapter we’ll cover specific techniques for that and how to customize them using the Adaptable Product Discovery Approach.
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:
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% accurate prediction but about a shared understanding within your team and company of 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.
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.
As mentioned earlier, the majority of Product Discovery should be spent trying to understand the problem space. While it might be tempting to jump straight into ideation sessions discussing specific ideas, it’s important to take your time to create clarity about the problem you're trying to solve.
While 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 time-box to set up the team for a "best effort" mission. As a starting point, six weeks have proven to work quite well. Why six weeks?
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 a 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.
Don’t be scared of moving the milestones you’ve set if you have to and if you can provide convincing arguments. Your initial estimation was based on the situation as you knew it back then. If the situation has changed in the meantime, it’s more than fair to communicate this change to your key stakeholders—as long as you do it early on and are transparent about the implications.
When it comes to planning the first Product Discovery activities, neither team members nor stakeholders should expect a date-driven Gantt-chart. Furthermore, teams should focus on those activities they already know they want to tackle, and make sure to schedule those in advance.
Treating Alignment, Research, and Ideation as collaborative activities means inviting stakeholders and fellow team members with enough lead time to ensure participation. So, while the details of those meetings might still need to be defined, having them blocked in calendars lays a solid foundation. Even with an in-house research team at your disposal, it often takes at least 1-2 weeks to have interview participants available after the briefing of whom to recruit.
In order to avoid getting stuck between research sessions, I recommend scheduling them out ahead. You will always find a way to utilize a research session. But don’t sacrifice the quality of your insights by swapping properly recruited participants with random people waiting in-line at Starbucks.
Another scheduling block that is often forgotten is the time it takes for quantitative experiments to generate significant results. By significant I mean results that prove that the actions are not just the result of random behavior.
So, even if you have the traffic to utilize quantitative validation, allow time in your schedule for results to come in.
As mentioned above, it's important to treat this six-week period only as a starting point. Teams shouldn't be incentivized to check off a list of activities within this period. Instead, plan for regular check-ins with management and stakeholders to discuss and evaluate insights. This way, you're creating transparency and clarity about the actual progress of Product Discovery, which should not be measured by the number of completed activities, but by the number of insights revealed and decisions made.
A Product Discovery check-in shouldn't be another slide-heavy executive meeting. Instead, use the work-in-progress documentation on your (on-site or virtual) war room to give everyone an update on where you stand and to prepare for decision-making. A great way to facilitate a Product Discovery check-in visually is Impact Mapping, which will be discussed later.
Treating Product Discovery as an ongoing/continuous/recurring process instead of a one-off effort at the beginning of the year is important to establish the habit of being customer-centric as a Product Team.
However, there are risks to continuously digging through data for new insights, trying to get in touch with users every week, and running experiments too often (in relation to your traffic/capacities). Here are a couple of negative patterns I see teams make during continuous Product Discovery efforts (and which I have been guilty of myself):
Regular (e.g., weekly) customer interactions are great for shaping the team and creating a company culture that’s user-first. However, talking to users in the wrong cadence can lead to iterative and small step thinking. Incremental improvements of a well-established product or feature can be useful, but when you want and need to think big(ger), investing time upfront is important. Try to resist the fear of missing out (FOMO) on"new insights" when you leave out one or two opportunities to talk to customers. Instead, focus on setting the stage.
Getting distracted by every new bit of insight can lead to a lack of decision-making and focussing on shipping what has already been validated. I'd argue that if you a) don't have a pressing research question you need to get answered right now or b) don't have the operational capacity to act (concept, validate, or build) on new insights within the foreseeable future (four weeks max) running user research poses a threat to your execution (especially if the insight is based on a single user).
If you're not clear about how discovery efforts fit into the overall strategy of your product or company, you're wasting your time. When you feel like it's time to jump on the next Product Discovery S-curve, instead invest time in clarifying the overall strategic fit of an initiative before stabbing around in the dark.
Experimentation is an essential activity in Product Discovery as it helps you to collect evidence for making decisions, but it doesn't make sense to chase quantitative experiments if you don't have the numbers. N=1 is rarely a viable foundation for deriving conclusions and making product decisions. An a/b test with an audience of 100 will never give you statistically significant results. Focus on the most effective validation to build the product/feature. Be honest and transparent with yourself (and the team) about how compelling some insights are.
In order to optimize every Product Discovery phase, teams need to be aware of when to 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. I’ll conclude by introducing Adaptable Product Discovery, which shows you how to customize these techniques to your own context and practices.
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 micro-manage 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 managers. Overall, Bungay’s version of the mission briefing can be summarized into three directives:
The Mission Briefing consists of five parts and unfolds its true impact on alignment when co-created by the entire team:
Here's an example of what an exemplary "Context" section could look like. Let's assume we're building an Analytics platform called "Analytico" that wants to align around the problem space in which most of our customers also use JIRA for their work.
The key is to describe the current situation from an internal and external perspective without going into interpretations or solutions, as shown on the sticky notes above. Stick to the facts. Then, close the section with the kicker, describing the problem with the current situation.
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 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 originally developed 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:
Every 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:
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.
I prefer to document evidence and team insights in an Impact Map built in Miro. Below, you can find my proven Impact Mapping template for structuring Product Discovery efforts.
"I don't know why the adoption rate is so low amongst our users. No one from the target audience had any problems using the prototype in the lab."
Does that sound familiar? I hope not. If it does, this section's for you.
When we talk about building and validating products, we ask a broad range of questions. Can we build it? Can people use it? Do people want it? The problem here is that qualitative validation (like testing a prototype in the lab) only tells you one part of the story. And while it's worth arguing that telling 50% of a story is better than not saying a word, you have to put it into the right context.
This is why, in a perfect world, you should look at the idea you seek to validate from as many angles as possible.
To support this kind of thinking, I love to teach (and apply) the Validation Grid as a neat way to encourage fast-forward thinking during validation, without losing sight of your goals.
Which aspect of your idea is this experiment validating? What do its results tell you about the next experiment you should run? Should you repeat the usability test with a different objective? Or maybe, it's now time for a smoke test?
The Validation Grid is a holistic take on structuring idea validation, incorporating results, and collecting insights throughout Product Discovery. It's about challenging teams to think about certain questions in advance when setting up validation efforts: Which aspect of your idea is this experiment validating? What do its results tell you about the next experiment you should run? Should you repeat the usability test with a different objective? Or maybe, it's now time for a smoke test?
The core principles are to align around the underlying assumptions of an idea, determine what ultimate success would look like for this idea (user outcomes), decide which experiments would help to falsify/validate those assumptions, and continue working with experiment results.
A User Story Map consists of three primary levels: The user activities, the user tasks, and the user stories that enable the user to perform these tasks.
User stories should be listed according to their importance for the user to complete the task. So, if the user task is to monitor the dashboard, the user stories on top should contain the individual widgets and not necessarily the account settings (which are part of a different user task).
The slicing of user stories should be a collaborative effort with the UX and engineering team members because the split of user stories will depend on both the user perspective and the needed technical implementation steps.
User Story Mapping is also an excellent stakeholder management tool to visualize the progress of your delivery work later on. While the detailed organization of your user stories probably takes place in a tool like JIRA, marking the status "done" or "wip" in a User Story Map is a lightweight alternative to status reports, especially when combined with a tool like Miro, which makes your User Story Map publicly accessible all the time.
Here's an example of what a User Story Map could look like for an imaginary breakdown of building a WhatsApp-like product from scratch:
If you aren’t sure how these techniques (and others) will work in your real-world context, I’ve developed the Adaptable Product Discovery Approach that will guide you through your specific problem space, based on your industry, your team’s skills and processes, and the problem you’re trying to solve.
Adaptable Product Discovery allows you to:
I’ve created a 9-module online course to help you put these into practice. Learn more
Remote work affects many of the (agile) ways teams work. So in this chapter, I wanted to share the four most critical Product Discovery habits teams need to adopt when working remotely.
It’s dangerous for co-located teams to make implicit assumptions about where a team wants to go and where it stands on the Product Discovery journey. But for distributed work, tacit assumptions are even more harmful than for co-located teams.
Don't confuse shared information with real understanding.You have written down the context or critical problem behind a Product Discovery in a Google Doc, but that doesn't mean everybody is actually on board. Instead, invest in synchronous meetings with team members and stakeholders to walk everyone through your narrative and discuss it.
Bonus points if you make this a collaborative exercise and use visual facilitation tools to outline the problem space.
In my experience, it's way easier to get away with an improvised ideation session when everyone is in the same room. In a remote scenario, that will not end well (trust me). Instead, invest the time up front in picking a moderator (or take on the role yourself) and prepare the workspace.Plan for virtual icebreakers, explain tools, and walk through exercise outcomes. After all, teams might have to work on their own in a Zoom Breakout Room during specific exercises.
There are a ton of great templates out there for that—so, don't try to reinvent the wheel. But meeting preparation and facilitation become 200% more important for remote sessions, especially when you involve non-product stakeholders.
There's certainly no shortage of tools you can deploy for remote Product Discovery activities. But that's also one of the most significant risks—having your user insights, experiment results, and ideas scattered across numerous tools and file servers. I always like to create one central hub as early as possible.
I prefer to use my Product Discovery template in Miro and link or embed all related documents there. The beauty here is that you can embed entire prototypes, .pdf presentations, and video recordings from user interviews, then run the ideation sessions from there, and maintain continuous Impact Maps to tie everything together.
This hub should also serve as the starting point for Product Discovery check-ins and can be a great visual tool to onboard new team members or to walk stakeholders through your status quo.
While it can be tempting to map out a user journey super quickly using sticky notes at home, try to resist it. Effective remote Product Discovery is based on communication and collaboration at eye-level. No one should have an advantage due to their location. If you're the only one who has a visual representation of the user journey at home (despite the blurry picture you uploaded in Slack), that creates a misbalance.
Ideally, you want your team to be as invested in Product Discovery activities as you are. That means creating new artifacts and document insights in a place where everyone can access and edit those equally.
While it might be ok to scribble ideas or insights on paper during an interview, make sure to transfer those into an editable digital format as soon as possible. If you're proudly pointing to the customer journey map you created earlier during a video call, team members will soon zone out if it seems to be 'your' thing.
Here are some additional resources which have either inspired my own Product Discovery work over the years or are great deep dives into some specific parts of Product Discovery.