Jobs To Be Done

People do not buy products, they hire them to make progress in a situation. The frame that stops you building features nobody asked for.

What is it?

Jobs To Be Done says that people 'hire' a product to make progress in a specific situation. The job is the progress they are trying to make — not the product category.

The format: when [situation], I want to [motivation], so I can [expected outcome].

Why does a founder care?

Because it moves you off features and onto the circumstance, which is where buying decisions actually get made.

It also reveals your real competition. If the job is 'get Friday back', then a spreadsheet, an assistant, working late and simply accepting the mess are all competing for the same hire.

Example

Product framing: 'We're building scheduling software for logistics.' This tells you to compare features with other scheduling software.

JTBD framing: 'When it's Friday afternoon and I still have next week's rota to build, I want to produce a workable rota quickly, so I can leave on time and not spend Sunday worrying about Monday.'

What this reveals:

  • The job is emotional as well as functional — 'not spend Sunday worrying' is the real hire
  • The competing options are the spreadsheet, working late, delegating badly, and doing nothing
  • Speed matters more than sophistication. A tool that produces a perfect rota in two hours loses to one that produces a good-enough rota in ten minutes
  • The moment of need is Friday afternoon, which tells you when to send a reminder

    • None of that comes out of a feature comparison.

    The common mistake

    First-time founders often write jobs that are really feature requests: 'when I need to schedule, I want a scheduling tool'. That is circular and produces no insight.

    A real job statement contains a situation with a time and a trigger, a motivation that could be satisfied several ways, and an outcome that is often emotional.

    The second mistake: assuming there is one job. Different segments hire your product for different jobs, and that is usually the clearest signal about which segment to serve.

    How it works

    Step 1: Find the situation, not the persona

    'Friday afternoon with a rota still to build' is more useful than 'ops manager, 35–50'. Situations trigger purchases.

    Step 2: Write the job without naming your product

    If your product appears in the sentence, you have written a feature request.

    Step 3: Include the emotional outcome

    'Not spend Sunday worrying' is often the real reason. Functional benefits get compared on price; emotional ones do not.

    Step 4: List everything else that could do the job

    This is your real competitive set, and it usually includes doing nothing.

    Step 5: Check which job you are best at

    If several jobs emerge, pick the one where the alternatives are worst. That is your wedge.

    When to use this

    After interviews, when writing positioning, and whenever the roadmap feels like a list of unrelated features.

    When not to use it

    Do not turn this into a formal methodology exercise with workshops and templates. One good job statement written from real interviews beats a deck of them invented in a room.

    Do this now

    Apply this to your own startup in My Full Journey (free account).