What product discovery usually means

Most teams think of product discovery as a familiar set of activities:

• Talking to users and running contextual interviews to explore real-world use.
• Analysing data to understand how products perform in practice.
• Conducting usability testing and evaluations to spot friction points.
• Mapping service journeys to reveal where user experience breaks down.

All of this is essential. But it’s also incomplete.

Traditional discovery focuses on the product–user relationship: what’s being built, how it works, and how people respond to it.

But on its own, you risk getting a flat, one-sided picture. Use these insights to fix the product, and you’ll likely end up right back where you started.

When product issues are really governance issues

A while back, our team reviewed the digital ecosystem for a high-profile, nationwide service. On paper, the task was simple: make it easier for people to access life-changing services. But as we traced real user journeys, the problem turned out not to be the interface at all.

The digital front end, the underlying transaction system, and the policy rules that drove both were owned by different divisions, funded separately, and managed by disconnected measures of success. No one team could see — let alone steer — the whole system.

What users experienced as a “complicated system” was really a governance issue: a product working exactly as the organisation had allowed it to.

Once the organisation could see that, the conversation shifted from “how do we fix the product?” to “how do we fix how we run the product?”

That moment is common across many sectors, especially in enterprise and public services. Many digital products work perfectly inside their own walls, yet fail when they meet structures that slice responsibility by portfolio instead of user need.

The org chart reveals the fault lines in the user experience.

The system around products

Studies on digital transformation show that product outcomes correlate more strongly with operating model maturity than with design or technical sophistication.

Recent research by McKinsey shows that organisations with more mature product operating models generate around 60% higher returns to shareholders than less mature peers.

“Among the five core areas of a product and platform operating model, ‘ways of working’ has the strongest correlation with overall business performance.”

Delivery maturity matters more than tooling or tech stack — yet “ways of working” is also the least mature dimension across industries.

In Inspired, Marty Cagan highlights the difference between teams who ship features and teams who solve problems:

“It’s all about solving problems, not implementing features. Strong teams ensure the solution solves the underlying problem.”

Most teams, particularly in large organisations and public services, lack clarity on the connection between their output and the underlying problem it aims to solve.

Melissa Perri calls this the build trap:

“The build trap is when organisations measure success by outputs rather than outcomes. It’s when they focus more on shipping and developing features rather than on the actual value those things produce.”

You should absolutely still do all your product discovery activities. The product may be wrong — but often it’s wrong because the system is.

How you know it’s not “just” a product problem

There are signs that should get your attention during discovery. These indicators usually surface while talking to your product team and signal that you need to explore people and process more deeply.

You know you’ve got more work to do when:

• Priorities shift faster than anyone can keep up with.
• Ownership blurs. No one can say who defines success or who can stop an unhelpful feature.
• Teams are exhausted but progress is slow. Busyness hides systemic blockage.

These are clear clues that your “product” issue is a governance or culture issue wearing a different coat.

Getting permission to look beyond the product

Expanding discovery to include people and process can feel political. It means asking questions about power, decision flow, and accountability.

The trick is to position the shift as risk reduction, not extra scope.

“We’ll start by assessing product performance, then extend the insight into how governance and decision-making have shaped what we’re seeing. That lets us tackle causes, not just symptoms.”

Make the first step small: a short decision-flow workshop, or a couple of sessions to understand product strategy and how priorities are set and measured. These exercises are low-risk and high-value: they reveal where process or incentives quietly undermine delivery.

This approach aligns with how mature digital organisations work. Thought leaders like Teresa Torres and John Cutler argue that continuous discovery includes the system: the rhythms and rituals that decide which ideas survive.

Do one thing on your next discovery

If you do one thing differently on your next product discovery, do this:

Pick a single feature and trace its journey from idea to release.

Who asked for it? Who approved it? Who funded it? Who tested and measured it? What changed along the way — the team, the priorities, the constraints?

You’ll probably find that what broke wasn’t the feature, but the path it travelled.

Once you can see that, you’re already halfway into people-and-process discovery — where the real levers for change live.

Coming soon! Next in the series:

People Discovery: Culture as the Invisible Interface

If products are shaped by the systems around them, then systems are sustained by the people inside them: incentives, hierarchies, and unspoken rules.

In Part 2, we explore how culture, confidence, and power structures determine what gets built — and how observing decision forums, mapping relationships, and surfacing friction points reveal things usability testing won’t.