How Good Frameworks Turn Into Bad Religion: The Six-Stage Death Spiral

Every useful framework starts its life as a coping mechanism.

Somebody is overwhelmed by reality — too many inputs, too many choices, too many ways to get it wrong — and they compress what they've learned into a simple way of seeing. It works. Other people use it. The language spreads. The diagrams show up in decks.

The AI gold rush is intensifying this pressure, at high speed. Teams want to prove they’re not behind the curve. That can make any framework more tempting as a performance: a canvas, a workshop, a maturity label, a roadmap theme, a set of rituals that make the chaos and uncertainty feel manageable.

And then, slowly, almost invisibly, the thing that helped people think starts telling them what to think. That's what happens when a framework goes from being a lens to being a law. From "this helps" to "this is how it is." From good framework to bad religion.

This article maps the pattern, so you can recognize where your own team is in it. Each article in this category explores different facets of the underlying issue: how do frameworks actually work, and when do they stop working?

You'll find pieces on where JTBD specifically goes wrong in practice, how methodology theater replaces real thinking, and how to keep the tools honest instead of letting them calcify into performance. It starts here, with the death arc that every framework follows if nobody interrupts it.

You can watch it happen in six stages.

Stage 1: Honest lens

In the beginning, the framework is a story about failure.

Someone has seen enough projects blow up that a pattern emerges, and they articulate that pattern in a way other people can use. Jobs-to-be-Done was a reaction to solution-first product development. Agile was a reaction to big-batch, waterfall projects. OKRs were a reaction to vague goals and fuzzy accountability.

At this stage, the framework is a lens, not a law. People use it to see their situation more clearly, not to win arguments. It's grounded in specific contexts — "this seemed to explain why A worked and B didn't for companies like ours." Its creator cheerfully admits where it doesn't apply.

This feels like relief. You have names for things you kept feeling but couldn't describe. You have a way to ask better questions, or to say "this is why that project blew up" without blaming individuals.

The framework is doing its job: compressing experience into something other people can reuse.

Stage 2: Codification and canon

Then someone writes it down "properly."

There's a talk, a book, a canvas, a set of official steps. The messy, lived thing is flattened into a process you can teach to people who weren't there for the original scars. The appeal is obvious: now you can train teams, scale practice, and pretend alignment.

This is where the benefits and risks both start to grow.

On the plus side, more people can access the lens. New folks don't have to reconstruct the hard-won lessons from scratch. On the downside, the codified version begins to drift away from the original context. The caveats and "it depends" get edited out. The diagrams smooth over the parts where judgment used to live.

That context loss is particularly dangerous with AI because the hard parts are almost always contextual. What should be automated? What should be augmented? What should be explained? What should stay human? What needs to be reversible? Those answers change based on the user's job, stakes, trust level, and situation. A neat canvas can hide that complexity.

Inside organizations, the framework moves from "a way we see" to "how we do things here." The fact that it came from a particular time, place, and set of constraints starts to fade. And that's where the trouble starts — because what you've got now is canon without context.

Stage 3: Social currency and status

Once a framework has canon, it gets followers.

People start signaling that they "get it." Certification programs appear. Internal champions build their identity around being the person who knows how to run the canvas, the sprint, the JTBD interview, the Agile ceremony.

At this stage, the framework is no longer just a tool. It's a badge.

You hear it in how people talk: "We're an OKR organization." "We're very JTBD-driven here." "We ship Agile now." 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."

This bad religion starts with social pressure and rewards. It feels good to be the person who "knows the right way to do product," especially in organizations that are otherwise chaotic. The framework offers identity and status where there used to be anxiety.

Once that happens, criticism of the framework can feel like criticism of the people attached to it. That's when it gets hard to say "this isn't helping here."

Stage 4: Ritual over results

By now, the framework has real institutional weight. It has slides, training budgets, tooling. It shows up in performance reviews. It lives in onboarding.

And with that comes the most visible symptom of the death spiral: the rituals remain even after the results disappear.

User stories are written and groomed, but nobody can say which users and which stories actually matter. Standups happen religiously, but nobody is actually unblocked by them. Jobs interviews are run, but the "jobs" disappear into a slide deck instead of shaping what gets built. OKRs are set, graded, and color-coded, but they don't change how people spend their week.

The map has replaced the territory. The ceremony has replaced the conversation.

You can hear it in the way people defend themselves: "We did the process." "We filled out the canvas." "We followed the framework." Outcomes become negotiable; adherence does not.

At this stage, the framework is no longer a lens. It's a rigid checklist.

Stage 5: Dogma and defensiveness

Then something breaks.

A big bet fails. A launch flops. A "textbook" initiative produces the wrong behavior in the market. Someone asks, very reasonably, whether the way you're using the framework might be part of the problem.

The reaction is telling.

Instead of curiosity — "maybe our context changed," "maybe we misread the job," "maybe this tool isn't a fit here" — you get defensiveness: "We didn't follow it closely enough." "People weren't committed to the process." "Leadership undermined it." "We need more training."

The framework becomes unfalsifiable. If it works, credit the framework. If it fails, blame the implementation.

That's dogma: a belief system that explains away every contradiction instead of letting the contradictions teach you something. Notice who gets protected and who doesn't. The framework is above scrutiny. The people are not.

Stage 6: Hollow orthodoxy

Finally, the framework becomes wallpaper.

Everyone knows the words. Everyone has been through the training. The ceremonies are on the calendar. The templates exist. The acronyms show up in every deck.

And almost nobody believes the thing actually changes their day-to-day decisions.

You've seen this. The team holds a two-hour OKR planning session, sets objectives that sound strategic, assigns key results that sound measurable — and then goes back to building whatever was already in flight. The OKRs get graded at the end of the quarter. The grades are gently massaged to avoid a conversation nobody wants to have. New OKRs are set. The cycle repeats. The work never changes.

Or the product team runs a "JTBD sprint." They interview users. They produce a beautiful jobs map. They present it to the org. People nod. The language shows up in the next roadmap deck — "we're building for the coordination job" — but the roadmap itself is the same feature list it was before the sprint happened, just with new labels on the rows.

People route around the framework. They make the real call in a hallway or a DM thread and then backfill the framework afterwards. They write the OKR to match what they already decided. They retrofit "jobs" language onto whatever roadmap they wanted in the first place. They reverse-engineer user stories to justify decisions that were made weeks ago.

From the outside, it looks like a model organization: so many best practices, so much "maturity." From the inside, everyone is performing a religion they no longer expect results from.

This is the last stage of the death spiral: the framework is everywhere and completely absent at the same time.

How to break the spiral

If you want good frameworks to stay good — especially something like JTBD that works best as a lens, not a religion — you have to interrupt this arc on purpose.

Protect context, not canon. Make it easy to ask "what was true when this was invented that might not be true here?" Encourage people to name where the lens distorts as well as where it clarifies. Treat "this doesn't fit" as useful data, not heresy. In practice, this means every time you introduce a framework to a new team, you should also introduce its limitations — the situations where it falls apart, the contexts it wasn't built for, the assumptions baked into its origin story. If you only teach the framework and not its boundaries, you're planting the seed of Stage Two.

Tie rituals to real decisions. Only keep a ceremony if you can point to specific decisions it changed. Not "informed" — changed. If your jobs work doesn't alter what ships, how onboarding works, or what you measure, the jobs work isn't complete. Same for backlogs, OKRs, research templates, or any other framework artifact. The test is simple: if we stopped doing this tomorrow, would anyone's decisions get worse? If the honest answer is no, the ritual has outlived its usefulness.

Let outcomes override orthodoxy. Make it normal — expected, even — to say "the playbook says X, but for this job, in this context, we're doing Y, and here's why."  That's the framework working as intended: a lens you can set down when it stops helping you see. The moment "we're deviating from the framework" feels like a confession instead of a judgment call, you're in Stage 5 and the spiral is accelerating.

Every useful framework has a half-life. The question isn't "will this turn into religion?" — it will, given enough time and enough people. The question is how far down the spiral you let it slide before you pull it back up into what it was supposed to be in the first place: a way to see more clearly, not a way to win the process war.