Defining the Customer's Core Functional Job

Define the customer's core functional job: one solution-free statement, at the right altitude, for a named job executor, that anchors JTBD work.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

The core functional job is the task a customer is trying to get done, described without reference to any product. Every other artifact in the Jobs-to-be-Done (JTBD) Framework hangs off it: the job map breaks it into steps, the outcome statements measure those steps, and the survey and segments score them. If the core functional job is wrong, everything downstream measures the wrong thing with great precision.

Defining the core functional job means making three decisions. The first is who the job executor is: the person who actually carries out the job, who may not be the buyer or the person who approves the purchase. The second is what the job is, written in Strategyn's format of verb, object of the verb and contextual clarifier, as in "listen to music while commuting to work" (Strategyn JTBD template). The third is the altitude: how broad the job is, which decides how much of the customer's world your research will cover.

The output is short: a single sentence, the job executor, a note on what is in and out of scope, and the evidence behind it. It is also where most JTBD projects go wrong. Teams describe their own product's workflow and call it the job, or they pick a job so broad that no survey could cover it. This skill is about avoiding both.

The Christensen school frames the job as the progress a person is trying to make in a particular circumstance, and it stresses that jobs also have social and emotional sides (Christensen Institute). Keep those in view, but write them down separately. The core functional job is the practical task. The emotional and social jobs are the feelings and perceptions that come with it, and they need their own statements.

How It Works

A job statement works when it stays true as solutions change. Strategyn requires needs to be "stable over time and devoid of solutions" (needs framework), and the same test applies to the job itself. "Track expenses in a spreadsheet" fails it, because the spreadsheet is a solution. "Keep spending within a monthly budget" passes, because someone was doing that before spreadsheets and will be doing it after.

The verb carries the action. Pick one that describes what the executor is trying to achieve, such as keep, prepare, ensure, determine or resolve, rather than an interaction with a tool, such as click, log in or upload. The object is what the action is applied to. The contextual clarifier narrows the situation enough to separate this job from neighboring ones, for example "for a household" or "while traveling for work". Keep adjectives about quality out of the statement: "quickly", "easily" and "accurately" belong to the outcome statements you write later, where they become measurable.

Altitude is the judgment call. Bettencourt and Ulwick's job mapping article describes people hiring products to get a job done, from surgeons to janitors (The Customer-Centered Innovation Map), and in each case the job is the executor's goal rather than one move inside it. A useful test is to ask "why?" of a candidate job. If the answer is a larger task the executor also cares about, you may be too low: "enter a receipt" becomes "keep spending within a budget". Ask "how?" of the candidate. If the answer is a list of distinct steps, you are at a level that can be mapped. If the answer is a list of separate jobs, you are too high.

Scope follows from the executor and the market you want to serve. A company that sells to accountants and a company that sells to households may study jobs with similar words and very different executors. Name the executor explicitly and write the job for that person, and record the buyer and any other stakeholders separately so their concerns do not leak into the statement.

The definition is a hypothesis until evidence supports it. Draft it from what customers have said and done, test it in interviews and revise it before the job map is built. A job statement that customers cannot recognize as a description of what they do is not finished.

Step-by-Step Guide

Step 1: Gather raw customer evidence

Collect what you already have: interview notes, support tickets, sales call notes, reviews and any usage data that shows what customers do before and after using your product. Prefer records of behavior over opinions, since what customers did is more reliable than what they say they want. Pull the verbs customers use to describe their goals. Note the situations they mention, because those become contextual clarifiers. If you have little evidence, run a few switch interviews first using Conducting JTBD Customer Interviews.

Step 2: Name the job executor

Decide whose job you are defining. The executor is the person who carries out the job, which in business products is often not the buyer. Write down the executor, the buyer and any approver as separate roles. Pick one executor for this definition, and plan a separate job statement if another role has its own job worth studying.

Step 3: Draft candidate job statements

Write several candidates in the form verb, object, contextual clarifier. Aim for variety: some broader, some narrower, some with different verbs. Keep each to one sentence. Do not judge them yet, since the point of this step is to have options to test.

Step 4: Remove solutions from every candidate

Read each candidate and strike any product category, technology, feature or brand. Replace a tool-based verb with the goal it serves. Remove quality words such as "fast" or "easy", which belong in outcome statements. If a candidate collapses to nothing once the solution is gone, it described your product rather than the job, so drop it.

Step 5: Set the altitude with why and how

For each surviving candidate, ask why the executor does it and how they do it. Move up a level when the answer to "why" is a task the executor clearly owns and would want help with. Move down when the answer to "how" is a list of unrelated jobs. Stop at the level where "how" produces a sequence of steps that could form a job map, which is the input to Creating Job Maps.

Step 6: Consolidate and test with customers

Merge the surviving candidates into one statement. Read it back to a few job executors and ask them to describe the last time they did it, from start to finish. If they describe a different task or skip large parts of the job, revise the wording or the altitude. A customer should recognize the statement without explanation.

Step 7: Document the definition

Record the final statement, the executor, what is in and out of scope, the emotional and social jobs you heard, and the evidence behind each decision. Share it with product, design, engineering and marketing before mapping begins. Changing the job after outcomes are written means rewriting them, so agreement here saves rework later.

Best Practices

• Write the executor into the definition document next to the job statement. Many disagreements that look like arguments about the job are disagreements about whose job it is.
• Keep a short list of rejected candidates with the reason each was rejected. It shows stakeholders that broader and narrower options were considered, and it stops the same candidate from coming back every review.
• Use the customer's verbs where they are solution-free. A statement in the customer's language is easier to validate in interviews and easier to use in survey wording.
• Record emotional and social jobs separately from the core functional job (Christensen Institute). They matter for positioning and design, but mixing them into the functional statement makes it unmappable.
• Revisit the statement after the first round of interviews and before writing outcome statements. Once outcomes are drafted, a change to the job costs far more.

Common Mistakes

• Describing your product's workflow: "Manage projects in our tool" is a solution, and a job map built on it will list your screens. Remove the product and ask what the customer is trying to achieve by using it.
• Choosing an altitude by convenience: Teams pick the level that matches their current product scope, which hides adjacent steps where competitors or new entrants may help. Use the why and how test instead, and decide scope explicitly afterwards.
• Blending executors: A statement that tries to cover the buyer, the user and the approver describes nobody's job well. Write one job per executor and study them separately.
• Putting quality words in the job: "Quickly reconcile accounts" mixes the job with a need. Keep the job neutral and capture speed, accuracy and effort as outcome statements, where they can be measured (Strategyn needs framework).

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Jobs-to-be-Done (JTBD) Framework

Related Skills

• Creating Job Maps
• Conducting JTBD Customer Interviews
• Writing Desired Outcome Statements

Sources

• Strategyn: Jobs to Be Done template
• Strategyn: Customer Needs Through a Jobs-to-be-Done Lens
• Christensen Institute: Jobs to Be Done
• Bettencourt and Ulwick, The Customer-Centered Innovation Map, HBR

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.