Comparing by fit
Two ways of thinking, side by side. There is no winner here — read across each row and choose the one that fits your situation.
Product
People don't buy products, they hire them for a job — find out what the job is.
By 6days
Innovation
Understand the person, frame the real problem, build something rough, and learn from their reaction.
By 6days
When to use — Jobs To Be Done
Use it when demographic segmentation has stopped generating insight, when you cannot explain why customers churn or convert, when entering an adjacent market, or when a roadmap has become a queue of the loudest requests with no organising logic.
When to use — Design Thinking
Use it on ill-defined problems where the need is genuinely unclear, where the people affected are not you, and where the cost of building the wrong thing is high. It is strongest early, when the framing is still open and cheap to change.
When not to use — Jobs To Be Done
Avoid it for incremental optimisation of a well-understood product — you know the job, and reopening it is procrastination. It is weak for infrastructure and compliance work with no discretionary hiring decision. Done badly it collapses into vague poetry about customer aspirations, and 'the job' becomes whatever the loudest person already wanted, now with better rhetoric.
When not to use — Design Thinking
Avoid it when the problem is well-specified and the answer is known — it is expensive ceremony for work that needs execution. It struggles with problems whose constraints are technical or regulatory rather than human. And it is the most ritualised framework in common use: workshops, sticky notes and a five-stage poster routinely produce the appearance of the method with none of the substance, because nobody left the building to observe anyone.
Teams describe customers demographically and build for the description. But 'marketing managers aged 30-45' do not share a need; they share a census category. So the roadmap fills with features requested by whoever asked loudest, competitors are defined as companies that look like you, and the actual reason people started or stopped using the product remains a mystery — because nobody asked about the situation that triggered the switch.
Organisations solve the problem they were handed. A brief arrives already containing its solution — 'build a dashboard' — and a team spends six months building it well, only to find nobody uses it, because the actual difficulty was never a lack of a dashboard. The expensive error was committed before any work began, in accepting a framing nobody tested against a real person.
Jobs To Be Done reframes demand around the progress a customer is trying to make in a particular circumstance. People 'hire' a product to get a job done, and 'fire' it when something does the job better. The job is stable over time while the solutions churn — the job of getting a household's laundry clean has outlived every washing technology that ever served it. The reframe has two sharp consequences: your real competitor is anything else hired for the same job, including a spreadsheet or doing nothing at all, and the useful research question is not 'what do you want?' but 'walk me through the last time you switched.'
Design thinking is a loop for problems where the requirement is not yet known: understand the people affected, define the problem from what you learned rather than from the brief, generate many candidate solutions before judging any, build a rough artefact, and put it in front of someone. The sequencing carries the value. Defining after observing prevents you from solving the wrong problem, and prototyping before committing makes being wrong cheap. It is not linear — findings at the test stage routinely send you back to redefine — and treating it as a five-step process to march through is the most common way to get nothing from it.
Find customers who recently started or stopped using something, and reconstruct the episode in detail: what happened, what they tried, what finally pushed them. Anchor on a specific event. General preference questions produce a plausible story rather than a true one.
Identify the circumstance that made the old way intolerable on that particular day. People tolerate bad solutions for years; something specific changed. That trigger, not the feature comparison, is what actually created the sale.
State it as circumstance plus motivation plus desired outcome — 'when a client emails a change at 6pm, help me update the quote without reopening the whole file, so I can leave on time.' No product nouns. If your solution is in the sentence, you have written a feature request instead.
List everything currently hired for that job — rival products, a spreadsheet, an assistant, an established habit, doing nothing. The incumbent is almost never the company you benchmark against, and the status quo is the most common winner.
Not specified
An ordered process with 5 phases.
Observe the people in their situation.
Frame the real problem from what you saw.
Generate many options before judging any.
Worked example — Jobs To Be Done
A team building invoicing software for freelancers assumes the job is 'create professional invoices' and invests in templates and branding. Switch interviews tell a different story: nobody switched for a nicer invoice. They switched after a client paid late and an awkward chasing conversation followed. The real job is 'get paid without having to ask twice.' The competitors are not other invoicing tools but the freelancer's own dread of chasing. The roadmap turns to automated reminders, payment-status visibility, and gentle escalation wording — none of which was on the template-driven plan, and all of which address the trigger that actually moves people.
Worked example — Design Thinking
A hospital is asked to reduce missed outpatient appointments and briefs a team to build an SMS reminder system. Observation first: patients who miss appointments overwhelmingly received the letter and remembered the date. The barriers are transport, unpredictable shift work, and a booking line answered only during working hours — the hours they are at work. The problem is redefined from 'patients forget' to 'patients cannot attend or rearrange within the constraints of their lives.' Prototypes: a text-back rescheduling line, evening slots, a standby list. The reminder system, which was the entire original brief, addresses a cause that barely exists.
The framing is most associated with Clayton Christensen, who popularised it from the mid-2000s alongside collaborators including Bob Moesta and Rick Pedi, and it connects to earlier outcome-driven work by Anthony Ulwick. Several schools now interpret it differently — some treating jobs as functional specifications, others as situational narratives — and the disagreement between them is genuine rather than cosmetic.
The approach draws on design practice and cognitive research going back to the 1960s, with roots in work on the nature of design problems by figures such as Herbert Simon and Horst Rittel. Its current business form was shaped substantially by the firm IDEO and by the Stanford d.school from the 1990s onward. The five-stage articulation is one popular formulation among several, not a canonical definition.
Not specified
For each planned feature, ask which job it serves and whether it beats the current hire for that job. Features that serve no articulated job are the ones to cut, and the exercise usually finds several.
Watch and talk to the people who live with the problem, where they actually encounter it. Watch what they do rather than trusting what they say; the workarounds they have stopped noticing are where the real problem is visible.
Write a problem statement grounded in what you observed, not in the brief you were handed. If your definition is identical to the original brief, you have almost certainly skipped the observing.
Produce many candidate directions with evaluation explicitly suspended. The first plausible idea is a local optimum and will kill the search if allowed to. Quantity first, judgement second, deliberately separated.
Build the crudest thing that could elicit a real reaction — paper, a clickable sketch, a manual process behind a form. Fidelity is not a virtue here; it is a liability, because polish makes people admire the artefact and makes you reluctant to discard it.
Put it in front of someone from the affected group and watch them struggle without helping them. Most tests send you back to define rather than forward to build, and that is the loop working rather than failing.
Build the crudest thing that can be wrong.
Put it in front of real people and learn.