Using Jobs to Be Done to Build What Matters

BACK TO OVERVIEW PAGE

In a world where AI removes almost every technical barrier to creation, that question has become the only one that matters.

David Duncan, Partner at Disruptive Edge, and Tyler Anderson, CEO at Disruptive Edge, argue that Jobs To Be Done is the framework that forces that discipline — not a legacy methodology, but the essential filter for the AI era.

Building the right thing requires moving beyond fuzzy customer profiles to create sharp, nuanced pictures of customer needs — and knowing exactly where AI helps and where it gets in the way.

The current landscape of AI-enabled creation reveals a proliferation of apps that range from the useful to the absurd, such as 'MeowTalk,' which translates a cat's meow into human language, or an app that vibe-codes a narration of your life in the voice of David Attenborough.

While these examples are humorous, they illustrate a serious reality for corporate innovators. The tools available today allow you to bypass technical hurdles that once acted as a natural filter for bad ideas. David frames the central challenge for the modern innovator:

Most new products miss the mark. This failure rarely stems from an inability to engineer the solution, but rather from building without a really sharp, clear understanding of the customer need they're aimed at solving.

To make fruitful decisions around what to build, what to say, and what to invest in—leaders require precise information. However, in most large companies, the understanding of the customer problem is often incomplete, or it's missing entirely, or it's de-prioritized.

Without this sharp, nuanced picture, organizations fall back on metrics that may drive the wrong behavior.

An example from Tomer Cohen, Chief Product Officer at LinkedIn, illustrates this point. While LinkedIn is an incredibly successful company, they realized that optimizing solely for metrics like 'time on site' could lead engineers to build features that keep users trapped on the platform without understanding why the user is there.

Optimizing for the metric is not the same as solving the problem. The fundamental reason Jobs To Be Done exists is to provide that missing layer of resolution.

Jobs To Be Done (LTBD) is a simple model for explaining why customers make the choices they do. Every customer has a default: do what they have always done. Changing that behavior takes energy, and what generates that energy is the Job.

A job is a problem a customer wants to solve or a goal they want to achieve — the progress they are trying to make in a particular moment in their lives. When a job appears, it gives people the motivation to go looking for something that can help. In the JTBD language, customers do not buy products, but hire them.

The circumstance matters just as much as the job itself. On a Monday morning, someone hires a cup of coffee because their energy is low and they have a full day ahead. On a Saturday, that same person hires the same cup because a friend is in town and a coffee shop is the easiest place to catch up. Same product, same customer, but entirely different jobs — and therefore entirely different competitors.

On Monday the coffee is up against an energy drink or a brisk walk. On Saturday it is up against a bar, a park, or a phone call. The job tells you what the customer is trying to accomplish, whereas the circumstance tells you what game you are actually playing.

Innovators need a specific language because customers are unreliable narrators of their own needs, since customers almost never tell us directly the specific things we need to be able to help them.

If you listen to a customer stream of consciousness—for example, a user describing their experience with Slack—you get a messy mix of complaints about notifications, desires to feel supported, and context about remote work. JTBD provides a 'language' to parse this input and sort it into categories that drive innovation.

This language divides into three distinct types of jobs that you must listen for:

By categorizing feedback into these buckets, you move from a transcript of complaints to a structured map of human needs.

Adopting this language changes how you view your entire business. A thought experiment involving a coffee shop illustrates this shift. If you view the business through a Product Lens, you define yourself as being in the 'coffee business.'

However, if you view the business through a Jobs Lens, the picture shifts entirely. You ask: Why did the customer 'hire' that cup of coffee?

As David puts it from the coffee shop owner's perspective: 'I'm not in the business of selling coffee; I'm in the business of helping people solve these very diverse sets of jobs to be done.'

Once you reframe the business this way, your competitive set explodes. If the job is 'Informal Chat,' you are competing against a walk in the park, a bar, or a phone call. If the job is 'Get work done,' you are competing against a coworking space, a hotel lobby, or working from home.

You might actually be in 20 different markets and competitive games at once. The goal is not to solve every job, but to decide where to 'double down and invest' based on which job offers the most attractive opportunity for differentiation.

A common criticism of JTBD is that the jobs can feel generic. 'I want to look my best' is a job, but it is too broad to be actionable. David argues that the 'fundamental unit of innovation opportunity' is found at the intersection of the Job and the Circumstance.

A job itself doesn't define an opportunity, but it's really the intersection of jobs and circumstances that does. To illustrate this, the coffee shop jobs map against different circumstances:

Every one of the intersections on this map has a different competitive set. The competition looks completely different depending on the situation you are in. When you combine the functional, social, and emotional jobs with the specific circumstance, you finally achieve the 'sharp, nuanced picture' required to build products that resonate.

Tyler addresses how AI changes—and doesn't change—this process. While AI is a powerful accelerator, it introduces new risks if used as a replacement for human understanding:

Can a company just ask an AI, 'Give me all my jobs to be done'?

There is a warning against this approach. AI can generate a high-quality first draft or a ‘gut check,' but if you only stick with what's been generated by AI, you risk missing something really important. AI models are trained on existing data, which means they are excellent at summarizing what is known but risk missing the net-new insights that come from a live, human conversation.

Tyler team uses AI for synthetic research, creating synthetic customer personas based on real data and run simulations.

They feed customer data and public data into the AI. The AI identifies potential pain points, user journeys, and prioritized jobs.

Tyler is explicit that this is just the absolute tip of the iceberg. You can use synthetic customers to test hypotheses (e.g., 'If we launched this, would it solve the job?'), but you must then validate these synthetic findings with real humans.

Perhaps the most counterintuitive insight is that the speed of AI development has forced his team to move slower in the definition phase.

Building is so fast and so democratized now that teams can keep adding features and capabilities without stopping to ask whether any of them actually solve the customer's problem. Eventually, you end up with a lot of cool things the customer doesn't love.

Because the cost of building has plummeted, the cost of building the wrong thing has become the primary risk. Tyler admits, 'We've actually had to slow ourselves down and focus more on the jobs to be done, because it's so much faster to build now.'

AI can support every step of the research workflow. It can generate high-quality first drafts for developing hypotheses, creating interview strategies, and synthesizing insights. Just think about a general market research process where you're thinking about who you want to talk to, developing hypotheses around them, developing your kind of interview strategy.. with all of that, you can get a good, quick, high quality first draft using AI.

In-depth, one-on-one interviews remain essential for eliciting the types of information needed to uncover root jobs. Once that information is gathered, AI becomes 'amazing' at synthesizing it and pulling out insights rapidly, far faster than the traditional method of manually highlighting and looking for patterns.

The winners in the next era of innovation will not be those who code the fastest, but those who use AI to rigorously map the intersection of jobs and circumstances, and who have the discipline to ask 'should we build it?' before they let the AI write a single line of code.

AI can simulate the customer, synthesize the data, and build the solution. Nevertheless, it cannot replace the strategic choice of which job is worth solving; that remains the distinct responsibility of the innovator.

BACK TO OVERVIEW PAGE