Jobs-to-Be-Done Framework Applied to Content Planning

Tony Ulwick built the framework around 1990, applying Six Sigma discipline to innovation problems. His first real test came in 1992 with Cordis Corporation's angioplasty products, where the methodology surfaced unmet customer outcomes with a precision conventional market research couldn't touch. Clayton Christensen encountered Ulwick's work at Harvard and later gave us the phrase "jobs-to-be-done" in his 2003 book "The Innovator's Solution." The formulation is deceptively simple: when we buy a product, we hire something to get a job done.

The milkshake case is the one that made this click for most people. A fast-food chain ran conventional research to improve milkshake sales. More chocolate? Thicker consistency? Lower price? Nothing moved. When researchers instead asked what job people were actually hiring the milkshake to do, an entirely different picture emerged. The largest buyer segment was purchasing in the morning, alone, before a long commute. The job wasn't "enjoy a dessert." It was "survive a boring drive without going hungry, with one hand free." The real competitors weren't other milkshakes. They were bananas, bagels, and skipping breakfast entirely. Nobody's product brief had ever named those competitors, because the research was asking the wrong question from the start.

What makes JTBD durable is one specific observation: jobs are stable; products are not. The job of listening to music while moving through the world has persisted across records, cassettes, CDs, MP3 players, and streaming services. The solution changed with every technological generation. The job didn't budge. For content planners, this means the research you invest in today, the genuine jobs your readers are trying to accomplish, stays valid even as formats, platforms, and algorithms shift under you.

Any job worth understanding has at least three layers. The functional layer is what the person concretely wants to achieve. The emotional layer is how they want to feel during and after the process. The social layer is how they want to be perceived by others. Most content planning lives almost entirely in the functional layer, which explains why so much content is technically correct and emotionally flat. It answers the question but never reaches the person asking it.

One clarifying note before moving on: "JTBD" covers multiple schools of thought. Ulwick's Outcome-Driven Innovation and Bob Moesta's Switch methodology share a conceptual core but diverge in emphasis and application. This article draws on that shared core because the underlying logic holds across both.

What a "Job" Looks Like When Applied to a Reader, Not a Buyer

In the context of content, the product being hired is the content asset itself: the article, the video, the case study, the tool. The job is the progress the reader is trying to make. That shift moves the unit of planning from "what topic should we cover?" to "what is this person trying to accomplish, and will this piece actually help them get there?"

The job story format gives that question workable structure: "When I [current situation], I want to [desired action], so I can [desired outcome]." NerdWallet's retirement planning content maps to something like: "When I haven't been able to organize my finances, I want to find simple ways to plan for retirement, so I can feel better and move toward my future with some confidence." Notice what's happening in the outcome clause. "Feel better" and "move toward my future with confidence" are emotional jobs, and they're doing the actual motivational work. Without them, you have a technically accurate article about retirement accounts. With them, you have something that reads like it was written for a person's actual experience, not their demographic profile.

L'Oréal's interview preparation content maps to a different job entirely: "When I have an upcoming interview at L'Oréal, I want to learn how to make an overall good impression, so I can get hired." The social dimension, being perceived as qualified and composed, carries the weight here. That job drove the format toward video, because seeing how to present yourself is more useful than reading a description of it. That's not a content calendar decision; that's the job talking.

Here's what this surfaces that a persona never will: two readers with identical demographics can be hiring completely different jobs from the same topic area. One wants validation that they're on the right track. One wants a step-by-step process. One wants ammunition for an internal conversation with a skeptical executive. These are different jobs. They require different content, even when the topic label looks identical.

The emotional and social layers are the ones content planning most reliably ignores, and they're frequently the ones that determine whether a piece converts. A small business owner researching customer acquisition has a functional job: get more customers. But the emotional job is building confidence in a domain that feels overwhelming. The social job is being recognized, by peers, by employees, by customers, as someone who knows what they're doing. Content that addresses only the functional job never reaches the reader where they actually are.

How to Conduct Research That Surfaces Real Jobs

Before any method, one thing needs to be said plainly: teams that apply JTBD conceptually without talking to actual customers almost always produce the same content they would have created anyway, just described in different language. The framework generates nothing on its own. Research does.

The Switch Interview, developed by Bob Moesta, is the most rigorous tool available. It's a structured, timeline-based qualitative interview designed to reconstruct the exact moment a person decided their current solution was no longer adequate. The key distinction is that these interviews focus on transition moments, not current usage patterns. The operative question isn't "how do you use this?" It's "what happened that made you start looking for something different?"

The method targets recent switchers specifically, people who changed their solution within roughly the last 90 days, because long-term users cannot reconstruct their switching decision with enough fidelity. Memory smooths over friction; recent switchers can still feel it. Four forces are active in any switching decision, and they give the interview its analytical structure: the push of the current situation (what pain drove them to look?), the pull of the new solution (what attracted them?), the anxieties they felt about switching, and the inertia from habits they had to overcome. Each force maps to a content opportunity. The push is problem-aware content. The pull is consideration and comparison content. The anxieties become objection-handling content. The inertia becomes content that makes getting started feel less costly.

Conducting and properly analyzing a meaningful set of Switch interviews, coding timelines, mapping forces, identifying patterns across interviews, takes weeks. Not hours. Teams that treat it as a quick survey will get surface-level output, and surface-level output is exactly what they were producing before they picked up the framework.

Lighter-weight signals can supplement interviews without replacing them. Support chat logs, help desk tickets, community forum questions, customer reviews: these are all places where people describe their struggle in their own language, without any interviewer shaping the response. That language matters specifically because it shows how people articulate their jobs while they're in the middle of them, which is exactly the language to mirror in headlines, introductions, and section headers.

For SEO-oriented programs, this research frequently surfaces lower-competition, higher-intent keyword territory. The situational phrases people use when they're actively in the middle of a job are more specific than generic head terms, and more specific queries convert at higher rates because the person has moved from browsing to doing. AI-assisted analysis can accelerate pattern recognition across large volumes of qualitative data, interview transcripts, support logs, review text, without replacing the underlying research. The rigor requirement stays constant regardless of how the synthesis happens.

Using Job Stories to Decide Which Content to Build First

Once interviews and supplementary signals have been analyzed, each distinct switching pattern or struggle cluster becomes a candidate job story. That's the raw material for an editorial brief. But not all jobs warrant equal investment, and prioritization is where JTBD thinking generates its clearest competitive advantage over topic-driven planning.

Three criteria determine which job stories deserve the first briefs. Frequency: how many customers or prospects surface this job? Underservice: does adequate content already exist for this job, or is there a genuine gap? Strategic fit: does satisfying this job move someone meaningfully closer to hiring your product or service? A job story that scores high on all three is an unambiguous priority. One that scores high on frequency but is already thoroughly addressed by well-ranking competitors requires a different calculus entirely.

Ulwick's Outcome-Driven Innovation framework provides a formal mechanism for this, the Opportunity Algorithm, which scores which outcomes matter most to customers and are least well served by existing solutions. Content planners can apply the same logic informally: high importance to the reader, poor service by existing content, equals a high-priority brief. Strategyn, Ulwick's firm, reports a markedly higher success rate for this method against the general industry average. That figure comes from Strategyn's own reporting rather than independent audit, so it's directionally meaningful rather than independently verified.

What this changes in practice is the shape of editorial planning. Instead of a topic cluster built around "project management," you build briefs around distinct job stories: "when I'm presenting a roadmap to a skeptical executive team and need to preempt objections before they surface," or "when I've just inherited a chaotic project mid-flight and need to establish credibility fast." Each of those jobs maps to a different content type, a different tone, a different call-to-action, a different conversion path. The topic label is the same. The content could not be more different.

Matching Content Format and Structure to the Job Being Served

The job determines the format. Not the content calendar, not the team's preferred medium, not what a competitor published last month.

A functional job with a sequential process requires a step-by-step how-to; the reader needs to execute, not be inspired, so structure and completeness matter more than narrative arc. A job involving an internal recommendation requires a case study or structured comparison, because the reader needs evidence they can carry into a room and defend. An emotional or social job involving identity, credibility, or professional self-presentation calls for narrative or thought leadership, because the reader needs to see themselves succeeding before they'll believe the content is for them. A job triggered by a specific data need, benchmarks for a board presentation, statistics for a proposal, requires reference content that functions as a source, not a guide.

Search behavior makes this concrete. Readers use search to accomplish specific, situational jobs: finding conference recommendations, locating statistics for presentations, answering technical questions, sourcing templates, discovering tools worth evaluating. Each of those is a distinct format opportunity. Treating them as variations on the same blog post is precisely why so much content covers topics while missing jobs entirely.

The principle extends to language at every level. A headline that reads "All-in-one Project Management Software" describes the product. A headline that reads "Keep every deadline on track and your team aligned" names the job. The second creates immediate recognition in the reader who is living that problem right now. The same logic applies to article titles, section headers, introductions, calls-to-action.

Introductions are where this matters most, because the reader is deciding in the first two sentences whether this content will accomplish their job. An introduction that surfaces the specific struggle the reader is already in, before it explains what the piece covers or establishes the writer's credentials, passes the hiring moment. One that opens with context-setting or definitions loses it. That's not stylistic preference; that's how content earns continued reading.

In competitive content markets, where many pieces address the same topic, the piece that most precisely names the reader's job wins the engagement. Not the longest piece. Not the most heavily linked piece. The one the reader recognizes, in the first paragraph, as written for their actual situation.

Building a JTBD-Informed Editorial System That Scales

The output of JTBD research is not a persona document you refresh annually. It's a living library of job stories that informs every brief, every format decision, and every prioritization conversation your team has going forward.

A minimum viable JTBD content planning layer has a specific shape. It starts with a documented set of job stories derived from real research, not assembled from internal intuition. Each job story is mapped to its functional, emotional, and social dimensions, along with the trigger moment that activates it and the competing solutions the reader is hiring instead, including the decision to do nothing. Each story carries a priority ranking based on frequency, strategic fit, and content gap. And each one feeds format and angle guidance directly into briefs, so writers know not just what to cover but what job they're serving and what success looks like for the reader.

For SaaS content programs specifically, this layer sits on top of whatever persona infrastructure already exists. The persona handles the tactical questions: tone, channel, reference points, vocabulary level. The job story handles the strategic questions: why is this person looking for content right now, what are they trying to accomplish, and what would make this piece feel like it solved something rather than just covered a subject? HubSpot's approach of maintaining both persona and job-story infrastructure in parallel is an instructive example of this working at scale, where personas provide audience calibration and job stories provide strategic intent.

AI-assisted content production fits into this system in a specific place: after the job stories are defined and documented, not before. Content workflows that deploy AI generation without a clear job-story brief default to generic topic coverage, because the job-story layer is precisely what distinguishes purposeful content from comprehensive content. A well-defined job-story brief, one that specifies the trigger situation, the functional goal, the emotional and social stakes, and the competing solutions, gives any writer or AI-assisted workflow the context needed to produce something that actually converts. The constraint producing generic output isn't the technology. It's the absence of strategic specificity upstream.

Speed and quality stop being in tension once the strategy layer is built first. A content team working from a job-story library can move quickly without drifting, because the brief answers the questions that otherwise stall production: What angle? What format? What should the reader be able to do when they're done?

That planning investment pays forward in one specific way: it answers "what should we build next?" with evidence rather than intuition. Which is, ultimately, the difference between building something and just keeping busy.