The Jobs-to-Be-Done Framework for AI Product Decisions

Every AI product decision comes down to one question: does this capability help someone make progress they’re already trying to make? The Jobs-to-Be-Done framework gives you a structured way to answer that question before you spend six figures finding out the hard way.

JTBD, developed by Clayton Christensen and refined by practitioners like Bob Moesta and Tony Ulwick, starts with a simple premise: people don’t buy products. They hire them to do a job. When a startup founder purchases an AI code review tool, they’re not buying “AI-powered static analysis.” They’re hiring a solution to reduce the anxiety of shipping code they can’t fully audit. The product is the means. The job is the reason.

If you’re building AI products without understanding the jobs your customers are hiring for, you’re guessing. And as we lay out in our product validation playbook, guessing at this stage is the most expensive mistake a founder can make. JTBD gives you a framework to stop guessing.

Why JTBD Matters More for AI Products

Most software products compete on a well-understood playing field. You know what a CRM does. You know what a project management tool does. Buyers have mental models for these categories.

AI products don’t have that luxury. The capabilities are new, the expectations are undefined, and customers often can’t articulate what they want because they don’t yet know what’s possible. This makes traditional feature-based competitive analysis nearly useless.

JTBD cuts through this ambiguity. Instead of asking “what features should our AI product have?” you ask “what job is the customer trying to get done, and where are they struggling?” The job stays constant even as technology changes. People wanted to get from point A to point B long before cars existed. They wanted to make sense of their data long before dashboards existed. The job is stable. The solution is variable.

This is what makes JTBD particularly powerful for AI product decisions. You’re not locked into building what competitors are building. You’re locked into solving what customers are struggling with.

The Three Layers of Customer Jobs in AI Adoption

Every job has three dimensions. Miss any one of them, and your product solves the wrong problem.

Functional Jobs

These are the practical outcomes your customer is trying to achieve. They’re measurable and observable.

Examples in AI product adoption:

• A startup founder’s functional job: reduce time-to-market for a new feature from 12 weeks to 4.
• An engineering manager’s functional job: review 300 pull requests per week without growing the team.
• A consultant’s functional job: deliver a competitive analysis to a client in 2 days instead of 10.

Functional jobs are where most product teams stop. They shouldn’t.

Emotional Jobs

These are the feelings the customer wants to experience — or avoid — while getting the functional job done.

• The startup founder’s emotional job: reduce the anxiety of shipping AI-generated code they can’t fully verify.
• The engineering manager’s emotional job: feel confident that code quality standards haven’t degraded despite higher throughput.
• The consultant’s emotional job: avoid the embarrassment of delivering AI-generated output that contains hallucinated data.

Emotional jobs often drive purchasing decisions more than functional ones. A product that saves time but increases anxiety won’t get adopted. A product that’s slightly slower but makes the user feel in control will.

Social Jobs

These are about how the customer wants to be perceived by others.

• The startup founder’s social job: demonstrate to investors that the technical approach is rigorous, not haphazard.
• The engineering manager’s social job: be seen by leadership as someone who scales the team intelligently.
• The consultant’s social job: be recognized by clients as someone who leverages AI effectively without cutting corners.

When you build an AI product that nails the functional job but ignores the emotional and social dimensions, you get the common pattern: impressive demo, weak adoption. The product works, but people don’t feel good using it. They don’t feel safe. They don’t feel smart. So they stop.

How to Run JTBD Interviews for AI Products

Standard JTBD interviews focus on past purchasing decisions — the “switch” moment when someone moved from one solution to another. For AI products, you need to adapt this approach because many customers haven’t switched yet. They’re considering it, or they’ve tried and reverted.

Step 1: Find the Right Interview Subjects

You want three groups:

1. Recent adopters — people who started using an AI tool in the last 3-6 months. They can recall the decision clearly.
2. Failed adopters — people who tried an AI tool and stopped. These interviews are gold. They reveal the jobs the product didn’t satisfy.
3. Active considerers — people currently evaluating whether to adopt. They’re in the middle of the struggle, which makes their language vivid and specific.

Aim for 10-15 interviews total. JTBD research reaches saturation faster than you’d expect. By interview 8 or 9, you’ll start hearing the same jobs repeated.

Step 2: Map the Timeline, Not the Features

Don’t ask “what features do you want in an AI tool?” That gives you a wish list, not insight.

Instead, walk them through the timeline of their decision:

• First thought: “When did you first start thinking about using AI for this?” This reveals the trigger — the struggling moment that made the status quo unacceptable.
• Passive looking: “What did you start noticing after that?” This uncovers the jobs they were trying to get done.
• Active looking: “What did you actually try or evaluate?” This shows you what solutions they considered and why.
• Decision: “What made you choose this tool / decide not to use anything?” This reveals the hiring criteria — the functional, emotional, and social jobs that tipped the decision.

Step 3: Listen for Forces, Not Features

Every switch decision has four forces acting on it:

• Push: dissatisfaction with the current way of doing things.
• Pull: attraction to a new solution.
• Anxiety: fear about adopting the new solution.
• Inertia: comfort with the current way, even if it’s imperfect.

For AI products, anxiety and inertia are usually the dominant forces. People are attracted to AI capabilities but terrified of the risks. When you skip this research, you end up building products that amplify the pull (more features, more capabilities) while ignoring the anxiety (quality concerns, job security fears, compliance risks). That’s how you end up with the prototype-to-production gap — a product that works in demos but fails in real environments because it never addressed what actually held people back.

Applying JTBD to Build, Buy, or Skip Decisions

Once you have your job map, every AI capability decision filters through three questions:

1. Does this capability address a job customers are actively struggling with? If not, skip it. It doesn’t matter how technically impressive it is. Features that don’t map to real jobs are waste.

2. Does building this in-house create differentiation on the job dimensions that matter? If the functional job is commodity (every competitor can do it), but you can uniquely address the emotional job (making users feel safe), build it yourself. If both are commodity, buy it.

3. Does shipping this without proper validation create risk that outweighs the benefit? This is where the cost of skipping research becomes concrete. A capability built on assumed jobs rather than validated jobs is a bet at bad odds.

The output of this process isn’t a feature roadmap. It’s a job-based priority map: which jobs are most important, least satisfied, and most aligned with your ability to deliver. That clarity is worth more than any backlog of feature requests.

What to Do Next

JTBD isn’t a one-time exercise. Run these interviews quarterly — customer jobs evolve, especially in a domain moving as fast as AI.

Start here:

• Read the full validation playbook. Our guide to customer research before building gives you the complete process for validating product ideas, with JTBD as one of several complementary methods.
• Run 5 interviews this week. You don’t need a research team. You need a phone, a note-taking app, and the willingness to listen more than you talk. Five interviews will teach you more than five months of feature brainstorming.
• Map the jobs before the next sprint. Take what you learn and create a simple job map: functional, emotional, social. Prioritize the jobs that are most important and least satisfied. Build from there.

The best AI products aren’t the most technically sophisticated. They’re the ones that do a job customers already care about — and do it in a way that makes them feel confident, not anxious. JTBD gives you the framework to find those jobs before you invest in building the wrong thing.

---