Nailing a Product Discovery is an ambitious task for every product manager. Here‘s hands-on advice for approaching it.
When the roadmaps for the year ahead get crafted, you should place the themes you and your team want to tackle in a rough order. Most often, the topics result from the epics you've worked on before, your Product Strategy, user feedback or, e.g. Objectives and Key Results (OKR) for your department.
So it’s mostly pretty 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 most significant 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. Which exact phases, tools, frameworks, and participants are needed depends on many individual aspects like the maturity of your product, which stakeholder environment you're operating in, which resources you have at hand, etc.
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. On a high level, I recommend to cycle through the steps of Alignment, Research, and Validation as you move along.
If want to learn how to put the theories of this article into practice, check-out my upcoming Product Discovery Online Training Course. In it, we'll walk through the critical techniques needed to succeed with your Product Discovery and practice them in an interactive learning group.
In a nutshell, product discovery is about ensuring that the right product gets built for the right audience. It's the foundation for a successful implementation and launch phase later on and should give you the confidence to represent your product vision towards your team, your stakeholders, and the upper management.
A product discovery is about ensuring that the right product gets built for the right audience. It's the foundation for a successful implementation and launch phase later on and should give you the confidence to represent your product vision towards your team, your stakeholders, and the upper management.
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. But it's important to understand that you rarely have the luxury to only work in a discovery mode.
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.
However, there's no fixed period or clear order of steps which can be assigned to determine what a Product Discovery exactly is. If you're working through customer feedback, prototyping and experiments in a structured way without building a final solution, chances are high that you're amid a Product Discovery.
You’ll quickly notice that, as soon as you discuss your upcoming roadmap topic with anybody, a lot of people will have a strong opinion about the 'right' solution and what your users want. Particularly at the beginning of product discovery, you need to stay focused on the problem and avoid falling in love with a solution. The opposite would be to eventually build someone else's product with which you cannot identify over time and for which you don't want to stand in.
So, it's pretty significant to nail it down the right way. Most often, the problem to crack is not even the hardest part here, but orchestrating the available resources in a given period is.
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. One tactic to achieve that is something like Team-wide customer exposure hours. Teams who spend at least 2 hours per person every 6 weeks “exposed” to customers (e.g., taking support calls, talking to users, watching people in a store, etc) developed more successful products (according to Jared Spool and confirmed by my own experiences/observations).
In my 2018 talk at the growth marketing SUMMIT, I shared hands-on advice on how you can make customer-centricity not just a hobby of one PM but part of your company's DNA. This is the foundation for continuous Product Discovery.
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.
Teresa Torres perfectly captured what Continuous Product Discovery is all about:
Weekly touch points with customers, by the team building the product, where they conduct small research activities, in pursuit of a desired product outcome.
Both approaches - treating a Product Discovery as a dedicated effort and Continuous Discovery are legitimate depending on the environment you're working in. I will discuss the specific pitfalls of continuous Product Discovery in my upcoming Product Discovery Online Training Course.
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 actual code, the belief to integrate your whole team in a Product Discovery has grown as we have moved to more true cross- functional collaboration over the past years.
Again, Teresa Torres has a valuable advice here:
Engineers bring skills to the discovery process that other members of the product team may not have. This is why it’s so valuable to have them participate—even if they’d rather be writing code.
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.
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 Owner 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.
I like to set up a "typical" Product Discovery phase to take six weeks and focus on the best effort possible to produce tangible results within that. This is meant to be a point of orientation for less mature organizations which haven't adopted a mindset of Continuous Product Discovery. The segmentation into certain phases also makes sense for structuring your thoughts and actions during continuous discovery efforts.
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.
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:
Alignment - Clarifying the most important cornerstones of the project like what the context is, how it ts into the overall strategy, how to measure success or what not to do.
Research & User Problems - Either starting to understand your users or updating the existing knowledge on them. This phase typically includes the gathering and interpretation of qualitative and quantitative data.
Ideation - Based on what you've found out about your user's needs, it's time to think big for coming up with lots of creative solutions to pursue.
Creation - Ideas are worth nothing if you can't turn them into tangible products or features. This phase typically involves lots of prototyping with all the tools you have (like paper, fancy interactive prototyping tools or areas in your existing product).
Validation - To validate your solutions, you sometimes need to get very creative. You might be able to "simply" test your prototype through qualitative interviews. But maybe you also need to work with a Concierge or Wizard of Oz Test like faking your product's capabilities through manually curated e-mails.
Refinement - While it's fun to cycle through different variations of your prototype, you need to put things into order for the transition into delivery. This typically means incorporating the latest user feedback changes, slicing down the concept and maybe even starting to plan the first set of releases.
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.
Starting out, it can sometimes feel a bit overwhelming deciding on which of the many rough ideas out there you want to dedicate time, money and people's attention to.
For initial guiding, you should turn towards your Product Strategy. I won't go into any detail about creating a Product Strategy, but want you to focus on 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.
One level lower, you should look towards your theme-based roadmap for guiding. 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:
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 your short list for Product Discovery opportunities.
Product Discovery is about reducing uncertainty and increase the confidence to invest resources in building a product. This is why frameworks like Effort-Impact-Scoring fall short, because you don't know much about the actual solution yet.
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.
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).
The key for you as a Product Manager is to determine where the urge of some stakeholders to be a regular part of the day-to-day product development process originates. You have to reverse engineer your stakeholder's feature requests back to 'jobs' they want you to fulfill for them or your target user. The most likely reason though is that they think that the product output becomes proportionally better with their involvement.
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.
A better way for stakeholders could be, e.g., to drop in inspiring snapshots, they've seen in other products with the apparent accompaniment that the way this product approached an individual problem may be helpful for your work.
Why do Stakeholders always come up with Feature Requests? Because they’re like users - They don’t know what they want.
Influencing the roadmap solely with specific feature requests is their way to remain involved in product development continuously — an incredible challenge for product managers within the domain of stakeholder management.
Why do they want to stay involved? Because they’re not convinced that the results will match their expectations. You haven't earned their trust (yet), and they may also have a hard time giving up micro-level control over 'their' product.
It’s your responsibility as a Product Manager to reverse engineer their feature requests using alignment tools to get to the bottom to what they want. Only then you can come up with better solutions than they can imagine.
So, the next time you're frustrated with the way stakeholders articulate their need, remind yourself to treat them like your users.
Develop empathy for them, get to the bottom of their actual problems and deploy ideation and creative techniques against those problems to come up with better products.
I know, in an ideal world, we'd all be on the same page already. But on the bright side, you can count on an educational effect on your stakeholder's minds as a byproduct of problem-centered product development.
But be sure that this is your responsibility. The worst you could do would to just built those specific feature requests.
Mission Briefing - The strategy consultant Stephen Bungay originally described a
core alignment element called the mission briefing in his book The Art of Action. In it, Bungay shows how military leaders set up their subordinates for success in the 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. It has five parts and unfolds its true impact on alignment when co-created by the entire team.
Overall, Bungay’s mission briefing can be summarized into three directives:
Objectives and Key Results (OKR) - In short, OKR combine the best aspects of goal setting into one framework: A highly-inspiring qualitative vision and concise and measurable metrics to determine success or failure. An Objective is like a mission statement, only for a shorter period of time. A great Objective inspires the team, is hard (but not impossible) to do in a set time frame, and can be done by the person or people who have set it, independently.
Amazon Press Release/'Working backwards' - While there's no official material on this framework, it's widely confirmed and well-known in the product manager community. It's the result of Jeff Bezos' approach to cut subjectivity and fluff of product development. The result is a document which shouldn't exceed a page and a half in length which needs to be provided to meeting participants before, e.g., a kick-off meeting for tackling a new product.
Never used it in 'production' but will do shortly.
When I talk about the importance of alignment and the several frameworks to create it, I often hear questions regarding what those are for and what the goal of the invitee/creator should be when walking critical stakeholders through an alignment process.
When I then explain that, at the very end, it's all about getting commitment/buy-in, a typical response is something like that: "Ok, so, I need to convince everybody to agree with my point of view." And this way of thinking often leads to the initial rejection of an alignment process, because people then don't see any chance at all, to get individual stakeholders to agree with them on the process ahead.
That's why I wanted to use underline the importance of not confusing alignment with an agreement. 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.
I stole a beautiful phrase from this shareholder letter Amazon CEO Jeff Bezos just recently published: disagree and commit.
Third, use the phrase “disagree and commit.” This phrase will save a lot of time. If you have conviction on a particular direction even though there’s no consensus, it’s helpful to say, “Look, I know we disagree on this but will you gamble with me on it? Disagree and commit?” By the time you’re at this point, no one can know the answer for sure, and you’ll probably get a quick yes. This isn’t one way. If you’re the boss, you should do this too. I disagree and commit all the time.
We recently greenlit a particular Amazon Studios original. I told the team my view: debatable whether it would be interesting enough, complicated to produce, the business terms aren’t that good, and we have lots of other opportunities. They had a completely different opinion and wanted to go ahead. I wrote back right away with “I disagree and commit and hope it becomes the most watched thing we’ve ever made.” Consider how much slower this decision cycle would have been if the team had actually had to convince me rather than simply get my commitment.
This example perfectly outlines the position a manager should take when working together with an empowered team: 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.
So, coming back to the difference between aiming for agreement and commitment in an alignment process, a proper comparison is also to take bets, close the process and back them 100% compared to endless rounds of discussions to get harmonizing everybody's opinions for the sake of it.
If you're facing the latter one frequently during internal discussions, it's also a very fundamental cultural issue within your company. Focus on consent instead of embracing conflicting opinions.
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.
"Talking to users shouldn't feel like completing a task but like exercising a habit."
A convenient way to capture and structure continuously incoming customer feedback is to use a tool like EnjoyHQ or Receptive. It hooks into your feedback channels and helps you to turn it into a structured database. This way, you can quickly assess the qualitative data you already have, before starting any new research efforts.
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.
On the highest level, two categories of research exist.
Qualitative research is direct – as you observe how people interact with your experiment, you collect data about behavior. Insights based on this data can help to understand what matters, but even more importantly why it matters.
The richness of qualitative data can sometimes be overwhelming, and it is essential but challenging to keep neutral when forming insights. Quantitative research is often easy to interpret; its indirect nature (you measure a clipping of reality that you chose to represent rich behavior) makes it harder to create an experiment that will provide the right kind of data. Quantitative results tell you for how many users something matters, or how much.
Behavior: You observe what people do.
Attitude: You listen to or read what people say. You are asking people to tell you how they interact – which they will to some degree get wrong. Be aware! What people say and what they do can be completely different. Along the lines of this differentiation, most of the famous (and not so famous) frameworks can be categorized.
Which path and therefore framework to pursue and use depends on the questions you want to see answered. In a low-traffic environment (like b2b enterprise), quantitative data mostly doesn't tell you much. Instead, you have to double down on qualitative insights.
In b2c environments, there's often-times plenty of data to look into. But don't mistake numbers with a context. You need to accommodate them with qualitative user feedback to understand the whole picture.
Impact Mapping helps you to structure feedback and map out specific solutions. You can use it to sanity check ideas and make sure they influence the right product or the KPIs the company needs to focus on.
It's probably my favorite tool in this phase of a Product Discovery, as it's a constant companion for your ongoing efforts and also a great way to document learnings.
To help you get started with your own impact map, I created a free impact mapping .pdf template for you which is ready to use right away.
During my various consulting projects, I used Impact Mapping to point out mismatches in specific features or product ideas, things which were not aligned with the overall company goal.
The top is usually comfortable. Then, one level down, the ‘who’ is also easy for a lot of people. One level down from that, you need to talk to users and do qualitative and quantitative research to lay out the behavior changes you want to implement. Then, at the very bottom, you can list specific features and ideas.
So, while it makes sense to start using Impact Mapping in the user research phase of your discovery, you can use it all the time until it's time for the transition into delivery.
Here's a rough mapping of the impact map levels to your Product Discovery phases:
You can see that the heavy lifting of working your way through an impact map is done in the second half of your Product Discovery. So, make sure to document your findings on an ongoing basis to get through the levels one-by-one.
Just because you somehow involve users into your operations, doesn't mean you're doing it right. And while you can and have to divide user testing into its separate domains (research, deep interviewing, usability testing), I want to point out three widespread misconceptions which I stumble upon in early discussions and which are easy for you to avoid.
Focus Groups are "better" than 1:1 interviews - Nope, they're not. Focus groups are one of the worst ways to get feedback on your product or getting to real user struggles (right behind building assumptions just on your behavior). When it comes to pointing out the failures of a product, people are herd animals. They'll follow the most common opinion in the room and will be too embarrassed to be the first ones acknowledging a mistake or aw.
Only personal situations and a comfy and trustworthy environment will bring you closer to see the real behavior of people and hear about their real struggles.
If you want to have the room full of like-minded customers of yours as part of your product creation process, I instead recommend the format of Co-Creation Sessions.
We'll just ask users what they want - While I can’t stand the iPhone comparison when it comes to user research (‘Steve Jobs never asked anybody, whether someone wants an iPhone), there’s a certain point in it: Users are not able to articulate the right solution to their problems. This is why you are a tasked with building products which serve their needs. But to get there, you have to entirely focus on issues and not potential solutions, when talking to users before even sketching the first wireframe. But to get there, you have to solely focus on problems and not possible solutions, when talking to users before even drawing the first wireframe. Don’t ask them what they want (also if it itches you to shout this question at them after they’ve neglected 6 of your fancy prototypes) and instead focus on what makes them happy or grumpy.
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.
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.
How might We... - HMW statements are a great way to reframe challenges to encourage more liberal thinking about solutions. It helps the participants to think about approaches to solve the problem and supports not getting caught up with the negative aspect of it. When starting, it can feel different to strike the right balance between framing them too narrow or too broad. But once you've figured it out, you don't want to go back.
Crazy 8 - This method encourages people to rapidly fire ideas from the top of their head instead of overthinking them. Everybody gets an A4 sheet of paper and folds it 3-times until you have eight small boxes. Then, during a time-boxed 8-minute slot, everybody has to draw sketches into every box. The idea is to generate as many ideas as possible within a short timeframe, focusing on quantity of views, not quality, and then once you’ve got a bunch of divergent thinking on one topic, to begin converging on some winning ideas by voting on the favorites.
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.
This shortened list of ideas should inform your next steps. As you have very little evidence on how every idea will perform right now, it's important to treat more granular scoring and ranking as a constantly evolving act. I recommend the ICE score for achieving just that:
ICE stands for:
Each of these criteria is graded from 1–10 and the average presented as the ICE score.
It's important to keep in mind that this is not a carefully researched prioritization of business models, but a starting point for your following prototyping and validation efforts. The goal is to prevent you from being bogged down in trying to fine-tune the score too much. Think of the ICE Score as a minimum viable prioritization framework. It’s not objectively perfect but it’s good enough to get the job done.
The ICE score of an idea should update as you move forward. Especially the Confidence score should change as you run your experiments and the data points informing it should be weighted accordingly. Confidence based on gut feeling and talking to a colleague is a lot less valuable than first hand user feedback.
Dot voting and the ICE score serve different purposes. Dot voting helps you to make pragmatic decisions about e.g. design elements or specific action items. The ICE score on the other hand is aimed at high level prioritization of bigger ideas, whose score evolve over time as your learning continues. Think of it as tactical prioritization (dot voting) compared to strategic prioritization (ICE score).
Of course, there are more ways to prioritize ideas. You can also score them based on the individual factors of your business (internal dependencies, cost, etc.). But eventually, you will arrive at the same results.
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.
There's a variety of prototyping tools available right now, so I want to share a set of them which can help you for multiple challenges when trying to simulate experiences.
Pen and Paper - Especially in a workshop or group collaboration scenario, the best prototyping tool is the one which is accessible to most users. This is why sometimes the right combination of pen and paper can prove valuable for low-level prototyping. Especially in conjunction with a tool like Marvel (see below), it helps you to recognize the most basic shortcomings of your concepts pretty quickly. And in combination with pre-defined templates like this one or full-fletched kits like this one, "creating" a mobile app on paper becomes easy for everyone. Learn more about Paper Prototyping
Sketch + InVision - While Sketch is primarily known for its UI design capabilities, I find the tool to be quite accessible even for non-designers to create basic wireframes. But especially in combination with InVision, it's easy to produce some seriously stunning prototypes. What makes this combination stand-out is the native design part combined with a web-based collaboration/commenting approach. Secret pro tip: Even though prototypes aim at answering why users, e.g. click a button, combining InVision prototypes with Maze enables you also to capture quantitative data from prototypes.
Figma - The main benefit of Figma is how accessible it is and thereby enables easy collaboration on prototypes across the entire team. My favorite scenario is adding copy to a prototype. Instead of passing on copy ideas to the designer, only to recognize that it breaks the layout, product managers and marketers can make changes themselves. Combined with built-in prototyping, it's one of my favorite go-to solutions. Learn more about Figma in this tutorial video from AJ&Smart:
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.
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:
Let's take a look at how to avoid these.
While you most likely already defined some hypotheses earlier on as simple statements, it's now time to formalize them as it’s sometimes difficult to find the right format for executing against them. The reason for that is that you're now much more explicit about the desired results you want to see from your experiments. You know more about your user problems, and you have a set of solutions which are tangible in the form of prototypes.
I love using the Lean UX Hypothesis Template originally created by Jeff Gothelf and Josh Seiden for this. It provides enough guidance for crafting the hypothesis and helps you to set up your experiments and success metrics. You can grab a free .pdf template for using it right here:
The hypothesis itself should be stated following the structure of what you want to build for whom and to achieve what kind of impact. A simple example would be:
We believe creating a prominent “add contact” opportunity in the news stream for freshly registered users will achieve an increase of 10% WAU within this segment.
Afterward, you have to define which qualitative or quantitative experiments will help you to validate this hypothesis. Ideally, you can come up with a test which doesn’t involve your development team. For our example from above, one experiment could be sending out contact recommendation e-mails even earlier than initially planned to check whether the action of triggering more contact adds support our hypothesis. But we will talk more about suitable experiment formats in a second.
Then, we have to set a time constraint for our experiment(s) to run and define the target outcome at which we would consider the hypothesis to be validated. Like:
30% Click Rate on provided contact recommendations and 50% of recipients become a WAU within 30 days.
By now, you hopefully worked your way through the impact map we introduced earlier. As I mentioned, the levels of the impact map can be loosely mapped with the phases of your discovery for better orientation. So, in this phase of your experiment, it's about running experiments to validate the potential solutions you gathered at the bottom of your impact map.
The prioritization of your ideas through the ICE score now determines the order of your experiments. We're running experiments instead of going ahead and building our solution ideas to increase our confidence that the ideas we had are actually valuable to our users and have a chance to significantly impact our goals.
To structure our experiments, we now combine the Impact Map with the Experiment Grid.
The Experiment Grid has some overlap with the Lean UX Hypothesis template, but is better suited for our needs at this stages, as it not only focusses on the current experiment, but also the ones following.
Filling the Assumptions and Hypotheses part of the Experiment Grid should be quite easy. These thoughts have been part of our Ideation and Creation phases already. If not, it's now time to think about it. Where it gets more tricky is which experiment technique you're going to pick not to validate the hypothesis.
Just as there are qualitative and quantitative techniques to do user research, there also qualitative and quantitative experiments. And, depending on the underlying mechanic of your idea, you need to chose wisely.
If you're looking to answer the question if people actually want your product or which design works better, you need to turn to quantitative validation techniques. However, if your primary concern is the usability of your idea and why people would prefer/reject it, qualitative techniques might be right.
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 styleguide. 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. The goal here is not to put the responsibility of "approving" designs into the hands of a particular team member. Instead, it's about making sure the various perspectives (e.g. business and tech) have a chance of articulating ideas, concerns or inspiration.
A great format for facilitating this phase is a design critique.
The word 'critique' could lead to the impression that this is a format which is focussed on criticizing the designs or, even worse, the designer through from intentional negative perspective. But when you conduct a design critique according to its original purpose, it is a positive event that should feel good for all parties involved.
"A design critique usually manifests as a group conversation with the ultimate goal of improving a design. It does not mean simply judging a design."
According to the Nielsen Norman Group, an effective Design Critique is centered around three themes:
They also summarized their recommendations for facilitating the process in this neat little cheat sheet:
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. 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.
"An MVP is about building the most critical value proposition (meaning feature) to prove your product idea's potential first and shipping it in the best possible quality to your target users. It is not about building slimmed down or extremely compromised versions of all your feature ideas and bringing those to market."
User Story Mapping helps to establish a perspective on your product along the activities and needs of your users, instead of the visual design. 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 Mural or 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 our idea of sending a weekly highlight e-mail to players of a game:
My upcoming Product Discovery Online Training Course walks you through the step-by-step process of transitioning your Product Discovery insights into tangible and actionable backlog items.
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.