Idea · Emerging
Structured Discovery
Understanding a problem and understanding the environment that produced it are two different things. A user's friction often originates in a system, a dependency, or a decision made elsewhere, so discovery that stops at the user need routinely locates the problem in the wrong place.
4 connected pieces
systems-thinking-orchestration
Discovery in product development usually means identifying user needs, validating problems, and exploring solutions. Those activities are necessary, and in complex business and technology environments they are not sufficient. The friction a user reports can originate in a disconnected system, an inconsistent data model, an operational dependency, or a decision made somewhere else in the organization entirely.
I treat discovery as a rigorous (not rigid) thinking exercise in reading an environment: the domain and where value is created, the technology and capabilities that enable it, the relationships and constraints that bind it, and the evidence that either confirms the resulting picture or breaks it. It develops across a series that takes each of those four areas in turn.
The approach draws on several established ways of thinking, including systems thinking, process thinking, and evidence-based reasoning. Rather than applying them as separate methodologies, I use their underlying principles to examine how an environment functions, how its components relate, and whether the resulting understanding reflects reality.
The second half of the idea is orchestration. Reading an environment well rarely requires one person to hold all the answers, only someone able to ask useful questions and connect what different specialists already know.
Artifacts advancing this idea
- Discovery Is More Than Understanding the Problem Article / Systems Thinking & Orchestration Understanding a problem and understanding the environment that produced it are two different jobs. Most discovery only does the first, which is why so many product problems turn out not to be product problems.
- Understanding Where Value Comes From Article / Systems Thinking & Orchestration A reporting problem often starts in how the information was collected, and a launch delay often has more to do with handoffs than technology. Following the value chain, rather than the org chart, is what makes the difference visible.
- The Systems Behind the Experience Article / Systems Thinking & Orchestration What the customer sees is a list of products. What delivers it is identity, behavioral data, catalogs, models, and real-time decisioning. Discovery has to tell what looks simple from what actually is.
- The Whole Is Greater Than the Sum of the Systems Article / Systems Thinking & Orchestration A capability that works well on its own can still fail once it depends on another team, system, or process. Improving one component rarely improves the outcome if the relationships around it stay the same.