8 Tips for Product Discovery that Actually Work

Does your product team sit around with little work to do, wondering what you’re going to do next quarter?

Yeah, I didn’t think so. If there’s one thing that product teams all have in common is that they all suffer from the opposite problem – too many things to do.

When done right, product discovery helps product teams decide what they should work on, and perhaps more importantly, what they should not work on. The focus that a team can get from proper product discovery helps them deliver those products or features in the right way.

All of that begs the question, what’s the right way to do product discovery? Here are eight tips to help you structure your product discovery efforts so that you can be sure you’re working on the right things.

Fall in love with the problem

So what exactly should your team work on? Your product discovery efforts should focus on understanding the problem space, which means having empathy for your customers and understanding their needs.

Figure out what problem your customers would like to have solved most and what solving that problem looks like. Learn how the problem impacts your customers, how they feel when they experience the problem and what it would mean to them to have it go away.

Your goal during product discovery is not to come up with the perfect solution; it’s to understand the problem better than the people who have that problem understand it. When you fall in love with the problem, you’re more likely to try different solutions and throw those away that don’t do the best job of solving the problem.

Look at Apple and Microsoft. According to Paul Lopushinsky, much of their success and resilience can be attributed to the fact that “they’ve fallen in love with the problems, and they let the customers fall in love with the solutions they build”.

Involve the whole team in product discovery

Even though you’re not creating solutions during product discovery, you uncover information that will help you come up with solutions. To come up with the best ideas, involve as many team members as possible in discovery.

When everyone on your team is involved in some way in product discovery, you’ll all build empathy for your customers and will gain an in-depth understanding of the context in which you’re working. You’re more likely to solve the problem in a way that best satisfies the needs of your customers.

When you involve people with different skill sets and backgrounds in product discovery, those different perspectives synthesize the information you uncover in different ways.

• A product person is looking for value and viability
• A designer is considering things that will influence usability
• A developer focuses on things that impact the feasibility of building a solution.

In addition, people with different backgrounds will notice different nuances of your customer’s context that could impact how they might use a product. For example, if your team is working on a podcast app and you don’t have someone who frequently drives at night, you may not account for the annoyance an extremely bright app screen has on people listing to your app in the car.

Make product discovery continuous

You don’t fully understand the problem you’re trying to solve (including how a solution may or may not address it) until you’ve been able to get something in the hands of your customers and get feedback.

So instead of all your product discovery happening at the beginning of your effort, perform product discovery alongside, perhaps just a little bit ahead of, product delivery.

Reflecting on the previous tip, you may be asking how do you get anything built if your entire team is continuously in discovery mode.

Some product teams identify a product trio, consisting of a product manager, product designer, and tech lead who focus most of their time (say 70%) on product discovery. In contrast, the remainder of their team focuses the same percentage of their time on product delivery. 

Product trio members still participate in product delivery, primarily answering questions and clarifying the team working on a solution. The other team members will also join in some discovery efforts, but the entire team is not involved in every discovery activity. After all, it may be intimidating for a user to be interviewed by a whole nine-person product development team. 

Use feedback from delivery to guide discovery

You’d expect that the things you learn from product discovery would involve what the team delivers. After all, an output of product discovery efforts will be backlog items that provide information that guides the team’s solutions during delivery.

But the information flow should not be a one-way street. The whole purpose of spreading discovery throughout your effort is to get information from delivering a working product or feature to your customer and getting their quick feedback. You can then use that feedback to guide your subsequent discovery efforts.

Perhaps you found out that you didn’t entirely solve the problem, so you need to dig into the situation a bit more to understand what else you can do.

Perhaps you completely solved the problem, so now you can turn your focus to a different problem.

Perhaps you solved one problem, but your solution created a different one. Now you need to figure out the cause of that new problem and determine if you can change the solution you already delivered or if you need to provide a new one.

Discover breadth-first then dive deep

One easy way to make your product discovery efforts more continuous is to avoid the temptation to dive into deep details on everything initially. Teams that take this approach to discovery are working under the false assumption that it’s possible to gather all the information you need at the beginning of the effort and just through discovery.

A better approach is to do enough discovery at the start of the effort to understand the breadth of the problem space and the conditions your solution needs to satisfy. If you don’t know what will solve the problem, identify a set of ideas for possible solutions if you’re in a situation. Pick one idea you think will have the most significant impact and explore that one in detail first.

If you’re in a situation where you know the solution, but it’s a significant effort, pick the first slice of work you need to do and perform discovery on that slice.

Then in both cases, deliver the piece you explored and get feedback. Use that feedback to guide what you study in your subsequent discovery efforts.

Trust what people do, not what they say they would do

A great deal of product discovery surrounds understanding your customers and learning what they see, think, feel, and do. Talking to the people who will buy and use your product is an essential piece of product discovery, but there is a caveat to those discussions.

If you ask people to predict how they will react in a given situation, they are bound to tell you what they think you want to hear, which may or may not be what they will do. You’re better off asking them to talk about what they have done in situations they have experienced. You’re not asking them to predict the future but rather report on what’s happened in the past.

Ask people to tell you stories

A great way to get people to report on what’s happened in the past is to ask them to tell you a story. You, of course, don’t explicitly ask them to tell you a story, but instead, you say, “tell me about the last time you [some scenario relevant to the problem you’re exploring]

Then shut up and listen to what they have to say.

Give them a chance to tell you about that scenario. Initially, only jump in when you want them to expand on some aspect of the situation.

You ask people to tell stories to get richer information than you would if you simply asked a bunch of yes/no questions. Taking this route will uncover unexpected information that provides insight into their problems and potential solutions.

Seek to prove yourself wrong

We’re all human, which means we’re constantly working with cognitive biases that drive our actions in specific ways. One confirmation bias that hinders product discovery is confirmation bias – where you only pay attention to information that confirms your assumptions and ignore everything else.

One way to combat confirmation bias is to prove yourself wrong during product discovery. Instead of finding information about why a potential solution you have will work, try to look for why it won’t work. 

And since you’re having multiple people engaged in your product discovery efforts, you may agree ahead of time that some of you are trying to prove a particular assumption valid, and others are trying to disprove it. Then after your interview, compare notes and see what each of you picked up on.

craft.io helps you practice product discovery that works

Effective product discovery involves several members of your team exploring the problem space on an ongoing basis. To make the best use of all that information that your team uncovers, you need to make it organized and in one place. craft.io’s Spec Editor provides that one place where your team can track all that information. Try craft.io today to see how it can help you do product discovery that works.