Functional Job

Ask customers what they need and most of them answer with the name of a feature. Give us folders, let us export to a spreadsheet, let us turn off notifications. Build what you heard and the feature list gets longer while the number of people using it doesn't move, because what the customer named was the solution they happened to think of, not the task they were trying to finish.

Requirements meetings kept stalling in the same spot. Someone would say customers want folders, someone else would say then let's build folders, and three months later, with folder usage at 4 percent, nobody could explain the result. No one had written down what work the folders were supposed to take over, so there was nothing to point at when they failed.

A functional job is an agreement to strip the solution out at that moment. Jobs to be done, the lens that reads demand through what customers hire a product to finish, sees three layers behind a purchase, and the functional job is the layer you can confirm through a result. Not folders, but "find last month's meeting notes in under 30 seconds." Written that way, search is as valid an answer as folders, and when usage comes in low you can tell whether the solution was wrong or the task was read wrong.

Being the visible layer, it's also where most requirements documents stop. The other two layers — feeling and standing — go unwritten.

Extracting a functional job means deleting the solution words from what the customer said and writing down the task that remains. Three steps.

1. Delete the solution words. Folder, tag, button, dashboard — anything naming a screen or a feature. Keep going until no product or feature name is left in the sentence.
2. Rewrite it as a verb and an object. "Find," "export," "keep a record of what was agreed" — the action the customer is trying to take becomes the center of the sentence.
3. Attach what finished looks like. Without a test, you end up arguing after the build about whether it's done.

Run the steps and "we need a folder feature" becomes "find, in under 30 seconds, the meeting notes from last quarter where billing was discussed." By contrast, "help customers manage documents well" hasn't been through the steps at all. There's no test hiding in the word "well," so any build can claim success.

Size matters too. "Work efficiently" is so broad it fits every product, and "put a star next to the note title" is so narrow it's already a solution. The useful size is the unit of work a customer sits down to do. Something that happens in the 30 minutes right after a meeting ends is about right.

Functional jobs are used mainly in the opening line of documents about what to build, and in deciding who the competition is. Four places.

1. The top of the product requirements document (PRD), which states what is being built, why, and how done is judged. Before any feature list, pin down in one sentence which task this is taking over.
2. The outcome slot of a job story, which records a need as a situation, a motivation, and an expected outcome. Without a functional job the sentence trails off, and anything built will seem to fit.
3. Deciding who you compete with. Ask what people currently use to get the same functional job done, and the answer is often a spreadsheet or a chat thread rather than a product in your category.
4. Setting priorities. It's the basis for choosing between finishing the same job faster and taking on one more task.

Digging them out happens elsewhere. They come out of customer interviews, where you hear a customer's experience and context firsthand, and especially out of the switch interview, which retraces the moment someone changed products. Ask why they use something today and you get an invented reason; ask what happened on the morning they decided to switch and the task they had to finish comes out as a scene.

"The functional job isn't written here. Not 'build folders' — what is the customer trying to finish?"

The document has the solution and not the task.

"That functional job? They're doing it in a spreadsheet today."

The competition isn't another product in the category, it's a spreadsheet.

"The functional job is already handled and the deal still isn't closing."

The task itself is solved, so look at the other two layers.

At Pagedeck, the typical scene is Mia sitting down with Noa over twelve interview transcripts. Folders, tags and bookmarks each came up three or four times. When Mia deleted the solution words and rewrote the lines, all three collapsed into one sentence: find again what was decided in an earlier meeting.

That changed the next discussion. The agenda was no longer whether to build folders but what to solve that task with, and Noa pulled out a view that collects only the decisions at the top of each set of notes. It took less time to build than folders and covered nine of the twelve interviews.

The most common mistake is reading a functional job as another name for a feature list. Both look like records of what the product should do, so the assumption is natural. But a feature list is a sentence about what we will build, and a functional job is a sentence about what the customer will finish. The subject is different. Treat them as the same thing and no amount of interviewing stops the document from filling with feature names, leaving nothing to reason from six months later when those features go unused.

Believing a full set of functional jobs opens wallets is the other frequent one. Tasks are confirmed by results, which makes this layer more tangible than the others and makes filling it feel like finishing. In practice, products where every functional job works get praised in the demo and stall at the contract. What's left is the worry about migrating records and having it go wrong, or the worry about having argued for a new tool and being the person who picked badly. Try to solve those two by adding features and the features keep growing while conversion doesn't.