Learn / Product Forge / Article
How to balance continuous delivery with continuous discovery
Continuous delivery and discovery help product teams learn more effectively and provide value to customers.
But some teams have been hesitant to adopt these techniques because they aren’t sure how to properly balance delivery and discovery.
Let’s take a look at continuous delivery and continuous discovery: where they came from, how they’re different, and how an effective product team can strike the right balance to deliver customers the right product, in the right way, at the right time.
Where did the concepts of continuous delivery and continuous discovery come from?
You may have heard of the waterfall approach to product development, which assumes you can learn everything you need to know at the beginning of the product development process through extensive analysis and design phases.
That assumption is inherently flawed.
You learn about the problem and solution throughout discovery and delivery. If you only do discovery at the beginning of an effort, you lose the ability to apply things you learn during early development to the rest of your work.
To take advantage of the opportunity to learn things throughout the discovery and delivery cycle, product teams adopt iterative processes for building products where they build and deliver a small subset of their solution at a time.
They also adopt continuous discovery practices so they aren't trying to learn everything in one big analysis and design phase at the beginning, but instead spread this investigation—which is referred to as discovery—throughout the entire process of building a product.
As teams develop more frequent updates to their product, they need to revise the processes and tools they use to get those updates into customers' hands. Embracing the DevOps practice of continuous delivery helps streamline your activities to make products available to customers and users.
Definitions of continuous delivery and continuous discovery
Understanding the differences between continuous delivery and continuous discovery helps to explain why you should use them together:
What is continuous delivery?
Continuous delivery refers to a product team’s ability to quickly, frequently, and sustainably launch product changes and updates like new features and bug fixes.
Teams gain this ability by placing their code under source control and creating a deployment pipeline that generates a deployable package of software. The source control helps the team keep track of all changes they make to their product.
The deployment program automates the process of integrating and testing their product so they can combine their changes and release them to users regularly, sometimes multiple times per day.
The benefits of continuous delivery include:
Lower-risk releases: when your team releases code frequently, you include fewer changes in each release, reducing the chance that those changes will conflict with each other.
Faster time to market: your team releases code more frequently, reducing the time you need to deliver changes to your users.
Higher quality (and fewer bugs): because there are fewer changes in each release, your team has fewer opportunities to introduce bugs. On top of that, each release includes automated testing, so you have a better chance of catching any bugs you may have introduced.
Better products: continuous delivery allows you to deliver changes to your customers faster, thus getting faster feedback. That means you can find out sooner whether certain features delight your customers or not.
What is continuous discovery?
Continuous discovery is a process in which product teams continually search for new information about user needs using research activities like user interviews, or tools (like Hotjar 👋 ) that give you a constant stream of information on what your customers are thinking, how they're experiencing your product, and what their specific needs are.
Continuous discovery allows your product team to question assumptions, learn how users really think, and constantly improve the products you deliver.
Interweaving discovery with delivery also allows you to build upon the feedback you receive from your users to influence future changes you make to your product.
Let’s take a look at how these two different activities support each other.
Why you need continuous delivery and continuous discovery
If you release the initial version of a feature and feedback shows that people aren’t using it at the rate (or in the way) you’d hoped, you can steer your ongoing discovery efforts to understanding why they don’t use the feature the way you intended. This may include collecting user feedback or looking at heatmaps to see why users don’t launch the new feature.
Continuous discovery incorporates feedback cycles into your process, in contrast to waterfall approaches that keep your team delivering new features without regard to what your customers tell you about the functionality you’ve already delivered.
This example shows how discovery and delivery form a virtuous cycle. In this case, delivery incorporates both the development of product increments and getting those product increments in customers' hands.
So you want to do both, but how do you decide who does what and when?
How to balance product discovery and product delivery
To properly balance discovery and delivery, you can consider three options:
You can split the team into a discovery team and a delivery team
You can have the entire team switch back and forth between discovery and delivery
Or you can take a dual-track product development approach
The first approach introduces several unnecessary handoffs into your workflow. The second approach makes your team’s efforts a bit choppy and results in less frequent value delivery.
That leaves dual-track product development, an approach many product teams find strikes a good balance between discovery and delivery.
What is dual-track product development?
Dual-track product development is where product team members simultaneously perform discovery and delivery.
They accomplish this by having a subset of the team focus the majority (but not all) of their time on product discovery. The remainder of the team focuses the majority (but not all) of their time on product delivery.
Here's how it might look in action:
A product trio (a product manager, product designer, and tech lead) spends around 70% of their time on product discovery—customer interviews, watching session recordings, analyzing user feedback—and 30% of their time in product delivery, usually answering questions from the rest of the product team.
The remainder of the team sees their involvement roughly reversed. They’ll spend 20–30% of their time in discovery activities, and the remaining 70–80% in product delivery (development, testing, and deployment).
Note: everyone on the team should be involved in product discovery to some extent so they get the necessary background and context about their customers and their jobs to be done (JTBD).
Pro tip: dual-track product development tends to divide time between delivery and discovery, with the majority of the team focusing 70–80% of their efforts on delivery and 20–30% on discovery.
But it’s important to note that these percentages vary depending on where you are in the product lifecycle and how much uncertainty you have about your product. When you start work on a new product or feature, there’s more uncertainty, so there’s a more significant need for discovery. The items you deliver are often for the purposes of learning through feedback.
As you move into maintenance mode for your product, make sure your discovery effort decreases, with the discovery you do being focused on identifying opportunities for improvement. Your efforts should focus on delivering the features that will solve your customers’ problems.
Let’s take a closer look at what each track does on an ongoing basis and how the team ties the activities of both tracks together.
The discovery track
As the leaders of the discovery track, the product trio identifies the outcome the team will focus on and how they’ll measure their progress toward that outcome.
They identify that outcome through interviews and observation to build a deeper understanding of their users. They may use an empathy map during this process to organize their observations and gain insight into what their users do, think, see, and feel.
Once the product trio knows what outcome they’re trying to deliver, they work with the rest of the product team to identify and prioritize ideas and initiatives, and manage the product backlog to help drive progress toward the product goal.
Pro tip: product discovery can be a very fluid activity with new ideas popping up and getting discarded on a regular basis.
Kent McDonald, a product manager at KBPMedia, uses a couple of tools to keep track of his team’s discovery work.
First, he establishes a definition of ready with his team that serves as an agreement about what information a backlog item needs to have for the team to consider it ready to include in a sprint.
The definition of ready may include a description of the change, acceptance criteria, examples of how the change would work, and any sketches that might further explain the intent of the change.
This definition of ready helps the team that’s focused on discovery know what information they need to pull together to best explain the idea and help the team deliver as effectively as possible.
Second, he uses a discovery board to track the progress of backlog items through the discovery process and on their way to meeting the definition of ready.
The discovery board is similar to a board that product teams use to track their work during a sprint, but in this case, the columns are key steps on the team’s self-created discovery process. During one recent project. Kent’s discovery board had the following columns:
New
Needs UX
Ready for Product Trio
Further Analysis
Ready for Sprint Planning
Each team’s discovery board and definition of ready will differ from other teams as these tools reflect a specific approach.
A team may also revise the items in the definition of ready and the columns on the discovery board as they reflect on their work and realize they need to make changes.
The delivery track
The discussion around backlog refinement and sprint planning serve as connection points for discovery and delivery efforts. During backlog refinement, the product team discusses backlog items that the trio identified to ensure everyone has a shared understanding.
Any backlog items that appear to provide a good solution to problems the team is looking to solve will get included in sprint planning, where the product team determines which items they’ll work on in the upcoming sprint.
During the sprint, the product team develops, tests, and delivers the functionality identified in the backlog items during discovery. As development and testing proceed, the product team may identify additional questions. The product trio may answer some of those questions, while others may inspire additional discovery activities and additional backlog items.
When the team practices continuous delivery, they deploy changes to production (and potentially their users) when they are done and get feedback. The product trio will apply that feedback to guide their further discovery efforts, including throwing away some ideas they thought they’d explore next and exploring a new idea that came about due to things they learned from their users.
Tools can help you balance continuous discovery and continuous delivery
When you work on an existing product, product discovery is often a matter of identifying opportunities for improvement that require small code changes that can sometimes offer significant benefits.
As your existing product becomes more complex, you’ll need tools to help you organize your product discovery efforts and stay focused on the changes that will positively impact your customers.
Tools like session recordings and Feedback widgets help you organize information about how people use your product and identify areas where you can make improvements.
With the addition of heatmaps, these tools can also help with your continuous delivery efforts: you can run tests, confidently make changes to existing code, and quickly see whether those changes had any unintended consequences.
When your team uses the right tools to drive continuous discovery and delivery, you can focus your time on making the right product decisions rather than manually testing and releasing updates to your product.
Do your continuous discovery efforts need continuous information?
Hotjar tools provide you with a steady stream of product experience insights that will help you separate good ideas from the bad.
