The Trap That Started It
Can you outline the work?
I got asked this constantly, early in my career. The intent was reasonable. Program managers wanted artifacts they could share, schedule against, and use to communicate progress. So we'd break it down — two weeks of discovery, four weeks of design, six weeks of build, two weeks of launch. Each piece named, dated, owned.
Then week three would arrive, and someone would ask whether discovery was done. I'd have to explain that, well, technically yes — but also no, because we'd just learned something in the design conversation that changed what we should be discovering. We'd need to revisit. Not start over, but circle back.
The chart said discovery was done. The work said it wasn't. Somebody was wrong.
After enough of these conversations, I started suspecting it wasn't the work that was broken. It was the way we were describing it.
What I Started Seeing
The pattern repeated across very different transformations — across industries, across domains, across organizations sitting at very different levels of maturity. The contexts kept changing. The shape of the failure didn't.
The work did have discrete pieces. Real milestones. Real handoffs. Real deliverables that could be scheduled, costed, and reported on. Strip those out and you couldn't run a program at all.
But the work also had something else: a continuous current of learning, refinement, and sense-making that ran underneath the discrete pieces. Discovery thinned out, deepened, redirected — but it never stopped. Neither did design intent. Neither did the calibration of what done actually meant.
Treat the discrete pieces as the entire reality and the continuous current doesn't disappear — it just goes unmanaged. Insights surface in build that should have shaped design. Decisions get revisited weeks past their cost-effective revision window. The team produces what was scheduled, and somehow that isn't enough.
Treat the continuous current as the entire reality and the work becomes impossible to plan, fund, or communicate. The people paying for it ask when something will be done. There's no answer they can use.
Neither view alone was wrong. Both views alone were insufficient.
The Two Honest Attempts
This problem isn't new. Over the last fifty years, two strong answers emerged. Each addressed real constraints. Each got real work done. Each ran out at the same place — including in the most mature organizations, the ones with the deepest investment in either approach.
The first answer was to run the work as a process. By the 1970s, large-program management had crystallized around a phased model — what later got called waterfall. The logic was reasonable: complex programs need predictable schedules, accountability, and fundable structure. Phases produced artifacts. Artifacts produced contracts. Contracts produced trust.
When agile arrived with the 2001 Manifesto, it didn't replace the process logic — it shortened the cycles inside it. Most enterprise adoptions kept the funding gates, upfront requirements, and release gates of the older model, and ran scrum in the middle. Forrester named the result water-scrum-fall in 2011: agile inside, waterfall outside. The lifecycle got smaller. The failure mode didn't.
The numbers tell the story. The Standish CHAOS data consistently finds about 29% of projects succeed, 48% are challenged, and 19% fail outright. McKinsey and BCG keep landing on the same headline: roughly 70% of transformations fall short of their objectives. Bain's 2024 analysis put 88% of business transformations below original ambitions. Agile, on the same data, succeeds about three times more often than waterfall — meaningful, but still not majority.
The process answer was right that complex work needs structure. It just kept assuming requirements stabilize and that insight, once captured, holds.
The second answer was to lead with research and design thinking. Human-centered design and its cousins emerged because real users were getting designed around, not designed for. IDEO and the Stanford d.school built a vocabulary and a method that ran across boardrooms for a decade. The contribution was real.
Then the critiques landed. Innovation failure rates stayed at 70 to 90% despite a decade of design thinking adoption. The pattern was specific: research-heavy front ends that produced compelling artifacts and shallow learning, empathy theater that confirmed decisions already made, and business sponsors understandably unwilling to keep funding discovery that didn't show concrete progress.
The research-led answer was right that humans matter. It just assumed that more research, done sooner, would yield the understanding the work needed — and missed that real understanding emerges in the work, not before it.
Both answers were honest attempts. The process answer fought for predictability against a reality that doesn't stabilize. The research answer fought for human relevance against a reality that won't reveal itself until something exists to react to. Both ran into the same wall: each tried to separate understanding from making. Each tried to fight the wave with a better-shaped particle.
The Spectrum is what comes from taking both seriously and asking what neither could do alone.
Particle and Wave
The way out of this isn't a better process or a sharper research method. It's a different way of seeing the work itself.
In physics, light is sometimes best described as a stream of discrete particles, sometimes as a continuous wave. Neither description is wrong. Neither is complete. Light behaves as both, depending on what you're measuring. The same turns out to be true of electrons, atoms, and matter at the quantum scale. Wave and particle are properties of how the substance of the world behaves, not just of how we describe light. Physicists call this wave-particle duality.
I'm not making a physics argument. I'm borrowing a way of seeing.
Complex work has the same dual nature.
The particle view is the discrete elements — steps, milestones, deliverables, the artifacts that can be named and scheduled. Particles are what make work fundable, communicable, operationally tractable. Without them, you can't run a program — only attend one.
The wave view is the continuous element — insight compounding, understanding deepening, relationships forming, intent refining. Waves are what make the work produce value, rather than just produce outputs. Without them, you get on-time delivery of work that didn't move anything.
The Experience Spectrum is what you get when you stop forcing one view to be the whole story. It isn't a process model with continuity bolted on. It isn't a flow with phases sprinkled in for legibility. It's both, simultaneously, by design.
The orchestra is the closest analogy I've found. The notes on the page are particles — discrete, written, schedulable. The music is the wave — continuous, present even between notes, the thing the audience actually experiences. Music isn't the notes. It isn't the silences between them. It's both, played as one thing.
How the Spectrum Is Built
The Spectrum runs across two dimensions at once — the human dimension and the work dimension. Each provides substance the other can't, and the discipline is running them in concert rather than in sequence.
The human dimension runs as two folds.
The first fold shapes the solution itself — bringing business context and human context together at the same table, early and continuously, to figure out which solution to build and how to arrive at it. This is empathy in the service of the work, not as a separate research artifact. It runs with the people who'll live with the result — not for them, not around them.
Designing for people produces solutions that look right and don't fit. Designing around people produces compromise dressed up as craft. Designing with people produces solutions that the people who'll use them helped shape — which is the only reliable foundation for fit.
The second fold is what carries the solution into the world. Ownership and advocacy aren't a workstream that begins when build ends. They're engineered into the work as it takes shape — by who's involved in shaping it, how their reactions get absorbed, how the work visibly reflects their thinking back to them. By the time the work reaches the point that traditionally calls for adoption, there isn't much to adopt. The people who'd be asked to adopt have been driving its shape for months.
The work dimension has three load-bearing properties.
First, research is hypothesis-first and meets people where insights live. Instead of an exhaustive discovery phase, the work produces a clear-enough hypothesis early, gives it form, and learns from how people react.
Humans react to shape, not concept.
A leader cannot tell you in the abstract what would make her work better, and asking her to is a category error. She doesn't experience her work in the categories the question presupposes. What she can do is see a candidate version of the way she'd be working and react to it.
The reaction is the discovery. The team's job is to read between the lines of it. Invalidation counts as progress — you now know what the answer isn't, and the next form is sharper for it.
Second, the work translates from hypothesis into shape in deliberate stages. A hypothesis becomes what I call an experience building block — a candidate shape of the work, specific enough to react to but light enough to refine.
Blocks are designed to be refined and validated incrementally, then become features, then translate into the working units the implementation team builds against — user stories in a software context, work packages or service specifications in others.
The translation isn't documentation handoff. It's the architecture that keeps intent intact from concept to delivered work.
Third, what moves forward is decided by what the Spectrum runs as dual-criteria gates. Most methodologies have one or the other: business-value gates or human-insight gates. The Spectrum uses both, jointly — and either one alone is insufficient.
Is research done enough to design for validation? Is design done enough to build? Is build done enough to scale? Each answer has a business-value half and a human-insight half. Both have to clear before the work advances.
What makes the Spectrum the Spectrum isn't any single one of these properties. It's the connective tissue — how the gates are set, how the translation from hypothesis to buildable shape preserves intent, how ownership is engineered into the work rather than chased afterward. The depth of each property belongs to the pieces that follow. The point of this article is that the Spectrum is built to be run, not admired.
Change Is the Energy
The Spectrum is structure. Particles, waves, folds, and gates describe what the work is. None of it describes what makes the work produce impact.
That's the role of change — in the broadest sense, not the narrow sense of training and communications at the end.
Change is the energy that runs across the Spectrum. It shows up as readiness, alignment, engagement, and the active calibration of intent across leadership, the team, and the people who'll live with the work. Without it, the structure exists and nothing flows through it. Particle work can be flawless and wave work can be flawless, and the result still produces nothing meaningful.
Change isn't a phase. It's the field the whole Spectrum operates in. It's the current in the wire — the thing that turns a structurally sound program into something that actually changes how people work.
This is also why change management treated as a workstream bolted on at the end fails so reliably. By the time you reach the end of the Spectrum, the energy needed to make the work land had to have been building across the whole shape of it. You can't generate readiness, alignment, and engagement in the last six weeks that should have been compounding for the last twelve months.
The Spectrum is the structure. Change is the energy. Both have to be present, both designed for, both sustained — or the work produces deliverables instead of impact.
The Discipline
The Spectrum doesn't promise that complex work becomes more straightforward. Nothing makes complex transformation more straightforward. What it does is align the way the work is described, run, and measured with the way the work actually behaves.
Insights surface where they're useful instead of trapped behind phase gates. Validation isn't a checkpoint at the end; it's what's happening continuously, building the solution and testing it in the same motion. Delivery stops being confused with transformation — a program can ship every deliverable on schedule and change nothing about how the organization operates, and the Spectrum, run as designed, is the difference.
Problems no one had named begin to surface. Problems the customer hadn't articulated. Problems the team hadn't anticipated. Sometimes problems that didn't exist until the new shape made them visible. Treating those as scope noise is what most programs do. Treating them as the actual point is what builds the kind of trust that makes the next program possible.
Every era brings its accelerant. AI is the current one. The trap underneath it is older, and so is the discipline that escapes it: not a process, not a flow, but both — designed with the people who'll live with the work, activated by change as energy, and judged by what actually changes in how the work gets done.
That's the Spectrum. The pieces that follow go where this one stops.