How Much Time Should You Spend in Product Discovery?

Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery.

I get asked all the time, “How much time should we spend in discovery?”

I have two problems with this question. First, it assumes you do discovery first and then delivery second, which is not true. You should be discovering and delivering all the time.

Second, it implies that there is an answer that is true in all situations. There isn’t. You need to do enough discovery to mitigate unacceptable risk. That’s it.

That sounds simple. It’s not. So let’s break it down.

What do I mean by unacceptable risk? If you spend six months building the wrong thing, most of us can agree, that’s unacceptable. But what if you spend two weeks building the wrong thing, is that unacceptable? It depends on what you learned during those two weeks.

If you spend two weeks building feature A and then you decide as a team to build feature B instead, you might argue that you wasted your time building feature A. But if you had to build feature A to learn that feature B was a better option, then those two weeks weren’t wasted. They were a necessary effort to get you to feature B.

Now as a discovery coach, I would ask, “How could you have learned about feature B earlier in the process?” But that doesn’t necessarily mean, “How could you have learned about feature B without building feature A?” Writing code is a perfectly valid way to learn, if it’s the fastest way to learn.

Writing code is a perfectly valid way to learn, if it’s the fastest way to learn. Most of the time, it’s not.
– Tweet This

The key with discovery is speed of learning, not speed of writing code. If writing code helps us learn faster, by all means do it. Even if it means you will throw away 100% of that code.

However, most teams have a strong bias toward building to learn when there are much faster ways to learn. This is why as an industry we see an over-reliance on A/B testing—a measurement method that we’ve shoehorned into a discovery method.

However, I also see teams with the opposite bias. They spend months doing research without shipping any code. This is equally bad. Remember, we want to balance discovery and delivery.

But it’s debates about how you balance the two that lead to the question, “How much time should we spend in discovery?”

Getting to a Better Question

In discovery, we start by defining a clear outcome and then asking, “What’s the best path to that desired outcome?”

We need to discover what needs, pain points, desires, wants—or what I call opportunities—impact that outcome.

We then ask, “Which of these opportunities, if we addressed them, would have the biggest impact on our desired outcome?”

From there, we need to discover what solution will best address the target opportunity we chose.

I just outlined four key discovery activities:

1. Defining a desired outcome
2. Discovering opportunities
3. Choosing a target opportunity
4. Discovering solutions

You might ask, “How much time do we spend doing each of these activities?” But that’s still not a good question.

Just like we don’t discover first and then deliver next, we also don’t discover opportunities and then discover solutions. Discovery isn’t a linear process. It’s a complex, messy process that is happening all at once.

Discovery isn’t a linear process. It’s a complex, messy process that is happening all at once. – Tweet This

We might start a quarter with a clear desired outcome, but as we explore opportunities and potential solutions to those opportunities, we might learn that we missed the mark on defining our desired outcome.

If this is the case, we shouldn’t blindly push forward, but rather take a step back and reconsider our desired outcome. We want to question if this is the best thing we can do to create value for our customers and our business.

The same thing happens when we discover solutions. We should be exploring solutions in the context of a target opportunity. However, along the way we may learn that another opportunity is more important. If so, we need to take a step back and revisit the decision we made around our target opportunity.

Because discovery isn’t linear, whenever we learn new information, we need to revisit our previous decisions and ask if this new information changes anything.

Whenever we learn new information, we need to revisit our previous decisions and ask if this new information changes anything. – Tweet This

However, some teams fall prey to analysis paralysis—both the first time they make each decision and every time new information comes in. This is particularly problematic because if you are doing discovery well, you are learning something new every week. We don’t have time for analysis paralysis at all, let alone every week.

Teams can avoid this trap by asking a better question. Instead of asking, “How much discovery do we need to do?” teams should be doing continuous discovery and asking, “How can we quickly integrate the new information we are learning without losing momentum?”

I have two tools that teams can adopt to help answer this better question: the opportunity solution tree and understanding the difference between one-way door decisions and two-way door decisions.

Use an Opportunity Solution Tree to Map Out Your Decisions

First, teams should use an opportunity solution tree to map out what they are learning in discovery.

An opportunity solution tree helps you draw strong logical connections between the solutions you are exploring, the opportunities you have identified, and the impact both have on your desired outcome. As teams make decisions, they are charting out a path through a branch of their opportunity solution tree. When new information comes in, teams can use their opportunity solution tree to quickly revisit those decisions.

For example, if an experiment fails, the team learns something new. The team can use their opportunity solution tree to quickly decide if this new information means they need to evolve their solution, if it means they need to choose a new opportunity, or if it means they are pursuing the wrong outcome.

Because they have captured their learning as they go, they aren’t starting from scratch with each iteration. Instead, they are pruning their tree in some areas (lopping off opportunity branches that aren’t as promising as they once thought), growing their tree in other areas (adding new opportunities they uncover as they explore), and sometimes even starting a new tree (when they learn that they are chasing the wrong outcome).

While a traditional product roadmap (the kind with features and dates) depicts the route a product team will take to some uncertain outcome, an opportunity solution tree depicts all the routes a team might take to reach a known outcome. The route they will take is uncertain, but they are able to optimize that route based on what they learn in discovery.

A traditional product roadmap depicts the route a product team will take to an uncertain outcome; an opportunity solution tree depicts all the routes a team might take to reach a known outcome. – Tweet This

The opportunity solution tree is a great way to map your potential routes to your desired outcome, however, I still see teams get stuck with analysis paralysis when deciding which route to take. For this problem, let’s turn to Jeff Bezos, founder of Amazon, for some advice.

Jeff Bezos on High-Velocity Decision Making

Jeff Bezos, in his 2015 shareholder letter, gives us a simple framework for deciding which decisions should be made quickly and which decisions should be more deliberate and cautious.

Here’s what he writes:

I find this one-way door/two-way door framework to be immensely valuable when it comes to product decisions.

If you are trying to decide which companies to acquire to build out your product portfolio, this is a one-way door decision. You can’t easily reverse course if you get it wrong. This is the type of decision where you want to slow down and get it right the first time.

If you are trying to decide to invest in one feature over another, as long as you are thinking iteratively and not in terms of long-term product initiatives, this is a two-way door decision. As you start to experiment with a feature, you will quickly learn if you made the right decision. If you were wrong, you can always reverse course and pick a different solution or even a different opportunity altogether.

In the world of digital products, not only are most of our decisions two-way door decisions, but we also have fast feedback loops. If we make the wrong decisions, we’ll know soon enough, especially if we have a continuous discovery practice.

This means that we should make fast decisions. Don’t spend weeks choosing the best desired outcome. Look at your data, have a conversation about what metric would create the most value for your business if improved, and make a decision.

When mapping out the opportunity space, be inclusive. If you hear more than one customer share a need or pain point, add it to your tree. Remember, you aren’t committing to addressing it, you are just adding it to your map of possibilities.

When you are assessing and prioritizing opportunities, don’t get mired in the need for perfect data. Use the data you have today to pick a target opportunity. Keep collecting data with your continuous discovery practices, and when new information comes in, revisit your target opportunity.

When prioritizing solutions, don’t frame your decision as choosing the one best solution. You aren’t. If you are truly iterative, you’ll get many chances to choose, revise, and refine. Do the best you can based on the data you have today and start shipping this week.

At the same time, work diligently to collect more information through your continuous discovery practices, so that next week’s decisions are even better.

Bringing It All Together

So stop asking, “How much discovery should we be doing?”

Don’t think about discovery as a finite, discrete chunk of work. Discovery should be continuous. Instead, ask, “How can we best integrate new information while still maintaining momentum?”

Momentum is everything. If you aren’t shipping software, you aren’t creating value for your customers. But if you are building the wrong software, you aren’t creating value for your customers either.

If you aren’t shipping software, you aren’t creating value for your customers. But if you’re building the wrong software, you aren’t creating value for your customers either. – Tweet This

Balance discovery with delivery by continuously doing both. Use the opportunity solution tree to map out the potential routes and two-way door decisions to move fast. Make sure you have the right feedback loops in place to know when you got it wrong, and don’t be afraid to course correct when needed.

If you are still wondering how much time you should spend in discovery, the answer is: as much as you can every week. Try to spend more time on discovery next week than you did this week. Repeat.

Are you interested in more articles like this? Subscribe to the Product Talk mailing list.