Jobs to Be Done

The shift ends. The questions don’t.

Mira has finished her shift when her phone rings. The incoming coordinator needs to know which customer callback is still outstanding. The answer is somewhere between a chat thread, a notebook, and a review Mira was interrupted halfway through.

The team behind Relay Notes thinks this is a note-organization problem. Its first idea is folders. Mira’s interrupted evening suggests a question worth asking first: what would a successful handover let her do?

This is a hypothetical case. Relay Notes, Mira, the episode, and the research material below are invented to demonstrate the method.

Jobs to Be Done investigates the progress someone wants in a particular circumstance. The Christensen-associated view treats products and services as things people “hire” to help make that progress. Here, we’ll use it to work from a messy handover toward a product experiment.

Map the handover before designing folders

Before sketching a feature, Relay maps the work Mira is trying to complete. She needs to capture updates, identify what remains unresolved, brief the incoming colleague, and confirm who will take responsibility.

This map gives the team somewhere to investigate. Folders might help recover an update. They might do little to establish whether the next person has seen it or agreed to act.

The steps also remain meaningful if Mira uses paper, chat, or another application. That is a useful check: a job should leave room for different solutions. A workflow beginning with opening Relay’s dashboard would already contain the answer the team hopes to sell.

This is a provisional map. In a real project, customer accounts and observation would need to challenge its steps and order. Drawing a sensible sequence does not establish that everyone works that way.

Look at the episode, then question the explanation

Relay’s next move is to reconstruct the difficult handover. It asks what happened just before the review, where the updates arrived, what interrupted Mira, and how she decided she could leave.

The questions stay close to an episode. “Would folders help?” would invite a verdict on the team’s idea before the problem is understood.

The illustrative account contains two visible behaviors: Mira checks chat and a notebook, and her review is interrupted. The team writes down a possible interpretation—folders might help—but keeps it separate from those observations.

The later clarification call adds another question. Was the information missing, difficult to find, or available without a clear owner? Those problems could lead to different designs.

Relay asks how the incoming coordinator understood the handover and what still needed clarification. In this case, the team develops a working interpretation: Mira needs a dependable way to know what remains open and pass it on. A tidier collection of notes may be only part of that.

In real research, keep reported behavior distinct from direct observation. Someone describing a notebook check is an account of behavior; watching it happen provides different evidence. Preserve the source, context, and uncertainty so colleagues can inspect the interpretation.

Build a job story you can investigate

Now the team has a more useful sentence to test:

When my shift is ending and updates are scattered, I want to know what still needs attention, so I can hand over without leaving gaps.

Each part earns its place. The circumstance explains when the difficulty matters. “Busy coordinators” would describe an audience but leave the moment vague. The progress is understanding outstanding work. The outcome is a handover that lets the next person continue reliably.

A job story is a practical writing aid, not a quotation from Christensen or proof that the job has been discovered. Relay would need to compare it with other relevant episodes, including accounts that contradict it. A coordinator who works alone may face a different problem despite holding the same title.

The case also has three connected dimensions:

• Functional: the next shift can identify open work and understand who will handle it.
• Emotional: Mira can leave without mentally replaying every update.
• Social: colleagues can rely on her handover without repeated clarification calls.

These are interpretations to check, not boxes to fill from imagination. Mira’s account could support one dimension more strongly than another. The team should ask what matters instead of supplying feelings the evidence never established.

This changes what Relay might measure. Counting organized notes says little about whether an incoming colleague knows what needs attention. A useful test should examine the handover itself.

Ask what would make changing tools difficult

Even if the job story fits, a new feature still competes with the ways Mira already manages. Her notebook is familiar, chat reaches colleagues, and a phone call can resolve ambiguity quickly. Keeping the current approach is an alternative too.

Bob Moesta’s switching lens helps investigate four pressures around a change. Applied to this hypothetical case:

• Push: repeated clarification after the shift makes the current arrangement frustrating.
• Pull: a trustworthy handover could let both coordinators see what needs attention.
• Anxiety: moving updates could lose context or create another place to check.
• Habit: the notebook is familiar and available during interruptions.

Those are questions to investigate, not established reasons that real coordinators adopt software. Ask about actual attempts to change and what happened, rather than assuming a better interface will overcome every concern.

For Relay, this suggests testing a handover view using familiar material before asking anyone to migrate everything. If the trial depends on perfect data entry during a hectic shift, it may ignore the circumstance that created the problem.

The switching lens sits alongside the circumstance-and-progress view. Other JTBD traditions differ: Anthony Ulwick’s Outcome-Driven Innovation emphasizes measurable desired outcomes and a more structured research process. This walkthrough uses an editorial workflow map and job story; it does not reproduce that full method.

Choose a small test that could change your mind

Relay now has a different design question: can the next coordinator understand outstanding work without reconstructing the whole shift?

One possible response is a shared handover view that brings open items together and makes responsibility explicit. Folders remain an option, but the team has a reason to investigate whether they solve enough of the job.

Relay could start with a prototype and a realistic set of fictional shift updates. Ask an outgoing coordinator to prepare a handover, then ask an incoming colleague to identify pending work and who should handle it. Observe where clarification is still needed. A supported real-work trial could follow when appropriate.

Agree the check before the session. Could the incoming colleague find the relevant open items? Was ownership understandable? What information was absent? A polished screen and a favorable opinion would not answer those questions.

If the necessary updates never reach the view, investigate capture and access. If the information is visible but responsibility remains unclear, the problem may involve a team agreement or workflow outside the interface. Both findings could change the proposed solution.

A successful prototype task would still leave questions about sustained use, effort during interruptions, and willingness to adopt. The next commitment should match what was learned. This case ends with an experiment to run, not an invented success story.

Try the same reasoning on your own problem

Use the following checklist to apply the walkthrough. These are FrameworkWorld’s working recommendations, rather than a universal JTBD procedure.

1. Choose a recent episode. Start with a purchase, workaround, cancellation, or frustrating moment someone can reconstruct.
2. Map the work. Describe what the person is trying to accomplish without building your product into the steps.
3. Separate evidence and interpretation. Keep observations, reported accounts, and assumptions traceable. Preserve contradictions.
4. Write and challenge a job story. Name the circumstance, progress, and recognizable outcome. “Save time” alone is too broad.
5. Examine alternatives and switching. Include familiar workarounds and doing nothing. Ask what makes change attractive or difficult.
6. Choose a test and a challenge condition. Explain what result would make you revise the proposed response before investing further.

A handful of stories can suggest a useful direction. They do not establish how widespread a need is, what customers will pay, or whether you have found a profitable market. Choose further research to suit the uncertainty and consequence of the decision; a fixed interview count is not proof of understanding.

Once you have scoped possible responses, RICE can help compare their expected impact and effort. AIDA can help explain a credible offer. Porter’s Five Forces examines industry pressures and substitutes beyond this customer episode.

Relay’s useful change is a better question, supported by a visible chain of reasoning. The team began with folders. It now knows what to investigate before choosing them.

Sources and further reading

• Clayton M. Christensen, Taddy Hall, Karen Dillon, and David S. Duncan, “Know Your Customers’ ‘Jobs to Be Done,’” Harvard Business Review, September 2016: hbr.org/2016/09/know-your-customers-jobs-to-be-done.
• The same authors developed the argument in the book Competing Against Luck (HarperBusiness, 2016).
• Clayton Christensen Institute, Jobs to Be Done Theory, accessed October 21, 2026. Public explanation of circumstances, progress, and functional, social, and emotional dimensions.
• Thomas Arnett, Bob Moesta, and Michael B. Horn, The Teacher’s Quest for Progress, September 2018. The Forces of Progress section explains push, pull, anxiety, and habit. The handover example and interview sequence here are FrameworkWorld’s editorial applications.
• Strategyn, Outcome-Driven Innovation, accessed October 21, 2026. Primary explanation of the outcome-focused approach; this article does not reproduce its complete research process.