Value Proposition Canvas

Origin & evolution

The Value Proposition Canvas was developed by Alexander Osterwalder and the team at Strategyzer as a companion to the Business Model💰Business ModelBusiness ModelThe business model canvas or definitionView reference → Canvas, and set out in the 2014 book Value Proposition Design, written with Yves Pigneur, Greg Bernarda, and Alan Smith. The Business Model Canvas had a single box labelled "Value Propositions" sitting opposite "Customer Segments"; this canvas zooms into those two boxes and gives each its own structure. It draws openly on Clayton Christensen's jobs🔨JobUserJob To Be Done: what the user is trying to accomplishView reference →-to-be-done thinking for the customer side. Since 2014 it has become a standard discovery and product-marketing tool, taught in workshops and built into product courses worldwide.

How it works in practice

The canvas has two halves that you fill in a deliberate order. Start on the right, the customer side, drawn as a circle.

• Customer Jobs: the tasks☑️TaskProduct SpecificationA unit of work within a story or epicView reference → the customer is trying to complete, whether functional, social, or emotional.
• Pains: the frustrations, risks🎲RiskComplianceA risk to the product or businessView reference →, and obstacles around those jobs.
• Gains: the outcomes🏆OutcomeStrategyA desired business or user outcomeView reference → and benefits the customer wants, including the ones they would not think to ask for.

Then move to the left, the value map, drawn as a square.

• Products & Services: what you offer.
• Pain Relievers: how the offer eases specific pains.
• Gain Creators: how the offer produces specific gains.

Fit happens when each pain reliever lines up against a real pain and each gain creator against a real gain. The order matters. Teams that start on the left, listing features⭐FeatureProduct SpecificationA product capability or featureView reference → they are proud of, tend to invent pains to justify them. Starting on the right keeps the customer's reality in charge. A worked example: a payroll product lists "files taxes automatically" as a service. The matching pain is the fear of a filing mistake and a penalty, and the matching gain is closing the month without chasing a deadline. If a feature has no pain or gain across from it, that is a signal to question the feature, not the customer.

When to use it (and when not)

Use it when you are shaping a new offer, repositioning an existing one, or working out why a product is not landing despite shipping features. It is strongest in early discovery and in product marketing, where the gap between what a team built and what a customer wanted needs🫀NeedUserA user need, pain, desire, or constraintView reference → to be made visible.

It assumes you can talk to or observe real customers. Filled from a meeting room with guesses, it produces a tidy diagram that quietly launders assumptions🤔AssumptionStrategyA belief taken as true that underpins a strategyView reference →, and the neat layout can make those guesses look validated. It also works best one segment at a time; a single canvas covering several customer types blurs into vagueness. When the question is the whole business model and not just the offer, step out to the Business Model Canvas. When you want to test the riskiest assumption on the canvas, pair it with an experiment🧫ExperimentValidationA test designed to validate a hypothesisView reference →.

In the Unified Product Graph

The Value Proposition Canvas is a matrix framework in the discovery category, and its slots map cleanly onto entity types so that fit becomes a set of real, checkable relationships and not a wall of sticky notes:

• Customer Jobs become job🔨JobUserJob To Be Done: what the user is trying to accomplishView reference → entities.
• Pains become need🫀NeedUserA user need, pain, desire, or constraintView reference → entities.
• Gains become desired_outcome🌟Desired OutcomeUserWhat the user hopes to achieveView reference → entities.
• Products & Services, Pain Relievers, and Gain Creators all resolve to feature⭐FeatureProduct SpecificationA product capability or featureView reference → entities.

Held in the Unified Product Graph, a pain reliever is more than a note opposite a pain. It is a feature⭐FeatureProduct SpecificationA product capability or featureView reference → linked to the need🫀NeedUserA user need, pain, desire, or constraintView reference → it addresses and the job🔨JobUserJob To Be Done: what the user is trying to accomplishView reference → that need sits within. Fit becomes traceable. You can ask which features have no need across from them, or which customer jobs no feature serves, and the graph answers directly.