The Solution Nobody Dreamed Of

In 2009, Jim McKelvey — a glass artist in St. Louis — lost a sale of over $2,000 because he couldn't accept a credit card. He called his friend, Twitter founder Jack Dorsey, and the two of them started asking a question that the payments industry had ignored for decades: why can't a small business accept cards as easily as a large one?

The Job itself wasn’t new.

Every coffee shop, farmer's market vendor, and freelancer who'd ever turned away a customer for not carrying cash was feeling it. They'd hired workarounds — cash-only signs, trips to the ATM, clunky terminals with monthly fees and multi-year contracts most small sellers couldn't qualify for. Before Square, only about 27% of small businesses accepted credit cards.

Square's solution was a small white dongle that plugged into a smartphone's headphone jack. Flat fee — 2.75% per swipe, no hidden costs, no contracts. The reader shipped for free.

Nobody asked for that. Nobody would have described it in a survey. But millions of small sellers recognized it instantly as the thing they'd needed all along.

Solutions change, Jobs don’t

This is one of the most important principles in Jobs-to-be-Done theory, and one of the easiest to forget: jobs don't change. Solutions change. How you design for the job changes. But the underlying thing people are trying to accomplish stays remarkably stable across decades and even centuries.

People have always needed to coordinate work with others. They hired memos, meetings, cc'd emails, hallway conversations, and sticky notes on monitors. Slack didn't create the job of team coordination. It solved it in a way that made every previous solution feel like a workaround.

People have always needed to capture and organize what they know. They hired cave walls, filing cabinets, notebooks, bookmarks, Word documents saved in nested folders. Evernote didn't create the job. It solved it in a way that made the old approaches feel impossibly clunky.

People have always needed to get where they're going without wasting time stuck in traffic. They hired radio reports, leaving twenty minutes early, memorizing back roads, printed out Mapquest directions, called ahead to ask "how's the drive?"

Waze didn't create that job. It solved it by turning every driver on the road into a real-time sensor — reporting speed, police, accidents, road closures, potholes — in a way nobody would have predicted from existing behavior.

Why surveys can't find these solutions

If you had asked commuters in 2008 what they wanted for navigation, they would have said faster GPS recalculation. Better maps. Maybe real-time traffic overlays from highway sensors. The job would have been visible in every answer. The solution Waze eventually built — crowdsourced intelligence from millions of drivers — would have appeared in none of them.

This is the gap that JTBD exposes more clearly than any other way of thinking. People can articulate the job with surprising precision when you interview them well. What they cannot do is imagine solutions that don't yet exist.

Brian Chesky understood this when he built Airbnb. The job of experiencing a place like a local — not like a tourist — was as old as travel itself. People hired guidebooks, asked friends for restaurant recommendations, wandered off the main streets hoping to stumble into something authentic. Every traveler who'd ever felt the disappointment of a generic hotel lobby was feeling this job.

Nobody would have described the solution as "sleep in a stranger's apartment." That solution was unimaginable until it existed. But the job it served was immediately recognizable.

The "Belong Anywhere" campaign, launched in 2014, made this connection explicit. The messaging pointed at the job — the kind of travel experience you actually want — and positioned Airbnb as the solution that finally made it possible.

Designing the solution means choosing which Job to solve for

The most consequential design decision isn't what features to build. It's which stable, enduring, and specific Job to build around.

Square faced this choice clearly. The job "process financial transactions" describes an enormous range of products — from bank wire systems to PayPal to Venmo. If McKelvey and Dorsey had built for that broad framing, they'd have been competing with every payment company on earth.

Instead, they chose to attack a specific slice of the status quo: let a small seller accept a card payment, right now, with no setup. That narrowing shaped everything — the hardware (tiny, free, plugs into a phone), the pricing (flat percentage, no contracts), the onboarding (sign up and start swiping). The product was the Job made physical.

The specificity is what made it work. A product designed for "payments" would have looked like every other payment product. A product designed for "the farmer's market vendor who just lost a sale" looked like nothing that existed.

Building the context where the Job becomes urgent

Sometimes the job exists broadly but at low intensity — people feel it, but not strongly enough to hire anything for it. The design work in these cases isn't inventing a job. It's building the conditions where an existing job becomes acute enough that people start looking for a solution.

Crossfit is a clear example. The job "test myself physically against other people" existed long before Crossfit — in pickup basketball, in weekend races, in gym rivalries that never had a scoreboard.

Crossfit didn't invent the competitive instinct. It designed a structure — competitions, standardized workouts (WODs), personal records, the annual Open — that made the job hireable for millions of people who had never thought of themselves as competitive athletes.

GoPro designed context for the job "capture and share my experience." That job existed every time someone wished they could show a friend what the wave looked like, or what the trail looked like from the summit.

Before GoPro, the only solutions were expensive professional equipment or shaky phone footage that didn't survive the moment. GoPro built a product — and then a content ecosystem of awards, highlight reels, and sharing tools — that made the job feel essential rather than aspirational.

In each case, the job was already real. The design work was making it feel urgent enough, and the solution accessible enough, that people finally acted on it.

The solution shapes how people understand the Job

Here's where it gets subtle. When a solution is good enough, it changes how people talk about the job — even though the job itself hasn't changed.

Before Waze, "navigation" meant getting directions — a route from A to B. After Waze, navigation meant something closer to real-time situational awareness. Not just where to go, but what's happening on every road between here and there, updated by the second, reported by the people actually driving on them.

The job didn't change. But the solution was so effective that it expanded what people expected. "Get where I'm going efficiently" was always the job. Waze raised the bar for what "efficiently" meant — and made every static navigation tool feel broken by comparison.

Airbnb did the same thing to travel. The job of wanting an authentic local experience existed forever. But after Airbnb, people had a word for the opposite — the generic hotel experience became something to actively avoid, rather than just passively accept. The job was stable. The solution created a new standard against which every other solution was now measured.

This is a common pattern with great solutions. They don't create new jobs. They solve existing jobs so well that people retroactively wonder how they ever tolerated what came before.

Why specificity wins

Products that try to solve every version of every job tend to solve none of them memorably. Products that choose a specific, stable job and commit to solving it in an unprecedented way develop the kind of clarity that makes adoption feel inevitable.

"Help me communicate with my team" is a real job, but it describes email, Slack, Zoom, phone calls, and a hundred other products. The solution Slack designed — persistent, searchable, channel-based team communication — was specific enough to own. It solved one version of the communication job so well that it redefined expectations for the entire category.

The design decision is choosing which job to solve, and then building a solution so specifically tailored to that job that it feels like it was always supposed to exist.

That narrowing is a competitive advantage. The product that tries to be the solution for every job ends up being nobody's obvious answer for any particular one.

The best solutions look obvious in retrospect

The products that solve jobs most unexpectedly share a strange quality: they feel inevitable after the fact.

Waze feels like an obvious idea — of course drivers should share what they see. Airbnb feels like it named something travelers always wanted. Square feels like it solved a problem so basic that it's hard to believe nobody solved it sooner.

But none of these solutions were obvious before they arrived. The gap only feels obvious in retrospect, after the solution has made it visible.

That's the hallmark of a well-designed solution to a stable job. It arrives and people say "finally" — as if they'd been waiting for it. But they hadn't been waiting. They'd been living with inferior solutions to the same job, and they'd adjusted their expectations so thoroughly that they'd stopped noticing the gap.

The job was always there. The solution just made it feel inevitable.