Design Thinking, Agile, JTBD: Same Framework Failure Mode

Design Thinking, Agile, and Jobs-to-Be-Done all start from the same sane insight: your plans are less important than reality. People don't behave like specs. Learning has to happen while you build, not after. You need a way to keep noticing what's actually happening and adjust around it.

Then the same thing happens every time: the thing that helped people think starts telling them what to think. The lens hardens into a framework. The framework hardens into a checklist. The checklist hardens into an identity.

The failure mode is shared. The problem isn't Design Thinking, or Agile, or JTBD, or any UX-informed variant of it. The problem is what happens when you stop using them as ways of seeing and start using them as proof that you're "doing it right."

Same insight, different labels

If you strip away the branding, they all start in the same universe.

Design Thinking says: we're shipping things nobody wants. Go watch real people. Prototype quickly. Iterate from observation instead of opinion.

Agile says: big up-front plans lie. Work in small slices. Ship incrementally. Respond to change instead of worshipping the plan.

JTBD says: people don't buy your product, they hire it to make progress. Understand the job and the forces around it instead of reverse-engineering "needs" from the roadmap.

A UX-aware jobs lens takes that further: design entry points, flows, defaults, and states around specific jobs-in-context instead of around your org chart or feature list.

Different terminology, same underlying correction: stop treating your internal structure as reality. Go see what people are actually trying to do, under real constraints, and let that shape what you build, how you build it, and how you know if it's working.

Used that way, all of them are lenses. They change what you pay attention to and the questions you ask. They're not "the process." They're how you look at the work.

How lenses harden

The moment a lens helps, the instinct is to bottle it.

You get the double diamond, the Scrum ceremonies, the jobs canvas, the "proper" job story format, the official UX flow structure. None of that is evil. It's a natural way to teach and scale a practice.

The trouble starts when the process stops being optional.

You can hear the shift in the way people talk: "We're a design thinking organization." "We ship Agile." "We're very JTBD-driven here." That language sounds harmless, but it shifts the center of gravity. The goal subtly stops being "solve this problem in front of us" and becomes "do this the right way." The conversation stops being "does this lens help us see this situation more clearly?" and becomes "are we following the method?"

JTBD is especially vulnerable here because it looks like a framework even though it was meant as a way of understanding demand. It has canvases. It has interview scripts. It has a four-forces diagram that photographs well on a whiteboard. Once it becomes "our official way of doing product," the lens is already calcifying into a framework. And any UX practice built on top of JTBD can easily inherit that same risk without specific guardrails.

The shared failure mode, three times over

You can watch the same pattern play out with different stickers on it.

Design Thinking starts as "go see real people, prototype, test, iterate." It turns into workshop kits: empathy maps, journey maps, "How Might We" walls covered in sticky notes. Teams end up with canvases and photos and a sense that they "did design thinking," even when none of it changed what shipped. The workshop felt productive. The product didn't move. But the team can point to the artifacts and say the process was followed.

Agile starts as "work in small slices, ship often, adapt to change." It turns into standups, burndown charts, and a calendar full of ceremonies. Success becomes "we hit our commitments and moved the tickets" instead of "we responded to reality faster." The team that rigidly follows two-week sprints and refuses to change direction mid-sprint because "that's not how Scrum works" has turned a principle about flexibility into a ritual about predictability. The lens that said "adapt to change" now punishes adaptation.

JTBD starts as "understand the jobs and forces that drive hiring and firing." It turns into a pile of job stories and a few neat axes on a slide. The roadmap looks the same as it did before the jobs work happened — same features, same priorities — just with "Job 1 / Job 2 / Job 3" labels attached after the fact. The jobs language gets used to justify decisions that were already made, not to make different ones.

A UX practice informed by JTBD has exactly the same risk: if "doing jobs-first UX" means filling in boxes and running a generic checklist, you've already lost the plot. The point was to see jobs and forces and contexts clearly enough that you'd make different design decisions. If the decisions don't change, the lens didn't do its job.

The failure mode is identical across all three: the framework becomes self-referential. It exists to prove that the framework was used.

What makes JTBD especially prone to this

Design Thinking and Agile have been through enough cycles of hype and disillusionment that most practitioners have some antibodies. They've seen the failure mode. They know what "Agile theater" looks like. They've sat through the Design Thinking workshop that produced a wall of sticky notes and nothing else.

JTBD is earlier in that cycle, which makes it more vulnerable. The language is still fresh enough to feel like insight instead of jargon. The frameworks are still novel enough that using them feels like progress. And because JTBD deals with something genuinely hard — understanding why people switch, what progress they're trying to make, what forces hold them in place — it's easy to confuse "we did the analysis" with "we understand the job."

The most common version of JTBD theater looks like this: a team runs a round of switch interviews, produces a jobs map, presents it to leadership, and then files it away. The jobs language shows up in decks. "We're building for the coordination job." But the roadmap was already set. The research didn't change what gets built. It changed the vocabulary used to describe what was already going to get built.

How to keep it a lens

If you want JTBD — or any of these frameworks — to actually help, you have to keep them explicitly in lens mode. That means a few specific things.

Use jobs to interpret what you're seeing, not to exclude what doesn't fit the template. When a stakeholder concern or a technical constraint doesn't drop neatly into "when / I want / so I can," that's not a reason to ignore it. It's a reason to ask "what job, in what context, makes this matter?" The lens should make you curious, not dismissive.

Treat job statements and force maps as working models, not fixed truths. If your "main job" hasn't been updated in a year, that's not evidence you nailed it. It's evidence you stopped looking. Jobs shift as markets shift, as competitors shift, as the user's context evolves. A job statement that was true eighteen months ago might be irrelevant now — and you won't know if you've frozen it in place.

Make "this lens is wrong here" a valid move. Some problems really are supply-side. Some constraints really are legal or technical. Some situations genuinely call for a different way of looking at the work. Forcing everything into a jobs frame is its own kind of delusion. You keep a lens honest by letting other lenses win when they fit better.

Tie the lens to visible decisions. No jobs research, no forces workshop, no JTBD canvas is finished until it changes something concrete: what ships, how it ships, who it ships for, or what you watch afterwards. If nothing moved, you produced content, not meaningful work.

Same insight, same trap — unless you keep it a lens

Design Thinking, Agile, and JTBD all share the same starting point: reality beats process. You learn by watching people try to make progress, not by arguing from first principles.

They also share the same trap: once they work, people turn them into a calcified process. The lens that said "go look at reality" becomes the framework that says "fill in this canvas." The practice that said "adapt to change" becomes the ceremony that punishes deviation.

The way out isn't to throw them away or invent yet another branded framework. It's to be relentless about their role. JTBD and any UX practice built on it should always stay what they were at their best: ways of seeing your product and your users more clearly. Not ways of proving you believe the right things.

The moment the framework becomes something you perform in lieu of thinking instead of something you use after real analysis, the lens is dead. What's left is compliance — and compliance will never tell you it's not working, because compliance doesn't have a feedback loop. It just has adherents.