openskills.info
Course Preview

Jobs to Be Done

Jobs to Be Done is a way to understand why someone chooses a product or service. It studies the progress a person seeks in a specific situation, including alternatives they might choose instead.

itEngineering leadership and delivery management

Don't Panic: Jobs to Be Done

Jobs to Be Done asks what progress a person wants in a particular situation. The name sounds like a task list, but the job is broader than a list of clicks. A person can hire a product, a spreadsheet, another person, or a familiar workaround to make that progress. Products from different categories can therefore compete, which is inconvenient for anyone hoping the competitor list would fit neatly on one slide.

The old habit in product research is to start with a customer type, a requested feature, or the product already on the table. Each can be useful, but each can also hide the reason a choice happened. JTBD starts with a real decision. What changed in the person's circumstances? What did the old approach fail to provide? Which alternatives were considered? A purchase is the visible ending of a story that may have started much earlier.

Switching forces give that story some structure. Push comes from a struggle with the current approach. Pull comes from the appeal of a new one. Anxiety asks whether the new one will disappoint, cost too much, or take too much effort. Habit argues for staying put. A person can want change and still keep a spreadsheet for another month. That is a clue to investigate, rather than a contradiction to discard.

The surprising part is that the buyer and the person doing the work may have different jobs. In business software, a manager may need a trustworthy status report while a responder needs to identify the next action. One platform can serve both, but one interview cannot stand in for both accounts. Social and emotional concerns also sit beside the functional work. The choice has more moving parts than a feature ranking suggests.

A job statement describes the progress without naming the proposed tool. A desired outcome says how well the work should go. "Reduce the time needed to identify the next responder" is an outcome. "Add an on-call button" is one possible response to it. Keep those in separate columns. Otherwise the research can end with a beautifully organized version of the idea the team had before it talked to anyone.

Start with the Intro for the full account of jobs, circumstances, and the two main research traditions. Use the Slides to see how the layers and switching forces fit together. The Cheatsheet gives a compact interview sequence and a job map for checking what the current product misses. Then try the Exercise: its fictional switch leaves deliberate gaps, and noticing those gaps is part of the work.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources