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 didn't. That durability is the whole point of Jobs to Be Done: name the timeless job and you can out-build whoever is solving it badly. I built a lot of product on that assumption. It was correct. It's now expiring.
The load-bearing part of JTBD was so obviously true that nobody named it. Jobs outlive products. You could spend six weeks on switch interviews, build a job map, and trust it to still describe reality two years later. The map depreciated slowly, and that slow depreciation is what made the heavy upfront research worth it.
AI changed the depreciation schedule. When a general model can do a whole task end to end, it doesn't 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 don't get out-competed. They evaporate.
So I stopped thinking about a job as having a lifespan and started thinking about it as having a half-life. A lifespan says this job exists, then one day it doesn't. A half-life says every period a predictable fraction of the job decays into something AI now handles, and a smaller, higher job survives above it. The job rarely dies all at once. The low end gets automated, the customer's expectation resets upward, and the residual job moves to a level that's harder to serve and worth more. Drafting is the cleanest example. The blank-page job collapsed for most people in under two years and moved up to help me judge which draft is right and what it's missing. Same customer, same trigger, completely different job, and the move outran almost every roadmap built for the old one.
Here's the part people get wrong. The instinct is to treat this as strategy. Strategy is too slow. If you only revisit the job at planning offsites, you're sampling a fast-decaying signal a few times a year, which is how you ship a great solution to a job that quietly halved in relevance two months ago. You measure a half-life the way you measure radioactive decay: constantly, with instruments running in the background. The signals aren't 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.
I'm not telling you to throw out JTBD. I'm telling you to add a clock to it. Pick your most important customer job this week, write down its current altitude and what the level above it looks like, then go find the decay signal. If you can't find the instrument that would show the job halving, that's the thing to build before anything else.