Product discovery vs. delivery: How to uncover what your users need

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.

What’s the difference between product discovery and product delivery?

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:

• Product discovery means uncovering what creates value
• Product delivery means producing what creates value

Now, I must clarify some aspects of this before we continue:

• Responsibilities — Don’t split discovery and delivery between different teams. This will lead to a lack of accountabilities, unnecessary handovers, confusion, and, ultimately, watered-down results
• Phases — Don’t treat discovery and delivery as distinct phases. Both are continuous and overlap. Discovery enables meaningful delivery and delivery creates evidence for a clearer understanding of the problem
• Learning — Discovery won’t ensure you know what creates value; it will produce learnings that increase your chances of success. Discovery also reduces the chances of developing pointless features. It’s not a silver bullet but a way of creating value faster

What happens during product discovery and delivery?

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.

Product discovery

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?

User research

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.

Problem framing

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.

Experiments

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.

Avoid common traps

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 delivery

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:

• Release frequently — The shorter your release cycle is, the faster you learn. Outstanding product companies do several releases per day. Of course, you need to understand your scenario. You cannot move from three months’ release to daily. But you can move to monthly, bi-weekly, weekly, and daily
• Measure results — Never assume impact. Measure the result. It’s not about measuring how long you took to get a solution live but understanding how it creates value. Build to learn
• Scale gradually — In the past, teams used to invest months implementing solutions, then releasing them to the whole audience at once. This approach is dangerous. If something goes wrong, it’ll impact your entire audience. A better approach is starting with a smaller audience and scaling gradually based on evidence

“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

Balancing discovery and delivery

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.”

Teressa Torres

Challenges of balancing product discovery and delivery

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.

1. 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

2. 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.

3. 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 — That will block you from continuous learning
• Don’t do discovery in a separate team — 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 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:

• 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.

Be curious and humble

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.