When Jobs to Be Done Meets Domain-Driven Design

Mike Dyer March 22, 2026 8 min read

There are moments in practice where two ideas you've held separately for years suddenly click together — not because someone told you they were connected, but because you were working through a problem and the structure fell out on its own.

This happened to me recently while thinking through how user input normalizes into domain concepts. I was working with the Jobs to Be Done framework on one side and Domain-Driven Design building blocks on the other. And the mapping wasn't just convenient. It was nearly exact.

What surprised me more: nobody seems to have published this connection.

Two Frameworks, Same Year, Same Problem

Clayton Christensen popularized Jobs to Be Done in The Innovator's Solution in 2003. The core idea: customers don't buy products — they hire them to do a job. Understanding the job — the situation that triggers the need, the motivation behind the action, the outcome that signals completion — is the only reliable way to understand what to build.

Eric Evans published Domain-Driven Design: Tackling Complexity in the Heart of Software in 2003. Same year. His core idea: software should model the domain — not the database, not the UI, not the org chart. The domain model is the shared language between engineers and domain experts. Get the model right, and the system writes itself. Get the model wrong, and no amount of engineering fixes it.

Two books. Same year. Completely different audiences — product people reading Christensen, architects reading Evans. They decomposed the same fundamental question: what should this system do, and why?

They never cited each other.

The Mapping

A JTBD statement has a canonical structure:

"When I [situation], I want to [motivation], so I can [outcome]."

That structure isn't decorative — it's a decomposition. And each component maps directly to a DDD building block:

JTBD Component	What It Captures	DDD Building Block
Situation ("When I...")	The state of the world that triggers the need	Context / Preconditions
Motivation ("I want to...")	The action the actor wants the system to perform	Commands / Intents
Outcome ("So I can...")	The observable result that satisfies the job	Domain Events / Post-conditions

Read that table again. A product manager who writes "When a compliance violation occurs, I want to be notified immediately, so I can remediate before audit" has already decomposed three things:

A domain event that triggers behavior (violation occurred)
A command that expresses intent (notify me)
A post-condition that defines success (remediation triggered before audit)

They don't know they've done it. They've never heard the term "aggregate root." But the decomposition is structurally identical to what an architect would produce in an Event Storming session.

What the Mapping Means

This isn't a party trick. The structural alignment has three real consequences.

First, JTBD input normalizes directly into DDD concepts. If you take a well-formed JTBD statement and decompose it — situation into context, motivation into command, outcome into event — you get the raw material for a domain model. No interpretation layer required. The structure does the translation.

Second, DDD gives JTBD structural rigor. JTBD practitioners struggle with vague outcomes. "So I can feel confident" is a common pattern — and it's useless for both product and engineering. DDD's requirement for observable state changes forces outcomes to be concrete. Not feelings — events. Not aspirations — post-conditions. If the outcome can't be modeled as something that happened in the system, the JTBD statement is incomplete.

Third, the gap between product and engineering shrinks. If JTBD input maps to DDD building blocks, then the translation layer between "what the user needs" and "what the system models" becomes mechanical, not interpretive. The architect doesn't have to guess what the product manager meant. The product manager doesn't have to understand aggregates. The decomposition structure itself bridges the vocabulary gap.

This is the part that excites me most. The perennial friction between product and engineering isn't a people problem — it's a structural problem. Product teams and engineering teams decompose the same domain using different vocabularies. The JTBD-to-DDD mapping reveals that the vocabularies are isomorphic. They're describing the same structure with different words.

The Event Storming Parallel

The mapping gets more interesting when you bring in Alberto Brandolini's Event Storming.

Event Storming uses a specific flow: a domain event (orange sticky) triggers a policy or reaction, which issues a command (blue sticky), which produces a new domain event (orange sticky). The canonical reactive loop:

Event → Policy → Command → Event

Now look at the JTBD structure again:

Situation (something happened) → Motivation (I want to do something) → Outcome (something new happens)

And the DDD mapping:

Precondition (system state) → Command (intent) → Domain Event (state change)

Three independent frameworks. Three different disciplines — product management, domain modeling, collaborative workshop facilitation. Developed across a decade (2003, 2003, ~2013). And the decomposition shape is the same:

Trigger → Action → Observable Result.

The Shape of the Problem

Here's the thesis I keep coming back to.

When independent frameworks converge on the same structure without ever referencing each other, the structure isn't a framework artifact — it's a property of the problem domain itself.

Christensen wasn't thinking about domain events when he formalized the Situation → Motivation → Outcome structure. Evans wasn't thinking about jobs to be done when he modeled Precondition → Command → Event. Brandolini wasn't thinking about either when he laid out Event → Policy → Command → Event on a wall of sticky notes.

They were all trying to answer the same question: how do you rigorously decompose what a system should do and why? And they all arrived at the same shape.

That shape — trigger, action, observable result — isn't Christensen's invention, or Evans's, or Brandolini's. It's the shape of the problem. Every rigorous decomposition method finds it, because it's the only shape that captures causality, intent, and outcome in a single structure.

I've seen this convergence pattern before. When you model a domain with temporal scope — events crossing bounded contexts over time — Event Storming's swim-lane vocabulary emerges naturally as a byproduct. You don't set out to build Event Storming. You include temporal scope in the design, and the reactive flow (event → policy → command → event) organizes itself into the same vocabulary Brandolini formalized. You don't find Event Storming. Event Storming finds you — the moment you model events crossing boundaries over time.

The JTBD mapping is the same phenomenon one layer up. You don't set out to connect JTBD to DDD. You try to normalize user input into domain concepts, and the decomposition maps itself.

What This Means for Practice

If you're a product manager writing JTBD statements, you're already doing domain decomposition. You just don't have the vocabulary to name what you've produced. Learn enough DDD to recognize that your "outcomes" are domain events. It will make your JTBD statements sharper and your conversations with engineering more productive.

If you're an architect practicing DDD, look at the JTBD statements your product team is writing. They're not requirements — they're decompositions. The situation is your precondition. The motivation is your command. The outcome is your event. You may find that the product team has already done half your Event Storming before the session starts.

If you're a solo builder wearing both hats, this mapping is a gift. Write your own JTBD statements for the domain you're modeling. Then decompose them. Situation into context. Motivation into command. Outcome into event. You'll have the skeleton of a domain model before you draw a single diagram.

And if you're skeptical — try it. Take any well-formed JTBD statement and apply the mapping. See if the DDD building blocks fall out. In every case I've tested, they do. Not because the mapping is clever, but because the problem has a shape, and both frameworks found it.

Christensen and Evans published in the same year. They decomposed the same problem. They never cited each other. And the mapping is nearly exact.

Every JTBD statement is a domain event waiting to be named.

Further reading:

Clayton Christensen & Michael Raynor, The Innovator's Solution (2003)
Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software (2003)
Alberto Brandolini, Introducing EventStorming (~2013; eventstorming.com)
narrativedriven.org — Narrative-Driven Development, temporal modeling, and the reactive path vocabulary