Jobs to Be Done Has a Half-Life Now (And AI Is Shrinking It)

The short version

Jobs to Be Done has one load-bearing assumption: the underlying job is stable even when the products that serve it change. That assumption was true for most of software history, and it is the reason JTBD worked. AI breaks it. AI does not just out-compete your product at the job, it absorbs the job, so the thing your customer hired you for can stop existing inside a single release cycle. The job now has a half-life, and the half-life is shrinking from years to weeks. JTBD is still the right lens for a moment in time, but you can no longer interview your way to a job map and reuse it for two years. The job is a depreciating asset. Measure its decay continuously or you will keep optimizing a need your customer no longer has.

Clayton Christensen's most quoted idea is that customers hire products to do a job, and the job is durable while the product is disposable. People needed to send a quick message in 1995 and they need it now. The messenger changed five times. The job did not. That durability is the whole point of Jobs to Be Done: if you can name the timeless job, you can out-build whoever is solving it badly.

I built a lot of product on that assumption. It was correct. It is now expiring.

The assumption nobody is naming

Here is the part of JTBD that was so obviously true that nobody wrote it down: jobs outlive products. You could spend six weeks on switch interviews, build a job map, and trust that map to still describe reality two years later. The map depreciated slowly. That slow depreciation is what made the heavy upfront research worth it.

AI changed the depreciation schedule.

When a general model can do an entire task end to end, it does not become a better hire for the job. It dissolves the job into a sentence. The customer stops experiencing "draft the email, then clean it up, then check the tone" as three jobs you can serve. They experience it as one prompt. The intermediate jobs your product was hired for do not get out-competed. They evaporate.

“

AI does not win the job. It absorbs the job. The need you validated last quarter can be gone before your next planning cycle.

”

Half-life, not lifespan

So I stopped thinking about a job as something with a lifespan and started thinking about it as something with a half-life.

A lifespan says: this job exists, then one day it does not. A half-life says: every period, a predictable fraction of this job decays into something AI now handles, and a smaller, higher job survives above it. That framing matches what I actually see. The job rarely dies all at once. It erodes. The low end gets automated, the customer's expectation resets upward, and the residual job moves to a level that is harder to serve and worth more.

The drafting job is the cleanest example. For ten years the job was "get me past the blank page." We hired templates, outlines, and snippet tools for it. By 2025 a model did the whole draft, and that version of the job collapsed for most people in under two years. It did not disappear. It moved up: "help me judge which draft is right and what it is missing." Same customer, same trigger, a completely different job, and the move outran almost every roadmap built to serve the old one.

Why this is a discovery problem, not a strategy problem

The instinct is to treat this as a strategy question. It is not. Strategy is too slow. If you only revisit the job at planning offsites, you are sampling a fast-decaying signal a few times a year, which is how you end up shipping a great solution to a job that quietly halved in relevance two months ago.

This is a continuous discovery problem, and it is the strongest argument I know for putting discovery on autopilot. You cannot measure a half-life with an annual study. You measure it the way you measure radioactive decay: constantly, with instruments running in the background.

The instruments are not exotic. The job is decaying when the old workflow's usage flattens while logins hold, when support tickets shift from "how do I do this" to "why would I do this manually," and when customers start describing the task in past tense. None of that shows up in a quarterly NPS. All of it shows up if you have continuous listening wired into the work.

“

You cannot interview your way to a job map and trust it for two years anymore. The map depreciates while you are still presenting it.

”

What I actually do now

Three changes, in order of how much they matter.

First, I log the job's altitude, not just its existence. Every job I track gets a note on what level it is operating at and what the next level up looks like if the floor gets automated. That way, when the decay signal fires, I already know where the surviving job went and I am not starting discovery from zero.

Second, I test against the new shape with a prototype inside a week, not a quarter. When the signal says the job moved up, the fastest honest way to confirm the new job is to put a working prototype of the higher-altitude solution in front of the same customer and watch whether they reach for it. A prototype tells me in days what an interview cycle tells me in a month, and the month is exactly what I no longer have.

Third, I assume my own moat is decaying too. If AI can absorb my customer's job, it can absorb the job my product does for them. The same half-life math applies to me. The work I describe in PM as a Team of AI Agents is partly defense: the only durable position is being the team that re-measures the job faster than the job changes.

The uncomfortable part

JTBD trained a generation to find the timeless job and build for permanence. That instinct is now a liability. There is no timeless job left in any category AI can touch. There are only jobs decaying at different rates, and your edge is knowing which of yours is decaying fastest.

I am not telling you to throw out Jobs to Be Done. I am telling you to add a clock to it. The framework still names the job. It just stopped telling you how long the answer is good for, and in 2026 that is the only number that matters.

Pick your most important customer job this week. Write down its altitude and what the level above it looks like. Then go find the decay signal. If you cannot find the instrument that would show you the job halving, that is the thing to build before you build anything else.

Sources: Clayton Christensen, Jobs to Be Done (HBR) · Tony Ulwick, Outcome-Driven Innovation · Teresa Torres, Continuous Discovery Habits