What is jobs-to-be-done (JTBD)?

The reframe

Products get hired and fired. A customer has a situation, feels a struggle, and reaches for something that will make progress. That thing might be your software, a competitor, a manual workaround, or nothing.

The practical consequence is that your competitive set is defined by the job, not the category. Intercom built its early product thinking explicitly in these terms, which is how a messaging product ended up competing with email, helpdesks and internal tooling simultaneously — all things people had hired for the same job.

Why it beats feature requests

Ask what customers want and you get solutions shaped by what they've already seen. Ask what they were trying to do, what they tried first, and what made them give up, and you get the job.

The second question is the valuable one. Customers are reliable reporters of their own struggles and unreliable designers of their own solutions.

Forces that decide the switch

JTBD frames every adoption decision as four competing pressures: the push of the current situation, the pull of the new solution, the anxiety about switching, and the habit of what exists today. Most product teams over-invest in pull — more features, better demos — and ignore anxiety and habit, which are usually what actually block the switch.

Lego's turnaround has a version of this in it. The company nearly died building products designed around what it thought children should want, and recovered partly by re-examining what building sets were actually hired for: absorbed, sustained, tangible progress that a video game was also competing for.

Where it gets misused

JTBD is a discovery lens, not a planning system. Teams that convert it into a rigid taxonomy of hundreds of micro-jobs end up with a documentation exercise. The value is in the interview and the reframe — in noticing that you're not competing with who you thought.