View a product through the Jobs-to-be-Done lens and write a hypothesis in testable form.
JTBD and testable hypotheses explained
JTBD and testable hypotheses explained
Jobs-to-be-Done (JTBD) is a lens for understanding why people use products. The core idea: people do not buy products for their features — they 'hire' a product to help them make progress on a job they are trying to do in a specific context. A classic illustration: nobody wants a drill; they want a hole in the wall. Nobody buys a milkshake because of the ingredients; a commuter 'hires' a thick, slow milkshake to survive a boring drive without spilling anything. When you frame problems through JTBD you stop asking 'what feature should we add?' and start asking 'what progress is the user trying to make, and what is stopping them?'. This reframing leads to very different — and often far more impactful — solutions.
A JTBD statement captures: who the user is, what job they are trying to do, and the context in which they are trying to do it. Example: 'When I have ten browser tabs open during research, I want to save and label pages quickly so I can find them again later without losing my train of thought.' Notice: no mention of a specific app or feature — just the job and the context.
Once you have a job statement and a problem hypothesis, you need to make it testable before investing in a big build. A testable hypothesis follows the format: 'If <change>, then <metric> will <move>, because <reason>.' For example: 'If we add a one-click bookmark from the browser toolbar, then the number of saved pages per user per week will increase by 30%, because the current multi-step process is the main friction point.' A good hypothesis must be falsifiable — there must be a result that would prove it wrong — and cheaply testable, meaning you can run a quick experiment (a landing page, a prototype, a manual process) before committing to full engineering effort.
The workflow is: (1) frame the job the user is hiring the product for, (2) state a specific change you want to make, (3) predict a measurable outcome, (4) explain the mechanism, (5) test it cheaply before building.
Lesson notes
JTBD and testable hypotheses explained
Jobs-to-be-Done (JTBD) is a lens for understanding why people use products. The core idea: people do not buy products for their features — they 'hire' a product to help them make progress on a job they are trying to do in a specific context. A classic illustration: nobody wants a drill; they want a hole in the wall. Nobody buys a milkshake because of the ingredients; a commuter 'hires' a thick, slow milkshake to survive a boring drive without spilling anything. When you frame problems through JTBD you stop asking 'what feature should we add?' and start asking 'what progress is the user trying to make, and what is stopping them?'. This reframing leads to very different — and often far more impactful — solutions.
A JTBD statement captures: who the user is, what job they are trying to do, and the context in which they are trying to do it. Example: 'When I have ten browser tabs open during research, I want to save and label pages quickly so I can find them again later without losing my train of thought.' Notice: no mention of a specific app or feature — just the job and the context.
Once you have a job statement and a problem hypothesis, you need to make it testable before investing in a big build. A testable hypothesis follows the format: 'If <change>, then <metric> will <move>, because <reason>.' For example: 'If we add a one-click bookmark from the browser toolbar, then the number of saved pages per user per week will increase by 30%, because the current multi-step process is the main friction point.' A good hypothesis must be falsifiable — there must be a result that would prove it wrong — and cheaply testable, meaning you can run a quick experiment (a landing page, a prototype, a manual process) before committing to full engineering effort.
The workflow is: (1) frame the job the user is hiring the product for, (2) state a specific change you want to make, (3) predict a measurable outcome, (4) explain the mechanism, (5) test it cheaply before building.