JTBD Has a School-of-Thought Problem
I thought I'd nailed Jobs To Be Done. Then I used it for the wrong thing.
I'd learned about the framework through marketing. Christensen's emotional and social jobs, Moesta's forces of progress. It clicked immediately for understanding why people switch, what messaging to use, how to build an acquisition funnel. So when I needed to define requirements for an app, I reached for the same approach.
It didn't work. The outputs were too abstract. I could articulate the emotional job beautifully but I couldn't turn it into something an engineer could build from. The framework felt right but the results were fuzzy and unusable.
It took me a while to realise the problem wasn't JTBD. It was that I was using the wrong version of it. There are at least three distinct schools of thought under the JTBD umbrella, and they're good at very different things. Choosing the right one matters.
Three schools, briefly
Clayton Christensen developed the original concept. The core idea: people don't buy products, they hire them to make progress in their lives. He broke jobs into three dimensions: functional (what I need to accomplish), emotional (how I want to feel), and social (how I want to be perceived). His book Competing Against Luck is the definitive read.
Tony Ulwick made it systematic. His Outcome-Driven Innovation approach defines jobs in a precise format (verb, object, context) and maps the outcomes people use to measure success. You can survey it, score it, prioritise from it. It turns fuzzy needs into concrete requirements.
Bob Moesta focused on the moment of switching. His Forces of Progress model maps four things: the push (pain with the current situation), the pull (appeal of something new), anxiety (fear of change), and habit (comfort with the status quo). All four need to line up for someone to switch. If they don't, it doesn't matter how good your product is.
They come from the same root insight. But they produce very different outputs. And part of the problem is that each school's advocates tend to present their version as the complete picture. Ulwick's books barely mention Moesta. Christensen's work doesn't engage with outcome-driven scoring. The practitioner is left to figure out the synthesis on their own.
How I built an acquisition funnel with Christensen and Moesta
At Béa Fertility, we used JTBD to develop a consultation-based acquisition funnel. Béa made an at-home fertility treatment device, an alternative to the clinical pathway. The functional job was obvious: help people conceive. But that's not what drove decisions.
Fertility treatment is overwhelming. A maze of options, clinical jargon, conflicting advice. One of the biggest jobs we uncovered wasn't "find a treatment." It was "make sense of what could actually help me." The need was for clarity. For someone to give an honest assessment, even if that meant hearing "this isn't right for you." That honesty built confidence and trust.
The other job was deeply personal. Enough understanding and conviction to have difficult conversations with a partner, to navigate the emotional weight of the journey together. We tried to take on some of that burden by offering clear, honest answers through the consultation. Not a sales pitch. Genuine guidance.
Moesta's forces shaped how we structured the funnel around that. The push was real: the confusion and emotional toll of the clinical pathway. The pull was a simpler, more personal alternative. But the anxiety was significant. Trusting an at-home approach with something this important? That's a big ask. And the habit of deferring to clinical authority was strong. The consultation existed to address those two forces head on: build trust, reduce anxiety, give people the confidence to act.
Without mapping both the emotional jobs and the switching forces, we'd have built a funnel that talked about product features. Instead we built one that addressed what people were actually struggling with.
How I used Ulwick to make sense of a legacy app
Different problem, different lens.
I've been using Ulwick's approach recently to audit an application that had grown organically over years with no documentation. The challenge was making sense of what it actually did before planning its next evolution. Feature audits are fine for cataloguing screens and buttons, but they don't tell you what's actually important.
JTBD gave me better scaffolding. Instead of mapping features, I mapped jobs. What were users actually trying to accomplish? Structured job statements forced precision. And once you layer in user profiles — who does what, and why — things show up that a feature audit would completely miss.
The "oh shit" moment came around account management. The app had one login flow, one dashboard, one set of tasks. But when I mapped the jobs by user profile, it was obvious that different roles had fundamentally different needs. One type of user needed quick, focused task completion. Another needed oversight and configuration. The app was throwing everything at everyone and overwhelming people with stuff that wasn't relevant to them. The whole account and password system had no concept of separate roles. That wasn't a UI problem. It was an architectural assumption baked in from day one that had to change before anything else could improve.
It also showed that some jobs couldn't be solved in the app at all — they needed to happen in the physical world, on the device. A feature audit would never have caught that. It would have just catalogued more screens.
The routing question
Before your next JTBD exercise, ask yourself one thing: what am I actually trying to figure out? The answer tells you which school to reach for.
"What should we build?" → Use Ulwick. Structured job statements, outcome mapping. You get requirements grounded in real user needs, prioritised by what's underserved. At the legacy app, this is what exposed the missing role separation.
"How do we reach people?" → Use Christensen + Moesta. Emotional and social jobs, forces of progress. You get messaging that speaks to what people actually care about, and a funnel shaped around what's blocking the switch. At Béa, this turned a product-features pitch into a trust-building consultation.
"Why aren't people switching?" → Use Moesta. Forces of progress. You get a diagnosis. Which force is working against you: anxiety, habit, weak push, or weak pull? Fix the force, not the feature list.
If you're about to run a JTBD exercise and you haven't decided which version you're using, stop. That decision is the difference between something you can build from and a wall of sticky notes that makes everyone feel productive but changes nothing.