A team spends months building a feature customers never actually asked for, because nobody understood what those customers were really trying to accomplish in the first place. It's one of the most common ways good teams waste good effort.
Jobs To Be Done reframes a product around the progress a customer is trying to make in a specific moment, not their age, job title, or which segment they fall into on a spreadsheet. Everything you need to master Jobs To Be Done: clear concepts, practical examples, an actionable template, and the framework to turn "what should we build?" into a clear, validated plan.
What Are Jobs To Be Done?
The core idea is simple once it clicks. People don't buy products; they hire them to make progress in a specific situation. That progress is the job. A customer isn't buying your app; they're hiring it to get something done that was bothering them a moment before.
The classic example is a milkshake chain trying to sell more milkshakes in the morning. Instead of asking what features people wanted, researchers watched who bought them and when. It turned out a huge share of morning milkshake buyers were commuters, hiring the milkshake for a long, boring drive: something filling, one-handed, and slow to finish. That's a completely different job than an afternoon milkshake bought for a kid as a treat; same product, two entirely different jobs.
That is why JTBD beats demographics for understanding customers. A demographic profile, "35 to 44, urban, mid-income," shifts constantly and tells you almost nothing about what someone's actually trying to accomplish. The job itself stays remarkably stable over time, even as the people hiring a product for it change completely.
Feature-thinking asks "what should we build next?" Job-thinking asks "what is someone actually trying to accomplish, and does this help?" That shift in the question changes almost everything downstream, from the roadmap to the way you talk about the product.
The Jobs To Be Done Framework
The Jobs To Be Done framework breaks a job down into three dimensions. This same structure is often just called the JTBD framework for short, and both terms refer to the same three-part breakdown.
- Functional. The practical task someone is trying to complete. Get from point A to point B, track expenses, hire a contractor.
- Emotional. How they want to feel while doing it, or avoid feeling. Confident instead of anxious, in control instead of overwhelmed.
- Social. How they want others to perceive them while getting it done. Competent, thoughtful, ahead of the curve.
A clean job statement follows a simple structure: when [situation], I want to [motivation], so I can [outcome]. For example: "When I'm switching between three different tools to track my freelance income, I want one place that shows me everything at a glance, so I can stop worrying I've missed a payment."
Uncovering real jobs happens through interviews focused on one specific moment: the last time someone actually struggled with this. Not a hypothetical, not "would you use X," but a real memory. "Tell me about the last time you tried to do this, and it didn't go well." That question tends to surface the actual job far more reliably than asking people what they want in the abstract.
This connects to outcome-driven innovation, a way of thinking that treats customers as hiring products to reach specific outcomes, not to use a particular set of features. Once you know the outcome someone's actually after, the features either serve it or they don't, and that distinction becomes much easier to see.
Jobs To Be Done Examples
A few concrete Jobs To Be Done examples across different product types make this less abstract:
- B2B, project management tool. Job statement: "When my team is spread across five different channels for updates, I want one place to see what's actually blocking a project, so I can stop chasing people for status." Functional layer: centralized visibility. Emotional layer: relief from constantly feeling behind. Social layer: looking organized and in control during leadership check-ins.
- Consumer meal kit service. Job statement: "When I get home exhausted after work, I want dinner sorted without having to think about it, so I can actually relax instead of standing in a grocery store." Functional layer: a ready plan and ingredients. Emotional layer: relief from decision fatigue. Social layer: feeling like a capable adult who has their life together, even on a hard week.
- B2B, accounting software. Job statement: "When tax season is approaching, I want my records already organized so that I can avoid a stressful scramble at the deadline." Functional layer: clean, categorized records. Emotional layer: avoiding dread. Social layer: appearing reliable to a business partner or accountant.
Naming the outcome this specifically reveals exactly what to build. A team chasing the meal kit job above would prioritize speed and simplicity over recipe variety, because the actual job is relief from decision fatigue, not culinary adventure. Notice, too, how the same product category can serve very different jobs depending on who's hiring it. The same accounting software might get hired by a freelancer avoiding tax panic, and by a small business owner trying to look competent to investors. Different jobs, same product, very different priorities for each one.
How to Write Your Own Job Statements
Here's a simple Jobs To Be Done template to fill in right now: "When [situation], I want to [motivation], so I can [outcome]." Write one for your best-understood customer segment and see how specific you can actually get.
Turning raw interview notes into clean customer jobs takes some filtering. Read back through what someone actually said, and look for the moment they described struggling, not the moment they described a feature they wished existed. Someone saying "I wish there was a button that did X" is describing a solution. Someone saying "I spent twenty minutes trying to figure out if this invoice had already been paid" is describing a job. The second one is what you actually want to capture.
Once you have several job statements, prioritize by two things: how important the job is to the person, and how satisfied they currently are with existing ways of getting it done. A job that's both important and poorly served today is the strongest opportunity. A job that's important but already well served by a competitor is a much harder fight. Keep the Jobs To Be Done template open during this step so every job you're comparing follows the same structure.
One warning worth taking seriously. Don't write solutions disguised as jobs. "The customer's job is to use a mobile app" isn't a job; it's a feature wearing a job statement's clothing. The real job sits one level underneath that, in whatever the mobile app is actually letting them accomplish.
Using JTBD to Decide What to Build
Once you document real jobs, they inform the roadmap directly. Instead of debating features in the abstract, a team can ask whether a proposed feature actually moves someone closer to completing their job, or whether it's just interesting to build.
Testing this is fairly direct. Take a proposed feature and ask: does this reduce friction in the actual moment someone struggles, based on what they told you in interviews. If the honest answer is "not really, but it's a nice addition," that's a signal to deprioritize it in favor of something that speaks to the job more directly.
This connects straight to positioning too. You sell the job done, not a list of features. "Track your freelance income in one place" sells a completed job. A bullet list of dashboard widgets sells a feature set that means nothing until someone connects it to their own struggle. Knowing the job is the starting point. Positioning it clearly and validating it with real customers comes next.
Frequently Asked Questions
What are Jobs To Be Done? Jobs To Be Done is a framework built on the idea that people hire products to make progress in a specific situation, rather than buying based on demographics or feature lists. The job is the progress someone is actually trying to make.
What is the Jobs To Be Done framework? The framework breaks a customer's job into three dimensions: functional (the practical task itself), emotional (how they want to feel while doing it), and social (how they want to be perceived by others in that moment).
What is an example of a job to be done? "When I'm commuting for over an hour, I want something filling and easy to eat one-handed, so I can make the drive less boring." A morning milkshake, hired for a completely different job than an afternoon treat.
How do you write a job statement? Use the format: when [situation], I want [motivation], so I can [outcome]. Ground it in a real moment someone described struggling with, not a hypothetical or a feature they say they'd like.
Find the Real Job, With solvee
Understanding the real job behind a product takes real discovery work, and most founders either skip it or stop halfway through, ending up with a feature list instead of a clear job statement. That's the gap solvee is built to close. It's a personalized AI accelerator that helps founders uncover the actual job their product is hired for, instead of guessing based on untested assumptions.
The fit works because it turns messy customer notes into clear job statements and persona cards you can actually build from, holding your full business context so you're not starting over every time you revisit the question. The real problem most founders run into is building features nobody actually hired them for, and guided discovery prevents that before a team wastes months on the wrong thing.
Not sure what job your product is actually being hired for? Get free access to solvee. No credit card, no equity, start today.