Chapter 3

The product discovery process: a step-by-step guide

While every product manager has their own best practices and favorite techniques when it comes to product discovery, the process is always roughly the same. Let’s take a look at what each step involves one-by-one. We’ll include some tips on what to consider at each stage, and how to know when it’s time to move on.

The stages of the product discovery process might be named or split differently, but the overall framework follows a similar trajectory that product teams at most startups use. This makes the process of product discovery something worth internalizing, as it won’t change much from project to project. The time you spend on each stage might vary depending on your exact methodology or overall product strategy, but not the stages themselves.

Here’s the four stages of product discovery process:

  • Learn & understand
  • Define & decide
  • Ideate & prioritize
  • Prototype & test

If you’re new to product discovery, stage zero is understanding its principles and adopting them into your design thinking. To brush up on product discovery principles, check out the previous chapter of this guide.

Put an end to pain points

Identify user pain points, define solutions, and prioritize fixes for your product rapidly with Maze.

Stage 1: Learn & understand

When embarking on a new round of product discovery, your first job is to immerse yourself in the world of your user. The goal at this stage is to absorb as much information about your users’ needs and pain points as you can until clear patterns start to emerge.

Often the inspiration that kickstarts product discovery is a cool new product idea that you or someone in your team wants to delve into. But to really open your ears and understand things from your users’ perspective, it’s vital to enter this first stage with a completely neutral mindset—which means leaving your cool ideas to one side for now.

Instead, think about the broader problem (or group of problems) that your idea is aiming to solve, and use this to inform your user research. Nadine Krishnamurthy-Spencer, Product Manager at We Are With You, sees understanding your own assumptions as the very first stage of the process—before you even start speaking to your users.

You can usually find a few people in the team who have strong assumptions about how the product is going to end up. It’s good to identify these early so you can gather data to validate why you chose that path—or more often, why you didn’t!

Nadine Krishnamurthy-Spencer, Product Manager at We Are With You

Once you’re fully aware of your own assumptions about your product, it’s time to start user research. Typically this involves some combination of customer interviews, focus groups, and validating any user experience insights that arise with product analytics data (if you already have a product, at least).

Even if you’ve done a good job identifying your product assumptions, it’s important to keep checking that your user interviews stay unbiased. That means avoiding leading questions that hint at a solution you're already thinking of adding to your roadmap, which can be trickier than you think. For Nadine, this is the most vital part of the whole product discovery process:

Getting your user interview questions right is absolutely key. It’s surprisingly common to witness users being asked if X is a good idea, or if they would use Y or Z. Write down all your questions ahead of time and get someone else to challenge each one for neutrality.

Nadine Krishnamurthy-Spencer, Product Manager at We Are With You

This stage is also a good time to do some market research. Analyzing the competitive landscape is another great way to reveal new product opportunities. For more on this and other ideas for methods you can use, check out the next chapter on product discovery techniques.

Stage 2: Define & decide

After a while, patterns should start to emerge from your research. One or two problems will start to come up again and again in different user stories. Once you’ve identified roughly what these are, the next step is to refine them into hypotheses and choose one to build your new product or feature around.

This might sound like a much easier step than organizing and conducting all those user interviews in stage one, but remember: defining the right hypothesis will ultimately set the course for the product solution you work on. Getting it right is crucial.

So take your time. One of the most common mistakes in product discovery—and product development more generally—is spending too much time crafting solutions without fully nailing the problem first. It might seem counter-intuitive for a product team to spend so long thinking without creating anything. But even when you’ve observed and understood your users’ behavior, it can still take several attempts to define what’s needed correctly.

Freddie Beesely, VP of Product at Attest, has a product management story that perfectly demonstrates the importance of spending time defining and deciding on the right problem. Despite their survey tool having its own area for analyzing results, his team noticed that most users were downloading their survey results off the platform. This led them to pose a number of questions and hypotheses:

  • Why aren’t people using our built-in data visualization?
  • Why are dwell times in our results area so low?
  • How could we improve our results features for customers?

They experimented with different improvements, spoke to many customers, conducted a lot of research, but nothing stuck. Eventually, they tried rephrasing the problem:

What if, instead of discouraging people from exporting their results, we encouraged it? Clearly, our customers want to manipulate their data on different, more sophisticated, and familiar tools. So why don't we make this super easy?

Freddie Beesely, VP of Product at Attest

After the development team threw together some quick prototypes for integrations based on this hypothesis, they recognized this was the way forward:

We realized that our customers don't think of our tool in isolation, but as a tool within an ecosystem of others. Outcome: far more satisfied customers, and avoided investing huge resources into an area that brought little value.

Freddie Beesely, VP of Product at Attest

The main takeaway? Stay focused on the problem for as long as you need. You’ll save time and resources further down the line in the product development process.

Stage 3: Ideate & prioritize

The first two stages of the product discovery process are all about understanding the problem. Now it’s time to start solving it.

Start by brainstorming and collecting as many ideas as possible. Ideation is the fun part—a good product team will never be short on product or feature ideas.

Then comes the more difficult part—prioritizing which ideas to focus on. Sebastien Phlix, Product Manager at N26, identifies this as a key challenge for product managers doing product discovery:

Deciding what not to do is the kind of strategic thinking expected from good product managers.

Sebastien Phlix, Product Manager at N26

He lists five filters as a template to help figure out the ideas worth putting time into:

  • Does it align with your business goals? If an idea won’t positively impact the metrics or company goals that your team is currently focusing on, discard it for now.
  • Is it relevant to your target audience or potential users? You should be able to easily answer this with your research from stages one and two.
  • Do the numbers add up? Do a quick calculation to determine exactly which metric you expect the idea to impact, and estimate by how much. This helps compare ideas that solve a problem in different ways.
  • Are people asking for it? If customers or stakeholders are requesting a similar idea directly, this is useful data to take into account.
  • Would it be stupid not to do it? Sebastien often asks his team this question and says it yields interesting answers: “Pay attention to the thinking process and how they arrived at their conclusion. Asking this question has surfaced promising ideas that we’ve researched and later released.”

Once you’ve narrowed your ideas down to a shortlist, you can use a prioritization framework to assess the viability of each. For more on prioritization techniques, check out the next chapter of this guide.

Stage 4: Prototype & test

Next, it’s time to create a mockup or MVP (Minimum Viable Product) and get some customer feedback on it. While the previous stage is important to narrow down the solutions worth building, this doesn’t mean they’ve been validated. The only people who can definitively show you whether an idea is valuable enough to progress to product delivery are your users.

Since you’re essentially still at the discovery phase of product development, your prototypes and testing techniques should be quick and cheap. That way if an idea fails, it fails quickly and you can move on. Staying agile is key. Here’s Freddie again on some techniques he finds useful:

Cheap and simple tests bring you real-world behavioral data. This is far more reliable than qualitative intent. Tests like Wizard of Oz, painted door, and A/B testing can really help you quickly see if an idea is worth continuing with.

Freddie Beesely, VP of Product at Attest

For in-depth advice and step-by-step guides on testing with prototypes, check out some of our dedicated articles on these topics:

Product tip ✨

One simple and fast way to test your prototypes is using a remote usability testing platform like Maze. Learn more about how Maze works here.