This is my complete guide to Product Discovery in 2020.
In this all-new guide you’ll learn:
So 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 the 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 the remaining questions for you as a Product Manager are 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 enters the stage.
The goal of this guide is to show you the extensive range a Product Discovery can have and how to set up and execute your own Product Discovery process. The most effective way to start the implementation of your own Product Discovery process is to focus on a set of Product Discovery techniques and habits you want to internalize.
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.
In this Chapter I want to introduce the basic concept of Product Discovery to you and answer some of the fundamental questions around when to do it and who should participate.
A 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). A product discovery can have many forms and structures, as we'll discuss later.
Product Discovery Definition
A 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. Based on a Product Discovery, a Product Team has higher confidence in their path forward. It is also the foundation for a successful implementation and launch phase later on.
If you look at the typical activities Product Teams are busy with, they're either working on the problem space or the solution space. Meaning, they're still trying to understand whether a problem exists for their users, customers or stakeholders or are focussed on executing a matching solution.
While working in both spaces is necessary to delight 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 of Product Discovery. Roughly speaking, you could map the phases like this:
But make no mistake. Just because there might me more phases dedicated to iterating through solution ideas, doesn't mean that 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 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 in regards to 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.
Of course, ultimately, you want to add value to your users so that they can succeed (faster, better, more comfortable, etc.). But this doesn't mean that you should be obsessed about discussing solutions in your Discovery.
Here's the quickest way to recognize if a team is doing Alibi-Discovery: They start their discovery mandate with ideation sessions. Alibi-Discovery, for those of you who are not familiar with it, describes the process of further fleshing out an existing (top-down) idea, which is already set to be next in line for the feature factory.
Realizing this shortcoming requires, of course, a proper understanding of what Product Discovery actually is about.
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 can not only make a difference for your company if it results in shipped features. Identifying the right problem space to explore and genuinely understanding it alone is already extremely valuable for any company out there.
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 often as possible to user feedback. Which ultimately leads to continuously leads to new insights in user's needs.
Most product managers face a scenario called Dual-Track Agile. This means that you have to apply Agile principles like cross-functional collaboration, user-centered thinking and improving iteratively for the discovery and delivery track of your product in parallel.
Often, Dual-Track Agile is visualized as two, in parallel running, streams. Based on my own experience and the teams I'm working 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 extend, 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 once a certain threshold of certainty has been passed, it's also important to focus on the effective execution of a validated idea.
This idea is part of my argument that companies should not split-up Discovery and Delivery responsibilities amongst teams. Instead, 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 and yourself 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 what a solution to achieve your business goals need to bring to the table, the more explicit you have to embark on a Product Discovery. But in general, I recommend changing your mindset from treating Product Discovery as a particular end clearly defined task. Product Teams need to adopt it as a habit.
While your development team is probably in a pretty fixed state, the range of people which matter during the different phases of your discovery is not.
And while it might be tempting to keep the developers on your team 'busy' with shipping code, more and more teams involve the entire team in a Product Discovery right from the beginning. Which is 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 temporarily will contribute and the general Supporters of the Mission.
The degree of which every 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 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 differentiating between the actual (value-producing) core team, key stakeholders (owning the budget) and certain individuals who hold mission-critical assets have proven to be quite useful.
You should always be clear about the prioritization of those group of colleagues. 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, the way Product Strategy and Product Roadmaps are handled are closely related.
Without going into too much detail about Product Strategy, I want to outline the main cornerstones every (good) Product Strategy should be built on:
I like to visualize the answer to these questions using the Product Field framework to have the (constantly evolving) pillars guiding Product Discovery efforts constantly 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 the existing 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 when navigating through the problem space of a discovery mission.
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.
The way you handle roadmaps and plan "the work" directly influences the freedom and autonomy you have for Product Discovery.
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 represents a more significant user or business problem you want to discover a solution (aka Epic) to reach your goals.
The three categories of a typical theme-based roadmap can be differentiated like that:
NOW - Stuff that you are currently working on.
NEXT - Stuff that’s coming up soon.
LATER - Stuff that you’d like to work on in the future, but need to do a bit more research before you move on.
Examples for a theme could be things like '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 represent the priority 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 activities. Ranging from creating shared context all the way to breaking-down validated concepts into user stories.
While every Product Discovery starts at a different stage, I found this mental model of working through the challenge of finding out what the right product is helpful. The segmentation into certain phases also makes sense for structuring your thoughts and actions during continuous discovery efforts.
But just because there are so many theoretical Product Discovery activities, doesn’t mean that you have to work through them in a linear way, step-by-step.
But you need to be prepared to bring answers or insights around those activities to the table.
Whether it’s referring to an existing set of OKR for alignment or using identified user problems to frame ideation. It’s not doing all those activities, but using them to inform your path forward.
While it's nice to see these phases lined-up so neatly you need to be aware of the messiness which awaits you "out in the wild."
It's important to understand that you won't just walk through these phases one-by-one towards a pot of gold at the end of the rainbow. You might get stuck during one stage and have to walk one or multiple steps back to pursue a different path - And that's ok. A Product Discovery is rarely a linear process.
Generating and keeping product management alignment across all levels of an organization - from C-level until the single engineer - is one of the most important (and often most challenging) for a Product Manager and is essential to create clarity about your Product Discovery right from the beginning.
And while often suggested a simple change of habits like 'talk more to each other' or 'keep a confluence page about what has been agreed' are right, they don't necessarily provide the right level of confidence to a Product Manager to strive at his mission.
Almost every product manager knows the situation: Some of your stakeholders just always come up with particular features (aka solutions and no problems) they want you to build into your product.
While some of them may have learned and agreed to the concept of building an MVP first and no stuffing the first product release with more functionality, they a least insist on storing them as they are in the product/feature/idea backlog (here's why that's not an approach to pursue).
Unfortunately, this misconception is the result of a lack of trust these stakeholders have that the delivered output by you and your development team matches their expectations. Why that may seem like a miserable situation, the best way to resolve this issue is to focus on alignment early on in the product discovery and the commitment to a particular outcome rather than feature idea.
Creating alignment is more than just sending an email. It also doesn't necessarily mean that you have to get everybody to agree. The way more critical part of alignment is commitment. And it's way easier to get the commitment from your stakeholders, then making them agree.
It's fair to have a different opinion in your mind and articulate it. But when your team of experts then chooses a different path to pursue anyway, you must have their back as if they'd follow your suggestion in the very same way.
An effective way to achieve this kind of alignment together is the Mission Briefing.
Every effort around identifying a new product opportunity should start with the why. And while there's pretty much always also a business need in place to justify discovery efforts, the success of your product ultimately depends on whether it can solve your user's problems. So, this is where you get started: Understanding the struggles of your (desired) users.
While I'm not a fan of building up a research backlog without clear intent behind research activities, 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 is about to build something which aims to serve an unsolved need, identifying what your users want and need is critical.
In general, four categories of research can be differentiated:
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 just a 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 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, they can make the right decisions of 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 discuss it in more detail in the Product Discovery Techniques chapter.
FREE Product Discovery Navigator Email Course
Learn how to approach the uncertainty of running a Product Discovery using Impact Mapping.
Once you have developed a basic understanding of which problem's 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. To not remain stuck with incremental features which 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 tend to stick with what they know and that they're lazy. 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 thereby maybe also better) ways to solve a problem doesn't seem to be an option. That's why I encourage teams to embrace a "together alone" working mode not just in workshops but also the majority of their workshops. By giving individuals the time to think clearly, the following group discussion mirrors 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 think big(ger). Reality will catch-up soon enough, but let's reach for the start at this stage of the Product Discovery.
Of course, with so many ideas being created throughout a lot of fun sessions, the question remains how to 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 on the idea she or he likes the most. So, you should try to democratize the process.
On the highest level, you first need to bring structure into 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. Then, every cluster should get a name or description. You can get goofy here as well and use fun names.
Afterward, 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.
A rough indicator, for how many votes everyone has to spare, divide the number of available clusters by two. So, if there are 10 clusters to vote on, every participant has five votes.
What about all the ideas which get lost in the process because nobody voted on 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 with 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 what I like to call "shiny objects" of a Product Discovery, you should keep in mind that you don't have to use them or shouldn't use them just for the sake of it. Instead, focus on the challenge of simulating an experience to validate your ideas in front of you. Remember that it's about prototyping an experience - Which isn't necessarily always defined through a UI.
One example could, e.g. be 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). So, let's take a look a this: 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 which 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 get 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, parts ways to execute the tasks and comes back along 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.
Ready to build your own Toolbox?
My Product Discovery Online Masterclass teaches you the tools and techniques it takes to navigate through Product Discovery with confidence and ease.
Enroll today for lifetime access to over 30 video lessons and more than 20 templates and cheat cheats.
There's a simple reason why you need to prove hypotheses and ideas before starting to deploy your team against it. And 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 based on what I think to spend time, people and money on!"
Compared to a 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: Validation. Everything up until this point was "only" the ramp-up. And while your discovery efforts are iterative and continuous anyways, entering the validation stage always carries a certain weight.
Here are the four most common validation mistakes I see people making trying to follow a validation process:
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.
The dimensions of validation tools are also, whether you want to observe people (quantitative and behavioral) or hear from them (qualitative and attidudinal).
And 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 the next best 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 to ultimately build or discard them. Continuing to utilize Impact Mapping as a lens for our efforts here, 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 nevertheless. If your environment doesn't allow for high-traffic experiments, run with the tests you can create instead of dwelling over the ones you can't.
But when communicating the results, make sure to be transparent about the signal strenght 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. At the latest 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 one of your ideation session, or back 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.
But once you have arrived at a set of validated assumptions and ideas ready to turn into a real product in the form of a first iteration or MVP, 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.
Chances are that the concepts you used were 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 party 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 (a topic we'll cover in the Product Discovery Techniques chapter) 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 based on the feedback from your users. The days of building and releasing a complex concept in one monolithic attempt are over.
An effective way to tackle your backlog creation is User Story Mapping. User Story Mapping helps to establish a perspective on your product along the activities and needs of your users, instead of the visual design.
All too often, our first releases or MVPs are just shitty versions of all initially planned features, just to hit an artificial deadline. Instead, I advocate for a reduced scope, which doesn't compromise on quality, but only the most valuable features.
The slicing of user stories should be a collaborative effort with the UX and engineering team members because the split 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. Using 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 their individual approach which works for them. Instead of thinking in linear blueprints, the main goal is to create a flexible system which is built for non-linearity.
Product Discovery is about reducing uncertainty and increase the confidence to invest resources in building a product. This is why frameworks like simple Effort-Impact-Scoring fall short, because you don't know what kind of solution you should rate.
So, for determining which solutions will remain in focus for your discovery and which ones maybe only need to be executed, I prefer a different grading:
By evaluating the uncertainty, you get a much clearer picture about which ideas you need to further explore during the Product Discovery. The area on the upper right included your next targets to evaluate also. Everything on the lower right should be looked at from a delivery capacity perspective.
Prioritizing opportunities maybe seems rough to you - and that's ok. This is not about a 100% accurate prediction but about a shared understanding within your team and company, 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 around understanding whether 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, 6 weeks have proven to work quite well. Why 6 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're committed to. Even when your project has more of an explorative character, you shouldn’t just go along without considering how much time is reasonably spent on each phase.
And you also shouldn’t feel bad to just set your best guess as a first estimate for timings. Don’t think of milestones as limitations, but instead use them as constraints which will give you as the Product Manager the best arguments for condensing the generated output into concrete deliverables. It’s also a good mechanic 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 could only have been 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 the impact of 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 the calendars lays a solid foundation.
Because 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 in-between research sessions, I recommend scheduling them out ahead. You will always find a way to utilize a research session. But you should not sacrifice the quality of your insights by swapping properly recruited participants with random people waiting in-line at Starbucks.
Another "waiting block" which is often-times forgotten is the time it takes for quantitative experiments to generate significant results. And by significant I mean results which prove that the number of actions is not just the result of random behavior.
So, even if you have the traffic to utilize quantitative validation, you should be clear about the implications in terms of having to wait a bit for results to come-in.
As mentioned above, it's important to treat this 6-week period only as the 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 in by the number of completed activities, but by the number of insights and decisions being 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 where you stand and to prepare decision-making. A great way to facilitate a Product Discovery Check-in visually, is, for example, Impact Mapping.
Treating Product Discovery as an ongoing/continuous/recurring "thing" instead of a one-off effort at the beginning of the year is important to establish the habit of acting customer-centric as a Product Team.
However, the act of continuously digging through data for "new" insights, trying to get in touch with users every week and running experiments at a too frequent rate (in relation to your traffic/capacities). There are a couple of patterns I see teams make during of 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 company culture of thinking user-first. However, talking to users in a cadence which doesn't match the ambition level of the impact you want and needs to make can lead to iterative and small step thinking. Incremental improvements of a well-established product or feature have their time, but when you want and need to think big(ger), investing time upfront is important. Try to resist the fear of missing out (FOMO) of hearing "new insights" when you leave out one or two opportunities to talk to customers to instead focus on setting the stage.
Getting distracted from every new bit of insight can lead to a lack of making decisions and focussing on shipping what has already been validated. Especially in environments where stakeholders have a volatile opinion, it can be distracting to reject new suggestions. 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 (4 weeks max.) running user research poses a threat to your execution (mainly if the insight is based on n=1).
Discovering without clear guidance. 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, rather invest time in clarifying the overall strategic fit of an initiative before stabbing around in the dark.
Know your capabilities for experimentation. N=1 is rarely a viable foundation for deriving conclusions and making product decisions. It also doesn't make sense to chase quantitative experiments if you don't have the numbers. An a/b test with an audience of 100 will never give you statistically significant results. Don't run past the point at which the most effective validation would mean to build the product/feature. Experimentation is an essential activity in a Product Discovery as it helps you to collect evidence for making decisions. But be honest and transparent with yourself (and the team) about how compelling some insights are. Of course, you can only make decisions based on the evidence you have. But you also have to frame it in a way that everybody *still* stands behind it when having the full context.
In order to truly achieve the main goal of every Product Discovery phase, teams need to be aware of when to use which framework. In this chapter, I want to share techniques which work well across the entire Product Discovery process and help teams to execute with clarity and confidence.
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 eld, without narrowing their choice of options.
Strategically, these leaders couldn’t micro-manage their teams in the eld; 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 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 how an exemplary "Context" section could look like. Let's assume we're building an Analytics platform called "Analytico" which wants to align around the problem space of most of our customers also using JIRA for their work.
The key is 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 what's the problem with the current situation.
I recommend to work through the Mission Briefing together section-by-section. It's important to align on every section, before moving on to the next one. The reason is, that choices made in one of the sections influences the other ones severely.
Impact Mapping is one of the most effective techniques to help Product Teams make sense of all the evidence collected and make trade-off decisions. Originally developed by Gojko Adzic in 2012, I've iterated the framework over the years to specifically support Product Discovery activities and outcome-thinking.
At its core, my version of Impact Mapping consists of 5 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 every activities of teams navigating through the problem and solution space.
Over the years, I've seen three main benefits of the Impact Map for teams:
The Impact Mapping Playbook
Get my favorite tactics to put Impact Mapping into practice in this FREE 13-page eBook.
In my trainings, I introduce Impact Mapping as a companion guide for Product Teams to navigate through the problem space. If you want to learn more about how that looks like, you can enroll in my FREE 6-day email course on how to put Impact Mapping into practice:
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 have to work through during Product Discovery, finds its place on an Impact Map.
When utilizing it in practice, 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 one's for you. When we talk about building and validating products, we talk about a broad range of aspects to consider. 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 to start talking at all, you have to put it into the right context.
This is why, in a perfect world, you're able to 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 touch with your goals.
Which aspect of your idea is this experiment validating? What do its results tell you about the next experiment you should run? Repeat the usability test with a different objective? Or maybe, it's now time for a smoke test?
It's a holistic take on structuring idea validation, incorporating results and insights collect throughout Product Discovery. It's not so much about the framework. It's more about challenging teams to think about a certain set of aspects when settings up validation efforts.
The core ideas are to align around the underlying assumptions of an idea, how ultimate success would look like for this idea (user outcomes), which experiments would help to falsify/validate the assumptions and how to continue working with experiment results.
A User Story Map consists of three primary levels: The user activities, the user tasks, and the needed user stories enabling the user to perform these tasks.
The list of user stories should be listed according to their priority 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 should not only be defined by a user perspective, but also by 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 make your User Story Map publicly accessible all the time.
Here's an example of how a User Story Map could look like for an imaginary breakdown of building a WhatsApp-like product from scratch:
Remote work affects many of the (agile) ways teams work. So in this chapter, I wanted to share the most critical Product Discovery Habits teams need to adopt when working remotely.
Implicit assumptions about where a team wants to go and where it stands on this journey are already dangerous for co-located teams. But for distributed work, tacit assumptions are even more harmful than for co-located teams. So, when you're looking to clarify the starting point for exploring a problem space, don't confuse shared information with real understanding.
Just because you have written down the context or critical problem behind a Product Discovery in a Google Doc, 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 for making this a collaborative exercise and using 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 upfront in picking a moderator (or take on the role yourself) and prepare the workspace.
That means planning for virtual icebreakers, tool explanations, and bulletproof explanations of 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 also want to 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.
My preferred way is 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, video recordings from user interviews, run the ideation sessions right in 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 post-it notes at home, try to resist it. Because effective remote Product Discovery is based on communication and collaboration on eye-level. Which also means (at least to me) that no one should have an advantage due to their "location."
So, when you're the only one having a visual representation of the user journey at home (despite the blurry picture you uploaded in Slack), it creates a misbalance.
Ideally, you want your team to be as much invested in Discovery activities like you are. That also means, to create 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 at the customer journey map you created earlier during a video call, team members will soon zone-out as it seems to be 'your' thing anyway.
Here are some additional resources which have either inspired my own Product Discovery work over the years or are great deep dive into some specific parts of Product Discovery.