Jobs to Be Done Framework: A Startup Founder's Guide

What the Jobs to Be Done Framework Actually Says

The core idea, developed by Clayton Christensen and refined by researchers like Tony Ulwick, is that people don't buy products — they hire them to get a job done. The "job" is the underlying progress they're trying to make in a specific situation.

A person doesn't buy a project management tool because they want a Kanban board. They hire it because their team keeps missing deadlines and they're tired of chasing updates in Slack. The board is a feature. The job is "keep my team aligned without constant interruption."

That distinction matters because features can be copied. Jobs don't change as fast. If you understand the job deeply enough, you can build something that does it better than anything else on the market — even if your feature list is shorter.

The Three Layers of Every Job

Every job has three components worth separating:

• The functional job: The practical task the user is trying to complete. "File my quarterly taxes without missing a deduction."

• The emotional job: How the user wants to feel during or after completing it. "Feel confident I'm not going to get audited."

• The social job: How the user wants to be perceived by others. "Look like someone who has their finances under control."

Most products only address the functional layer. The ones that stick tend to solve all three, even if they never say so explicitly.

Why Founders Get This Wrong Early On

The most common mistake is conflating the job with the solution. You'll hear founders say things like "the job is to send better emails" or "the job is to track expenses." Those are solutions, not jobs.

A better framing: "The job is to stay on top of client communication without things falling through the cracks." Now you're describing a situation, a struggle, and a desired outcome. The solution could be email, a CRM, a shared inbox, or something that doesn't exist yet.

The second mistake is interviewing users about what they want rather than what they've done. People are unreliable narrators of their own future behavior. Ask someone what they'd pay for and they'll describe a fantasy product. Ask them about the last time they struggled with a specific task and they'll give you something real.

How to Run a JTBD Interview

You don't need a formal research operation. You need five to eight conversations with people who have recently made a decision in your problem space — ideally within the last three months.

The questions that get useful answers:

• "Walk me through the last time you tried to [do the thing your product helps with]."

• "What triggered you to start looking for a solution?"

• "What did you try first? What didn't work about it?"

• "What would have to be true for you to switch away from whatever you're using now?"

You're listening for the moment of struggle, the trigger that made them move, and the criteria they used to evaluate options. Those three things tell you more about the job than any survey.

Using JTBD to Scope What You Build

This is where the framework earns its place in a founder's toolkit. Once you've identified the job clearly, you have a filter for every feature decision.

The question isn't "is this a good feature?" It's "does this help the user make the progress they hired us for?" Features that don't serve the job are scope that slows you down and confuses the user.

When NFN Labs works with founders to scope an MVP, the first conversation is almost always about the job, not the feature list. What is the user trying to accomplish? What's the minimum product that lets them do that job better than their current workaround? That framing keeps scope tight and ships faster. If you want to see how that process works in practice, the How we scope an MVP in one week piece covers the mechanics.

The Competing Solutions Problem

One thing JTBD surfaces that most frameworks miss: your real competition isn't always another app. It's whatever the user is doing right now to get the job done.

If someone is managing their freelance invoices in a Google Sheet, your competition is Google Sheets — not another invoicing tool. That changes how you position the product, what friction points you need to eliminate on day one, and what "better" actually means to that user.

Understanding the competing solution also tells you how much behavior change you're asking for. A product that does the same job as a spreadsheet but requires users to learn a new system has a higher switching cost than one that feels like a natural upgrade. That's a product design problem, not a marketing problem.

JTBD and Product-Market Fit

Product-market fit is often described as a feeling — a moment when things start pulling. The Jobs to Be Done framework gives you a more operational definition: you have fit when your product does the job better than every alternative the user has tried, and the user knows it.

That means fit isn't about retention metrics alone. It's about whether the job you're solving is real, whether your product solves it in a way users can actually feel, and whether the users who care about that job can find you.

A lot of early-stage products fail the second test. The job is real, the product technically works, but the experience doesn't make the progress obvious. Users complete the task but don't feel the relief or confidence they were hiring for. That's a signal worth paying attention to before you scale.

When to Revisit the Job

The job doesn't change often, but it can shift as the market does. A job that was being done manually might get partially automated by a new tool, which changes what users expect from the next solution. A job that was niche might go mainstream, bringing new users with different emotional and social layers attached to the same functional task.

Revisiting your JTBD interviews every six to twelve months — especially after a major product change or a new cohort of users — keeps you from building against a job that's already evolved.

Applying JTBD Before You Build Anything

The best time to use the Jobs to Be Done framework is before you write a single line of code. If you're still at the idea stage, JTBD interviews are the fastest way to validate whether the job you think you're solving is the one users actually care about.

This matters more than most founders expect. The instinct is to validate by building something small and seeing if people use it. The problem is that building takes time and runway, and if you've misidentified the job, you've spent both on the wrong thing.

Spending two weeks doing eight interviews costs almost nothing. It tells you whether the job is real, how users currently solve it, and what "better" means to them. That's the input you need before you scope anything.

If you're working with a development partner to build your first product, this is also the conversation to have before the engagement starts. A team that asks about the job before the features is one worth working with. For context on what that process looks like, Custom Software Development for Startups: What to Scope, What to Skip, and What to Reuse covers how to make those early scoping decisions without overbuilding.

The Limits of the Framework

JTBD is a thinking tool, not a delivery mechanism. It tells you what to build and why. It doesn't tell you how to build it, how to price it, or how to find the users who have the job.

It also doesn't resolve every product decision. Two features can both serve the same job. You still have to make judgment calls about which one to ship first, how much complexity is acceptable, and what to defer. The framework narrows the field. It doesn't eliminate tradeoffs.

And it's only as good as the interviews behind it. If you've only talked to five people from the same company or the same network, you might have a job that's real for that group but doesn't generalize. Diversity in your interview set matters more than volume.

What Comes After the Job

Once you've identified the job and built something that does it well, the framework shifts from a discovery tool to a communication tool. Your positioning, your onboarding, and your messaging should all reflect the job you're solving — not the features you've built.

Users don't share products because of feature lists. They share them because something helped them make progress they couldn't make before. If you can name that progress clearly, you've got the core of your story.

For founders thinking about how to take that story and turn it into a product someone can actually build, the product development outsourcing framework is worth reading before you start talking to any development partner.

FAQs

What is the Jobs to Be Done framework?
The Jobs to Be Done framework is a way of understanding why people buy or use products. Instead of focusing on user demographics or features, it focuses on the underlying progress a person is trying to make in a specific situation. The idea is that people "hire" products to get a job done, and understanding that job tells you more about what to build than any feature request or persona.

How is JTBD different from user personas?
Personas describe who the user is. JTBD describes what the user is trying to accomplish. Two people with completely different demographics can share the same job, and one person can have multiple jobs depending on the context. JTBD is more useful for product decisions because it focuses on behavior and motivation rather than attributes.

How do you identify the job your product should solve?
The most reliable method is interviewing people who have recently made a decision in your problem space. You're looking for the moment of struggle, the trigger that made them act, and the criteria they used to evaluate options. Five to eight conversations with the right people will surface patterns that surveys never will.

Can JTBD be used after a product is already built?
Yes. If your product isn't retaining users the way you expected, JTBD interviews can help you figure out whether you've misidentified the job, solved it poorly, or solved it well but failed to make the progress obvious to the user. It's as useful for diagnosing problems as it is for scoping new products.

What's the difference between the functional job and the emotional job?
The functional job is the practical task the user is completing. The emotional job is how they want to feel while doing it or after it's done. A product that nails the functional job but creates anxiety, confusion, or embarrassment in the process will still struggle with retention. Both layers matter.

How often should you revisit your JTBD research?
Every six to twelve months is a reasonable cadence, and always after a significant product change or a new wave of users. The job itself rarely changes, but the competing solutions do, and new users bring different emotional and social layers to the same functional task.

Is the Jobs to Be Done framework only useful for early-stage startups?
No, but it's most valuable before you've committed significant resources to a direction. Early-stage founders benefit most because the framework helps them avoid building the wrong thing before the runway dries up. That said, later-stage teams use it to identify adjacent jobs their existing users have — which is one of the more reliable ways to find new product opportunities.