From Product Theory: The Hidden Forces That Shape User Behavior — 40+ short chapters on why users behave the way they do.
A fast-food chain wanted to sell more milkshakes. They did the obvious things: focus groups, taste tests, tweaks. Thicker. Sweeter. Cheaper. New flavors.
Sales barely moved.
So they tried something else. Instead of asking people what they wanted in a milkshake, they watched who bought them and when. The pattern was strange: nearly half the shakes sold before 8:30 AM, to people alone in their cars.
Why would commuters buy a milkshake for breakfast?
The milkshake wasn't the product
Once you look at the context, it makes total sense. The shake lasted the whole drive. You could hold it one-handed while steering. It was thick enough to be a project, so it killed the boredom. It filled you up until lunch. And it beat the alternatives—a bagel was messy, a banana was gone in thirty seconds, a donut left you hungry.
These people weren't buying a "milkshake." They were hiring something to make my commute less boring and keep me full until noon.
That's the whole idea behind Jobs to Be Done, the lens Clayton Christensen made famous: customers don't buy products. They hire solutions to jobs. Understand the job—functional, emotional, and social—and you understand the choice.
The milkshake's job wasn't "be a delicious treat." It was "make my morning commute bearable"—with a functional layer (fill me up), an emotional one (give me a little pleasure), and a social one (this isn't junk food, it's just a shake).
Why this reframes everything
Most product decisions get made through two lenses that both quietly miss the point.
Demographics miss it. Traditional marketing segments by who the customer is—age, income, location. But two people in the same demographic can hire the same product for completely different jobs. One 35-year-old buys noise-canceling headphones to focus. Another buys the identical pair to signal status. Same product, same demographic, different job.
Features miss it. We love to compete on faster, cheaper, more powerful. But features don't explain choice—jobs do. Nobody bought the first iPod because it had 5GB of storage. They bought it because "all my music, always with me" got a job done.
And here's the part that quietly kills a lot of product strategy: your real competition is anything that gets hired for the same job. The milkshake doesn't compete with other milkshakes. It competes with bananas, breakfast bars, podcasts—and doing nothing at all.
Rule of thumb: Customers hire solutions, not products.
How to build with it
Once the job is the unit of analysis instead of the product, your decisions get sharper.
- Design for the job, not the category. Don't ask "what features should a note-taking app have?" Ask "what job are people hiring note-taking for?" If the job is "capture fleeting ideas before I forget them," that's a different product than "organize my research for a thesis." Same category. Different job. Different app.
- Solve the whole job. Customers hire the thing that finishes the complete job, even if it's mediocre at each piece. An all-in-one that does 100% of the job often beats a superior point solution that nails 80%.
- Speak in job language. "We integrate with Slack" is a feature. "Never miss an urgent question from your team" is a job. Users don't care about your product. They care about their problem. Talk to the problem.
How to actually find the job
The trap is asking people what they want. That gets you a feature list, not a job.
| You ask | You get |
|---|---|
| "What features do you want in a note-taking app?" | "Tags. Folders. Good search." (A wishlist.) |
| "Tell me about the last time you couldn't find something you wrote down." | "I knew I'd had the exact idea, but I had notes in Slack, email, random docs—spent ten minutes searching and gave up." (The job is retrieval, not organization.) |
One question hands you a backlog. The other hands you the job.
A few more places jobs hide:
- Workarounds. When people cobble together spreadsheets, sticky notes, and weird personal rituals, they're telling you a job isn't being done well. Workarounds are job requirements in disguise.
- Context. The same person hires coffee for energy in the morning, for social bonding at lunch, and for comfort at night. Identical product. The job changes with the moment.
- Hire-and-fire language. "I switched to…" "I stopped using…" "I started doing…" Those phrases tell you exactly what's being hired and fired, and for which job.
Once you hear it this way, you can't un-hear it. The next time a user tells you they want a feature, you'll catch yourself asking the better question: what are you actually trying to get done?
If the next time a user asks for a feature you catch yourself asking what they're actually trying to get done, this one did its job. The Context Limit newsletter sends the next idea along whenever you want it.