Yes, You Have Frameworks. Here's What They're Missing.

You already use frameworks. Personas. Problem statements. Agile user stories. Journey maps. OKRs. Design thinking rituals. They're not inherently stupid tools — they exist because teams genuinely need ways to align, prioritize, and build.

And yet. If you've ever shipped something "obviously useful" that nobody adopted, or watched a team debate UX polish while missing the actual point, you've felt the gap those approaches often fail to close.

The same thing happens when teams rush to add AI. Personas can make the audience feel defined. User stories can make the feature feel buildable. OKRs can make adoption feel measurable. Journey maps can make the flow feel understood. But none of those explain why someone would switch, use it, stick with it, or churn. You can ship the copilot, hit the roadmap goal, and still miss the reason someone would hire your product — much less stick with it — over their old way.

That's the gap the JTBD lens fills — and in most cases, it fills it better than anything else in your toolkit by providing the one variable most other tools collapse: the user's situation and the progress they're trying to make right now. Without that variable, the rest of your tools are organizing work around a target you haven't actually found.

This article gives you an overview about what the JTBD lens can do that your tools simply can't, and explains why teams that understand the difference make sharper product decisions.

Each article in this category helps you see exactly what a JTBD lens can uncover so you stop getting blindsided by adoption failures that your frameworks said shouldn't happen.

JTBD does what those tools do — arguably better

All the usual tools are trying to build empathy, focus energy, make needs buildable, and align the team. Personas try to build empathy by putting a face on the user. JTBD builds empathy by reconstructing a real moment in someone's life — the specific situation that made them start looking, the forces pulling them forward and holding them back. You don't need to imagine "Marketing Mary." You have a real person, in a real struggle, with real stakes.

Problem statements try to focus energy by naming the pain. JTBD focuses energy by naming the progress — not just "users struggle to manage projects" but what they're trying to make happen, what triggered the struggle now, what "better" means in their terms, and what's at stake if they don't get there. Pain without direction isn't a design target. Progress is.

User stories try to make needs buildable by giving developers a sentence and hoping they’ll know how to interpret it. JTBDUX — the integration of Jobs-to-Be-Done thinking with UX practice as a single way of working — makes needs buildable by looking at products and experiences through one question: what progress is this person trying to make?

The JTBD lens gives you capabilities that personas, user stories, and problem statements don't have a mechanism for.

It makes the four forces visible. Every switching decision is shaped by four forces: frustration with the current way (push), attraction to something better (pull), comfort of existing habits, and anxiety about change. Those forces explain why people switch, why they almost don't, and why they sometimes revert after trying. No persona captures that. No user story has a field for it. JTBD surfaces the forces by design.

It explains non-adoption. When a product is objectively better and people still don't switch, most tools have no explanation. JTBD does: the habit force or the anxiety force is stronger than the push and pull combined. That's not a mystery — it's a diagnosable, designable problem.

It segments by behavior, not attributes. Two people who match the same persona can be in completely different jobs — one is trying to avoid looking unprepared in front of leadership, another is trying to catch a risk before it becomes visible. Same "persona." Different urgency, different success criteria, different experience requirements. JTBD segments by what people are trying to do in context, which is what actually predicts what they'll adopt, pay for, and return to.

It aligns product and marketing around the same truth. Marketing is about why someone should change. Product is about making that change pay off. When both teams work from the same anchor — the user's desired progress in a specific context — the messaging promises what the product actually delivers..

The lens matters more than the tools

Every product decision you make — what to build, how to onboard, what to prioritize, how to message — depends on an assumption about why users choose you and why they stay.

If that assumption is based on the Job ("our users hire us when they need to defend a recommendation and they can't produce a credible analysis fast enough"), you know exactly what to build, what to say, and what success looks like — because you're designing for a real moment, not a fictional composite, hypothetical situation, or gut feeling.

That's the difference. Most tools describe something that may or may not match reality. JTBD  and JTBDUX describe the thing that actually determines whether someone adopts your product, sticks with it, or walks away.