If you are working in the software industry, you have probably heard about Continuous Integration, Continuous Deployment, and Continuous Delivery. But have you heard about Continuous Discovery? To be honest, before I had read the book “Continuous Discovery Habits” by Teresa Torres, I hadn’t. But the book does a good job of explaining the concept and why it actually makes sense to think about discovery as a continuous team process that - in contrary to what you might believe - shouldn’t be the product manager’s job alone.

Who owns product requirements?

The role’s name and description might vary from company to company, but in most organizations, there is a single person responsible for defining the product requirements. This person is often called the product manager, product owner, or product lead. It’s generally not the tech lead. It’s not the designer. It’s not the engineer. It’s the “product person”.

Most agile methodologies suggest that said product person is part of the team and, among other responsibilities, influences the product’s feature backlog. But how do they do it? How do they know what to build next? How do they know what the customer wants? How do they know what the customer needs?

The problem with traditional discovery

Traditionally, the product person would gather requirements from stakeholders, customers, and other sources. They would then write a product requirements document (PRD) or a user story and hand it over to the team. The team would then implement the feature, and the product person would validate it with the customer. Continuous Delivery, a standard practice in modern software development lifecycles, has taught us that we should deliver small increments of value to the customer as soon as possible. That’s good, because it allows us to test, validate and iterate on our implementation quickly, making sure we are reducing bugs and consistently delivering value to the customer. The process allows for fast feedback loops between product and engineering, making sure we are building what product wanted us to build.

But this process fails to acknowledge that customer needs might evolve quickly and the product person might not have all the answers right at the beginning of a project. In extreme cases, we might consistently and continuously be delivering awesome features, but the customer might not be using them. Or worse, they might be using them, but they are not happy with them. We just spent a lot of time and effort building the wrong thing.

There’s another disadvantage to avoiding iteration on customer needs. Product people, and product-focused engineers will often end up accumulating a significant amount of expert knowledge about their product. Users, potentially lack this in-depth experience with the product and therefor might not be able to navigate the application as well as we would assume they do.

Both issues reduce the quality of the Product Discovery’s outcome and might as a consequence harm business outcomes.

Continuous Discovery to the rescue

Continuous Discovery is a practice that acknowledges that customer needs are not static and we need to continuously validate our assumptions about what the customer wants and needs. The process iterates on the following steps:

• Understand: What are the customer’s needs? What are their problems? What are their goals?
• Evaluate: What are the possible solutions to the opportunities presented to us? How can we measure success?
• Learn: What did we learn from our experiments? What do we need to do next?

Contrary to traditional discovery, Continuous Discovery is not a one-time event. It’s a continuous process that happens throughout the lifecycle of a project. The benefits, are similar to those of Continuous Delivery compared to traditional Waterfall development:

• Fast feedback loops: We can quickly validate our assumptions and make sure we are building the right thing.
• Reduced risk: We are reducing the risk of building the wrong thing by continuously validating our assumptions.
• Potential Quick Wins: We can quickly identify opportunities and build features that provide value to the customer.

How to get started with listening to customers

“If I had asked customers what they wanted they would have said a faster horse”. – Henry Ford

As experts in our field, we often think that customers do not know what they want. And Henry Ford was not entirely wrong. Customers might not know what they want, but they often do know what they need (and what they don’t want).

As an example, think about the people travelling by horse. They might have said they want a faster horse, but what they really needed was a faster way to travel.

Customers of your SaaS might tell you, they want a dashboard where they see all the information they need to make decisions. If you build that dashboard, they might feel overwhelemed by the amount of information presented to them. What they really needed was an easier way, taking less than 15 clicks to get to the information they need.

The dashboard is only one possible solution to their pain point - complex navigation. Breadcrumbs, a search bar, an AI-powered assistant, or a better navigational structure, all might be useful solutions to the problem.

It is your job to understand the customer’s needs, deduce opportunities from them, and evaluate possible solutions.

Opportunity Solution Trees

Conclusion

I’m only at the start of my journey with Continuous Discovery, but I invite you to join me as I document my learnings, insights and lessons learned in this series of blog posts.