How to Implement a Product Discovery Process, Step by Step

Implementing a proper product discovery process will save you time and money in the long run. But spoiler alert: the product discovery process is not linear.

When we hear “discovery” we might think of plucking up a perfectly formed, brand-new idea and executing on it. Discovery to delivery, right? Wrong. In product management, the discovery process is circular – which means it’s a bit slower, and yes, maybe a bit more tedious than any straight-to-development pipeline.

But the benefits are worth it. Why? Because you’ll build the right things that add real value to your product, which means you’ll hit more goals.

We’ve already discussed why continuous discovery is great. So in this post, we’ll explain the practical side of things:

• What a product discovery process is
• How to conduct the product discovery process, step by step
• How to implement this process in your team’s structure and routine

Let’s get started!

What is a product discovery process?

The product discovery process helps teams uncover real user needs, define problems, and then refine solutions through testing and feedback. The product team seeks validation throughout the process – making hypotheses, iterating on the product, and testing with customers to create a viable product.

This circular product development process helps confirm that an idea is the right thing to build, given current needs and constraints. You won’t just add more features for the sake of it. The more testing and validation you do in product discovery, the more likely you are to actually solve problems and hit objectives!

How to implement a product discovery process, step by step

Follow these 8 steps to implement a product discovery process, from identifying the problem area all the way to conducting a mini-retrospective of the solution:

1. Identify the problem
2. Conduct user research
3. Brainstorm potential solutions
4. Prioritize!
5. Prototype
6. Experiment and iterate
7. Usability testing and iterate
8. Hold a mini-retrospective

1. Identify the problem

The first step in any product discovery process is to identify a problem, from the perspective of either the user or the business. This can be a high-level assessment that asks the question: What is your product actually trying to do? What are your company’s objectives?

By defining the problem area and identifying what the issue is that you’re looking to solve, you outline the general focus of the rest of your product discovery. It doesn’t need to be exact. Further refinement comes later!

So, where do you look to find a worthwhile problem?

• Start with these product discovery questions
• You could conduct fresh user research, host user interviews, or review existing user feedback to identify your target customer’s pain points, needs, and goals
• If you’ve set up channels to receive customer feedback from colleagues, such as the support and success teams, check if there are any, valuable insights, themes, or patterns that have come up organically
• If the problem lies with the business goals, that’s easier to identify. Select the metrics or objectives that need some improvement

Define success
Once you’ve defined the problem, you should also define what success looks like. Set some objectives around solving it. Is the goal to improve a particular user experience, increase activity by 15%, or hit a revenue goal?

2. Conduct user research

The research stage takes you from identifying the problem area to truly understanding it. The goal is to understand your users’ needs and behaviors so thoroughly that you can think about the problem from every angle with a deeper understanding of the customer demands.

Based on the high-level research, define who it is that you’re building for in this particular case. Consider your user personas, if you use them. And then start the product discovery user research.

There are 6 product discovery methods your team could use at this stage:

1. Customer feedback
2. Customer interviews
3. User analytics
4. Competitor Analysis
5. Business modeling
6. Internal discovery

The methods you choose will depend on what your starting point is. Maybe you’re striking out in a green field space, or maybe you’re iterating on an existing product.

No matter what, talk to your customers! Send out automated surveys, conduct in-person interviews, or whatever works for you. But you must talk to your customers to actually understand them. Check out our in-depth guide on how to run customer feedback sessions.

Define a hypothesis

Based on this user research, hone your assumptions into a very clear hypothesis, or set of hypotheses, about what could solve the problem. What would make a difference? You can frame the hypotheses like so: “If we were to do X, then Y could happen.”

3. Brainstorm potential solutions

In this stage, outline the potential actions and solutions you can try. Each potential solution is actually a product experiment you can test. So think up experiments and define how you’ll measure them.

Keep an open mind at this stage! Remember that a potential solution isn’t always building something. The experiment could be:

• Taking away or disabling a feature to see how it affects usability and behavior
• Changes in value proposition or even pricing
• A shift in positioning and the language of marketing copy

4. Prioritize

Like any good product person, you need to prioritize these experiments before you get started. Choose a prioritization model that works for the team, according to your constraints and your goals. If you need help choosing, or you’re curious about alternatives, learn about which prioritization model is best for your product.

Once you’ve prioritized your product ideas, the product discovery process accelerates!

5. Prototype

Start hashing out some mock-ups and prototypes of your ideas. The main goal of a prototype is to show how the thing might work. The prototype itself doesn’t have to actually work! It could be a sketch on a piece of paper – or the classic startup napkin.

The point is to lay out your assumptions in such a way that people can actually get an impression of your solution and articulate their feedback. If you’re just using words to explain a concept, they’re not going to grasp it and won’t have much valuable input.

Users are your gut check. Give them a physical, digital, and quasi-tangible representation of your idea so they can give you valuable feedback in return. Then you can iterate and improve.

Check out how to adapt MVP and prototypes to your product discovery process.

6. Experiment and iterate

Here’s where the circular process comes into play. You put your ideas down on paper, take it to the customer, then test, iterate, and improve on that prototype – and then bring it back to the customer, and so on.

You might also begin tweaking things in the app or making tangible changes to your product, then observing behavior and speaking with customers afterward – then tweaking again, and so on.

The more cycles, the better. The more you check your assumptions, the more likely you are to figure out which of those assumptions is right or wrong. This is why I think of the product roadmap as a tool for experimenting.

How many experiments can you run at once? Well, this depends.

Product teams often ship several things at the same time, where the work is not a single feature but rather a cluster of improvements in one area. You can test ideas together in a batch like this.

It’s nearly impossible to create the perfect environment for running single experiments. Isolating one change is really difficult unless you have a critical mass of users and you’re getting valuable data within 24 hours.

Most products don’t have enough user traffic to create quantitative insights through statistical significance within a short period of time. And most companies can’t wait indefinitely for that pure user data to amass over time. So the most practical advice is to run batch experiments and observe them collectively.

7. Usability testing, iterate

Now that you’ve validated your ideas, it’s time to put them into practice for customers and ensure the solution is working properly. This means usability testing and yes – more iterations! You could choose from various usability techniques, or you could run a beta program with select users.

At ProdPad we use a traffic light system to measure the usability of our product. When we set users on a task, they’re given the original interface, and they’re being watched, but they’re not being helped. We then assign a traffic light color to their behavior.

• Green: The user experience is smooth, and they don’t need any help
• Yellow: They need a little bit of help
• Red: They’re stuck

With this user test, our product designers see where users can complete tasks (green) and where they can’t (red). We have a traffic light map of the product that guides our next iteration. And we continue testing with other users until hopefully, we’ve achieved green lights consistently across the board.

And then you launch!

8. Hold a mini-retrospective

You knew this was coming! Build in time for a mini-retrospective on the solution and the process. You set your goals and objectives in step 1, you set your hypothesis in step 2. And now, your team should reflect on where you’ve hit the mark – or missed it.

Carve out time to ask:

• What worked?
• What didn’t work?
• How could we improve this particular project?
• How could we improve our product discovery cycle?

How to embed a product discovery process in your routine

So you understand how to conduct continuous product discovery itself, but how do you fit it into the larger rhythms and processes of product development?

Here are 4 ways to embed a process of product discovery in your team’s routine:

1. Dual track system of discovery and deliver
2. Block off time to talk to customers every week
3. Try the Product Trio configuration
4. Design your cycles and sprints accordingly

1. Dual track system of discovery and delivery

Ideally, product discovery is built in with the sprints, so your sprint work is infused with the stuff you’re learning. If you put this step-by-step discovery process in parallel to the sprint work, you’ve got dual tracks: discovery and delivery happening at all times. The developers are building what you discovered in the last round. And then the discovery work you’re doing now is informing what’s gonna happen in the next sprint work.

2. Block off time to talk to customers

This is the pillar of good product management! Someone on the product team should be speaking with users on a regular basis. Find some amount of time that you can devote to getting that feedback, and build it into your routine. Block it off on your calendars and keep a full pipeline of users or potential customers to interview.

As a PM, you’ve got 40 hours a week. If you spend two of those hours meeting with users, that’s 5% of your time. Totally reasonable!

When I started out as a PM, customer feedback sessions were booked for us every week. Whether we wanted to or not, whether we were ready to or not, we had customers coming in. This forced the pace of our learning and discovery, and it made a big difference.

If you’re really starting from square one, check out how to introduce a customer feedback process.

3. Try the Product Trio configuration

Some teams have a Product Trio, an interdisciplinary, cross-functional team with the product person, the engineer, and the designer working hand in hand. The engineer is brought into this process and the engineer is spending the time doing the goal setting and the interviews. The product manager is helping to design the solution.

How does this help with product discovery? Each function of the team is engaged with the process from the beginning, seeing it from all perspectives. And they see it through to delivery, too.

4. Design your cycles and sprints accordingly

Design your product management and development cycles with discovery in mind. At ProdPad we work in 7-week cycles that are divided up into individual sprints and then an overall retrospective:

• 2 week sprint
• 2 week sprint
• 2 week sprint
• 1 week of retrospectives and planning for the next cycle.

In that final retro/planning week, we will often identify the next set of problems we want to solve in the upcoming cycle. The product discovery is planned into the next three sprints. The whole team is involved and ready to hit the ground running.

At the end of the day, implementing a product discovery iterative process will take some testing and iteration of its own! You don’t need to get every step perfectly right the first time. You’ll find a version of the process that fits your team and your customers. The most important point is to start and reap the benefits of continuous product discovery.