Discovery Is More Than Understanding the Problem

Over the years, working across different industries, technologies, and business functions has shaped how I approach discovery. But the foundation of that thinking goes back to my background in industrial engineering.

Industrial engineering trained me to look at systems as a whole: how processes work, how resources and information flow, where dependencies and constraints exist, and how changes in one part of a system affect another. It taught me to look beyond individual activities and understand how the pieces work together to produce an outcome. That perspective has stayed with me throughout my career, from design and analytics to experimentation, product development, and technology leadership.

One thing I’ve learned is that understanding a problem and understanding the environment in which that problem exists are not necessarily the same thing.

In product development, discovery is often associated with identifying user needs, validating problems, and exploring potential solutions. These are essential activities, but in my experience they don’t always provide all the context needed to make informed decisions, particularly in complex business and technology environments. A user may experience friction in a workflow, but the source of that friction might be a disconnected system, an inconsistent data model, an operational dependency, or a business decision made elsewhere in the organization. What appears to be a product problem may have little to do with the product itself.

This is where my view of discovery has become broader.

Understanding the environment, not just the problem

Earlier in my career, much of my work involved measurement and analytics. Understanding what people were doing, how systems were performing, and what outcomes were being produced was central to the work. As my responsibilities expanded into experimentation, data platforms, and product leadership, so did the questions I needed to ask and answer.

It was no longer enough to understand what was happening. I needed to understand why, what made it possible, what was preventing better outcomes, and how changes in one part of the environment might affect another. In many ways, this was an extension of the systems and process thinking I had developed through industrial engineering, now applied to business operations, digital products, data, and technology.

This perspective is closely connected to systems thinking: understanding individual components is useful, but understanding how they interact and influence the larger environment is what makes the picture more complete.

Working on internal platforms, customer-facing products, and enterprise capabilities reinforced this perspective. The visible product or experience was often just one part of a much larger operating environment. Also, different disciplines tend to see different parts of the same problem. Business stakeholders understand commercial priorities and operational pressures. Users understand the realities of their daily work. Engineers understand technical dependencies and limitations. Data specialists understand what the available evidence can and cannot support.

Each perspective is valuable, but none necessarily provides a complete picture on its own. For me, discovery has increasingly become an exercise in bringing those perspectives together and developing a connected understanding of the environment before committing to a direction.

My four areas of discovery

While the nature of discovery changes depending on the domain and the problem, I tend to examine four interconnected areas.

1. Domain and Value

I start by understanding the domain itself.

• What are the business goals?
• How does the business operate?
• Where is value created?
• Who participates in delivering that value, and what workflows connect their activities?

I’ve found that understanding how work actually happens can reveal a different picture from how a business describes its products, capabilities, or organizational structure. Following the flow of value provides context that individual functions or product boundaries may not reveal.

2. Enablement

Behind every workflow is an enabling environment. Applications, platforms, integrations, data models, and increasingly intelligent systems all influence what an organization can accomplish.

My experience developing and managing data and experimentation platforms has reinforced how important this layer is. A capability may appear straightforward from the user’s perspective while depending on a complicated set of technical and operational conditions. Understanding those conditions is essential to evaluating what is possible, what needs to change, and where new capabilities might create value.

3. Relationships and Constraints

Individual components rarely tell the whole story. A workflow may depend on multiple teams, a product capability may rely on data generated elsewhere, and a technical decision may introduce operational consequences that are not immediately visible.

The same thing applies to individuals. I’ve encountered these relationships repeatedly when working across product, engineering, data, and business teams. The challenge is not simply identifying the contributors, but understanding how they interact, where dependencies exist, and which constraints or tradeoffs influence the available choices.

4. Evidence and Reality

Even a well-constructed understanding needs to be challenged. My background in analytics and experimentation has made me particularly conscious of the distance that can exist between what we believe is happening and what the evidence actually shows.

Usage patterns, operational performance, economics, voice of the customer, and technical measurements can reinforce an initial understanding or expose weaknesses in it. Discovery needs that confrontation with reality. Otherwise, we risk building convincing explanations around incomplete assumptions.

Connecting the pieces

I don’t see these four areas as a rigid sequence.

• Understanding a workflow may expose a technical dependency worth investigating.
• Examining a data model may reveal that a business metric is being interpreted incorrectly.
• Evidence from actual usage may challenge the original understanding of a user’s needs.

Each finding can change how the others are understood.

This is also why I place considerable value on working with people who bring different expertise to the table. I don’t believe effective discovery requires one person to have all the answers. In complex environments, that expectation is rarely realistic. What matters is the ability to ask useful questions, recognize where deeper expertise is needed, and connect what different specialists know into a coherent picture.

My role as a product leader has often involved creating that shared understanding, working across disciplines to connect business needs, technical possibilities, and operational realities. Translating needs and findings into a shared language. The objective isn’t to become an expert in every component. It’s to make the collective expertise useful in reaching better decisions.

From discovery to direction

Understanding is not the end goal. Discovery should ultimately help us make choices:

• Which problems deserve attention.
• Which opportunities are worth pursuing.
• What capabilities need to change.
• What tradeoffs we are prepared to make.

A broader understanding doesn’t eliminate uncertainty or guarantee that every decision will be correct. It does, however, provide a more informed basis for deciding where to invest time, resources, and effort. I’ve found this particularly important when working in unfamiliar domains or environments where different teams hold different pieces of the information needed to move forward.

The ability to build understanding becomes as important as the knowledge you bring into the room.

Exploring discovery as a discipline

This article introduces a series exploring the four areas that have shaped my approach to discovery. I’ll look more closely at understanding how value is created, examining the technology and capabilities that enable it, reasoning through relationships and constraints, and challenging assumptions with evidence.

These reflections come from working across different disciplines and environments, developing products and platforms, and navigating the practical realities of turning ideas into functioning capabilities. They are not intended as a universal methodology or a step-by-step guide, but as perspectives and lessons that continue to influence how I approach new challenges.

For me, effective discovery is not simply about finding a problem worth solving. It’s about developing enough understanding of the environment to make informed decisions about what should happen next.