Editor’s note: This article was updated on 25 July 2024 to discuss the challenges of balancing discovery and delivery in more detail.
How much time do you spend talking about features? How much time do you spend understanding end users’ problems?
If you asked me these questions several years ago, I’d say I spent at least 90 percent of my time talking about features. As embarrassing as it can be, I barely understood end user problems.
Teams receive pressure from all layers of the organization. Everyone has a brilliant idea that they’re sure will change the business forever. Others have urgent and important issues to solve. And you’re in the middle of this mess, trying to figure out how to create value.
It’s easy to do what others want. It’s hard to do what they need.
Without a meaningful balance between discovery and delivery, you’re more likely to create crap than value. Sadly, many teams invest too much time delivering and too little time discovering what matters.
Let me elaborate on some discovery and delivery strategies that I’ve seen to be sustainable for product teams to create value steadily.
Although the difference might be obvious, what I observe in the corporate world confuses me.
I see too many teams putting their energy into delivery without knowing which problem they’re ultimately solving. Meanwhile, I see too few teams striving for problem understanding before coming up with solutions.
The Agile Product Manifesto espouses “understanding the problem over thinking of solutions.” Here’s my simplified explanation of this tenet when it comes to discovery and delivery:
Now, I must clarify some aspects of this before we continue:
To create outstanding products, you need to master both discovery and delivery. I won’t go deep into how you do each of them, but I’ll share what great results look like for each phase.
Many people think that product discovery is about validating ideas. I’d disagree with that. Product discovery is all about understanding end users’ problems, then uncovering opportunities to create business outcomes.
It’s fundamental to understand that product discovery happens in the problem space. Yet, it’s easy to slide into the solution space and mess around.
A problem can be solved in multiple ways. If you’re talking about something you can only solve in one way, that’s a solution, not a problem. Step back, and go to the problem space.
So, what happens during product discovery?
Strive to understand your users’ scenario, what matters to them, what jobs they want to get done, their pains, and their wishes. It’s all about understanding what your users care about and identifying opportunities to improve their lives.
The more you understand your users, the clearer their problem becomes.
For example, you know how users care about it, how many users are impacted, how often they face this issue, and how that can enable business value.
Good problem framing makes it easy to decide which problems are worth solving.
Run product experiments to understand what works and what doesn’t.
Experiments are fast and short. You’re talking about hours or days, not weeks. Experiments have expected results, and you decide upon them whether to scale up, pivot, or drop it.
Good product discovery won’t confirm your assumptions, but it’ll uncover the unknown.
A falsification mindset is powerful in creating knowledge. Instead of striving to validate assumptions, you aim to prove yourself wrong. With such openness, you can avoid confirmation bias and commitment escalation.
Product discovery isn’t just an input to product delivery. They overlap and happen in parallel.
Treating delivery as a phase after discovery will create a waterfall effect and trap the team.
It’s not about receiving requirements and implementing solutions. It’s about building to learn and scaling up based on evidence.
After a successful discovery, you may get excited about the solution you uncovered. Be careful: just because it worked with a smaller user group doesn’t mean it’ll work with a bigger cohort.
Keep a learning mindset throughout the journey.
To make product discovery endeavors successful, you should:
“Winning products come from the deep understanding of the user’s needs combined with an equally deep understanding of what’s just now possible.”
—  Marty Cagan
Our current challenge is dealing with pressure for more output.
Delivering more features doesn’t mean creating more value; you’ve got to find out what creates value.
As Albert Einstein once said, “If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and five minutes thinking about solutions.”
This quote has variations — sometimes it’s 50 minutes thinking, or 59 — but you get the point 🙂
Curiously, in the digital product world, the balance between discovery and delivery seems to be inverted. I generally find teams investing no more than 10 percent of their time and effort in discovery. I wonder how they can create value without precisely understanding problems. This puzzles me.
A more sustainable balance would be 75 percent discovery and 25 percent delivery:
Do you think I’m exaggerating? Not really. I’m just afraid of creating bullshit. I want to increase the odds of thriving.
Discovery is continuous. The magic of discovery lies in uncovering what you don’t know.
You’ll inevitably realize that most of your ideas won’t work. And that’s fine, because it helps you avoid creating something nobody needs.
Given that most of your ideas won’t work, you need to invest time continuously in understanding your users and testing different ideas. That’s why it’s critical to put proper attention to discovery.
“The hard reality is that product strategy doesn’t happen in the solution space.”
Sadly, the world isn’t black and white; teams quickly fall into undesired situations, which prevent them from applying mindful product discovery. Let me share three different scenarios, their characteristics, and their impacts.
The most common scenario I experienced with product teams has the following traits:
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:
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:
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:
Both scenarios above are terrible for product teams. Let’s explore what works.
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:
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 percent of their time in discovery and 20 percent in delivery, the other 80 percent in delivery and 20 percent 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:
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:
You may wonder if that doesn’t create two teams inside one. That won’t happen if the team does the following:
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.
The digital product world is challenging because of its complexity. Curiosity and humility are vital traits to enable you to succeed.
You should be curious to discover untraveled roads and humble enough to drop your ideas when you learn they make no sense to your audience.
Great product teams work relentlessly to solve problems. They create state-of-the-art solutions, though that is a means to an end. Solutions are only valuable when people can use them to make their lives better. Otherwise, they are worthless.
You’ve got to pick which problems are worth solving carefully. The way to do that is to master product discovery. Without effective discovery, you’ll fall into endless traps and end up frustrated.
Do what’s right, not what’s easy.
Delivering solutions is easy. Creating valuable solutions is hard.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
As the name alludes to, the way you frame a product significantly changes the way your audience receives it.
A Pareto chart combines a bar chart with a line chart to visually represent the Pareto Principle (80/20 rule).
Brad Ferringo talks about how he helped develop modern “earconography” — sound language that creates context-driven audio notifications.
Without a clear prioritization strategy, your team will struggle to tackle competing demands and can end up confused and misaligned.