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: 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 is now expiring.
The assumption nobody wrote down
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 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 do not get out-competed. They evaporate.
Half-life, not lifespan
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 does not. 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 is 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 is missing. Same customer, same trigger, completely different job, and the move outran almost every roadmap built for the old one.
This is a discovery problem, not a strategy one
The instinct is to treat this as strategy. 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 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 in the background. The signals 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 describe the task in past tense.
I am not telling you to throw out JTBD. I am 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 cannot find the instrument that would show the job halving, that is the thing to build before anything else.