Making Sense of Product Discovery: Two Playbooks Anyone Can Use

The room was packed. Erin, the Product Manager, had called for an emergency meeting. The product they had just launched wasn’t meeting expectations. Erin stated with a determined voice: “We need to do more Discovery”. The room went quiet.

With confused looks, the team glanced at each other: “What does she really mean?”. “What does she mean by ‘Discovery?’”.

Perhaps this scenario resonates with you. A situation where the term “Discovery” is used, but it’s difficult to discern what it actually entails.

To be fair, the term Product Discovery is ambiguous.

My intention with this article is to try to demystify what Product Discovery is and to give you two Playbooks you can use.

But before we jump into the Playbooks, let’s first spend some time getting to know Product Discovery.

What is Product Discovery?

For simplicity’s sake, in Product Development, you have two engines running at the same time: Discovery & Delivery.

To paraphrase the don himself, Marty Cagan:

Discovery is about building the right product

Delivery is about building the product right

Meaning: Discovery are the steps you take together with your team to mitigate the risk of being wrong: to build a product that customers want, meets your business goals and is technically feasible.

Delivery, on the other hand, is about realizing the product with all the rigor that goes into development.

Discovery is an evolution of many different tools and methods

Discovery is an amalgamation of practices that have been around for ages, such as Agile, Lean Startup, Customer Development, User Experience Design, Business Model Generation, Jobs-to-be-Done and many others. All of these different methods have one thing in common: to de-risk building the wrong product. However, they have their different takes and nuances in doing so.

Discovery in your team should be the “best of the best” – a toolbox of the most suitable tools

Photo by Hal Gatewood on Unsplash

The analogy I use for Product Discovery is that it’s like a toolbox. There are many tools in a toolbox: hammers, screwdrivers, drills, etc. Sometimes you need a hammer, but other scenarios require a screwdriver. You wouldn’t use these tools at the same time, they have a specific use case.

During my years as a UX Designer, working in various design leadership positions and recently as a Product Discovery Coach, I’ve tried a plethora of tools relating to Product Discovery. My realization is that there are clear pros and cons to each one.

Two Playbooks

When I coach organizations, I typically stumble on two main problems:

1. The organization works with Product Discovery, but it either takes too long or the solutions defined in Discovery never get into the customers’ hands
2. The organization hasn’t worked with Product Discovery at scale. Teams have done smaller Discovery initiatives but what’s ultimately being premiered is the Delivery backlog

The ambition with these Playbooks is to create simplicity and enable anyone in a team to use the tools, regardless of role. 

But what is a Playbook?

The word Playbook comes from American Football. It’s essentially a book that the Football Coach uses to inform the team about different tactics to use during the game. I like the term because out on the field there are tactics, but you can never fully plan what’s going to happen. In Product Discovery, you can’t plan all the details up-front because Product Discovery is about learning. You might need to re-adjust as you progress. 

Photo by Dave Adamson on Unsplash

Known vs. Unknown

Product Development, plainly speaking, is about solving problems. Problems can have a varying degree of complexity. Sometimes, problems are quite straightforward to solve. Other problems might need a lot of digging to find out what the best solution could be.

For example, you have received an issue from customer service that customers can’t find a certain piece of functionality – which is causing frustration. With that information, you already have insights around the problem and you have a clear signal of what the solution could be. 

Another example could be that you have seen a drastic decrease in engagement from a particular customer segment. In order to solve the problem, you need to uncover the underlying issues and to find the root cause. This means that you have to do quite a lot of research. 

The first example is of a “known problem” and the other is of an “unknown problem”. One is tactical in nature, the other one is strategic. Hence, why there are two Playbooks; Known and Unknown.

Let’s start with the Known Playbook.

Known

Hypothesis > Design Studio > Prototyping > User Test > Team Pitch

Hypothesis

As the example above highlighted, known problems are quite tangible in nature, meaning you already have a hunch of what a potential solution could be. Therefore, the first step is to formulate a hypothesis.

Below is a structure for hypotheses that I’ve used with clients. 

We believe customers have a problem with [problem statement]. If we provide [solution], we will see [desired outcome]. 

Here’s an example.

We believe customers have a problem with understanding the pricing of our product. If we provide a clear overview and comparison of our different pricing options, we will see an increase in conversion. 

This should, by no means, be a rigid structure that you should follow verbatim. What’s important is that your hypothesis features:

• The problem you want to solve
• A high-level solution statement
• An intended outcome

Design Studio

After you’ve established a hypothesis together with your team, you can start to ideate a detailed solution(s). The Design Studio method is widely used within Agile and my colleague Yassal Sundman has written an excellent overview of the method. 

The essence is that you quickly sketch rough solutions, present and iterate on your ideas. 

Prototyping

Following the Design Studio, you’ve identified concepts that you need to further explore. Depending on the nature of the solution, you can either prototype in code or use a prototyping tool such as InVision or Figma. The idea is that you want to create something tangible that you can test on users.

User test

Since you’ve prototyped solution(s), you can now test on real users. If you don’t have someone within your team who has experience in user testing, I urge you to just give it a try. There are tons of resources online regarding best practices in user testing. I also recommend the book Rocket Surgery Made Easy.

Team pitch

The last step of the Playbook is to share what you have achieved: the insights you have gathered and the prototype(s). I recommend teams to invite a larger group of colleagues/stakeholders in order to have a wider spread of your learnings and to have the opportunity to receive valuable feedback. 

Unknown

Research questions > Research > Design Sprint > Team Pitch

When it comes to Unknown problems, there is more research required since the problem is more complex. Hence, why the Playbook starts with research questions.

Research questions

The simplest way of gathering important research questions is to invite the team to a 1-hour workshop. The steps of the workshop:

1. Everyone writes down the research questions they have about the subject on post-its
2. You create an Affinity Map of the post-its, meaning you cluster them in different categories
3. You dot-vote on the most important research questions to tackle
4. You’re done

Research

At the end of the workshop, you have clarity on what to focus on. I recommend that you use at least three sources to gather research data, for instance, analytics data, customer interviews, and customer service. If you have at least three sources, you will be able to triangulate and validate the data from different perspectives, meaning that you will be more certain around your insights. 

I won’t go into detail on how you can conduct research since there are so many useful books/blog posts on the subject. On customer interviews, I highly recommend Steve Portigal’s book Interviewing Users. 

Design Sprint

After you have gathered insights, it’s time to create tangible solutions. I’ve used the Design Sprint method for many years to align teams on the right concepts to build. The main benefits of running a Design Sprint are:

• You focus. You have one week to ideate, create prototypes and to test solutions on users
• It’s cross-functional in nature. You invite people from diverse perspectives
• You have all the tools at your disposal. The Sprint book is super-handy and gives you minute-by-minute schedules of each day

Team pitch

As a finale, just like the Known Playbook, you invite your team to review what you have accomplished. 

Final pieces of advice

There you have ‘em. Two Playbooks that you can use in your team to create more rigor in your Product Discovery efforts. From experience, to be even more successful with Product Discovery, I also recommend doing the following:

• Visualize: Try to visualize in either a Kanban or a Scrum board of what you’re working on, both in Discovery and Delivery
• Time-box: Time-box your Discovery initiatives and have a clear outcome in mind
• Work cross-functionally: Have a team that has the customers’, the business’ and the technical perspectives in mind

Best of luck in your Product Discovery efforts!

If you’re in Stockholm on December 9-10, please join Jens Wedin and I. We’re running a two-day course on Product Discovery where we’ll dig deep in the world of Product Discovery.