Creating digital products is challenging but often gets unnecessarily overcomplicated. Let’s look at two core aspects: product discovery and delivery. What are they for?
Product discovery uncovers what drives value, while product delivery builds what creates value.
Sounds simple, right?
It’s indeed simple, but teams face daunting situations when discovery and delivery are unbalanced. Let us explore two dangerous scenarios.
Let me help you out with this post.
Before we get into the details, I recently launched a self-paced Product Discovery video course that resonated with people worldwide. Join us if you want to step up your game and learn how to drive value when everyone distracts you.
Delivery is all that matters
The most common scenario I experienced with product teams has the following traits:
Delivering features on time and cost has the highest priority
Product discovery happens outside the product team
Features focus on requirements, not desired results
No matter how fast teams deliver, it’s never enough
This scenario is unsustainable.
When all energy goes into the present, somebody else will build the future.
You will observe some signs when the delivery obsession trap is around:
Extensive product backlogs
Feature roadmaps
Inability to set Sprint goals
Success = delivering features on time
Nobody measures the value delivered per feature created
Discovery is all that matters
Some teams become so risk-averse that committing to delivery frightens them. When that happens, product discovery becomes an obsession. You will observe the following:
Open-ended product discovery
Excessive product experiments and little or no commitment to delivery
Lack of focus on business goals
Extreme focus on what customers need while ignoring what drives business outcomes
The challenge of this scenario is that teams live in the future while forgetting the present.
When all energy goes to the future, somebody else will build the present.
This situation is frustrating because despite learning from customers, teams struggle to deliver what pushes the business forward. The following hints the discovery obsession trap got you:
Business stakeholders are frustrated with teams’ results
The product evolves slower than acceptable
Product backlogs are either nearly empty or loaded with discovery topics
The more teams discover, the more they want to discover
Both scenarios above are terrible for product teams. Let’s explore what works.
A sustainable balance between discovery and delivery
The difficulty of creating digital products is accepting our lack of knowledge.
We don’t know what we don’t know. It took me a long time to understand that, which led to painful failures.
When we overestimate our knowledge, we create features nobody needs. That’s why balancing discovery and delivery is essential. The question is how?
Let’s start with what not to do:
Don’t treat product discovery as a phase before delivery because that will block you from continuous learning
Don’t do discovery in a separate team because that will eliminate end-to-end responsibility
The product team should be responsible for both discovery and delivery.
End-to-end responsibilities enable a change of direction whenever necessary, and it avoids a blame game as the team is fully accountable for its fate.
Now, let’s bring down to earth how it is to balance discovery and delivery in a product team. Suppose you have a team with seven people: five software developers, a product manager, and a product designer. Part of the team should invest 80% of their time in discovery and 20% in delivery, the other 80% in delivery and 20% in discovery. How does that work?
I like following Teresa Torre’s product trio advice for continuous discovery practices.
Set a trio with different expertise, e.g., product manager, product designer, and product engineer. The trio is in charge of:
Understanding customer journey
Uncovering opportunities that create customer and business value
Prioritize opportunities worth pursuing
Share insights and learnings with the whole product team
The other part of the team focuses on delivery. Yet, that doesn’t mean they do as they are told. It means they understand the problem space to build valuable solutions. They will:
Know the problem they aim to solve before defining solutions
Understand what success looks like
First, build to learn, then to scale
Deliberate use of tech debt to accelerate learning
Pay off tech debt when a solution is worth remaining in the product
You may wonder if that doesn’t create two teams inside one. That won’t happen if the team does the following:
Share a common goal. While part of the team discovers value drivers to reach the goal, the other part strives to deliver what they know drives value.
Ideate on the future together. This is the part where the future meets the present. The product trio shares learning, and the whole team reinvents the future.
Make informed decisions on what to pursue and what to drop. The team accepts that not all solutions will go from scratch to product. They continuously evaluate if the delivered results are reached and decide what’s best for the product, customer, and business.
Measure value created from released features. Creating new features isn’t the goal. Driving value is. The team relentlessly monitors the value features created and takes corrective action whenever necessary.
A successful product team knows how to handle dual-track activities. They know how to navigate between the present and the future. They collaborate instead of coordinating activities. Beyond that, they trust each other.
When teams learn to balance discovery and delivery, they create solutions that users love and businesses benefit from. Ultimately, team morale grows, and creating digital products becomes fun instead of stressful.
Product discovery done right helps you learn when you’re wrong.
Mindful product delivery enables value creation for both customers and businesses.
If this post spoke to you, my book, Untrapping Product Teams, will resonate with you. Get a copy for you to learn what it takes to drive value :)
Let’s rock the Product world together!
Here are a few ways I can help you even more:
Upgrade your subscription to Premium and get one deeply thought newsletter per month (20+ minutes reading) plus access to 300+ episodes.
Join my cohort, Product Discovery Done Right
Have a lovely day
I love this approach
Amazing post David! I'm just wondering how to balance the workload of the UX contributor (let's take your example). This person will be pretty involved in Discovery activities, but it is also required to deliver a lot of artifacts for the rest of the team.
I don't see this happening with Devs or PMs because they can rely on other teammates or even do not need to build something shippable.
Any thoughts on this? Thanks!