The job, not the feature

The person asking has done you a favour, just not the one they think. They have told you three things: that a problem exists, that it hurts enough to mention, and roughly what part of their life it lives in. What they have not told you is what the problem is, because they skipped that step and went straight to the remedy.

The named solution is usually wrong for a boring reason: it is the nearest thing they have seen work somewhere else. "We need an app" often means "the last time something was easy on my phone, it was an app". That is a genuine signal about where the problem lives, and a bad specification for what to build.

The move is not to overrule them. It is to go one step back and ask what would be different if it worked. Three or four exchanges of that, and the job appears on its own, usually in their words rather than yours.

"What do you do about this at the moment?"

Almost nobody is doing nothing. There is a spreadsheet, a group chat, a whiteboard, a person who just remembers, a Sunday evening that gets eaten. That existing behaviour is the single most useful thing you can learn, for three reasons.

It tells you what the job really is, because you can watch what they actually do rather than what they say they want. It tells you what "better" would have to mean, because whatever you build has to beat the spreadsheet, not beat nothing. And it tells you how much the problem hurts: somebody who has built an elaborate workaround has an expensive problem, and somebody who shrugs and says "we just cope" may not have one worth solving.

A second question earns its place right after: "when did it last go wrong, and what happened?" One concrete incident is worth an hour of general description, and it hands you the outcome that matters.

A fast-food company wanted to sell more milkshakes. It did what most organisations do: asked milkshake buyers what would make the milkshake better, made it accordingly, and sold no more milkshakes than before.

Then somebody went and watched. The surprise in the researchers' own words was that 40% of all milkshakes were purchased in the early morning, by people buying nothing else, alone, taking them away. Those customers had a long dull commute, one free hand, and a stretch of boredom to get through before lunch. The milkshake was not competing with other milkshakes. It was competing with bagels, which crumble, and bananas, which are gone in two minutes.

The framing the paper gives it: "Customers just find themselves needing to get things done. When customers find that they need to get a job done, they 'hire' products or services to do the job." Once you know the job is "make my commute less boring and keep me going until lunch", the improvements are obvious and none of them are the ones the survey asked about.

Used well, "what job is this hired for" does one very specific thing: it widens your idea of the competition. If the job is a boring commute, your competitors are bagels and podcasts, not other milkshakes. If the job is knowing who is available on Saturday, your competitor is a group chat and a piece of paper, not other football apps.

Used badly, it becomes a phrase people say in meetings to sound rigorous while changing nothing. Two habits keep it honest. Write the job in the words of the person who has it, not in product language. And write it so that it could be false: "he wants to know by Thursday night" can be checked with him, where "he wants a delightful experience" cannot.

There is a more quantified variant of this idea, outcome-driven innovation, which attaches importance and satisfaction scores to each step of a job. It is a different tradition with its own literature, and its own promoters, so treat the tidy origin stories about how the two relate with the same suspicion you would treat any other unsourced story.

It names the solution. If the statement contains the word "app", "dashboard" or "portal", you have written a plan, not a problem. The tell: you cannot imagine two genuinely different things that would both solve it.

It is for everybody. If "who has the problem" says "our users" or "the business", nobody will be able to tell you whether it got better. The tell: you cannot name one real person you could go and ask.

It cannot be false. "Make the process more efficient" cannot fail, so it cannot succeed either. The tell: you cannot say what number or observation would show it had not worked.

All three are fixed the same way, by going back to the person and asking what they do today, in detail, until something specific and slightly embarrassing turns up. The embarrassing detail is usually the problem.