Frameworks tell you what to do. An operating model defines how value flows through your organization — and how you build the capability to create more of it, faster, with less waste.
D.I.D. is a behavior-anchored operating model for software product organizations. It integrates three disciplines — customer discovery, product innovation, and engineering delivery — into a single, continuous system for converting organizational uncertainty into measurable customer progress.
Unlike frameworks that prescribe ceremonies, roles, and artifacts, D.I.D. defines the conditions that must be true at the system level for value to flow reliably from customer insight to production outcome.
It is built on a simple, uncompromising premise: the only valid measure of a product organization's success is a measurable improvement in a customer's ability to make progress on a job they are trying to do.
"Value = measurable improvement in a customer's life. Not features shipped. Not deadlines met. Not velocity achieved. The only question that matters: did their behavior change in the direction we intended?"
— Discover Innovate DeliverCore Definition of Value
Value is a measurable change in customer behavior on a specific step of a job they are trying to accomplish — achieved faster, with less friction, or with greater reliability than before.
The Discover domain exists to solve one problem: we build the wrong things because we don't understand what "right" looks like in behavioral terms.
Most discovery processes generate insights about user preferences, pain points, or requested features. D.I.D.'s Discover domain generates something fundamentally different: Job-Step Outcome Statements — precise descriptions of how customers measure success on a specific step of a job they are trying to accomplish.
Every customer has functional, emotional, and social jobs they are trying to do. D.I.D. uses JTBD theory not as a research method but as a unit of analysis for the entire product strategy. The job defines the competitive landscape. The job-step defines the unit of value measurement.
The Discover domain enforces a discipline that most organizations find deeply uncomfortable: you must design the evidence of success before you design the solution. This means defining the exact behavioral metric, the instrumentation required to measure it, and the minimum threshold that constitutes proof — before a single wireframe is sketched.
What Must Be True in Discovery
The Innovate domain exists to bridge the gap between customer insight and engineered solution — but it does so through a discipline that most organizations skip entirely: proof before celebration.
Innovation in D.I.D. is not about generating creative ideas. It is about converting uncertainty into evidence using the smallest possible investment. Every solution is a hypothesis. Every sprint is an experiment. Every release is a test.
D.I.D. replaces the feature specification with a hypothesis statement that captures: the assumed customer job-step, the proposed behavioral change, the designed proof artifact, and the falsification criteria. This forces every solution decision to be traceable to a customer outcome and testable against real behavior.
Traditional backlog prioritization asks "which feature is most valuable?" D.I.D.'s Innovate domain reframes the question: "which hypothesis, if confirmed, would reduce the most uncertainty about our ability to create customer value?" This produces radically different prioritization decisions — and radically better outcomes.
What Must Be True in Innovation
The Deliver domain exists to answer a question that most organizations never ask: "Did our hypothesis prove true in production?"
D.I.D. reframes Continuous Delivery not as a DevOps preference or an engineering best practice, but as the strategic infrastructure of the entire operating model. Without fast deployability, the Discover and Innovate domains produce insights and hypotheses that take months to validate — by which time the context has changed entirely.
The highest-value learning doesn't happen in user research sessions or design sprints. It happens when real customers interact with real code in real contexts. D.I.D. treats production as the primary laboratory and Continuous Delivery as the mechanism that keeps the laboratory accessible.
Delivery without outcome telemetry is blind. D.I.D. requires that every deployment includes the instrumentation to measure the behavioral outcome defined in the Discover domain. A release without telemetry is an untestable hypothesis — and an untestable hypothesis is waste.
What Must Be True in Delivery
D.I.D. is not a destination — it is a direction. Most organizations cannot adopt the full operating model in a single transformation initiative. The Continuous Improvement layer provides the mechanism for moving incrementally from the current state toward the target state.
Drawing on Toyota Kata's coaching and improvement patterns, D.I.D.'s Continuous Improvement layer treats the gap between current and target state as a series of structured experiments — each one building the organizational capability required for the next.
Feature Factories optimize to win quarterly. D.I.D. organizations play a different game: they optimize to increase their capacity to create customer value over time. The Continuous Improvement layer is the mechanism that makes this possible — turning individual retrospectives into systemic capability building.
The D.I.D. Maturity Progression
Define what the organization looks like when D.I.D. is fully operational. What does value creation feel like? How does learning flow?
Honest measurement of the existing system. Where does value get lost? Where does uncertainty accumulate? What must be true that isn't yet?
The next measurable improvement in organizational capability. Specific, time-boxed, with defined evidence of achievement.
Run the experiment. Measure the outcome. Update the model. Move to the next target state. Repeat indefinitely.
D.I.D. is not a set of practices to adopt. It is a set of system-level conditions that must exist for value to flow. These conditions are the real target of transformation work.
The organization agrees that customer behavioral change — not output metrics — is the only valid measure of product success. This is a cultural precondition, not a technical one.
Teams own the full flow from customer problem to production outcome. Discovery and delivery are not separated into different teams, phases, or departments.
The deployment pipeline is a strategic asset. Teams can deploy safely on demand. The path from committed code to production is measured in hours, not weeks.
Behavioral instrumentation is designed before solutions are built. Every hypothesis is paired with its measurement infrastructure. Production is observable at the job-step level.
Work is sequenced by uncertainty reduction value. No feature enters development without a testable hypothesis, defined evidence of success, and a falsification threshold.
The organization has dedicated, protected capacity for system-level improvement work. Continuous improvement is not a retrospective activity — it is an operational capability.
Workshops, advisory engagements, and the book itself are designed to help your leadership team adopt D.I.D. at the pace your organization can sustain.