Value Proposition Design: How to Create Products and Services Customers Want

By Alexander Osterwalder & Yves Pigneur & Patricia Papadakos & Gregory Bernarda & Alan Smith & Nguyễn Thụy Khánh Chương

12 min read

Why does it matter? Because you're probably building something nobody asked for.

Most product failures aren't engineering failures — they're empathy failures. The team was talented, the execution was clean, and the launch was still a disaster because somewhere early on, someone confused their own enthusiasm for customer demand. They built what made sense internally, not what solved something real externally. That assumption gap — between what you think customers want and what actually drives their decisions — is where launches go sideways. This book is a systematic cure for it. Not a motivational argument for caring more about customers, but an actual methodology: frameworks for mapping what customers are truly trying to accomplish, tools for testing whether your solution fits that reality, and hard-won principles for knowing when to pivot before the market delivers the verdict for you.

You're Solving the Wrong Problem — and You Don't Know It Yet

Most product teams believe they understand their customers because they've spoken to them. The problem is that customers are remarkably good at describing what they want and remarkably bad at explaining why they want it. That gap is where value propositions go to die.

Consider a business book publisher trying to figure out what their customers need. The obvious answer is 'more books on relevant topics.' But push past that answer — ask why someone buys a business book, then why that matters, then why that matters — and you arrive somewhere unexpected. The customer isn't trying to read a book. They're trying to learn something that helps them earn more money or advance their career. The moment you see that, the competitive picture shifts entirely. The publisher's real rivals aren't other publishers. They're MBA programs, YouTube tutorials, and executive coaches. Design around 'what do readers want in a book' and you're optimizing the wrong thing. Design around 'how do professionals acquire career-advancing knowledge' and you're in the right fight.

Value proposition myopia is what happens when you unconsciously list only the customer jobs your existing product already solves. It feels like customer research. It's actually a mirror. You're cataloguing your own assumptions and calling it insight.

The fix is uncomfortable. It requires treating the customer's actual situation as the starting point, not your product. That means mapping jobs, pains, and gains as they exist independent of anything you sell — and being honest enough to include the jobs you can't address at all. A customer's frustration with a complicated onboarding process is a pain whether or not you've built a solution for it. A customer's desire to look competent in front of their manager is a job whether or not your product touches it. The customer profile belongs to the customer. You observe it; you don't design it.

Once you genuinely see the customer's situation on its own terms, the design conversation changes. Instead of asking 'how do we explain our features better,' you're asking 'which of these real problems are we actually equipped to solve, and how well?' The business book publisher who gets there stops competing on page count and starts competing on career outcomes. That's a different company.

Jobs, Pains, and Gains: A Vocabulary That Makes 'The Customer Doesn't Like It' Solvable

What does 'customers are frustrated' actually tell you about what to build next? Nothing actionable. It tells you sentiment exists. It doesn't tell you where to aim.

The Value Proposition Canvas gives you a three-part vocabulary that converts that blob of sentiment into specific design targets: jobs, pains, and gains.

Most product teams compete exclusively on functional jobs — the obvious task the product performs — and wonder why a technically superior product loses to one that makes users feel smarter when they use it. That's the social job at work: how someone wants to be perceived. The emotional job sits underneath that — how someone wants to feel. Winning on the functional layer while ignoring the other two is how you build something correct and unloved. The taxonomy also includes a category almost everyone misses: supporting jobs. These are the things customers do around the main job — comparing options before buying, posting a review afterward, figuring out how to cancel. If your onboarding is painful, you're failing a supporting job. If customers can't get out cleanly, you're failing another one.

Pains are where precision becomes non-negotiable. Vague pains produce vague solutions. 'Waiting in line is annoying' is not a design target. 'Waiting more than seven minutes in line' is — because now you know what the threshold is, which means you know what winning looks like. When you push customers to quantify their frustrations, you're converting opinion into a specification.

Gains operate on a hierarchy. Some are required — a phone must make calls. Some are expected — users assume it will look decent. Some are desired — seamless sync across devices. And some are unexpected — the original iPhone's touchscreen, which nobody asked for because nobody imagined it was possible. In consumer electronics, almost every competitive analysis clusters at the expected level, where everyone is fighting over the same marginal improvements. The unexpected gains — the ones that redefine what the category is — come from understanding what customers are genuinely trying to accomplish, not just what they're currently tolerating.

Taken together, these three concepts don't just organize feedback. They turn 'customers don't like it' into a question you can actually answer: which job are we failing, how severe is the pain and where exactly does it start, and are we competing at the floor of customer expectations or somewhere more interesting?

The Value Map: Focus on One Pain Extremely Well, Not Every Pain Adequately

Comprehensive coverage is a liability, not a feature. The product team that packs in every requested improvement signals effort; what customers experience is a product that does many things tolerably and nothing memorably. A value proposition earns traction by alleviating a small number of extreme pains with intensity, not by addressing every pain with adequacy.

The distinction sits in the word 'extreme.' Every customer has a long list of frustrations. Most are background noise — friction they've learned to live with, annoyances that don't change behavior. A few are genuinely acute: the pain that makes them cobble together workarounds, complain to colleagues, or actively search for alternatives. Those are the ones worth designing around. The Value Proposition Canvas asks you to identify your pain relievers and then check them honestly against the customer profile — does this actually address something that makes the customer's life materially better, or does it just add to the feature count? Pain relievers that don't connect to a genuine customer pain aren't neutral; they dilute the signal of what you're actually good at.

Competitive pressure is where teams lose the thread. The instinct is to add, not cut — to see a rival's capability and match it, then exceed it, then match the next one. What that produces is feature parity at best and an incoherent product at worst. The logic runs the other direction: find the pain that matters most and outperform on that dimension by a margin that can't be ignored. Customers don't recommend products that adequately served them. They recommend products that solved the one thing they'd given up hope of solving.

You haven't achieved fit when your value map has more checkmarks than your competitor's — you've achieved it when customers react with genuine excitement, which only happens when you've addressed something they actually cared about rather than something you found convenient to offer. Polish everything, but make one thing extraordinary.

What People Say They'll Do and What They Actually Do Are Different Data Points

Think of a weather forecast. It tells you there's a 70 percent chance of rain tomorrow. Does that mean you'll carry an umbrella? Maybe. But watch what people actually do — they glance at the sky, check if their coat has a hood, and decide based on what feels like effort. What they say when asked 'will you bring an umbrella?' and what they do when clouds appear are two completely different data points. Customer interviews have the same problem built in.

The interviewing discipline the framework imposes exists precisely to close that gap. Its most important rule is a ban on hypotheticals. The question 'Would you use a service that did X?' is useless — not because customers are dishonest, but because imagining future behavior is genuinely hard, and people default to agreeable. Replace it with 'When was the last time you ran into this problem, and what did you do?' Now you're asking for a memory, not a prediction. The answer is either there or it isn't. If someone can't describe a specific recent incident, the pain probably isn't acute enough to design around.

The most valuable interview subject isn't someone who says they have the problem — it's what Steve Blank calls an earlyvangelist: someone who has already, on their own initiative, cobbled together a workaround. A spreadsheet. A manual process. A combination of three tools that almost handles it. That behavior is evidence. It tells you the pain is real enough to spend effort on, and that the person has already allocated mental and sometimes financial resources toward a solution. Finding these people — and recognizing them when you do — is worth more than a hundred interviews with people who nod enthusiastically at your concept.

The practical anxiety here is legitimate: once you see how much your idea rests on verbal agreement rather than demonstrated behavior, the list of unvalidated assumptions gets uncomfortable fast. But that discomfort is useful. It redirects your attention toward the question that actually matters — not 'do customers say they want this' but 'what have they already done that proves it.'

The Business Model Is the Product — And It Can Be Worth 46 Times More Than the Thing You Built

A Hilti sales manager in the mid-2000s could have walked you through exactly why the company was losing ground. Cheaper competitors were flooding the market with tools that were good enough. Margins on high-quality drill bits and hammer drills were compressing year by year. The product was still excellent. The business model had expired.

What saved Hilti wasn't a better drill. It was the realization that construction managers don't actually care about owning tools — they care about delivering projects on time. A broken drill doesn't produce a sad foreman; it produces a delayed project, a financial penalty, and a furious client. That job — staying on schedule — was far more important than the job Hilti had been designing around for decades. Once that shifted, the entire model shifted with it. Instead of selling equipment, Hilti built a fleet management service: monthly subscriptions, guaranteed access to the right tool at the right site at the right time. Customers traded unpredictable capital costs for predictable operating expenses. Hilti traded compressed margins on hardware for recurring revenue and far stronger differentiation.

The underlying technology didn't change. The tool is still a Hilti tool. What changed was the structure around it — who pays, when they pay, what they're paying for, and what Hilti has to be good at to earn that payment. That structural change produced higher margins and a competitive position that a cheaper drill manufacturer can't easily replicate, because you can't copy a service model by manufacturing a similar product.

Most product teams treat the business model as a packaging decision made after the real work is done — you build the thing, then you figure out pricing. The Hilti case makes the cost of that sequence vivid. They had a great product for years and were slowly losing anyway. The product was necessary. It wasn't sufficient. What a customer will pay, how often, for what specific outcome, through which relationship — those aren't administrative details. They determine whether a value proposition customers genuinely want actually produces a business that survives.

Here's the specific test you haven't run yet: if you've validated that customers want what you're building but haven't tested whether your revenue model will cover what it costs to deliver it, you have half a validation. The channel you reach customers through, the partnerships you'll need, the cost structure of your operations — any one of these can kill a value proposition that customers love. Hilti knew its customers valued reliability long before the pivot. The question the new model answered was whether Hilti could capture value from that in a way that actually worked financially. Those are two different tests, and both have to pass.

Your Riskiest Assumption Is Probably the One You Haven't Written Down

Which assumption, if wrong, would end your idea entirely? Most teams can't answer that question without pausing — and that pause is where money disappears.

The testing discipline the framework builds around starts with a step almost everyone skips: writing down what needs to be true for your idea to work, ranking those assumptions by lethality, and designing experiments specifically to kill the deadliest ones first. Not to confirm them. To falsify them, cheaply, before you've spent anything you can't recover.

The Strategyzer team's own ranked hypothesis list for this book is instructive because of how ordinary it sounds: 'People still buy business books' sat near the top, alongside 'Value propositions are a real challenge for most people.' Not 'will readers love our format' or 'can we get good reviews.' Those matter, but only if the top hypotheses hold. If business book buying has collapsed, or if nobody actually struggles with value propositions, nothing further in the chain survives. You test the idea-killers first precisely because validating your second-tier assumptions while ignoring the first-tier ones is how teams spend six months learning the wrong things.

The structured tool for this is a Test Card: name the hypothesis, design a specific experiment, define what you'll measure, and set a success threshold in advance — the number that would tell you the hypothesis is valid or dead. That last piece is where rigor lives. Define success after you see the results and you'll find a way to call almost anything a win.

Even rigorous experiments can mislead you, and the Dropbox case makes the failure mode vivid. Early on, someone tested whether customers wanted a file-syncing service by running Google ads and measuring click-through rates. The ads flopped. The obvious read was that no market existed. The real problem was different: people weren't searching for file-syncing solutions because the category didn't yet exist in their minds. You can't search for something you haven't imagined needing. This is what the framework calls the false-negative trap — your experiment fails to detect a real opportunity not because the opportunity isn't there, but because the experiment was measuring the wrong signal.

The practical implication is uncomfortable: a failed test doesn't automatically mean a dead idea. It might mean you tested a behavior that couldn't exist yet, surveyed the wrong population, or defined the wrong metric. Before you pivot, ask whether the experiment itself was adequate — then design a better one.

Owlet Proves the Method: Wrong Customer, $220 MVP, A/B Price Test, Regulatory Pivot

A few years before Owlet became a consumer electronics brand, its founders sat across from hospital administrators with a pitch: a wearable monitor for newborns that would alert parents to dangerous changes in oxygen levels. Fifty-eight nurses said they loved it — 93 percent, in interviews that must have felt like momentum. Then the founders asked the administrators who actually controlled hospital budgets whether they'd pay for it. Zero percent said yes. That single week of interviews, which cost almost nothing, could have ended the company. Instead, it redirected it.

The founders didn't conclude they had the wrong product. They concluded they had the wrong customer. Parents at home, not hospital procurement departments, were the people losing sleep over infant health. So rather than refine the pitch for a buyer who'd already said no, they rebuilt the value proposition for a buyer with a genuine, immediate job to do: keep watching the baby without standing over the crib all night.

To test whether that market existed before spending real money, they built a landing page — product description, some visuals, a place to register interest — and spent $220 promoting it. Seventeen thousand people visited. That's not proof of a business, but it's evidence of a pain acute enough to generate curiosity, which is more than most teams have before they hire engineers.

The next question was price. They ran an A/B test across 1,170 people over eight weeks, comparing responses to different price points. At $299, the signal was strong enough to proceed. That's a validated number, not a guess — which means when Owlet set its retail price, they weren't hoping the market would accept it. They'd already watched it happen.

The regulatory path produced one more test. Getting FDA clearance for a device that triggered medical alarms would cost somewhere between $120,000 and $200,000, and might fail anyway. So before committing to that route, Owlet tested a different product framing: a health tracker without alarm functionality, aimed at less anxious parents who wanted data rather than alerts. Retailers picked it up. Twenty percent adoption confirmed that a real commercial path existed on the safer side of the regulatory line.

What the Owlet sequence demonstrates isn't cleverness — it's discipline applied in the right order. Wrong customer identified in week one at zero cost. Market size approximated for $220. Price confirmed with real people before production. Regulatory risk routed around through a targeted experiment. Each test was designed to kill a specific assumption, and the founders let the results lead. That's the method, not the mythology.

The Assumption You Haven't Tested Is the One That Will Burn You

Not creativity, not hustle — just the methodical practice of turning your beliefs into falsifiable claims before they become expensive regrets. So before you redesign anything: write down the single assumption whose failure would end your idea entirely. Not a list — one. Then figure out the cheapest artifact that could prove it false. That's your next move. Everything else waits.