Many agile organisations say they value discovery.

They talk about user needs. They talk about experimentation. They talk about learning before building.

Yet in practice, discovery is still one of the first things to be squeezed, rushed, isolated, or misunderstood.

That is rarely because people do not care about discovery. More often, it is because the organisation still treats discovery as something separate from delivery, separate from prioritisation, or owned by one role instead of shaped by several.

One line from my book Agile How To: Succeed as a Product Owner captures the challenge well:

“Product Ownership lies at the heart of Agile product development.”

That matters because when product ownership is reduced to backlog administration, discovery weakens almost immediately.

The trouble usually starts when discovery is treated as something the team should somehow “fit in” around an already committed roadmap.

Stakeholders want certainty. Delivery pressure is rising. Engineering is waiting for clarity. UX is involved, but often not early enough. Product is expected to make sense of it all while still keeping work moving.

So discovery gets compressed into a workshop, a few conversations, or a quick validation exercise before the team moves into build mode. The organisation says it values learning, but behaves as if certainty matters more.

This is where many agile organisations still get caught.

They adopt agile language and agile ceremonies, but still operate through structures and behaviours that reward output over learning.

In Product Agile Harmony (Book coming soon), I make a similar point in very simple terms:

“Digital work is exploratory.” and “Value is learned, not predetermined.”

That distinction is at the centre of why discovery still fails.

When discovery is treated as a phase, teams assume the learning is done before delivery begins.

When discovery is treated as a role, confusion grows further.

When discovery is treated as optional, delivery pressure wins every time.

The better way to see it is this: discovery is not a phase to complete or a role to hand off. It is a shared way of learning that should stay connected to prioritisation, shaping, and delivery.

That is why ownership becomes such a problem in agile organisations.

Many teams ask who owns discovery. The more useful question is: are the right people contributing clearly enough, early enough, and continuously enough?

The Product Manager often helps frame the opportunity space, strategic direction, and broader problem worth solving.

The Product Owner helps translate that into priorities, backlog shaping, and day-to-day trade-offs with the team. In the Product Owner book, I describe discovery as:

“Discovery: The Catalyst for Innovation”

That is exactly how it should be seen, not as a side activity, but as part of how better product decisions are made.

UX brings user insight, usability understanding, and a stronger grasp of the problem space.

Engineering brings feasibility, technical constraint awareness, and practical option shaping that stops discovery becoming detached from delivery reality.

Discovery works best when these perspectives overlap around the same problem. It weakens when discovery is handed from one role to another like a relay baton.

This is where agile organisations often reveal what they truly value.

If the backlog is only a delivery queue, discovery gets squeezed out.

If stakeholder confidence depends on early certainty, discovery gets shortened.

If engineers are measured only on build speed, discovery gets treated as someone else’s work.

If UX is treated like a service function, discovery arrives too late to shape anything meaningful.

If output is rewarded more than improved understanding, teams will naturally rush toward build.

That is not a discovery problem.

It is an organisational design problem.

This is one of the reasons discovery can appear present while being weak in practice. Teams may run workshops. They may hold refinement sessions. They may speak about experimentation. But if learning is still separated from prioritisation, if ownership is still blurred, and if evidence still loses to pressure, the same pattern repeats.

Features get shaped too early. Assumptions stay untested. Teams move quickly toward unclear value.

The answer is not to hand discovery to one role and hope for the best.

The answer is to create clearer contribution across Product Manager, Product Owner, UX, Data Science, and engineering, and to treat discovery as a shared learning activity that stays connected to trade-offs, backlog decisions, and delivery reality.

That is when discovery becomes useful rather than ceremonial.

It stops being a pre-build formality.

It becomes part of how the team thinks.

And that is usually the point where product decisions improve.

If this topic resonates, I explored Agile Product Discovery in more depth in an earlier Agile Product Hub Deep Dive, titled "Agile Product Discovery: Building the Right Thing, Not just hoping to Build the Thing Right". This podcasts discusses discovery pitfalls, spikes, team involvement, and the difference between discovery and delivery. It complements this article well.

#AgileHowToSeries