8 Things You Didn’t Know About The Product Discovery Process

Successful and popular products are rarely born in moments of inspiration, nor are they likely to just pop into the minds of entrepreneurs or product managers. More often, great products are the result of a rigorous and effective product discovery process.

When executed well, the product discovery process guides product development teams to find the right problems to solve for the customers. It also ensures that teams avoid wasting time and company resources in attempting to serve the wrong customers, solve the wrong issues, or build the wrong solutions.

But what is it that makes a product discovery process a success? We found eight tips that may surprise you.

What is the Product Discovery Process?

According to Andrea Milan, product discovery is about answering three basic questions:

• What is the biggest problem or pain point of our users? 
• Will the users choose and figure out how to use a possible solution? 
• Can we build this solution and does it work for our business?

Indeed, the goal of the product discovery process is to deduce – through asking questions – what to develop and produce. In today’s data-driven world, effective product discovery relies heavily on information gained from potential customers or existing clients.

A product discovery process traditionally starts by identifying the people that your organization serves. You should aim to learn as much as possible about their situation, needs, and the problems they need solved. One way to segment your target audience and understand it better is to establish personas.

Once you understand the people your organization serves, you can investigate the problems they need solved. Interviews are an excellent way to understand what your customers are trying to accomplish and ultimately identify your outcome.

Your product team can use information you learn from your customer interviews to identify opportunities to drive that outcome to build an opportunity solution tree. From that tree, prioritize the opportunities that you want to address. To help you decide which options you want to develop solutions for, you may run assumption tests to understand which options will drive the most progress toward your outcome.

Your product team will repeat this discovery process and incorporate a delivery process to identify a potential solution, deliver it, and get customer feedback to determine if they drove the desired outcome. 

When your team reaches the desired outcome, your team can then look at customer feedback to identify a different problem to solve. If you haven’t got the outcome you were targeting yet, you can pick another solution and drive further progress.

8 Things You Didn’t Know About the Product Discovery Process

Now that we’ve covered what you may already know about the product discovery process, here are eight things you may not.

#1 Product Discovery Never Really Ends

Product teams used to start work on a product with an extensive analysis and design phase at one point in time. They worked under the assumption that it was possible to learn everything they needed to know to build a product through an extensive requirements gathering and design effort.

Unfortunately, you will never learn everything you need to know about the problem you’re trying to solve and your solution just by laying down requirements and design. You need to go through the entire software development process – including design, development, testing, deployment, and customer feedback to truly learn everything there is to know about the problem you’re trying to solve and how your solution does or does not solve that problem.

Once you realize that, you’ll look for ways to make just enough discovery to prepare the product team to deliver a solution that will provide feedback that influences your continued discovery efforts. 

As a result, you no longer have a discovery phase at the beginning of your product work that attempts to establish a broad and deep understanding of your solution. Instead, you make sufficient discovery to understand the breadth of your solution, which you may describe in terms of the customers you serve or the specific use scenarios your product supports. 

Then you iteratively do a deep dive into the specifics of different aspects of your solution. If your product supports four different use scenarios, you start your discovery and delivery efforts on one scenario. Once you’ve addressed that scenario, you turn to the next one.

Once you’ve reached your targeted outcome, you then focus on your product discovery efforts to identify opportunities. You’ll then experience a continuous cycle of discovery that supports continuous delivery of improvements and an improved product overall. 

#2 Starting With User Interviews Give You An Edge 

Effective product discovery requires continuous meaningful interaction with current and potential customers. Your product exists to solve customer problems, so you need to understand what those problems are. The customer does not, however, care about your product.

Some product teams believe that they represent their customers, especially if they created their product to solve a problem they often face.

The trouble with this approach is that the product team is basing the product’s success on the assumption that there is a significant number of paying customers who have the same problem as the product team.

If you find yourself in this situation, you’d be better off talking to existing and potential customers to understand their actual problems and their willingness to pay to solve those problems. You’ll want to validate what you learn from your customer interviews with their actions, but even talking to your customers about their needs and the problems they face, you’ll be ahead of a different product team that is solely building a product to solve their own problems.

#3 Focusing On Your Ideal Customer’s Needs Will Help You Refine A Solution

You talk to customers to understand what their needs are so that you can address those needs. When customers feel that a product solves their problems, they are more likely to purchase and use a product.

The other benefit of building a product to address customer needs directly is that you avoid making a product that doesn’t address any significant needs.

If you don’t build your solution with customers’ needs in mind, you’re making the product to fit your own needs, but you may be making a product that no one will buy.

#4 Details Can Drown Out The Essence

When you do all your discovery work at the beginning of your effort you feel inclined to dive into deep detail on all aspects of your solution before you build any of it.

That means you specify all the details before you’ve had a chance to build anything and see how your assumptions play out.

When you specify everything up front, you end up with requirements that become outdated or are not needed. That leads to a great deal of rework and false starts.

You’re much better off performing a little bit of discovery along the way. You can certainly understand the breadth of your intended solution when you start but only do a deep dive for a particular feature right before you’re ready to build that feature. That way, you can take advantage of the things you learned when you delivered previous features during your discovery.

#5 Empathy Goes A Long Way

A key result of effective product discovery is that you not only understand your customers and users, but you empathize with them. It’s one thing to know what problems they’d like solved, but it’s much more useful to know why they want those problems solved and what it means to them to have their problems solved.

Building empathy starts with your approach to understanding your personas. Don’t just compile a bunch of demographic information. Instead, use techniques like empathy mapping to dig into what pains your users’ experience, what gains they are hoping to achieve, and what they think, see and feel when they use your product.

When you understand why your customers and users need specific problems to be solved, you’re in a much better position to deliver a solution that properly solves that problem without providing features that they don’t need.

#6 Without Timeframes, Product Discovery Processes Fail

It’s often referred to as analysis paralysis because the rhymes are so sweet, but it’s possible for you to get so wrapped up in discovering everything you possibly can about a problem that you forget to actually deliver anything.

It’s hard to know when you’re “done” with discovery because you can continuously learn more about the problem and possible solutions. You’re better off timeboxing your discovery activities so that you can stay focused on uncovering the information you need to make the decisions you face right now. If you know you only have two weeks to identify the key information to deliver that next feature you’ll be less tempted to chase down answers to interesting, but currently irrelevant questions. Make note of them and come back to them when you’re working on a related feature.

#7 Developers Should Be Involved In The Product Discovery Process

In addition to building empathy with your users, effective product discovery also helps you understand the context in which your product exists. That means you understand why customers and users want a problem solved, but also why it’s a problem in the first place.

Now you could try to convey all of that information to the people building the solution through requirements and models. But no matter how detailed those documents are, they will never fully convey all of the deep background information that is essential to building a great product.

A better answer is to include developers in your discovery efforts so that they can learn about the context first hand and develop empathy with users throughout the discovery process. When developers empathize with their users and understand the context in which they are building their product, their decisions result in a better product. 

When you involve developers with discovery, you’ll also get a valuable technical perspective involved in customer interviews. They’ll be able to pick out critical technical considerations from conversations that a product manager or product designer may not immediately identify.

If your team has the product trio of product manager, product designer, and tech lead leading design, you’ll get some of that technical perspective but the other developers will miss out on getting a first-hand understanding of context and the opportunity to build empathy with their users.

That’s not to say that every developer has to be involved in every discovery activity, Look for a balance where you have one or two developers involved with every interview or discovery session and rotate around so that all of your developers get some opportunity to be involved.

Through this process, you may find that there are some developers that are more interested in participating in discovery activities than others, and that’s ok.

#8 Failure Is An Option (And Not A Bad One!)

The main purpose of intertwining discovery with delivery throughout the entire product development process is to incorporate learning into the entire process. 

You discover a potential problem, you build a solution that you think will solve that problem and deliver it to your customers. Then you get feedback about that product to determine if it really solved the problem. If the product solves the problem, you may learn a little, but if you miss the boat, you’re going to learn a lot more.

So you shouldn’t be afraid of these failures as long as they are small, recoverable and you learn from them in a way that supports your future efforts.

Don’t take that to mean that you’re actively inviting and encouraging failure. You should always seek to deliver a successful product. But if you do encounter failure, view it as a chance to learn, not the end of the world.

Effective Product Discovery Helps You Make Informed Decisions

The purpose of product discovery is to uncover the information that will guide your product decision making. To get the most helpful information, spread discovery throughout your entire product development process, involve your entire product team and focus your discovery efforts on customers and users.

To make your product discovery truly effective, you also want to keep the whole team up to speed with what you’re learning. So even though you want to involve the entire team in product discovery, not everyone will be involved in every discovery activity. You need a consistent, agreed upon location to store all of your findings. 

That’s where craft.io comes into play. craft.io’s Spec Editor helps you get out of docs, confluence, and other disjointed tools and tap into powerful templates and create detailed product specs that reflect what you’re learning. Book a demo today to see how craft.io can help you organize everything you learn from product discovery in one place.