The Scene — Before Dawn, a McDonald's, and a Mystery

It was a little after six in the morning when Clayton Christensen, a Harvard professor, discreetly pulled into a nearly empty McDonald's. He wasn't there for coffee but to investigate a mystery the company hadn't been able to solve for months. The morning milkshake simply wasn't responding to surveys: users asked for more flavor, less sweetness, thicker consistency, thinner consistency... and none of it increased sales. It was as if the product was adrift, unable to improve despite all the "classic" data pointing to logical paths.

Christensen did what few leaders do: he stopped asking and started observing. One by one, exhausted drivers came in, bought only a milkshake, and left quickly, as if they were performing a silent ritual before hitting the road. The same scene repeated itself countless times. The clue was right there—but it would only make sense when he understood what job that product was really being hired to do.

The Hidden Science — The Real Job Wasn't the Product, It Was Progress

When Christensen spoke with those customers, the insight emerged with clarity. The milkshake wasn't being bought for its flavor, nor for indulgence, and certainly not as a dessert. It was a tool to help them get through long morning commutes. It lasted almost the entire trip, didn't make their hands messy, kept them alert, and held off hunger until lunch. It was viscous enough not to be finished too quickly, portable enough to be consumed without risk, practical for those with little time, and, above all, it solved an invisible problem: the boredom of the commute.

This is the core of Job To Be Done. People don't buy products. They hire products to do a job—whether it's functional, emotional, or social. And the job rarely shows up in surveys because the job is lived, not declared. Christensen realized that the milkshake wasn't competing with other milkshakes: it was competing with bananas, donuts, cereal bars, coffee, and anything else that could make the commute less tedious. The real competition was in the context of life, not on the menu.

When Behavior Reveals Life — Not Preferences

What traditional research failed to capture, behavior captured immediately. Users don't wake up thinking, "I want a milkshake to avoid the existential boredom of the morning"; they simply do what works. This is a critical point for any founder: behavior is always more honest than opinion. While interviews produce desires, habits produce evidence. It was by observing its real use that Christensen found the answer—and it looked nothing like what the product team expected.

The job it revealed was simple and profound: to help get through a daily transition that no one considers worthy of attention—the morning commute. Life is made of invisible micro-transitions, and within them lie the true jobs. The milkshake thrived because it performed this job better than any alternative.

The Bridge to the Present — Where Founders Still Go Wrong

Most companies still formulate products by asking, "What else can we add?" or "What improvements would you like?" This approach creates noise, a list of disconnected features, bloated products, and solutions that respond to superficial desires, not real needs. Meanwhile, founders of products that become indispensable ask a different question:

"What job is the user trying to get done—and how can my product do that job better than any visible or invisible alternative?"

When this question guides the process, the product ceases to be a set of features and becomes an ally. The most common mistake founders make is believing they compete with companies in the same industry; in practice, they compete with any makeshift strategy the user comes up with. You compete with a shortcut, a habit, a workaround, an already-installed app, a piece of paper, a WhatsApp conversation. The job defines who the real competitor is.

How This Applies to Creating a New Product

Creating a new product requires more than observing explicit needs. It demands identifying the progress someone is trying to make, especially in moments of transition:

• changing a routine,
• starting a new habit,
• trying to be more efficient,
• solving a repetitive annoyance,
• filling emotional voids,
• eliminating cognitive or operational friction.

The job acts as a compass. It guides design priorities, communicates the product's logic, and eliminates noise. The right feature is the one that makes the job flow; everything that doesn't contribute to this becomes a distraction. Similarly, the product's storytelling emerges naturally when you understand the job: you're not selling a tool, you're selling the transformation it provides.

In the milkshake's case, once McDonald's understood the job, it changed the formula, the preparation, the positioning—and sales grew. Not by adjusting the flavor, but by aligning functionality with the user's desired progress.

Conclusion — The Job Is Hiding in Plain Sight

This case remains relevant because it exposes the deepest truth about products: nobody buys what you sell; they buy what it does for them. The job is always invisible until someone investigates it seriously. That's why founders who build real products develop the habit of looking at the world the way Christensen looked at the McDonald's parking lot: with a mix of curiosity, patience, and respect for people's actual behavior.

And this is where Synaptic.run naturally connects to this story. Just as the milkshake revealed the job through everyday use, Synaptic identifies hidden jobs by observing real data patterns—weak signals, micro-choices, frictions, drop-offs, and silent progress. The data shows the job your user is trying to get done, even when they can't articulate it. From there, the right product is born—not the desired product, but the hired product.

FAQ — Q&A about Job-To-Be-Done and the Milkshake Case

1. What exactly is "Job-To-Be-Done"?

Job-To-Be-Done is a framework for understanding why a person truly uses a product. Instead of focusing on features or declared preferences, JTBD identifies the progress the user is trying to make in their life—be it functional, emotional, or social—and recognizes that products are "hired" to perform this job. It's not about the product itself, but about what it helps the user accomplish.

2. How does JTBD help build better products?

Because it shifts the focus from an endless list of features to the real impact the user expects. JTBD helps founders to:

• define the real problem,
• know what they are truly competing against,
• prioritize features based on concrete needs,
• create products that eliminate friction and resolve tensions,
• avoid development waste.
• In other words, JTBD replaces guesswork with clarity.

3. How can I identify my user's real job?

Observe behavior: what does the person try to do before, during, and after using the product? What makeshift solutions do they use? Where do they feel friction? Contextual interviews and data patterns reveal the job much more effectively than direct questions.

4. How does Synaptic.run use JTBD in practice?

Synaptic.run analyzes real behavior within the data—clicks, hesitations, drop-offs, repetitions—to identify hidden jobs and guide product decisions. The data shows the job the user is actually trying to get done, allowing for the creation of solutions that are truly "hired."