The Functional Job: It's Probably Not What You Think

When FedEx first built package tracking in the 1990s, it was a breakthrough. Customers could finally see where their shipment was — which hub it had passed through, what time it was scanned, whether it was on a truck.

More visibility. More data. More detail.

But for the business customers who relied on FedEx to ship to their own clients, all that detail often missed the actual job. They didn't need to know their package was at the Memphis hub at 3:47am. They needed to know one thing: is this going to arrive on time, and if not, how do I get ahead of it before an angry customer calls me?

"Better tracking" was the solution FedEx built. "Avoid a surprised and unhappy customer" was the job their shippers were actually trying to do.

That gap — between the product someone asks for and the job they're actually hiring it to do — is where functional jobs get misunderstood.

The functional layer isn’t a feature

When people talk about functional jobs, they sometimes mean "the thing the product does.” That's not quite right.

The functional layer is the what the user is trying to accomplish. The progress they're trying to make. The thing they'd put on a sticky note if you asked them what they need to do today.

It's not "use the CRM." It's "make sure nothing falls through the cracks in this deal."

It's not "open the design tool." It's "show the client what the homepage will look like before Friday."

It's not "check the analytics." It's "figure out why signups dropped last week."

The product is the hired solution. The functional job is what it was hired to do.

That distinction changes everything about how you design.

Why you might get the functional job wrong

The most common mistake is confusing the steps of the task with the Job. A user who opens a project management tool isn't trying to "create a task."

They're trying to make sure someone knows what they're responsible for, by when, so the thing actually gets done. Creating a task is a step. The job is "make accountability visible."

When you design for the step, you optimize the wrong thing. You make "create a task" faster, cleaner, more elegant. Meanwhile the user is still asking "but how do I know if anyone's actually looking at this?"

That question — the one the user is still asking after they've used your feature — is the functional job you haven't served yet.

TurboTax and the real job

TurboTax is one of the cleanest functional job stories in software. The job isn't "file taxes."

Filing taxes is the thing you have to do. The job — the actual progress someone is trying to make — is "get this off my plate without making a costly mistake."

Those sound similar. They produce completely different products.

A product designed for "file taxes" helps you fill in forms. A product designed for "get this off my plate without a costly mistake" has to do something much harder: it has to make someone who is anxious, uncertain, and non-expert feel confident they got it right.

That's why TurboTax's most important feature isn't its calculation engine. It's the "audit risk" meter, the plain-language explanations, the "we'll cover any penalties" guarantee.

None of those file taxes. All of them serve the functional job.

When the functional Job shifts

One of the most useful things about mapping the functional job clearly is that it tells you when your product has been outmaneuvered by a shift in the job itself.

Take GPS navigation.

For years, Garmin and TomTom dominated the standalone GPS device market. They were excellent at the functional job: "help me navigate from A to B."

Then the job shifted.

It didn't change in its essence — people still needed to get from A to B. But the job expanded: they now also wanted real-time traffic, faster rerouting when conditions changed, and integration with their phone.

Garmin and TomTom had built excellent products for the original functional job. Google Maps and Waze built for the evolved one. The collapse was fast — Garmin's portable navigation revenue dropped roughly 50% between 2008 and 2012, almost entirely because smartphones became mainstream and the job outgrew the device.

The underlying functional job — "get from A to B efficiently" — has existed as long as roads have. Paper maps served it. Printed MapQuest directions served it. Garmin served it. Google Maps serves it now. The job is stable. The solution has been disrupted four times.

That's why mapping the job matters more than mapping your features. If you're tracking what your product does instead of what the user is trying to get done, you'll miss the moment a better solution makes yours obsolete.

What makes a functional Job well-defined

A well-defined functional job is specific enough to generate design decisions.

"Help people communicate better" is not a functional job. It's a mission statement. "Help a distributed team make a decision and make sure everyone knows what was decided" is a functional job. It tells you what "done" looks like, who's involved, and what success means.

Intercom, the customer messaging platform, went through this distinction publicly. Their early positioning was broad: "make internet business personal." That's an aspiration, not a job.

Their product got sharper when they narrowed to specific functional jobs: help a support agent resolve a customer's issue without switching tools, help a marketer send the right message to the right user at the right moment. Each of those is specific enough to evaluate a feature against. "Make internet business personal" isn't.

The test: if you can't tell from the job statement whether a potential feature serves it or not, the job is still too vague.

How to find the real functional job

The question isn't "what do users do in your product?" It's "what are they trying to get done before they open your product, and what does done look like when they close it?"

Ask people:

• "Walk me through the last time you needed to do this. What triggered it?"
• "When you finished, how did you know you were done?"
• "What would have happened if you couldn't do it?"

That last question is the most important one.

"What would have happened if you couldn't do it?" surfaces the stakes. And the stakes are what tell you whether the functional job is a real job or a nice-to-have.

For FedEx's business shippers, the answer would have been: "The customer finds out their shipment is late from tracking it themselves, calls us angry, and we lose the account."

That's a real job. It has real consequences. Design for that.