The Systems Behind the Experience

In the previous article, Understanding Where Value Comes From, we explored how value moves through a business, from the activities that create it to the users and workflows that deliver it. Understanding that flow provides an important foundation for discovery, but it leaves another question unanswered: what makes those activities possible?

Behind every product, service, or business process is an enabling environment. Applications, platforms, data structures, integrations, and increasingly intelligent systems support how work gets done. Some are directly visible to users, while others operate entirely in the background. Together, they shape what an organization can deliver, how reliably it can operate, and how easily it can adapt.

This is the second area of the Structured Discovery idea: Enablement. It involves looking beyond what a capability does to understand the systems, data, and intelligence that make it work.

The experience is only the visible layer

A product experience can appear simple while relying on a complicated set of capabilities underneath. Consider an e-commerce experience that presents personalized recommendations. What the customer sees is a selection of products, but delivering that experience may depend on customer identity, behavioral data, product catalogs, recommendation models, decision rules, and systems capable of responding in real time. What happens behind the scenes carries a lot more weight in the discovery than expected.

The experience is the visible result of those components working together. Understanding the interface alone provides little insight into how the capability actually operates or what would be required to improve it.

I’ve encountered this distinction repeatedly when working with website development in my early days, to analytics, experimentation, and enterprise platforms more recently. A seemingly straightforward request, such as introducing a new measurement capability or making information available to another team, can involve changes across data collection, processing, integrations, and the applications consuming that information.

These dependencies are not necessarily problems. They are part of how technology enables business capabilities. The challenge during discovery is understanding enough of that environment to distinguish what appears simple from what is actually simple, and to recognize where opportunities or limitations may exist.

Understanding the systems that enable work

Technology environments are often described through their individual applications or platforms. While those boundaries are useful for ownership and development, they don’t always explain how a business capability operates from beginning to end.

This is where architectural thinking becomes useful. Beyond understanding individual technologies, it provides a way to examine how capabilities are organized, how systems support one another, and how technical decisions relate to the work the business needs to accomplish.

A customer-facing application may depend on internal services, external providers, shared infrastructure, and operational tools. An analytics product may rely on several upstream systems before information reaches the people making decisions. Understanding the role of each component matters, but so does understanding the pipelines, or how information and activity move between them.

In my experience the most useful technical conversations have often started with the capability we were trying to enable rather than a particular technology.

• What information does the capability require?
• Where does it originate?
• How does it move through the environment?
• What needs to happen before a user can act on it?

These questions help connect technical architecture to business purpose without requiring discovery to become a detailed technical or engineering exercise. They also reveal where existing capabilities overlap and can be reused, where additional integration may be needed, and where the current environment may limit what is possible.

Data is part of the operating model

Data deserves particular attention because it connects operational activity with measurement, decision-making, and increasingly automated capabilities.

Organizations often possess considerable amounts of data without necessarily having the structures needed to use it consistently. Information may be collected differently across products, defined differently by teams, or stored in ways that make it difficult to connect. These differences can remain largely invisible until someone attempts to build a shared capability or compare performance across the business.

Working on data and analytics platforms has reinforced how much depends on the underlying data model. Establishing common definitions, aligning events and metrics, and connecting information across systems can be just as important as the applications that eventually present or consume it.

For example, two teams may define customer engagement differently and produce conflicting results, even when both reporting systems work correctly. Without consistent data definitions, comparing performance and making informed decisions becomes difficult.

The issue goes beyond reporting. How data is defined, structured, and connected determines what systems can measure, understand, and support. That’s why examining data is an essential part of understanding what a business capability can actually deliver.

From information to intelligence

The enablement layer becomes more interesting when systems move beyond storing and presenting information to interpreting it and supporting decisions.

Analytics, experimentation, predictive models, and AI-enabled capabilities can all contribute to this intelligence. They serve different purposes, but each depends on a relationship between available information, the decisions being made, and the actions that follow.

An experimentation platform, for example, is not simply a tool for dividing traffic and reporting results. Its value depends on how experiments are assigned, how outcomes are measured, how statistical evidence is interpreted, and how teams use those findings to make product decisions.

Similarly, an AI-enabled capability is not defined solely by the model it uses. Its usefulness depends on the quality and relevance of the information available, the workflow it supports, and the degree to which its outputs can be trusted and acted upon.

Working across measurement, experimentation, and AI-enabled products has reinforced a simple lesson: more intelligence doesn’t necessarily mean better decisions. Its value depends on whether it helps people or systems make more informed choices.

During discovery, the focus should therefore be on understanding the decisions a capability needs to support before determining what technology should enable them, a consideration often overlooked in favor of personal preferences.

Technical understanding without knowing everything

Examining enablement requires technical curiosity, but it does not mean that one person needs to understand every system at an engineering level.

Complex technology environments involve specialized knowledge across architecture, infrastructure, data engineering, security, analytics, and application development. The depth required in each area depends on the problem being explored.

This also reflects an important principle of systems thinking: understanding a complex environment doesn’t require mastering every component independently. It requires recognizing how specialized knowledge contributes to an understanding of the whole, including the relationships that might otherwise remain invisible. The next step is to empower those who hold that knowledge, draw on their expertise, collaborate and learn along the way.

One lesson from leading cross-functional product and technology work is that understanding the right questions to ask can be as important as having the answers yourself. Engineers may recognize architectural limitations, data specialists may identify inconsistencies in the available information, and operational teams may expose requirements that are not apparent from the technical design.

Bringing those perspectives together helps establish a shared understanding of what the technology currently enables and what changes might be necessary. It also helps separate technical possibilities from practical capabilities. Something may be technically achievable but difficult to operate, expensive to maintain, or poorly suited to the workflow it is intended to support.

That distinction matters when moving from discovery into strategy. A direction that looks attractive in isolation may become less compelling once its technical and operational implications are understood.

Connecting enablement to value

The purpose of examining systems, data, and intelligence is not to produce an inventory of technology. It is to understand how those components contribute to the capabilities that create value while respecting the boundaries of each practice.

This perspective can reveal opportunities to reuse existing infrastructure, improve information flows, simplify workflows, or introduce new capabilities. It can also expose limitations that should influence how an opportunity is evaluated before significant commitments are made.

The relationship works in both directions. Business needs help determining which technical capabilities matter, while the existing technical environment shapes what the business can realistically accomplish. Understanding one without the other leaves an incomplete picture.

At this point in discovery, we have explored how value is created and what enables it. But knowing the individual components, even in considerable detail, does not mean we understand the system as a whole.

The next challenge is examining how those components interact, where dependencies and constraints emerge, and what tradeoffs they introduce.

In the next article, we’ll explore Relationships and Constraints: why some of the most important insights emerge not from the individual components, but from the connections between them.