Jobs-to-be-done (JTBD) is a way of describing what a customer is ultimately trying to accomplish, independent of any product or step they're currently using to get it done. Most of the material you'll find online treats JTBD as a research method: a way to run better interviews, fill in a journey map, or populate a persona template. That work is real and useful. But it stops one step short of where the leverage is. A well-framed job-to-be-done is the front end of a strategy: it tells you what the customer is hiring a solution to do, which lets you name what they'd otherwise do instead, which is the thing your strategy actually has to beat. And it feeds the rest of the analysis directly: each job becomes a set of measurable requirements, and the jobs, sized across your segments, inform the revenue forecast. Frame the job well and you've started building something you can model and test — not just a research finding, but a strategy hypothesis.
That distinction is the whole point of this article. Here's how a job seeds a strategy you can defend.
A job-to-be-done has two defining characteristics. It's solution-agnostic, framed without reference to any particular product or implementation. "Get groceries home" is a job; "use a delivery app" is one possible solution to that job, not the job itself. And it's stable over time — a well-framed job doesn't change just because the available solutions change. "Keep my home temperature comfortable" is the same job today as it was a century ago, even though the solutions have run from fireplaces through central heating to smart thermostats.
Three things a job-to-be-done is not, because confusing them is the most common framing mistake:
Frame a job as an activity, a solution, or a step, and you lock your thinking into the current way of doing things. A solution-agnostic job opens the design space to alternatives that might serve the same goal better. That's not a research nicety. It's the move that makes everything downstream possible.
In our own work we write every job in a tight, three-part syntax: Verb + Object + Clarifying Context. "Reduce time-to-decision when evaluating a new strategy hypothesis." "Maintain confidence in financial projections under high uncertainty." The clarifying context is what keeps a job from reading as too generic to be useful. Drop it and jobs collapse back into either vague aspirations or activity descriptions.
Each job then carries a small set of tags that make it usable downstream rather than just readable:
One more field earns its place early: what the customer does to get this job done today — the current solution, the workaround, the manually connected combo of partial solutions. Capturing it alongside the job is the first differentiation signal in the whole analysis. It's the seed of the competing-alternatives picture, and it's where the difference between your offering and the status quo first becomes visible.
Here's the turn that takes JTBD from research artifact to strategy. Once you've framed the job in a solution-agnostic, stable way, you can finally ask the question that matters: what else could the customer do to get this job done?
That question is the entry point to competing alternatives, and there are always more of them than a product category map suggests. We use four buckets, and a complete competitive picture addresses each one, even briefly:
The last bucket is the one most teams underweight, and it's usually the realistic baseline. A new B2B tool's hardest competitor is rarely a feature-comparable rival; it's the spreadsheet or manual process the buyer is already using plus the inertia of switching. In many enterprise contexts, doing nothing is the most likely outcome by default: the path your offering has to beat to win the decision at all.
This is why the strategy framing beats the UX framing. A journey map tells you how a customer moves through your product. A job, paired with its competing alternatives, tells you what your strategy is actually up against — and that's a far more consequential thing to know before you've spent real money. The job names the goal; the alternatives name the competition for that goal; and the gap between them is where a defensible strategy lives.
A research artifact ends with insight. A strategy starts with a structure you can build on. The reason a well-framed job is the front end of strategy (and not just a better research note) is that it feeds the rest of the analysis directly, in two concrete steps.
First — and most important — each job becomes a set of measurable, prioritized requirements. The mapping is direct and traceable: each job maps cleanly to one or more Market Requirements, the specific, measurable things a whole solution has to deliver to satisfy the job. The job stays the stable, solution-agnostic anchor; the Requirements derived from it carry the measurable attributes (importance, current satisfaction, the performance the solution must reach), which is what lets you prioritize them and build against what matters most to winning the job. That mapping is what takes you from "here's what the customer is trying to accomplish" to "here's what our offering has to do, and how well, to win."
Second, and more indirectly, the same jobs also inform the market sizing. The main job helps define the addressable market in the first place, and how many people perform each job (in which segment, at what frequency) feeds the revenue forecast downstream. This link is real but secondary: the load-bearing contribution of a well-framed job is the prioritized requirements above, and the sizing follows from getting those right. Either way, the same solution-agnostic jobs you framed at the start sit underneath the strategy — which is the literal sense in which a job is its front end: not a finding you set aside before the real work, but the structure the rest is built on.
Two more moves make the structure load-bearing rather than decorative:
Define jobs for more than the primary user. In any enterprise sale, the person who uses the product, the person who approves the purchase, the person who clears it on security or compliance, and the person who administers it are rarely the same human, and they have different jobs. A job analysis that covers only the primary user systematically misses why deals stall. The decision maker has a job ("justify the investment to leadership"); the approver has one ("confirm this meets our standards"); the admin has one ("get the team set up without friction"). Each carries its own evidence requirement.
Define jobs across the whole journey, not just the purchase. A complete solution to the main job usually has to satisfy supporting jobs spread across the journey — recognizing the problem, evaluating, committing, onboarding, using, troubleshooting, expanding, and eventually retiring. Those supporting jobs are part of the scope of the main job: miss a phase and you don't have a full picture of what the customer is really trying to get done. Solutions that win on Discovery and Evaluation but lose on Setup or Troubleshooting are common and instructive. The gap sits in a phase the team never analyzed.
Once jobs are framed this way — mapped to Requirements, sized into the forecast, spanning performers and journey phases — they stop being a deliverable and start being inputs to a model. Many of the highest-impact assumptions in any new-venture strategy are assumptions about how customers will perform their jobs: what they value, what they'll switch from, what tradeoffs they'll accept. Those are exactly the assumptions worth gathering evidence against first. The job work tells you where to look.
Jobs-to-be-done is a way of describing what a customer is ultimately trying to accomplish, independent of any product, solution, or step they're currently using to get it done. A well-framed job has two defining traits: it's solution-agnostic (framed without reference to a particular product) and stable over time (it doesn't change just because the available solutions change). "Keep my home temperature comfortable" is the same job today as it was a century ago, even though the solutions have run from fireplaces to smart thermostats.
A persona describes who a customer is — a profile of attributes, demographics, and goals. A job-to-be-done describes what a customer is trying to accomplish, independent of who they are. The two aren't competitors; they answer different questions. The risk with personas is that a profile can quietly substitute for understanding the underlying goal, and goals are what your strategy has to serve. In practice, the same job is often performed by several distinct people (a primary user, a purchase decision maker, an approver, an admin), so the more useful unit of analysis is frequently the job-and-performer pair, not the persona alone.
"Use case" gets used a few different ways. In its common software sense, a use case describes how a user interacts with a particular solution to accomplish something — solution-bound and step-oriented. At BRI we use the term differently: a use case frames the main job a customer is trying to accomplish (the highest-level statement of the outcome they want), and the more granular jobs-to-be-done break that down by performer and journey phase. Either way, a job-to-be-done stays solution-agnostic: it names the destination, not a path through any one product, which is what lets you compare your offering against everything else a customer could choose, including doing nothing.
Frame the job cleanly — solution-agnostic, stable, with enough clarifying context to be useful — then let it feed the analysis. It names the competing alternatives the customer is really weighing: direct competitors, substitutes, potential entrants, and the status-quo, do-nothing option. It maps to the specific, measurable, and prioritized Market Requirements your whole solution has to deliver to win against those alternatives. And sized across your target segments — by how many people perform the job, in which segment, at what frequency — the same jobs inform your revenue forecast. From there you identify which underlying assumptions are both high-impact and unproven, and gather evidence there first. At that point you no longer have a research finding. You have a strategy hypothesis you can model, evaluate, and revise as the evidence comes in.
Most JTBD content stops at the interview — it treats a job as a UX deliverable that feeds a journey map or a persona. Framed that way, a job is one more input to the patchwork of templates and models teams already juggle. Framed as the start of a strategy, a well-articulated job names your real competition (the competing alternatives) and seeds and helps prioritize the Market Requirements your offering must meet. That makes the job the first move in a connected sequence (defining a strategy you can model and evaluate), rather than an artifact that hands off to nothing in particular.
Worked as a research artifact, a job-to-be-done is one more input to the fragmented patchwork of PowerPoint templates and Excel models most teams rebuild every project; worked as the front end of a connected method, it's where a defensible strategy starts. Growth Forge® Software, built on BRI Associates' decades of practitioner experience in corporate innovation and new business development, is made to carry a job-to-be-done that far: its Jobs to Be Done tool structures customer jobs across the full journey and set of performers; from there, the same connected model derives and prioritizes Market Requirements, sizes the jobs across your segments into a revenue forecast, surfaces competing alternatives, and lets you model the financials and evaluate the strategy against evidence rather than presentation quality — stronger strategies, smarter investment decisions. If you've got a job-to-be-done worth pursuing and want to see what it looks like as a testable strategy, Growth Forge is a free trial away, with a worked example pre-loaded so you're not starting from a blank page.
