Understanding Where Value Comes From

In the first article of this series, Discovery Is More Than Understanding the Problem, I explored why effective discovery requires a broader understanding of the environment in which a problem exists. That includes how value is created, what enables it, how different components interact, and whether our understanding holds up against evidence.

This second article focuses on the first of those areas: Domain and Value. Before identifying opportunities or defining solutions, it helps to understand how a business actually works. Not simply what the organization sells, what its products do, or how its teams are structured, but how its activities come together to produce value for customers and the business.

I’ve found that organizations can describe their products, functions, and responsibilities in considerable detail while still having an incomplete understanding of how value moves across them. This becomes particularly important during discovery, when the way a problem is initially presented can influence which solutions are considered.

Understanding the domain before defining the opportunity

When entering an unfamiliar domain, I try to develop a working understanding of its structure before forming strong opinions about what needs to change, whether I know about it or not. That includes the business model, the people involved, the activities that matter, and the outcomes the organization is trying to produce.

This doesn’t mean becoming an expert in every aspect of the industry. It means coming in unbiased and with fresh eyes to develop enough context to recognize how the major components relate to one another and where deeper investigation may be necessary.

Working across different industries has taught me that similar technologies can serve very different purposes depending on the environment. A data platform supporting marketing decisions, for example, operates within a different set of workflows, incentives, and expectations than one supporting internal business intelligence or product experimentation.

The technology may share familiar characteristics, but its value depends on the business activities it enables. Understanding those activities changes how a problem is evaluated and what deserves attention during discovery.

Following the value chain

A value chain connects what an organization does to the outcomes those activities are intended to produce. I’ve found this perspective particularly useful because it shifts attention away from isolated functions and toward the relationships between them.

This connects naturally to process thinking and value stream mapping, where the focus is on how activities and information move through a system to produce an outcome. The objective isn’t necessarily to document every step, but to understand where value is created, where it depends on other activities, and where it may be interrupted.

In my work with analytics and data operations, the quality of an outcome has often depended on activities that happen well before the final product or report reaches its user. Data collection, processing, interpretation, and activation may involve different systems and teams, each with its own responsibilities.

Looking only at the final output can hide problems elsewhere in that chain. A reporting issue may originate in how information was collected, while a delay in launching a capability may have more to do with operational handoffs than the technology itself.

Understanding how value flows through these activities provides a broader perspective on where friction exists and where improvements might have the greatest effect. It also helps distinguish activities that create value directly from those that enable, support, or protect it. Both matter and contribute in different ways.

Users and the reality of workflows

Understanding the value chain is only part of the picture. The people participating in it, and how they actually perform their work, are equally -if not more- important.

Across internal platforms and customer-facing products, I’ve seen how the intended experience can differ from operational reality. Processes that appear straightforward in a diagram may involve manual coordination, workarounds, repeated validation, or dependencies that are invisible to someone outside the workflow.

These details matter because users experience systems through the work they are trying to accomplish, not through the organizational or technical boundaries used to design them.

In enterprise environments, the user is not always the person who ultimately receives the business value.

• An analyst may use a platform to produce information for a decision-maker.
• A product team may use experimentation capabilities to improve an experience for customers.
• An operational team may maintain data or processes that enable another function to deliver its work.

Each participant has different needs, but their activities are connected through the value being created. Understanding users in the context of their responsibilities, decisions, and workflows provides a more useful perspective than treating their needs as independent requests.

Where the gaps become visible

One recurring lesson from my work across product, engineering, analytics, and business functions is that different teams often have legitimate but incomplete or biased perspectives on the same process.

A business team may focus on the desired outcome, while an operational team sees the coordination required to deliver it. A product team may concentrate on the user experience, while engineering understands the systems and dependencies supporting it. None of these perspectives is necessarily incorrect. The gaps often emerge from how they connect.

I’ve worked on initiatives involving measurement practices, data products, and experimentation capabilities where improvements depended on more than introducing new functionality. Aligning definitions, clarifying responsibilities, adjusting workflows, and making capabilities usable within existing operations were also important parts of the work.

These experiences reinforced an important distinction for me: value is not created simply because a capability exists. It depends on how that capability participates in the larger flow of work and whether people can use it effectively.

From understanding value to identifying opportunities

Tracing the domain, value chain, users, and workflows doesn’t automatically reveal the right strategy. It does, however, change the quality of the questions we can ask.

Instead of evaluating an isolated request, we can examine the outcome it supports. Instead of assuming a new feature will resolve a problem, we can consider whether the underlying workflow, information, or coordination needs attention.

This broader understanding also helps distinguish symptoms from underlying causes. What appears to be a technology limitation may involve process design. What looks like a user adoption problem may reflect a mismatch between a capability and the way work is performed.

For me, developing this understanding is an important part of discovery because it provides context for identifying where change might genuinely matter. It also helps avoid defining opportunities around organizational boundaries or individual requests without considering the larger system.

But understanding how value is created doesn’t tell us everything about what makes it possible. Behind those activities are systems, data structures, integrations, and technical decisions that can enable or constrain the business.

In the next article, we’ll explore Enablement: the systems, data, and intelligence behind the capabilities that make value creation possible.