How do Jobs to Be Done and user research shape a growth-driven design strategy?

Jobs to Be Done is the theory that people buy products to make progress in a specific circumstance, not because of who they are demographically. Clayton Christensen and his co-authors stated it plainly in Harvard Business Review: when we buy a product, we essentially hire it to help us do a job, and if it does the job well, we hire it again [1]. The job is the progress a person is trying to make, the circumstance is the context that shapes it, and the alternatives are everything else that person could hire to make the same progress [1].

The canonical illustration is Christensen's milkshake study. A fast-food chain found that nearly half its milkshakes sold before mid-morning to solo commuters, who hired the shake over a bagel or a doughnut because it was tidy, it staved off hunger until lunch, and it gave a bored driver something to do on a long commute [2]. Demographic segmentation would never have surfaced that pattern, because the real competitor set was defined by the situation, a long boring drive plus looming late-morning hunger, and not by the buyer's age or income [2]. Two customers with identical profiles hired the milkshake for entirely different jobs at different times of day, which is the point: the job, not the demographic, predicts the purchase [1][2].

Strategyn, the consultancy Tony Ulwick founded to operationalize the theory as outcome-driven innovation, defines a job as the task, goal, or objective a customer is trying to accomplish in a given situation, and ties customer-defined outcome metrics to that job so progress becomes measurable [3]. Christensen's article adds the dimension websites most often miss: a job is never purely functional, it carries social and emotional weight, how the buyer wants to be perceived and how they want to feel [1]. For a strategy stage, that is the useful part. If you know the functional job, the social job, and the emotional job a visitor is trying to get done, you know what every page has to accomplish before you write a single headline [1][3].

Jobs to Be Done is a named component of the growth-driven design strategy stage, listed alongside UX research, buyer personas, and customer journey mapping in the methodology's strategy framework [4]. GDD front-loads this research before any building, because the strategy stage produces the assumptions the rest of the process will test [5]. The work is time-boxed, usually 10 to 14 days, so the goal is enough job clarity to launch a testable site rather than a finished catalog of every customer motivation [6].

The practical move is to treat every key page as something a visitor hires. A pricing page is hired to answer whether this will fit the budget without booking a sales call. A case study page is hired to de-risk a recommendation the visitor has to defend to a boss or a committee. A homepage is hired to confirm, in a few seconds, that this company serves someone in exactly their situation. Framing pages this way changes what the strategy prioritizes. Journey mapping stops being a diagram of your funnel and becomes a map of the visitor's progress from first struggling moment to confident decision, built on their needs and pain points rather than your internal org chart [4]. The fundamental assumptions the strategy documents, beliefs about what visitors want and how they look for it, are really hypotheses about the job, and the launchpad site exists to confirm or kill them with live behavior [5][6].

Jobs to Be Done interviews reconstruct the story of a real decision, in the buyer's own words, to surface the job behind it. The research splits into two halves in the GDD strategy stage: quantitative work that audits the current site and its analytics to find where visitors stall or exit, and qualitative interviews that explain what those visitors were trying to accomplish and why [5]. The interviews are where the job actually gets discovered rather than guessed.

Recruit people who recently made the decision you care about, ideally within the last few months while memory is fresh, and interview across the accounts that matter: recent customers, people who chose a competitor, and people who chose to do nothing. Ask them to walk you back to the first moment they realized they had a problem, then forward through everything that happened up to the purchase. Productive questions mirror the milkshake study: what was going on when you first started looking, what did you try before this, what almost made you give up, and what finally pushed you to decide [2]. You are listening for the struggling moment, the desired outcome, the alternatives they weighed, and the anxieties that slowed them down.

Avoid asking what people want or which features they would like, because those answers predict behavior poorly. Ask what they did and what happened, which is verifiable. Ten to fifteen focused interviews usually surface the dominant jobs and the language buyers use to describe them, and that language matters: the exact phrases customers repeat become the headlines and proof points a page needs later. The output is a short set of documented jobs and fundamental assumptions about motivation and information-seeking that then drive global and page-level strategy [5].

A job becomes a problem statement when you write it from the visitor's side as the specific progress they are stuck trying to make. A useful format names the situation, the desired outcome, and the obstacle: when a marketing lead has to replace an aging website but cannot risk months of downtime, they want a way to ship improvements incrementally so they can show results before the budget is questioned. That sentence is testable in a way that 'we need a modern website' is not.

Problem statements are the bridge between raw interview notes and page decisions. Each documented job produces one or more of them, and each statement carries the emotional and social stakes the interviews surfaced, not just the functional task [1]. In growth-driven design these become the fundamental assumptions the strategy records, explanations of user behavior and motivation that then shape global and page strategy [5]. Writing them explicitly forces two useful disciplines. First, it separates the job, which is stable, from your current solution, which is one of many the visitor could hire. Second, it exposes where you are assuming rather than knowing, which tells you what the launchpad site should measure first.

Keep the set small. A strategy that tries to answer twenty problem statements at launch dilutes every page, so the point of the time-boxed strategy stage is to isolate the few jobs that drive most of the value, state them sharply, and let live data confirm or correct them during continuous improvement [6]. A problem statement that survives contact with real traffic becomes a permanent fixture of the site's messaging.

Jobs turn a buyer journey from a funnel diagram into a sequence of progress a visitor makes, one hire at a time. Growth-driven design maps the customer journey from the ideal customer's needs and pain points rather than from your internal sales stages, so each step reflects what the visitor is trying to get done at that moment [4]. A single decision usually spans several smaller jobs in sequence: understand whether this is even the right category, judge whether this vendor is credible, confirm the fit for their specific situation, and justify the decision to whoever else has to approve it.

Mapping the journey against jobs tells you how many pages a path actually needs and what each one owes the visitor. A visitor in a problem-aware moment hires content that names their situation and frames the options. A solution-aware visitor hires content that compares approaches and proves outcomes. A decision-ready visitor hires content that removes final risk: pricing clarity, guarantees, and proof from peers in the same circumstance. Skipping a step, pushing a cold visitor straight to a demo request, breaks the journey because the earlier job was never done.

The strategy documents these paths as global and page-level strategy, the structure the launchpad will build and then test [5]. Because growth-driven design launches quickly and improves continuously, the journey map is a starting hypothesis, not a finished artifact: live behavior shows where visitors actually stall between jobs, and each improvement sprint targets the transition that is losing the most people [6].

Page messaging is where the job gets answered, so every core page should lead with the progress its visitor came to make. The discipline is simple to state and hard to hold: open each page by naming the job and the outcome, not the company or the feature. A visitor who hired the page to judge fit for a regulated industry should see that reassurance in the first screen, before any product tour.

Jobs decide three things on a page. They set the headline, which should restate the visitor's desired outcome in the visitor's own words, drawn from the phrases interviews surfaced. They set the proof, because most jobs include reducing the buyer's own risk, so each claim needs evidence a skeptic would accept: numbers, named results, and testimony from someone in the same situation. And they set the next step, which should match where the visitor sits in the journey rather than pushing everyone toward the same request.

This is also where social and emotional jobs earn their place [1]. A page that answers only the functional job, does the product do the task, often loses to one that also answers whether the choice will make the buyer look smart to their boss and whether they will feel confident they chose right. In growth-driven design, messaging is treated as a hypothesis: the launchpad ships the version that best fits the documented jobs, and continuous improvement tests headlines, proof, and calls to action against live behavior to see which framing of the job actually converts [5][6].

Jobs to Be Done is a lens for motivation, not a complete strategy, and treating it as one causes predictable problems. Naming what the framework does not cover keeps a growth-driven design strategy using it for the right work.

It does not replace segmentation. Two buyers can share a job and still need different tone, budget framing, and authority handling, which is why growth-driven design keeps personas beside jobs rather than discarding them [4]. Drop the persona and you can write a page that answers the job for nobody in particular.

It does not settle design and usability. Knowing the job tells you what a page must accomplish, not whether the layout, load time, or navigation let a visitor accomplish it, and those still need UX research and testing [5]. A page can name the right job and still fail on a broken form.

It does not produce certainty. Interview-derived jobs are hypotheses, strongest when a small number of interviews converge on the same story and weakest when you extrapolate from one vivid quote. Growth-driven design treats them accordingly, shipping a launchpad quickly and letting live behavior confirm, refine, or overturn the job model during continuous improvement rather than betting a full build on untested research [6].