Competing Against Luck

The Milk Shake Dilemma

McDonald's wanted to sell more milkshakes. The usual playbook came first: survey people who fit the profile of a milkshake buyer, ask what they'd want in an "ideal" milkshake, thicker, more chocolate, more chunks, then build it. Sales barely moved.

The research had answered a question nobody who actually buys a milkshake was asking. A researcher named Bob Moesta tried something different: he watched who actually bought milkshakes, when, and what else they bought alongside it, then came back the next day and interviewed those specific people about the full story of that purchase.

What the timestamps revealed

• Roughly 40% of milkshakes sold before 9am, to solo commuters buying nothing else.
• Those buyers wanted something to occupy a long, boring drive: thick enough to last through a straw for twenty minutes, one handed, not messy, filling enough to hold off hunger until lunch.
• Their real competitors weren't other milkshakes. They were bananas (gone too fast), bagels (crumbs, needs two hands), donuts (sticky fingers), and Snickers bars (guilt).
• Afternoon buyers were a completely different job: parents buying a treat for a kid, wanting something thinner and quicker so the wait wouldn't feel endless or indulgent.

Averaging those two circumstances into one "optimal" milkshake would have satisfied neither buyer. Two different circumstances were really two different jobs, with different competitors and different criteria for success, wearing the identical product.

This is the founding case for jobs theory, and it flips the usual research question. Instead of asking who buys a product, ask what circumstance someone was in right before they reached for it.

A PM staring at confusing or flat usage data should stop segmenting only by persona or demographics and start segmenting by the moment of use itself: what was this person actually trying to get done right before they opened the app, and who else, doing something else entirely, was competing for that same moment.

Progress, Not Products

A job is the progress a person is trying to make in a particular circumstance. Not a problem to solve and not a product category, progress: the move from a current, unsatisfying state to a preferred one. Most product teams reach for "the perfect feature set" by default; jobs theory asks a person to name the progress first and let the product follow.

Every job carries three dimensions at once. The functional dimension is the practical task itself. The social dimension is how the person wants to be seen by others while getting it done. The emotional dimension is how they want to feel while doing it.

A parent choosing childcare, for instance, is weighing trust and judgment about a caregiver as much as they're weighing logistics and safety, and the social and emotional dimensions frequently outweigh the functional one entirely.

Finding the right altitude

Defining a job well also means defining it at the right altitude. Too broad ("I want to be entertained") gives you nothing to build against. Too narrow ("I need a chocolate milkshake in a twelve ounce cup") just restates a product preference. The real test: if only products inside your own existing category can satisfy it, you haven't found a job yet, you've found a shopping list.

The hiring metaphor follows from this. A customer "hires" a product to get a job done. If it does the job well, they hire it again the next time that circumstance recurs. If it does the job poorly, they fire it, and go looking for something else to hire instead, often something that isn't even a competitor in the traditional sense.

For a PM, this reframes how a market opportunity gets scoped. State the target job as a verb and a noun, "help me feel confident presenting to my exec team," not "build a better slide deck tool." Scoping at the product level blinds a team to the real competitive set and to real expansion opportunities sitting just outside the category boundary.

Jobs in the Wild

Once you're looking for jobs instead of demographics, they turn up in places a conventional market map would never point to. Airbnb is the clearest case: it never had to win by being a cheaper, worse hotel.

Guests weren't hiring it for a hotel's job, predictable comfort, status, service. They were hiring it for an entirely different one: an authentic local experience, or simply being able to afford a trip they otherwise couldn't take at all.

That's why Airbnb's real competitive set was never just hotels. It was "staying with a friend," "not making the trip," and "booking a cheap motel and hoping," options that never show up on a hotel chain's competitive analysis because they aren't hotels. A job's biggest rival is very often a workaround, or doing nothing, not a branded competitor in the same category.

This is what makes jobs easy to miss and valuable to find: they hide inside behavior that looks irrational or beneath notice if you're only scanning for competitors who share your product's shape. A crude workaround someone has been quietly tolerating for years is a job sitting in plain sight, uncontested because nobody selling into that category has ever thought to look at it as a job rather than a market segment.

A PM should build the habit of mapping the real competitive set by walking through a customer's last several attempts at solving this job, a spreadsheet, an assistant's time, a manual workaround, giving up entirely, rather than assuming the competitive set is only the other logos in the category deck.

Job Hunting

New jobs worth building for don't usually announce themselves. Section Two turns from theory to method, and it opens with where to actually go looking.

Four places new jobs hide

• Inside your own company's products: what job do you personally use them to do, and where do you feel them falling short of nailing it?
• Nonconsumption: who isn't buying anything in your category at all, and what is stopping them, cost, skill, access, fear?
• Compensating behaviors: what workaround, hack, or improvised multi step process are people already quietly tolerating to get an imperfect version of this job done?
• Products or habits that look irrational from the outside: a purchase or behavior that "doesn't make sense" on paper is frequently a sign a real job is being served, just not the job an outside observer assumed.

Each of these is a different lens for the same question: not "what do competitors offer," but "what progress is someone still struggling to make, that nothing currently serving them actually nails."

Nonconsumption in particular deserves more attention than it usually gets, because a company staring only at existing customers and existing competitors will systematically miss the biggest opportunities: the people who wanted the job done badly enough to settle for nothing, or for something that barely counts as a solution.

For a product team, this argues for spending real time with people who aren't your users at all, and asking not "why don't you use us" but "what have you been doing instead, and why has that felt good enough to stick with." The gap between "good enough to stick with" and "actually nails the job" is where new products get built.

How to Hear What Your Customers Don't Say

Standard market research asks people what they want and trusts the answer. Jobs theory treats that as a trap: most of what actually drives a purchase decision is subconscious, social, or simply hard to put into words on a survey, so asking directly mostly produces answers people think they're supposed to give.

Storyboarding

The book's fix is a specific interview technique: reconstruct a customer's full switching story in chronological order, from the very first moment something felt wrong with their old solution, through everything they tried and rejected along the way, to the actual purchase and what happened right after.

The interviewer asks about specific moments, specific people involved, and specific near misses, the point where the customer almost didn't switch at all.

This works because a story carries context a rating scale can't. Asking "how satisfied are you" produces a number. Asking "walk me through the morning you finally decided to cancel your old subscription" produces the actual trigger event, the actual competing option that almost won instead, and the actual anxiety that nearly stopped the switch.

The method deliberately favors depth over breadth: a handful of customers studied in real narrative detail beats hundreds surveyed with a five point scale, because the story is the data. A single well told switching story can reveal a triggering event and a competing alternative that a thousand satisfaction scores would never surface.

For a PM, this means running "switch interviews" with the last eight or ten customers who churned to, or from, a competitor, walking the entire timeline with them, rather than sending out a satisfaction survey. Look specifically for the triggering event, the moment the old way stopped being tolerable, not for a general opinion about your product.

Building Your Résumé

Everything gathered from storyboarding needs to turn into something buildable. The job spec is that translation: a document capturing the job's functional, emotional, and social dimensions, the tradeoffs a customer will actually accept, the complete set of competing solutions that has to be beaten, workarounds and nonconsumption included, and the specific obstacles and anxieties standing in the way.

Call it a résumé because that's the test it has to pass: when the customer is deciding what to hire next time this job comes up, does your product's résumé beat every other candidate's, including the do nothing option?

Experience beats features

A subtle shift follows from taking the job spec seriously: competitive advantage increasingly lives in the full experience wrapped around the job, buying it, using it, getting help with it, not in a longer feature list. A cheap, low quality solution often generates its own anxiety, will this actually work, will I regret it, which is exactly the anxiety that pushes a customer toward a pricier but more trustworthy alternative instead.

It follows that a job spec should also say who the product is deliberately not for. Trying to satisfy every adjacent job with the same product usually means nailing none of them, and a team without a clear "not for" list tends to drift toward exactly that trap.

For a PM, this argues for drafting a job spec before a PRD: name the dimensions, the acceptable tradeoffs, the full competitive set, and the anxieties to defuse, and let the feature list follow from that document rather than the other way around.

Integrating Around a Job

Section Three turns from a single product decision to how a whole organization has to be built to keep delivering the job well. It opens with a line borrowed from W. Edwards Deming: if you can't describe what you're doing as a process, you don't actually know what you're doing.

Resources, cash, people, technology, are fungible. They can be bought, sold, hired away, or copied by a competitor with enough money. Processes are different: the specific patterns of coordination, communication, and decision making an organization uses to turn those resources into value are largely invisible from the outside and hard to replicate even when a rival can see the outcome.

That's why real competitive advantage increasingly comes from integrating processes tightly around the customer's job rather than around the org chart's default shape of function, business unit, or geography. Amazon is the clearest example: its processes are obsessively built around selection, price, and delivery speed, tracked almost minute by minute, because those three things are the literal components of the job "get me what I need, without hassle."

Southern New Hampshire University's enrollment map

Southern New Hampshire University did the same thing deliberately: its leadership charted the entire online enrollment journey from a prospective student's first inquiry to their first class, circled every step that served the university's convenience rather than the student's actual job, and rebuilt the process around removing exactly those steps.

A PM can run the same exercise on their own product: chart the onboarding or activation flow end to end, mark every step that exists for internal convenience rather than the customer's job, and redesign the flow around eliminating those steps rather than adding new features on top of them.

Keeping Your Eye on the Job

Growth is where companies quietly lose the job that made them, and this chapter names three specific ways it happens.

Three fallacies that pull a company off course

• The fallacy of active versus passive data: active data (units sold, uptime, satisfaction scores) is structured, easy to report, and becomes the model leadership trusts as reality. Passive data, the messy, qualitative stories behind why customers actually struggle and switch, resists a dashboard and gets discarded, even though it's where the job actually lives.
• The surface growth fallacy: instead of getting better at the one job that built the company, a growing business starts selling more adjacent products to the same existing customers to keep revenue climbing. Top line growth can mask the fact that the company has quietly stopped being excellent at the job it was originally hired for.
• The conforming data fallacy: ambiguous evidence gets interpreted in whatever way already fits the strategy leadership wants to keep running, rather than treated as a signal that might actually contradict it.

The book's healthcare example makes the first fallacy concrete: a hospital system is built, staffed, and paid to treat sickness, because that generates clean, billable, active data, not to promote health, because prevention only produces messy, passive data that's much harder to act on or reward internally. The organization's processes drift from the patient's real underlying job of simply staying well.

Before committing a roadmap bet to a metric, a PM should ask whether that specific metric was chosen because it's the one most likely to already agree with the strategy already decided on, and should go looking for the messiest, most qualitative piece of contrary evidence before locking in the budget.

The Jobs-Focused Organization

A well articulated job works the way "commander's intent" works in the military: a clear enough shared understanding of the actual mission that people far from headquarters can make good calls on their own, without waiting for permission on every decision.

This is what a jobs focused organization gets that a function first one usually doesn't. When everyone genuinely understands the job the company exists to do, three things follow: employees can make autonomous decisions that stay aligned with the mission, "what gets measured gets done" actually works because the metrics track real customer progress instead of internal throughput, and the job itself becomes a filter for saying no, clarifying what not to build as clearly as what to build.

There's a real cost to scaling, though. Startups are naturally jobs focused: a small team wears every hat and shares one unified picture of the job they're delivering. Growth tends to fracture that picture into functional silos, each optimizing its own slice, which is exactly the drift Chapters 7 and 8 already diagnosed.

Chapter 9 turns that diagnosis into a design principle: keep re-articulating the job explicitly as the org grows, rather than assuming shared understanding will survive scale on its own.

A useful exercise for a PM leading a team: write the "commander's intent" for the job you own in one sentence specific enough that a new hire could use it to make a correct call on their own, without needing to ask you first.

Final Observations About the Theory of Jobs

The book closes by stepping back from technique to theory itself. A job is a construct, an abstraction, not a fact you can point to directly, the same way you can't point at gravity, only at its effects. That doesn't make it less useful: a good construct is valuable precisely because it lets you predict what happens when you change something, which is exactly what jobs theory is for.

A well defined job is expressed in verbs and nouns describing the progress being sought, never in adjectives or adverbs like "convenient" or "better," which describe a feeling about a solution rather than the actual struggle underneath it. And the abstraction level test from Chapter 2 returns here as the book's closing check: if only products already inside your existing category can solve it, you still haven't found a genuine job.

Not every motivation rises to the level of a job, either. A job is specifically the recurring circumstance that triggers someone to seek progress, not every passing input into a single decision. Conflating the two is how teams end up chasing something too shallow or too situational to build a real strategy on.

The final section borrows a line from the accounting classic "Relevance Lost": every number hides a complicated story, and that story gets lost the moment it's compressed into the number alone. It's a direct callback to Chapter 8's active versus passive data fallacy: an organization that only manages the numbers, and never goes looking for the stories behind them, quietly loses touch with the customers those numbers were supposed to represent.

The Entire Book in One Framework

Every piece of the book connects into a single sequence. First, define the job precisely: the progress someone is trying to make, in a specific circumstance, expressed in verbs and nouns rather than product features (Chapters 1 through 3). Second, translate that job into a job spec: its functional, emotional, and social dimensions, the tradeoffs customers will accept, the full competitive set, and the anxieties to defuse (Chapters 4 through 6).

Third, integrate the organization's actual processes around delivering that job as a full experience, because processes, not products, are what a competitor can't easily copy (Chapter 7). Fourth, defend that focus deliberately as the company grows, because growth pressure quietly pulls organizations away from the job that built them unless leadership actively resists it (Chapters 8 and 9).

The theory itself, that a job is a construct built to predict behavior, not a fact to be observed, is what holds the whole sequence together (Chapter 10).

Jobs theory isn't a way to listen more closely to what customers say they want. It's a way to understand the progress they're actually struggling to make, which is very often something they could never have described to you directly.

10 Most Important Takeaways

• Customers hire products to make progress in a specific circumstance. That circumstance, not demographics, is the real unit of market analysis.
• A job has functional, emotional, and social dimensions, and the last two usually matter more than the first.
• Define a job in verbs and nouns, never adjectives, and never trapped inside the boundaries of your own product category.
• Your real competitive set includes doing nothing and every workaround people already tolerate, not just rival branded products.
• A new solution has to clear four forces at once: push and pull have to outweigh habit and anxiety combined, and anxiety is unusually powerful.
• A "big hire" (the sale) means little without a "little hire" (real, repeated use); track both, not just the first.
• Storyboard a handful of real switching stories in depth rather than surveying opinions from thousands of people.
• Write a job spec, its dimensions, tradeoffs, competitors, and anxieties, as the actual product brief, ahead of any feature list.
• Durable advantage lives in the internal processes that deliver a job as a full experience, because processes are far harder to copy than features.
• Growth quietly pulls companies off the job that made them, through tidy data that hides messy truth, revenue that hides a job going unmastered, and evidence bent to fit a story already believed.

The strongest idea in the book might not be "understand the job." It's that every purchase is really a resignation, the customer firing whatever they'd been using to cope with a struggle, so the real design question is never what features a product needs. It's what someone has been quietly suffering through, and what would finally make them let it go.