A step-by-step guide for conducting better product discovery

Coding features is hard and expensive. Yet many teams learn they’ve made a false assumption about what users really need once their new feature goes live – only to go underutilized. Well, life is too short for that. And any business that operates in such a way won’t be around for long.

Fortunately, there’s a better way.

The standard process for prioritizing what the delivery team works on looks like this:

What if we invested more in researching and validating ideas upfront before we ever sent them to delivery?

We call this second track “product discovery” and it complements and precedes product delivery.

Here’s how the legendary Marty Cagan describes it:

“First, you need to discover whether there are real users out there that want this product… Second, you need to discover a product solution to this problem that is usable, useful, and feasible.”

In short, product discovery is a process that helps product teams refine their ideas by deeply understanding real user problems and then landing on the best way to solve them. At Productboard, we are big proponents of this approach and will walk through the product discovery process we follow in the steps below.

The product discovery process is about building the right products and features for your customers

There is always uncertainty when it comes to making product decisions. We conduct product discovery because we want to reduce the risks around what we decide to build. Sacrificing discovery usually leads to a disconnect between user needs and the products that are built. 

Marty Cagan identifies four big risks in product management:

1. Value risk (whether customers will buy it or users will choose to use it)
2. Usability risk (whether users can figure out how to use it)
3. Feasibility risk (whether our engineers can build what we need with the time, skills, and technology we have)
4. Business viability risk (whether this solution also works for the various aspects of our business)

Essentially, conducting product discovery mitigates these risks and ensures that we are building the right products for users. It helps your team laser-focus on the problems and needs of users and sets them up to obtain deep user insights through continuous learning. 

It’s important to note that the goal of product discovery is not necessarily to ship features. Rather, it’s to promote an environment of learning that will help you improve your product incrementally and consistently.

The goal of product discovery is not necessarily to ship features. Rather, it’s to promote an environment of learning that will help you improve your product incrementally and consistently.

A step-by-step guide for conducting product discovery

Productboard uses the Double Diamond approach for conducting product discovery, structured as follows:

• Uncover the underlying user need
  • Understand
  • Define
• Identify the optimal solution
  • Ideate
  • Prototype
  • Test

Let’s break down each piece step-by-step.

Uncover the underlying user need

The product discovery process starts with identifying broad challenges that you are trying to solve with your product. This is the time for your product team to take a look at the big picture — high-level objectives or themes — not at specifics.

In Productboard’s case, a challenge could look like the following:

How can we enable mid-market companies to better use Productboard?

Defining the right types of challenges is sometimes tricky. There are new product challenges, where you work on an open-ended blank slate. There are value and need-oriented challenges, which revolve around the current needs and pain points of your users. Then there are growth vs. technical challenges. Growth challenges are usually quantitative — maybe you are trying to improve a metric within your product, like user retention. Technical challenges are often related to product performance. 

During the challenge identification stage, you understand and define what you are trying to solve. 

Understand

To correctly identify challenges, you must understand the underlying user needs you want to solve with your product. At this stage, product teams rely heavily on quantitative and qualitative research to find answers. Some useful tools and techniques to use include user research, focus groups, observation, customer interviews, data analytics, competitive research, empathy mapping, and more.

Define

After you understand the user needs you are trying to address, you must then clearly define them. There are a few steps to take to do this:

• Nail down the problem: Aim to nail down one sentence that covers the entire problem you are trying to solve. This helps you communicate clearly to your team and aligns them around a common cause. If you formulate the problem loosely, it will be difficult to keep everyone focused.
• Validate the problem: Make sure that you are actually working on problems that need to be solved. How big is the pain that your users are experiencing? How much value will tackling the pain truly add? 
• Prioritize: Essentially, you must figure out which of the identified problems you should tackle first. There are several popular frameworks that are used by product teams to do this. At Productboard we favor value vs. complexity, but there are others, like the RICE method, ICE, and more.

To clearly define problems, many product teams employ journey mapping, dive into the Five Whys or other similar techniques, or conduct a SWOT analysis.

Identify the optimal solution

After you isolate specific user problems, it is best to reframe them into chunks that can be attainably solved.

For Productboard, the broad challenge listed above can be re-framed and narrowed down into the following:

Mid-market companies experience limitations with Productboard’s public Portal because they want to communicate with multiple audiences at once.

During the reframing stage, you ideate, prototype, and test potential solution ideas that you have prioritized with your team. All this is due diligence to validate products and features before they go into delivery.

Ideate

You ideate to figure out how you plan to solve your users’ problems. This is where your team can get really creative with innovation exercises and other ideation techniques like team brainstorming, mind mapping, storyboarding, and running design sprints.

After ideas are proposed, your team can gauge their potential impact and feasibility, then prioritize which to prototype and present to customers.

Prototype

Prototypes enable teams to demonstrate their ideas and bring them to life.

There are many different types of prototypes, including but not limited to sketches, mockups, clickable prototypes, MVPs, or even using competitive/similar products. 

The type of prototypes teams choose to build depends on what they are trying to learn, what needs to be tested, and what open questions they still have. 

Learn more about prototypes:

• Why every product manager should be able to prototype 
• 8 examples of prototypes to build for your MVP

Test

Testing determines whether or not the proposed solutions are actually capable of solving the problem. Popular tools and techniques here include A/B testing, customer interviews, user testing, distributing surveys, and product beta testing.

Present solutions

Nothing is built yet at the solution stage, but you are ready to present ideas to stakeholders and users. Note that solutions don’t necessarily equal features. 

Going back to the example from Productboard, here is a viable solution: 

Let’s enable customers to build multiple Portals so they can communicate with each of their audiences differently.

Getting to a solution can take numerous iterations. After all, the product team wants to be sure that they deliver the right thing to users. Presenting the solution to stakeholders (in Productboard’s case, product leadership, delivery teams, and cross-functional teams) will be crucial for earning buy-in and alignment. 

At this stage, it is likely you will move into delivery, though not with a finalized design. Your solution is still rough around the edges.

Helpful tip

Product teams should codify best practices for how solutions should be used so internal teams and customers can get the most out of them. 

Intercom has an excellent product principle when it comes to this: stay opinionated but flexible. You can build a solution and have an idea of the best way your customers can use it, but also build in flexibility so your customers can use it in the way that best suits their needs. 

Build excellence into your product discovery process

Here is a summary of how Productboard evolved through this product discovery process:

• Challenge: How can we enable mid-market companies to better use Productboard?
• Re-frame the problem: Mid-market companies experience limitations with Productboard’s public Portal because they want to share/validate their ideas with multiple audiences at once.
• Identify a viable solution: Let’s enable customers to build multiple Portals so they can share/validate their ideas with each of their audiences differently.

(In case you were wondering, you can now create multiple Product Portals in Productboard. Go check it out!) 

We wanted to share this framework because many product teams spend most of their time working on solutions rather than working on problems. And it makes sense. It is a tempting shortcut with far fewer steps involved. However, skipping the discovery process can lead to teams shipping the wrong things, resulting in products and features that miss the mark and go unused. 

By using this framework and following its steps, our team has built an environment of continuous learning that benefits both our teams and users, increased transparency into our entire product management process, and involved a diverse set of stakeholders. We hope you find as much value in it as we have. 

Download the essential guide to product discovery e-book

Looking to improve the way your product team conducts product discovery? Check out Productboard’s free new e-book: The product discovery playbook.

In it you’ll find information on all of the following:

• A step-by-step guide for conducting better product discovery
• How to measure the impact of product discovery
• Advice for tailoring product discovery to your organization
• How to build a continuous discovery practice in your organization

Get your free e-book