Jobs to be done: write the job before you write the feature

By Meet Patel · 2026-10-03 · 6 min read

A feature request arrives as a noun: an export button, a calendar view, a Slack integration. The noun is the customer's guess at a solution to a situation, and the situation almost never travels with it. By the time the request reaches a backlog, the team is debating the noun and nobody can say when, where or why anyone wanted it.

The jobs-to-be-done framework exists to restore the right order. Its central idea, set out by Clayton Christensen, Taddy Hall, Karen Dillon and David Duncan in “Know Your Customers' Jobs to Be Done” (Harvard Business Review, September 2016), is that people hire a product to make progress in a particular circumstance. A job statement describes that circumstance and that progress. What follows is a template for writing one before any feature is discussed, a worked example, and three tests to check it.

What the milkshake study found

The most retold case comes from Christensen's work with a fast-food chain. According to a Harvard Business School Working Knowledge article by Carmen Nobel (2011), 40 percent of the milkshakes were bought first thing in the morning by commuters ordering to go. Christensen describes those customers as hiring the milkshake to keep an extra hand busy, to make the commute more interesting and to stave off hunger until noon.

The product consequence is the useful part. The company responded with a thicker morning milkshake with fruit chunks, so that it lasts through the commute and keeps the straw interesting. The same article describes a second group, parents buying a treat for their children, who needed a thinner version. One product category carried two jobs, and an improvement for one job would damage the other. My reading is that a survey asking every customer to rate thickness would have returned an average that served neither group.

Why the job comes before the feature

A feature is one of many possible answers to a job. If the team writes the feature first, the design space has already collapsed to a single option, and the only remaining question is whether to build it. A team that writes the job first can generate several answers and compare them, which is where most of the value is.

Intercom reached a similar view when it moved from personas and user stories to job stories. Paul Adams, writing about how the company arrived at the format in June 2016, says personas “focus too much on the differences between people” and that user stories are “formatted to describe functionality to be built, rather than motivations people have.” Those are Intercom's criticisms, and you can weigh them differently. The practical point holds either way: a spec that opens with functionality has skipped the motivation.

A template for the job statement

Intercom's job story format has three slots: “When ____, I want to ____, so I can ____.” The first slot is the situation, the second the motivation, the third the outcome. I would add two lines underneath, because they make the statement testable.

1. When (the situation): a trigger you could observe or put on a calendar.
2. I want to (the motivation): the progress the person is trying to make, with no feature words in it.
3. So I can (the outcome): what they are able to do next once the progress is made.
4. Current workaround: what they do today, including spreadsheets, colleagues and competitors.
5. What makes the workaround painful: time, error rate, delay or embarrassment, ideally with a number.

A worked example (hypothetical)

Take a 20-person SaaS company selling invoicing software to small agencies. Customers keep asking for “export to Excel.” The request is concrete and cheap to build, so it would normally go straight onto a roadmap. Suppose the team reads the tickets closely first and finds the same story repeated.

The job statement could read: “When I close the month on the last working day, I want revenue by client in the layout my bookkeeper already uses, so I can send it before the afternoon cut-off.” The workaround is copying the invoice table into a spreadsheet and reformatting it. Say, for illustration, that this takes 40 minutes per agency per month.

Now several solutions are visible. An Excel export removes the copying but not the reformatting. A pre-built bookkeeper report removes both. A direct sync to the accounting package removes the job entirely. A scheduled email on the last working day removes the need to remember. Each costs a different amount to build, and each can be judged against one measure taken from the job: how long month-end takes the customer. Without the statement, the team would have shipped the export and judged it by whether anybody clicked it.

Three tests for a job statement

I would run these before a statement is allowed into a planning discussion.

• The solution-free test. Strike every word that names a feature, screen or technology. If the sentence collapses, it was a feature request in disguise. “I want an export button” fails. “I want revenue by client in my bookkeeper's layout” passes.
• The situation test. The “when” clause must describe a moment that could be observed, scheduled or detected. “When I want to be more productive” fails because it describes every moment. “When I close the month” passes.
• The workaround test. Someone must already be doing something about the job, even if it is clumsy. A job with no workaround is often a job nobody has enough urgency to pay for.

A fourth check applies when the first three pass. If two groups describe the same product in situations that demand opposite things, as the commuters and the parents did with thickness, write two statements and decide which group the product serves first. I have made the wider argument about why building for everyone kills growth elsewhere, and the job statement is the mechanism that makes the choice concrete.

Where job statements go wrong

Three failure patterns recur. The first is a persona written in job clothing: “When I am a busy marketing manager” describes an identity and contains no situation. The second is the wrong altitude: “so I can grow my business” fits every feature ever built, so it cannot choose between any two of them. A usable statement sits at the level where a customer could say yes or no about the last time it happened.

The third is a statement written at a desk. If the team invented the situation, the statement is a feature request with extra words. I prefer to ask customers to walk through the most recent time the situation occurred, in order, and to write the statement from what they describe.

Putting it into the planning routine

The routine I would use has three rules.

1. No feature enters a planning discussion without a job statement attached. If the requester cannot supply one, the first piece of work is a short set of customer conversations about the last time the situation occurred.
2. Every statement is paired with at least three candidate solutions, including one that is cheaper than the obvious one and one that removes the job altogether.
3. The success measure is written from the job before the build starts. For the invoicing example it is minutes spent on month-end, in place of clicks on a button.

This also changes what a roadmap contains. A list of features is a list of answers, and answers expire when the situation changes. A list of jobs stays valid longer, which is part of why I argued that a fixed feature roadmap is the wrong artifact. Jobs also carry feeling as well as function. The commuters wanted the commute to be more interesting, and no spec field for “functionality” would have captured that. I wrote about this side of product design in emotion-first product design.

What to take from it

A feature is a hypothesis about a job. Until the job is written down, the hypothesis cannot be tested, compared with alternatives or retired when it fails. Write the situation, the progress and the workaround first, and the feature debate gets shorter because the team is arguing about evidence instead of nouns.

Written by Meet Patel — startup operator and growth strategist in Dubai.

Read on themeetpatel.com