Continuous discovery: the evolution of product discovery

Product discovery has been a big thing in product management since 2007.

It all started when Marty Cagan, one of the most influential names in Product Management, highlighted the differences between Discovery vs. Delivery in a famous blog post. Since then, numerous companies have changed the way they build products.

While Discovery informs what and when you should build something based on understanding your user needs, Delivery focuses on how you should build it.

Even though the term continuous discovery was something that Marty Cagan was already talking about since 2012, it was only a few years ago that another famous Product coach, Teresa Torres, made it famous in her Continuous Discovery Habits book.

If you haven’t read it, the idea is centered around the fact that most companies do Product Discovery on a one-time, standalone basis; they consider it the first step of a project where you define where you want to be, listen to the customer to understand how far you’re from that, define what to build, and then ship the product.

But if products are constantly evolving, how can a project mindset do the work of understanding what users need? Enters continuous product discovery.

What is Continuous Discovery?

Continuous discovery means constantly capturing and understanding customer feedback throughout the product development lifecycle to increase value delivery.

Put in another way, it consists in moving from a one-time, project-based research activity to a sustained process where a product trio, based on a clear and expected result, gathers user feedback, makes assumptions, interview users, and validate experiments on a weekly cadence to make product development decisions and inform product delivery, just to start it all again when something is delivered.

The assumption behind continuous product discovery is that we have to constantly measure where we are at and define what to do next because customers’ perception is constantly changing based on what we delivered, what our competitors are doing, and many other factors. It’s a constant work in progress.

Why do successful organizations adopt continuous discovery?

Building great products is all about better addressing user needs and desires. The most successful companies are the ones that are able to deeply understand customers, translate their needs into features of a product, and deliver that with mastery.

In a context where customer needs are constantly changing – now at a faster pace than ever before – continuous discovery arises as the solution to keeping up with what users want and ensuring that customer feedback is considered in the daily decision-making about what to build next in products. So it’s safe to say that the most successful organizations and world-class product teams are the ones that were able to adopt a continuous discovery program.

According to Harvard Business School, 95% of products fail, and in most cases they do because they don’t address a real customer need. But instead of understanding the problem and the user, companies keep investing in other things: sales, marketing, and more features. Truth is that product teams dedicate most of their time to defining features, managing tasks, and working on bugs (product delivery) instead of doing product discovery.

Not for successful companies: Amazon, for example, states in their first leadership principle: “Leaders start with the customer and work backward. They work vigorously to earn and keep customer trust. Although leaders pay attention to competitors, they obsess over customers.”

By investing more time into discovery, or to better say, into continuous discovery, product teams will end up orienting their decisions around the users, thus building products (and features) that generate more value.

Six key steps to doing Continuous Discovery

The continuous discovery process has six key activities:

Define a product outcome
Gather customer feedback to map opportunities for improvement
Prioritize your opportunities and define solutions
Prototype and test the proposed solutions with users
Select the most successful solution and prepare for delivery
Continue to monitor the delivered solution and changes on feedback vs. outcome

One of the main premises of continuous discovery is that it should always start with a clear product outcome. A product outcome is a leading indicator, normally associated with user behavior, that should impact and benefit the desired business results.

Once a product outcome is defined, the product team needs to discover the opportunity space – what unattended needs or expectations users have that would drive them to change that behavior in the direction they want. In order to do that, they need to talk to customers to understand what are these needs and expectations.

With all the opportunities mapped, it’s time to prioritize them. The most important here, according to Teresa Torres, is that the focus of prioritization is the opportunity and not possible solutions for them. That way you can keep connected to the outcome.

The solutions to these opportunities should then be prototyped, ideally in the most simple way to just prove the case associated with it, and brought back to the users to be tested and validated. The opportunity-solution duo that has the highest impact on the desired outcome should then be prepared for delivery, only to be tested again and improved with new input from user feedback and new opportunities that can be explored.

What is clear from this is that, to have a successful discovery program, product teams need to listen to the customer at the beginning, the middle, and the end of this process.

It pretty much requires that companies stop isolating research from product development and incorporate customer feedback into every product decision, shifting their product development process into a customer-centric and data-driven one.

Common challenges of Continuous Discovery and how to address them

With continuous discovery being such an important element for the success of a product, we can ask ourselves why so many companies still don’t do it. Well, the simple answer is: it’s not easy.

The most common challenges companies face when trying to implement a program are normally associated with:

Lack of knowledge
Lack of customer feedback
Lack of time

Let’s cover each one and suggest how to address them:

1. Lack of knowledge

One common challenge in organizations is the lack of knowledge inside the organization to establish a Continuous Discovery program. Even with a lot of content available about it, some common things happen.

One, Product teams suffer from what Teresa calls the “curse of knowledge”: they approach the problem from the perspective of someone who deeply knows the product and make assumptions that are not true to the user.

In some cases, they know that they need to talk to the customer, but they don’t really know how to conduct good interviews, which causes them to ask biased questions that don’t really lead to good assumptions.

Or they can even run the whole process correctly but struggle to prioritize the right features.

I believe this challenge is, at the same time, the hardest and simplest one to solve. Hardest because culture is something that takes time to change, easiest because there are several resources and shortcuts to help: you can hire a coach to re-wire your perceptions and habits, find continuous discovery frameworks to support you, and keep practicing.

2. Lack of customer feedback

A common challenge faced by teams wanting to implement a continuous discovery program is having enough user interactions to feed their program. As Teresa Torres once said, “the hardest part about continuous interviews is finding people to talk to”.

Truth is that you might be letting feedback go down the drain at this exact moment: according to IBM, more than 80% of data generated inside companies is never accessed, and that includes customer feedback.

Data from support tickets, customer calls, NPS surveys, user interview transcripts, and other feedback data are some examples of sources that remain untapped in most companies, especially when it comes to making product management decisions.

These types of feedback can be helpful in a few different ways. First, they can give you enough volume to be more confident about the size of a specific opportunity, or that a specific assumption is not unique to that user or segment – you can actually quantify how many people are complaining or requesting that exact same thing.

Second, they can be a great resource to decide which users to invite to interviews or even an inspiration for what to ask in these interviews. Not to mention that users who are normally being spontaneously vocal in other channels are more likely to want to jump into a call and discuss their needs and expectations with you.

And third, they are CONTINUOUS! Isn’t that amazing?

So fear no more: unless you’re a very early-stage startup that still has no users, lack of data shouldn’t be a problem. We’re not saying that these sources of feedback will replace user interviews, but they can help you expand your reach and even schedule more – and better – interviews at some point.

3. Lack of time

Another issue faced by companies trying to do ongoing product discovery is not finding time to run the whole process, especially considering that you need to constantly find users who are a fit and also are willing to talk to you, schedule (and sometimes reschedule) those interviews, have them, summarize the findings, build your opportunity tree…well, you got my point.

Running a continuous discovery practice definitely requires time and dedication, and even though we all know that this should be a #1 priority – especially the piece of getting the pulse of the customer – this is normally not what happens.

When it comes to the process of finding users and booking interviews, a few automation tricks might do the job of improving your efficiency and making this an easier task. I particularly like how Simon Knight described how he automated his interview scheduling.

Even with that figured out, there can still be a struggle with cataloging and managing all the data generated from interviews and other sources of feedback.

While Teresa Torres suggests that you create a one-page interview snapshot, that falls short as it has only a summary of the conversation and might lack some important details: the verbatim used, other relevant pain points, and more. Besides that, it’s not easy to connect each snapshot with one another. Not to mention the fact that it doesn’t combine interviews with other sources of data.

This is actually a very common problem: in a recent survey with 100+ Product Executives, we asked them what was their most time-consuming customer feedback-related task. 51% of them answered that it was categorizing opinions in order to make them useful.

To help you get started with that, we’ve created a customer feedback analysis template that will help you organize your process and start creating topics in a way that makes it easier to quantify customer feedback and translate it into opportunities.