Users and the Jobs They Hire Features For
"Users" is not a person. Name a role doing a task at a moment, and the job they are hiring the feature to do — then build for the job, not the request.
The ask, the obvious response, and how it goes wrong
Every lesson starts where the work starts: someone asked for something, and the first response that comes to mind has a problem.
Who exactly will use this, in the middle of doing what, and what are they trying to get done?
The PM says: "Users want to be able to edit their order after placing it." The ticket reads "Allow order editing on the order page". It has twenty upvotes on the feedback board.
Users want to edit orders, so build order editing: change items, quantities and the address until the order ships, recalculate the total and re-authorise the payment.
"Users" hides at least three different people: a shopper who typed an old address and noticed two minutes later, a shopper who forgot an item and does not want to pay shipping twice, and a support agent fixing an order on the phone. Each needs something different, and "order editing" serves each of them badly.
- "Users" hides at least three different people: a shopper who typed an old address and noticed two minutes later, a shopper who forgot an item and does not want to pay shipping twice, and a support agent fixing an order on the phone. Each needs something different, and "order editing" serves each of them badly.
- Full editing touches payment re-authorisation, stock reservation, warehouse picking and invoices. The estimate comes back at six weeks. The address fix on its own would have been two days.
- The upvotes counted people who liked the words "edit order", not people with the same job. After launch the feature is used mostly for addresses, and the item-editing half — which carried most of the cost and the risk — is barely touched.
- Finance discovers edited orders when invoices stop matching shipments, because nobody listed finance as a user of the order.
What is really going on
- "Users" is an aggregate, and aggregates do not have tasks. A feature is used by a specific person at a specific moment trying to get something done. Design decisions — how long, which fields, what happens to the payment — only make sense against that moment.
- Jobs to be done: people "hire" a product or a feature to make progress in a situation. The shopper editing her address is not trying to edit an order; she is trying to make sure the parcel reaches her. That job has other candidates: an address shown prominently before payment, a short undo window, a support contact that answers.
- The job is stable while the solutions change. "Make sure my parcel arrives at the right place" was true before this store existed. Framing around it gives you more options and a better signal — fewer mis-delivered parcels, not more edits.
- A request is a solution proposed by a user, filtered through what they imagine is possible. It is strong evidence that a job exists and weak evidence about how to serve it.
- Every order feature has secondary users: support who explain it, finance who reconcile it, the warehouse who act on it. They rarely file requests and always pay the cost.
"Users" is not a person
"Users want to edit their order" sounds like a requirement and contains nobody. It cannot be designed for, because every design question — how long after ordering, which fields, what happens to the payment — depends on who is editing and why.
The fix is almost mechanical: replace "users" with a role, a task and a moment, then write what that person is trying to achieve without mentioning the feature. The sentence gets longer and the feature gets smaller.
"As a user, I want to edit my order, so that I can change it."
"A shopper who has just placed an order sees on the confirmation email that the address is her old one. She wants to make sure the parcel reaches her new flat."
The second version rules things out. The window is minutes, not days; the field is the address, not the items; and success is a parcel arriving at the right door, which is something support can count.
Splitting a request by job
Reading the comments behind the upvotes and last month's order-change tickets, the single request splits into separate jobs. Each has a different person, a different frequency and a very different cost.
The frequencies below are words, not percentages, on purpose: they come from reading one store's tickets, and the split in your product will be different. Finding your own split is the exercise.
| Job | Who, and when | How often (from tickets) | Smallest thing that serves it | Rough cost |
|---|---|---|---|---|
| Make sure the parcel arrives | Shopper, minutes after ordering | Most of them | Address change allowed until the order is picked | About two days |
| Avoid paying shipping twice | Shopper, same day, forgot an item | Some | Merge a second order into the first shipment | Several weeks: payment and stock |
| Fix an order for a caller | Support agent, before dispatch | Few, but each takes long | Internal edit tool with an audit log | About a week, internal only |
| Reconcile paid against shipped | Finance, at month end | Never filed as a request | Change history on the order record | Needed by all of the above |
Explaining the split to the PM
The split is only useful if the PM can act on it. That means giving them something to announce, not just something to cancel.
The PM has told the feedback board that order editing is coming. You have read the tickets and think the address fix is most of the value.
"Full order editing is six weeks and touches payments. I do not think we should do it."
"I went through the tickets behind the upvotes. Most are wrong addresses spotted within the hour — we can fix that in about two days by allowing address changes until the order is picked. Adding items is the expensive half and fewer people ask for it. Could we ship addresses as phase one, tell the board, and see how many item requests are left a month later?"
The users who never file requests
Every order feature has users who will never appear on a feedback board. They do not ask for features; they absorb them. The time to find out what a change does to them is before it ships, and it usually takes one message each.
- Support will be asked how it works and what to do when it does not. What do they need to see in the admin to answer?
- The warehouse acts on the order once it is picked. At what point does a change stop being safe?
- Finance reconciles payments against shipments. What record do they need when an order changed after payment?
- The next team to touch checkout has to keep this working. Will it be clear from the code and the ticket why it exists?
How to do it
Most important first.
- Replace "users" with a role, a task and a moment: "a shopper who has just placed an order and notices the wrong address on the confirmation email".
- Write the job as progress, without the feature: "make sure the parcel arrives at the right place". Test it by asking whether it would have been true ten years ago.
- Split the request by job. Read the comments behind the upvotes and last month's order-change tickets, and group them by what the person was trying to get done, not by what they asked for (Qualitative Signals).
- Size each job roughly: how many people, how often, how painful the current workaround is. Support categories and a query on order changes usually answer it in an afternoon.
- List the secondary users — support, finance, warehouse — and ask each one what the change does to them before it ships (The Support Loop).
- Build for the largest job first with the smallest solution, and say out loud which jobs you are deliberately not serving yet (Cutting Scope by the Question, Not the Difficulty).
How to explain the decision
The sentences, the order, and what to lead with — for someone who did not make the call.
- Lead with the people, split: "Order editing is really three requests. Most are wrong addresses caught within the hour; some are shoppers who want to add an item; a few are support fixing orders on the phone."
- Attach the cost to each: "The address fix is about two days. Adding items touches payment and stock and is about six weeks."
- Recommend by job, with a signal: "I suggest we allow address changes until the order is picked, and watch whether mis-delivery tickets drop. Adding items waits until we see how many people still ask after that."
- Name who else is affected and that you checked: "Finance and the warehouse both see edited orders. The warehouse confirmed address changes before picking are safe; finance wants the change recorded on the order, which is included."
- "We already know our users." Then this will be quick: which of these three jobs is the most common? If we cannot answer from the tickets or the data, we do not know them well enough for this feature.
- "Twenty upvotes is a clear signal." It is a clear signal that something hurts. The comments say three different things hurt, and they cost very different amounts to fix.
- "Can we just build all of it so everyone is happy?" We can, in six weeks. Or we can make most of them happy in two days and decide about the rest with better information.
What can go wrong
- Personas as decoration: a slide of named personas with hobbies that no decision ever refers to. A role doing a task beats a persona with a stock photo.
- Inventing the job at a desk. A job statement nobody checked against tickets, calls or data is a guess wearing a framework.
- Serving the loudest job. The shopper who posts on the feedback board is not the typical shopper; the quiet majority shows up in the data, not on the board.
- Stopping at the analysis: the job map becomes the deliverable and nothing ships.
- Forgetting that internal people are users. The support agent's screen is a product surface too, and a bad one costs time on every call.
- "Jobs to be done is a framework we have to adopt." The useful part fits in a sentence: name the progress someone is trying to make. You do not need interviews and canvases to start using it.
- "The user asked for X, so X is the job." The request is a proposed solution. The job is what they would still want if X were impossible.
- "Internal users do not count." Support and finance use every order feature; they just do not have a feedback board.
- "More personas means more user focus." Two sharply defined roles doing real tasks beat six personas nobody consults.
Knowing whether it worked
- Mis-delivery tickets drop after the address change ships — the job moved, not just the feature usage.
- The mix of edit requests after launch roughly matches the split you predicted from the tickets. If it does not, your split was wrong, and that is worth saying.
- Support can explain the feature to a shopper in one sentence.
- Nobody in finance or the warehouse is surprised by the launch.
- At a few hundred orders a week you can read every ticket and know the jobs by heart. At 10x users you cannot, and sampling plus ticket categories becomes the method. The discipline of naming the role and the moment stays the same.
- At 10x team size, different teams serve different jobs for the same shopper and ship features that collide. A short, shared list of the jobs your area serves becomes a coordination tool.
- In B2B the buyer and the daily user are different people with different jobs, and a feature can win the deal and lose the user. The small consumer store does not have that split; most B2B products do.
- Splitting by job means shipping less than was asked for, and some of the twenty upvoters will say so in public.
- Reading and grouping tickets takes a day that does not feel like engineering, and someone will ask why the feature has not started.
- A job framing can talk you out of a feature that would have been right, because the job looked served by something smaller. Watching the signal afterwards is the check on that.
Where this applies
Product advice is context-sensitive. These labels say what each claim is specific to, and where a different stage, team or product would differ.
- GENERALNaming a role, a task and a moment helps any product. How you find the jobs differs: a consumer store reads tickets and data, while an internal tool can walk over and watch someone use it.
- PRODUCT-SPECIFICIn B2C the user and the payer are usually the same person. In B2B they split — a procurement buyer hires the product for compliance, the daily user for speed — and the job you optimise for must say which of them it serves.
- SIMPLIFIEDJobs-to-be-done has a fuller theory, with emotional and social jobs and forces that push people to switch. This lesson keeps only the part that changes engineering decisions: the progress someone is trying to make.