8 Jobs to Be Done Statement Examples
A customer asks for a dashboard. Another wants more notifications. Neither request tells you why the customer needs to act, what they currently do instead, or how they would judge a better result.
A jobs to be done (JTBD) statement captures that missing context. It describes a situation, the progress someone seeks, and the outcome that would make a solution useful. For teams with existing products, this can shift a conversation from feature requests to customer motivations that research can test.
These jobs to be done statement examples come from published cases, not invented interviews. Each statement below is a paraphrase constructed from its source, not a customer quote or an official statement issued by the company. Use the examples to sharpen your own research, not as proof that the same job exists in your market.
What is a JTBD statement? It describes progress in context
A JTBD statement names what someone is trying to accomplish in a particular situation without prescribing a product. In the Christensen Institute's explanation of JTBD, people hire products and services to make progress. The job is the reason for the hire, not the product itself.
The progress may have several dimensions:
Functional: Complete a practical task, such as resolving a support question.
Emotional: Feel confident that the answer is accurate and timely.
Social: Be seen by colleagues or customers as capable and dependable.
These dimensions can coexist. A procurement manager purchasing software licenses may need coverage for employees, confidence that deployment will work, and a defensible decision for leadership. Do not automatically put every dimension into one sentence. Write the core job clearly, then record associated concerns as research findings.
A feature names a possible solution, such as an alert. A user story usually specifies behavior to build, such as, "As an account owner, I want a low-balance alert so I can avoid an overdraft." A job remains useful even if that alert is not the right solution: "When upcoming bills could exceed my available cash, I want to understand what I can safely spend so I can avoid a shortfall." Jobs guide discovery; user stories help specify a chosen implementation.
How to write a JTBD statement: Start with the situation
Use this reusable jobs to be done template:
When [specific situation or trigger], I want to [make progress, without naming a feature], so I can [achieve a meaningful outcome].
For example: "When several customers ask the same support question after signup, I want to understand where their setup breaks down, so I can remove the recurring obstacle." This is a hypothetical writing example, not a reported customer finding. Interview customers before adopting it as a product insight.
Check each clause. Is the trigger something that actually happens? Does the middle describe what the person is trying to accomplish rather than "use a dashboard"? Can you observe or investigate the outcome? If the sentence already names a screen, replace it with the progress the screen is supposed to enable.
This format is not the only JTBD framework. Strategyn's approach often states a stable functional job as an action and object, such as "manage daily cash flow," then separately identifies and measures the outcomes customers use to judge success. The situational "When" format is useful for a decision or switching moment; Strategyn's functional-job format is useful for mapping a broader activity and its unmet outcomes. Neither format substitutes for customer evidence.
8 real jobs to be done statement examples, with sources
The eight cases below span consumer products, software, finance, transport, and e-commerce. The situations and product decisions are drawn from the linked reporting; the formatted JTBD statements are editorial paraphrases. Product implications are either documented responses or explicitly identified opportunities to investigate. They are not claims that a hypothetical feature shipped.
1. McDonald's milkshake: Make the commute easier
Customer context: In the well-known milkshake research, morning purchasers were often alone, in a hurry, and headed into a long drive. A milkshake lasted, offered something to do, and helped stave off hunger. Its alternatives included other breakfast foods, not just other drinks. Harvard Business School's account of the milkshake case describes the purchase circumstances.
JTBD statement, paraphrased: "When I have a long morning commute, I want something filling that I can consume with one hand, so I can stay occupied and avoid getting hungry before work."
Motivation and desired outcome: The functional need was portable sustenance; the emotional benefit was a less tedious drive. Success depended partly on how long the drink lasted and how manageable it was in the car.
Product implication: Evaluate the entire buying and consumption experience, including how quickly a commuter can purchase the drink. HBS's practical examples discuss making the milkshake thicker and speeding checkout as responses. Neither a demographic profile nor a taste survey alone would reveal this job.
2. Intercom: Respond when users need support
Customer context: Intercom investigated why businesses adopted its product. Intercom's account of the research describes 45 customer phone interviews and deeper analysis of 15 conversations. The team identified distinct jobs, including helping companies see users, learn from them, support them, and engage them.
JTBD statement, paraphrased: "When users contact us about a problem, I want to provide a timely response, so I can help them get unstuck and maintain a useful relationship."
Motivation and desired outcome: This reconstructs Intercom's published Support job, not the company's full set of customer jobs. The motivation is resolving a user's need at the moment it arises; the desired outcome is helpful, timely support.
Product implication: Separate support workflows from observation, learning, and engagement workflows rather than treating all communication as one undifferentiated feature set. Intercom's published account describes using the research to clarify how it presented its product. For an existing SaaS product, investigate which job a customer is actually hiring each workflow to perform.
3. Basecamp: Think a project through together
Customer context: Not every project-management user creates tasks primarily to close them. In Bob Moesta's account of Basecamp customer behavior, people could create tasks, invite colleagues, and discuss work as a way to think through a project, even when task completion was not the immediate goal.
JTBD statement, paraphrased: "When a project is still unclear, I want to work through the plan with others, so I can decide what needs doing before we commit to execution."
Motivation and desired outcome: The job is reducing uncertainty with collaborators, not simply increasing completed-task counts. It has a social dimension: colleagues need a shared understanding of what they will do.
Product implication: If research finds this pattern in your product, examine whether conversation, draft planning, and shared decisions are supported. Do not assume low task completion proves that a planning workflow has failed. Investigate what customers meant to accomplish when they opened the tool.
4. Simple banking: Manage money between paychecks
Customer context: Strategyn's discussion of Simple frames the customer job as managing finances, rather than merely checking a balance or making a transaction. The banking product brought together visibility into purchases, budgeting, savings goals, and spending information.
JTBD statement, paraphrased: "When I need to make spending decisions across bills and savings goals, I want to understand my financial position, so I can use my money without losing track of what comes next."
Motivation and desired outcome: Customers need a dependable basis for day-to-day decisions. Confidence matters alongside the functional work of tracking and allocating money.
Product implication: Look across the financial workflow, not only the account screen. Strategyn also uses "manage daily cash flow" as a functional banking job. An alert, budget view, or transfer might help, but each should be judged by whether it improves the relevant outcome. This statement is an interpretation of the published case, not a verified Simple customer quotation.
5. Microsoft Software Assurance: Manage licenses across their life cycle
Customer context: Software buyers need more than a way to purchase licenses. A published Strategyn case study on Microsoft Software Assurance reports interviews with procurement and IT professionals that surfaced needs related to purchasing, managing, deploying, maintaining, and training around software.
JTBD statement, paraphrased: "When our organization acquires software for employees, I want to manage licensing and deployment through its working life, so I can keep people equipped and the organization prepared."
Motivation and desired outcome: Procurement needs a workable purchase; IT needs software that can be deployed and managed after the contract is signed. This is a B2B job with multiple participants, so a single interviewee's feature request may cover only one step.
Product implication: Map the full job and identify which participant owns each step before narrowing the solution to a purchase interface. The Strategyn case describes Microsoft expanding the Software Assurance offering around needs beyond buying licenses. Its reported business results are case-study claims, not evidence that every JTBD program will yield similar results.
6. Uber: Get a ride when existing options fall short
Customer context: Transportation choices depend on availability and reliability in the moment. The Christensen Institute's analysis of Uber describes an app that connected riders and drivers, used mobile GPS, and changed access to rides. The source analyzes Uber's market and operating model; it does not publish a rider interview producing the sentence below.
JTBD statement, paraphrased: "When I need to reach a destination and finding a suitable ride is uncertain, I want an accessible way to arrange transport, so I can make the trip with less uncertainty."
Motivation and desired outcome: Getting to a destination is functional. Knowing a ride is available addresses uncertainty. Specific expectations, such as speed, price, or safety, must be investigated by situation rather than assumed to matter equally to every rider.
Product implication: Study the full journey from deciding to travel through requesting, finding, taking, and paying for a ride. Uber is an analytical example here, not a claim that the Institute documented this exact customer statement or attributed a particular interface decision to it.
7. DoorDash: Get food or essentials without making a trip
Customer context: An e-commerce transaction may be a means to solve a more immediate problem. Harvard Business School Online's JTBD examples describe DoorDash serving the need for food and everyday items without leaving home, including delivery beyond restaurant orders.
JTBD statement, paraphrased: "When I need a meal or an everyday item but cannot conveniently go out, I want to get it delivered, so I can meet the need without interrupting what I am doing."
Motivation and desired outcome: The job involves access and convenience, not merely browsing a catalog. The product implication changes when the customer needs an item now rather than casually exploring options.
Product implication: Investigate availability, item confidence, ordering, and fulfillment as parts of the same experience. A clearer product page is only one potential response. The Harvard Business School Online article offers a published interpretation of DoorDash's job; the statement above is not sourced from a DoorDash customer interview.
8. The condo move: Downsize without losing family history
Customer context: A housing developer struggled to sell new condos to people leaving longstanding homes. The Harvard Business Review case discussion describes how interviews exposed the emotional difficulty of parting with belongings, especially the family dining-room table. The developer introduced help with moving, storage, and sorting.
JTBD statement, paraphrased: "When I am ready to leave a long-term family home, I want to move into a smaller place without feeling forced to discard what matters, so I can begin the next stage of life with confidence."
Motivation and desired outcome: The functional job is moving; the emotional job is preserving continuity while making a difficult transition. A buyer may also need to explain the decision to family, but the source does not establish that as a universal social job.
Product implication: Remove friction around the transition, not just around viewing or purchasing the condo. For software teams, the parallel is onboarding or migration: customers may be reluctant to switch because of what they stand to leave behind, not because the new interface lacks a feature.
Good vs bad JTBD statements: Remove the solution from the job
A good statement identifies a real circumstance and leaves room for competing answers. These are illustrative rewrites, not additional researched cases.
Weak statement: "When I need a dashboard, I want a dashboard so I can see results."
What goes wrong: The proposed feature appears twice.
Stronger statement: "When a release changes activation, I want to understand its effect so I can decide what to do next."
What to investigate: Which decision is blocked, and what evidence would resolve it?
Weak statement: "I want faster support."
What goes wrong: No trigger, user, or definition of success.
Stronger statement: "When a customer is blocked during setup, I want to respond in time for them to continue, so they can finish onboarding."
What to investigate: What does timely mean in this situation?
Weak statement: "As a user, I want a new filter."
What goes wrong: This is a feature request, not a customer job.
Stronger statement: "When I review accounts with unusual activity, I want to narrow down the relevant cases so I can investigate them."
What to investigate: What makes a case relevant, and how is it currently found?
Weak statement: "When I use our product, I want productivity."
What goes wrong: Both context and outcome are too broad.
Stronger statement: "When the team disagrees about the next project step, I want to work through the options together so we can choose a plan."
What to investigate: What triggers the disagreement and signals a decision?
Practical check: If the named product disappeared tomorrow, could someone still try to accomplish the job? If not, the statement may describe an interface rather than customer progress.
How to discover customer jobs: Reconstruct behavior, not preferences
Start with a specific recent event. Recruit people who adopted, abandoned, switched, or developed a workaround for a solution relevant to your product. In behavioral interviews, ask what happened immediately before they acted, what they tried first, what alternatives they considered, and what made the decision difficult. Intercom's interview with Bob Moesta emphasizes reconstructing the purchase or switching timeline rather than asking for imagined future preferences.
Look for three kinds of evidence:
Switching stories: What pushed someone away from the old approach? What pulled them toward a new one? Which anxieties or habits slowed the change?
Workarounds: Which spreadsheets, manual messages, or repeated checks compensate for missing progress? Ask what each workaround helps the person accomplish before proposing to replace it.
Behavioral signals: What do support threads, usage patterns, and funnel steps show? These can locate friction but rarely explain motivation by themselves.
Keep observation separate from interpretation. "A participant checked the account balance before every purchase" describes behavior; "they lack confidence in their finances" is a hypothesis to test. Figr's customer insights guidance similarly recommends preserving original wording and labeling inferences. For interview planning, teams can compare AI question generators, but prompts should follow the person's real decision, not lead them toward a preferred feature. See also Figr's primary customer research guide for ways to connect customer discovery with later product discovery.
Turning JTBD into product opportunities: Test the chain of reasoning
A statement becomes useful when it changes what a team investigates next. Consider the published Intercom Support job as a starting point. The following sequence is an illustrative product exercise, not a claim about what Intercom built or measured:
Step: Insight
Example for a support workflow: Teams want to help users at the point they become stuck.
Evidence needed: Recent conversations and the steps preceding each request.
Step: Opportunity
Example for a support workflow: Make it easier to understand a user's issue and respond appropriately.
Evidence needed: Which information is missing, and how often?
Step: Solutions
Example for a support workflow: Compare a better conversation view, contextual user history, or improved routing.
Evidence needed: Which direction helps without adding unnecessary complexity?
Step: Assumptions
Example for a support workflow: Context will help agents respond; the displayed information is accurate and permitted.
Evidence needed: Agent feedback, data checks, and privacy review.
Step: Prototype
Example for a support workflow: Show alternative flows with empty, delayed, and unavailable-data states.
Evidence needed: Whether agents can use each state to choose an action.
Step: Validation
Example for a support workflow: Observe agents working through realistic scenarios.
Evidence needed: Whether they understand the issue and make an appropriate decision.
This progression prevents a customer job from becoming a disguised feature order. It also keeps diagnosis separate from explanation. If signup conversion falls, a funnel may show where users leave; interviews and usability work can help investigate why. Strategyn's Promethean case illustrates another route from job statements to opportunities: organize identified needs, then ask customers to rate importance and satisfaction before prioritizing. Such ratings inform a decision; they do not replace interpretation.
Common JTBD mistakes: Fix the research before polishing the sentence
Mistaking a feature for a job. Replace "need a dashboard" with the decision the person cannot make. Ask what they would do if the dashboard did not exist.
Using a broad aspiration as a job. "Be productive" is hard to investigate. Name the event and the progress sought within it.
Treating one account as one customer. In B2B software, buyers, administrators, and daily users may have different jobs. Interview each relevant participant.
Inventing a neat quote from a case study. A source may describe a job without publishing a customer's exact words. Label reconstructed statements as paraphrases and link the underlying case.
Assuming a funnel explains motivation. Pair the behavioral signal with interviews or observation before assigning a cause. For additional diagnosis methods, see these conversion optimization techniques.
Scoring outcomes too early. First establish what customers mean, then decide whether importance and satisfaction ratings would help compare opportunities.
How Figr helps: Carry evidence into testable designs
Figr is an AI product design agent for exploring, collaborating on, and iterating toward shippable design in the context of an existing product. It does not discover or verify customer jobs for you. Research must establish the situation, motivation, and outcome; the design workflow then tests how a proposed solution might support them.
Teams can bring research notes, PRDs, analytics, screens, Figma files, and design-system references into Figr's Context Pod. Its Visual Context Graph connects visual, behavioral, design-system, product-knowledge, and implementation context so an opportunity can be considered alongside how the product already works. Figr describes this context-led approach in its guide to design context across product pods.
From an evidence-backed job, teams can use UX Reasoning to examine flow logic and tradeoffs, map edge cases, explore multiple design directions, and build multi-state prototypes before preparing editable, Figma-ready output. The point is to compare possible solutions against the job and the existing product, not generate a polished screen that conceals an untested assumption. Figr's product manager workflow describes connecting product context with design exploration. If the opportunity reaches implementation, use developer handoff best practices to review states and decisions with engineering and QA. Existing tokens and components still require ownership; Figr's design system versus style guide comparison can help clarify which decisions the team intends to reuse. For competing internal requests, product leader tradeoff guidance can help keep the discussion tied to evidence.
Conclusion: Make the job useful in the next decision
The best JTBD statement does not sound clever. It identifies a circumstance, the customer's desired progress, and an outcome the team can investigate. The eight published cases show why a purchase, a support request, and a switch can point to different jobs than the feature someone mentions first.
Take one recent request from your backlog. Trace what happened before it, interview the people involved, write a statement without naming the proposed feature, and compare at least two ways to support the job. Record what remains uncertain.
Once the job is supported by evidence, carry it into flows, states, and prototypes that people can evaluate. To explore that design work in the context of your existing product, try Figr.
FAQ: Practical answers about JTBD statements
What are some real JTBD examples?
The milkshake commute, Intercom's Support job, Basecamp's collaborative planning use, Simple's financial management, Microsoft's software license management, Uber's ride access, DoorDash's delivery need, and the condo move are documented contexts above. Each formatted statement is a paraphrase, not a direct customer quote.
What is a simple jobs to be done template?
Use "When [situation], I want to [make progress], so I can [achieve an outcome]." Keep solution names out, then verify each clause with customer research. Use a broader functional-job statement when mapping a complete activity.
How is JTBD different from a user story?
A job explains why someone seeks progress and under what circumstances. A user story describes an intended product behavior from a user's perspective. Research the job before deciding which user stories belong in a solution.
How do I research customer jobs?
Interview people about recent actions and switching decisions. Trace alternatives, concerns, and workarounds; examine support records and usage data; and distinguish observed behavior from your interpretation. Do not rely on a feature-request survey alone.
How can Product Managers use JTBD examples?
PMs can use them to reframe backlog requests, compare opportunities, define assumptions, and commission prototypes for validation. The cases are models for asking better questions, not ready-made findings about their own customers.
Verified sources
Christensen Institute: Jobs to Be Done theory and Uber analysis.
Harvard Business School: milkshake research, Harvard Business School Online: JTBD examples, and Harvard Business Review: customers' jobs and the condo move.
Intercom: customer research and four jobs, including the Basecamp discussion.
Strategyn: Simple and other JTBD examples and its published Microsoft Software Assurance case.
Additional reading retained from the original article
The Wiley-published excerpt on jobs to be done discusses functional-job language. Harvard Business School's practical JTBD examples provide further context. The Promethean research case illustrates prioritization based on customer ratings.