Product Discovery and Delivery are better together.
I have experienced an interesting trend in the Agile and Scrum space this year. At first, it seems like a step to get us closer to our customer’s needs. But as I peel back the onion, I have seen how it can lead us down a treacherous path.
The trend involves Product Discovery. Several companies have approached me with a request, such as:
“We need a Product Discovery coach to help build capable Discovery Teams and improve the intake of backlog items with Delivery Teams.”
At first, the notion of Product Discovery coaching sounds intriguing. Design Thinking, customer research, and lightweight prototyping are engaging activities. Plus, exploring what customers need by engaging with them is not commonplace in today’s Scrum teams.
But my excitement dissipates when I absorb the rest of the request: “…and improve the intake of backlog items with Delivery Teams.”
This makes me realize the request for what it is. The ask is to coach traditional behavior disguised with fancy, new terminology. Splitting Product Discovery and Delivery across two teams is a form of a functional silo.
In my experience, splitting these critical product development activities across teams is problematic.
The desire to split Discovery and Delivery stems from an unfortunate misinterpretation. In error, we assume Scrum is only concerned with creating working software. So we form a separate Discovery Team to take a customer-focused view.
Often, this is a consequence of The Scrum Guide’s lack of guidance on “how” to deliver a valuable product.
“Scrum: A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”
—The Scrum Guide
My coaching these days focuses on integrating Discovery and Delivery using Scrum. I will get to this in a moment. But first, let’s explore what can go wrong if you decide to split Discovery and Delivery.
The Perils of Separating Discovery and Delivery
Splitting Discovery and Delivery results in two teams. One team focuses on Discovery and one focuses on Delivery. Each team is likely using the Scrum framework for its own narrow focus.
Often, a wall exists between the two teams. This is usually fortified through a digital Product Backlog.
Discovery includes defining product strategy, gaining customer empathy, and designing the customer experience. Design thinking, lean user experience design, and high user engagement are the hallmarks of the Discovery Team’s approach.
Delivery focuses on technology design and development to form a working product. The Delivery Team’s understanding originates from documentation in the Product Backlog.
Unfortunately, Delivery Teams have minimal contact with the end customer. And they are often disconnected from their Product’s purpose.
Each team is, more often than not, adept at Scrum for its localized focus. But I am sure your mind is already deducing the systemic pitfalls of this approach. The problems fall into three categories.
Pitfall №1–Diminished Shared Understanding
Shared understanding is the lifeblood of a high-functioning product team. To deliver a product, you need both sides of the coin—Discovery and Delivery. Splitting these activities between two teams segregates critical knowledge and expertise. And it leads to suboptimal and, often, wrong decisions.
The following behaviors have a negative impact on shared understanding:
- Over-reliance on documentation to communicate between teams
- Each team aims for a partial Definition of Done
- Disconnection of the Delivery Team from the customer
- Formulation of solutions by the Discovery Team without feasibility input
- Turf-building and lack of a one-team mentality
Pitfall №2–Slow Feedback & Limited Learning
At its worst, Discovery happens in a big, upfront chunk before handoff to the Delivery Team. At its best, the Discovery Team works a few Sprints ahead of the Delivery Team. Regardless, the feedback loop diminishes between the Discovery and Delivery teams.
In the end, the timeline for gathering customer feedback on working features elongates. This delays learning from customer findings and insights. So it takes longer to emerge the “Right” product when you separate Discovery and Delivery. This results in a longer time to market and an increased cost of delay.
Pitfall №3–Increased Lead Time
Lead time is the time required to get from concept to cash — from idea to user adoption and business impact. Separation of Discovery and Delivery into two teams creates waste. In fact, you experience each of the seven lean software development wastes 1:
- Handoffs: The transition from Discovery to Delivery results in misunderstandings and rework.
- Defects: Incorrect interpretation of customer needs resulting from batch handoff and communication hurdles.
- Extra Features: The Discovery Team designs without Delivery Team validation. The Delivery Team creates an architecture runway with unnecessary elements while waiting on Discovery.
- Extra Processing: Keeping the two teams in sync requires extra coordination.
- Partially Done Work: Batches of incomplete work pile up from Discovery activities waiting on Delivery.
- Delays & Waiting:. The Delivery Team waits on the Discovery Team’s output. The Discovery Team waits on the Delivery Team to catch up. And the customer waits due to increased waste in the process. And if anything needs to change, the delays keep adding up.
- Task Switching: Because Discovery and Delivery Teams don’t work on the same thing at the same time, they interrupt each other with concerns and questions.
Combining Discovery and Delivery Into One Team
The three perils of separating Discovery and Delivery now have your attention. So let’s talk about the solution. You will find it to be simple.
Instead of a Discovery Team and a Delivery Team, we need one team—a Product Team.
“Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.”
—The Scrum Guide
The Agile mindset focuses on the continuous delivery of value to customers. To emerge value, the Product Team must know its customers and its business and the needs of each. And the team must have rapid and early iteration to arrive at the “Right” product.
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
How does this work?
The model is simple. You have one small, cross-functional Product Team, which focuses on Discovery and Delivery. The team’s goal is to emerge the right product for its customers and its business.
During Discovery, the team forms an understanding of the purpose of its product and the “why” behind it. The team builds an understanding of the goals of its customers, its business, and its own team members. And then, the team defines the target outcomes and impact of its product.
The Product Backlog ceases to serve as a communication layer between the teams. Instead, it becomes a repository of options to try for achieving the target outcomes. And the team evolves the options from direct customer engagement feedback.
After the team devises options to meet the target outcome, Delivery commences. Here, the team assesses which option to try next and the learning objectives.
The team will choose to build a lightweight experiment if the option uncertainty is high. This might take the form of a questionnaire or a lightweight prototype. But if the team is more certain about the option, it will deliver releasable working software.
In either case, the team will gather direct customer feedback on what it builds. This allows them to gain critical insights.
The insights from Delivery feed back into Discovery. The cycle continues until the “Right” product to release emerges.
What Improved Results Should You Expect?
The perils of the separate team approach evaporate when you have one Product Team focused on Discovery and Delivery. And there are notable improvements with the Product team approach. These fall into three primary areas.
Improvement №1–Seamless Shared Understanding & Purpose
Full team participation in Discovery and Delivery results in high shared understanding. Collaboration is rich, with high-bandwidth communication methods. The team members no longer rely on backlogs and documentation to communicate.
An interesting side-effect emerges when the team focuses on all product development aspects. Empathy builds in the team for its customer and its business. Its purpose becomes real.
And the team’s purpose provides a guiding force for everything it does. Team engagement increases.
Improvement №2–An Enhanced Focus on Value
The Product Team has no outside dependencies. It has complete responsibility for understanding its customer and business needs. This removes the seven wastes of the separate team approach.
Having control within the team builds team autonomy. And this autonomy focuses the team on delivering value versus dealing with the waste of the siloed approach.
All team members innovate to devise options for meeting their target outcomes. When this happens, the “Right” product emerges faster. Different perspectives provide the necessary conflict to produce better ideas.
Improvement №3–Rapid Learning
Learning velocity increases when Discovery and Delivery are within one team. This rapid learning happens across two dimensions.
First, the “Right” product emerges faster through lightweight, inexpensive experimentation and iteration. The team navigates using evidence gathered from a rapid feedback cycle. As a result, the team validates ideas and options before investing in them fully.
Second, the team discovers the “Right” way to build the product and they learn from each other. Team members proficient in Discovery and customer experience learn Delivery skills. Those with Delivery expertise gather skills in Discovery.
The higher learning velocity translates into better outcomes, better impact, and better teams.
So What Is The Point?
We started this post on the trend to separate product Discovery and Delivery into two teams. And we reviewed why this is problematic. While well-intentioned, it gets in the way of the effective pursuit of the “Right” product.
But there is a better alternative. One Product Team focused on both Discovery and Delivery leads to great results. You will experience:
- Higher team engagement
- Improved delivery of products your customers need
- Better achievement of your business impacts
So these days, when asked for Product Discovery coaching, I encourage Product Team coaching instead. It is a better, holistic approach. Try it for yourself and experience the power and ease of the Product Team.
Also published in Serious Scrum on Medium.
Related Posts
Read more on the related posts below:
References
- Implementing Lean Software Development — From Concept to Cash, Mary and Tom Poppendieck — Sept 7, 2006 ↩
Todd Lankford unlocks Lean Leverage in organizations to cultivate powerful, engaged product teams who maximize outcomes and impact.
His articles share his experiences and learnings along the way. Join the mailing list to get them in your inbox.