What is the Jobs to Be Done framework?
Jobs to Be Done is a product framework that explains buying and use as progress: people choose a product because they want to change a specific situation. By the end, you can write a useful job statement, interview users, map alternatives, and test product ideas.
The framework starts with a simple shift in attention. A product is not the job. A drill is a tool, a hole is an immediate result, and hanging a shelf may be the progress a person actually seeks. Even that answer can be too shallow. The shelf might create enough storage to clear a crowded desk before a new school term begins.
A job therefore joins three things: a person's situation, the progress they want, and the limits on an acceptable solution. It is more stable than a product feature because people often seek the same progress through very different means. A commuter who wants to arrive alert may take a train, cycle, drive, work remotely, or move closer to work.
A job is progress in context. “Buy a blender” names a transaction. “Prepare a filling breakfast in five minutes without waking the household” describes progress and the conditions that shape the choice.
The word job does not mean employment. It means something a person is trying to get done. Jobs can be practical, emotional, and social at the same time. A teenager may use a revision app to remember facts, feel less panicked before a test, and show a parent that revision is happening. Treating only the practical part as real leaves useful evidence on the floor.
Why do product ideas become clearer when you start with the job?
Starting with the job gives a team a stable problem to solve and a direct test for every idea. A feature deserves attention only if it helps someone make the desired progress better than the alternatives, within the limits of the real situation.
Feature-first thinking begins inside the company. Someone proposes an artificial intelligence assistant, a streak counter, or a social feed, then searches for a reason to add it. Job-first thinking begins outside the company. It asks what changed in a person's life, what result they now want, and what prevents them from getting it.
How could we add reminders to our study app?
How might a student restart revision after missing several planned sessions?
The second question opens more useful routes. A reminder may help, but so might a smaller restart task, a revised plan, a way to hide missed targets, or a prompt tied to the student's timetable. The job sets the destination without prescribing the vehicle.
This resembles decomposition in breaking large computing problems into smaller ones. A vague demand such as “make studying easier” becomes a set of decisions that can be examined: choose the next topic, begin without delay, detect a knowledge gap, and recover after interruption. The analogy has limits, but the habit is valuable. Precise subproblems produce testable ideas.
A clear job also stops attractive ideas from multiplying without purpose. If a proposed leaderboard makes anxious learners avoid the app, it works against their emotional job even if engagement rises for another group. The framework does not make decisions automatic. It makes the reason for a decision visible enough to debate and test.
What does a strong job statement contain?
A strong job statement names the situation, the desired progress, and the standard for success without embedding a particular product. It is specific enough to guide research but broad enough to allow competing solutions. Good wording describes what must change, not what must be built.
A practical template is: When [situation], I want to [progress], so I can [meaningful outcome]. Add constraints when they shape choice, such as time, cost, privacy, effort, risk, or the involvement of other people.
Example: Late on a school night + identify tomorrow's highest priority task + stop planning within ten minutes.
The expression is a writing aid, not a scientific law. Its value comes from forcing missing information into view. “Organise my work” lacks a trigger and a finish line. “When several assignments are due in the same week, decide what to do next without rebuilding my whole plan” gives a team something it can observe.
Remove product nouns during the first draft. “When I am hungry, I want a meal delivery app” already chooses the answer. “When I arrive home late, I want a hot dinner with almost no preparation or washing up” leaves room for delivery, a frozen meal, leftovers, batch cooking, or food prepared by someone else.
Be careful with demographic descriptions. Age, income, and location can affect constraints, but they do not explain causation by themselves. Two people of the same age may hire a notebook for entirely different jobs. Two people decades apart may use it for the same job: capturing a thought before it disappears.
How do you find the real job in an interview?
Find the job by reconstructing a specific choice that already happened. Ask for events, actions, doubts, alternatives, and timing. Do not ask people to design a product or predict distant behaviour. A remembered decision gives firmer evidence than a general opinion about what sounds useful.
Choose an interviewee who recently started, stopped, switched, or rejected a product. Then build a timeline. What first made the old situation uncomfortable? What solution did the person use before? What event made action feel necessary? Where did they search? Who influenced the choice? What nearly stopped it?
Ask for the last time the person made the choice. Anchor the account to a place, day, and task.
Learn what they used before, including manual work, help from another person, delay, or doing nothing.
Ask what created urgency, what alternatives entered the choice, and what risks produced hesitation.
Ask how they knew the new solution had worked and what still felt difficult afterward.
Follow concrete details. If someone says, “It was convenient,” ask what inconvenience disappeared. Perhaps the old tool required a laptop, while the task happened on a bus. Perhaps setup took longer than the available break. Each detail suggests a condition that a concept must survive.
A customer says, “I bought the premium calendar because I wanted to be organised.” Ask what happened the day they paid. You learn that two meetings were missed after a rota changed. The job is closer to absorbing schedule changes without losing commitments than to generic organisation.
Avoid leading questions such as “Would automatic rescheduling help?” They reward politeness and imagination. Ask, “What did you do when the rota changed?” and “What was hard about that?” Behaviour can still be misremembered, so compare several interviews and, with permission, examine receipts, messages, calendars, search histories, or other records tied to the decision.
What forces make a person switch?
A switch occurs when pressure from the current situation and attraction to a new solution outweigh attachment to old habits and anxiety about change. Mapping all four forces explains both demand and resistance. A better feature list alone may fail because switching carries practical and emotional costs.
The two forces pushing towards change are dissatisfaction with the current situation and attraction to the imagined result. The two holding forces are familiarity with the old method and fear of the new one. Fear can concern price, learning time, privacy, reliability, embarrassment, or the chance of losing existing work.
Consider a small business moving customer records out of spreadsheets. Search and duplicate entries may create pressure. Shared access and automatic follow-up may attract the team. Familiar formulas preserve the old habit, while fear of a difficult migration blocks the new system. Knowledge of how databases store and relate records helps explain why a structured system can prevent some errors, but the product still has to make the transition feel safe.
Do not confuse dislike with demand. People can complain about a tool for years and keep using it. A credible job includes enough pressure, opportunity, or consequence to make action plausible.
This is why onboarding, import tools, trials, guarantees, and compatibility can matter as much as headline features. They reduce the holding forces. A team that studies only desired outcomes sees half of the decision and may build something appealing that few people adopt.
How do alternatives reveal the true market?
The true market contains every method a person could hire for the same job, including another product category, a manual workaround, another person, postponement, or no action. Competitors are defined by the progress they enable, not by their shelf label or software category.
A cinema competes with other cinemas for screens and films, but for the job “spend an easy evening together outside the house,” it may also compete with a restaurant, a walk, bowling, or staying home. The relevant set depends on the situation. A rainy night, limited money, a tired child, or a need for conversation changes the field.
This is an economic choice under constraints. Time and money spent on one option cannot be spent on another. The ideas behind shared goods and incentives also show why some jobs are poorly served by ordinary markets: people may want a clean local park, yet no single visitor can easily charge everyone who benefits.
A task manager competes with other task managers on filters, reminders, and integrations.
For “stop worrying that I forgot something,” it also competes with paper lists, email drafts, asking a colleague, and keeping the thought in memory.
List alternatives before proposing features. For each one, record what makes it attractive, what it costs, where it fails, and why someone returns to it. The humble workaround often contains the strongest clue. A paper list has weak search and no automation, yet it opens instantly, accepts any mark, and keeps private tasks off a company server.
Market boundaries change when the job changes. For “calculate a monthly loan payment,” a spreadsheet, calculator, bank website, and adviser can substitute for one another. The underlying relationships connect unknowns with known quantities, while the chosen tool depends on trust, speed, explanation, and the consequences of an error.
How do you turn job evidence into product ideas?
Turn evidence into ideas by separating the job into steps, locating moments where users lose time or confidence, and generating several ways to improve those moments. Rank concepts against observed needs and switching barriers, then test the riskiest assumption before building the full product.
Begin with a job map. This is the sequence a person follows to make progress, independent of any one product. For planning a week, the sequence might include gathering commitments, estimating effort, spotting conflicts, choosing priorities, assigning time, adjusting after change, and checking completion. The map exposes where outcomes break down.
For each step, ask what the person wants to make faster, more predictable, less effortful, or less risky. Keep the outcome separate from the solution. “Reduce the time needed to find schedule conflicts” is an outcome. “Build a colour-coded calendar” is one possible response.
A simple scoring model can force assumptions into the open. Rate importance, current dissatisfaction, and confidence in the evidence on a scale from 1 to 5. Multiply them to get a comparison score. This is a team-made decision aid, not a universal JTBD formula.
If importance is 5, dissatisfaction is 4, and evidence confidence is 3, then .
The arithmetic is visible, but the ratings remain judgments. Use the score to expose disagreement, not to disguise it. If one researcher assigns confidence 5 and another assigns 2, discuss the missing evidence. Never let a neat total overrule a serious safety, legal, or accessibility concern.
Test the weakest link in each concept. A clickable mockup can test comprehension. A manual service can test if the promised outcome is valuable. A landing page can test whether the situation and promise attract attention, but it cannot prove long-term use. A price conversation can expose tradeoffs more honestly than asking if someone “likes” an idea.
What mistakes make Jobs to Be Done useless?
Jobs to Be Done becomes useless when teams write vague aspirations, treat interview wishes as facts, ignore non-product alternatives, or use the language to decorate a decision already made. The remedy is traceability: every job, constraint, and concept should connect to observable evidence.
- Writing a slogan instead of a job. “Feel in control” may describe an emotion, but it lacks the situation and visible change needed to guide design.
- Treating every difficulty as a market. A minor irritation is not enough. Look for consequences, repeated workarounds, spending, delay, or a trigger that makes action likely.
- Asking only loyal customers. Include people who quit, chose a rival, returned a product, or decided to do nothing. Their resistance reveals boundaries.
- Forgetting emotional and social outcomes. A tool can complete the task yet fail because it makes the user feel exposed, incompetent, dependent, or rude.
- Turning one interview into a universal truth. One story can generate a hypothesis. Repeated patterns across distinct cases provide stronger grounds for a decision.
- Confusing correlation with cause. Heavy users may share a trait without that trait causing adoption. Reconstruct the choice and seek the mechanism.
Research records should preserve the chain from raw observation to interpretation. Store the interview excerpt or behavioural evidence, the proposed job, the condition it supports, and the product decision that followed. This discipline is close to good work across computer science and its data systems: later conclusions are easier to audit when the inputs and transformations remain available.
Five interviewees request calendar integration, so the team builds it. Later, use is low. The underlying job was receiving an early warning about overloaded days. Integration was the interviewees' familiar solution, while a workload alert could have served the job with less setup.
Jobs also change with context. A solution hired during an emergency may be abandoned during routine work. Someone cooking for one person has different constraints from the same person hosting ten guests. Segment by situation and desired progress before assuming that a personal profile predicts the choice.
A clear job turns research into a testable product decision
A usable Jobs to Be Done process ends with a decision that can be challenged by evidence. Name the situation, desired progress, success condition, current alternatives, switching forces, and weakest assumption. Then choose the smallest test that could change the team's mind.
A compact example brings the pieces together. Suppose students abandon revision plans after missing two days. Interviews show that the old plan now feels impossible, rebuilding it takes effort, and visible missed tasks create shame. The job might be: “When I fall behind, help me choose a realistic next session without making me account for every missed task.”
Possible concepts include a one-session restart, automatic rescheduling, or a clean slate that preserves future deadlines. The team might test a manual restart service with a small set of volunteers before writing scheduling code. Success means participants resume a planned session and understand what comes next. Failure means the proposed help does not change behaviour or creates a new worry.
The takeaway: Do not ask what feature to build until you can state whose situation is changing, what progress they seek, what they use now, and what could stop them switching. That evidence makes a product idea specific enough to test.
The framework cannot guarantee a successful product. It can expose weak reasoning early, widen the set of alternatives, and connect design choices to real decisions. That is enough to make many product ideas look obvious in retrospect: the useful idea is the one that removes a demonstrated obstacle to progress.