Value Modelling
Value modelling ties every design decision to the value it creates for a named stakeholder. The Agile Extension to the BABOK Guide gives it a one-line structure: customer value = benefits - costs. Benefits are real when they solve a problem or perform a job, perceived when they touch status or reputation; costs cover the price and the risk, then the opportunity costs that are time and travel. The model names the customer, the outcome they expect and the terms of that subtraction. It is used at all three planning horizons.
Goal
Value modelling quantifies what a design decision brings a named stakeholder and what it costs them. The Agile Extension states the structure in one line, customer value = benefits - costs, then asks that every development decision be referred back to that equation for an identified customer. The guide also calls the technique the Customer Value Model.
The problem it addresses is justification. A team debating features argues from preferences and from business convictions, and the call goes to whoever speaks loudest or pays. Value modelling replaces that debate with a subtraction whose two terms are on the table. The Agile Extension assumes that an initiative exists in order to create value for its stakeholders.
The deliverable is the value model: a document naming the target customer, the outcome they are after and the benefit and cost items.
Usage
When to use it
- A large initiative with several delivery teams: the Agile Extension places the technique's best return here, each team tying its decisions to the same model.
- User experience design: the guide makes it a component of that discipline. The model separates two paths through the product that both work, by quantifying what each one saves the customer.
- Setting a price or a subscription: the equation bounds what a customer will pay before preferring the solution they used until then.
- Choosing between two options of comparable revenue: the subtraction separates what the customer keeps from what the organisation takes in.
When not to use it
- A decision expected the same day: the model presupposes qualitative and quantitative research, a weight the Agile Extension lists among its limitations. On two options already costed, cost-benefit analysis answers faster.
- Ranking features by the satisfaction they produce: the subtraction ignores the threshold effect and the excitement effect, which Kano analysis measures.
- Describing the whole business model: channels, key resources and customer relationships belong to the business model canvas, wider than the value model's blocks.
Description
Customer value = benefits - costs
Benefits come in two kinds. A real benefit solves a problem or performs a job the customer would otherwise have to carry out: a trip saved, a data entry removed, a breakdown avoided. A perceived benefit touches status, reputation or the goodwill a choice attracts. The first is costed from what it replaces, the second calls for a self-reported measure whose uncertainty has to be owned.
Costs divide the same way. Direct costs are the price paid and the risk taken on. Opportunity costs are the time spent and the travel agreed to, items the customer bears without anyone taking them in. A model that leaves them out overstates net value.
Three construction steps
The first step lists the stakeholders of the solution, which the Agile Extension groups into three sets. The second identifies each group's needs and what brings it value. The third defines the process by which those needs will be met. All three rest on qualitative and quantitative research.
The guide illustrates that grouping with a figure titled Flow Chart of Customer Value. Its text names the three groups. The value objective of each is read off figure 7.22.2, which lays over those three rows a process chain that no sentence in the section accounts for.
| Stakeholder group | Value objective |
|---|---|
| Internal and external customers | Design products that offer superior customer value. |
| The team delivering the initiative | Deepen the relationships and the domain knowledge gained. |
| The sponsor or owner who funds it | Make the most of the opportunity taken. |
Four representations
The Agile Extension offers four ways to present a value model, none of them mandatory: the choice turns on what the reading has to make visible.
The Value Proposition Canvas sets what a proposition offers against what the customer is looking for. It comes from Alexander Osterwalder, Yves Pigneur, Greg Bernarda and Alan Smith, who published it in 2014 in Value Proposition Design; the Agile Extension takes it up and gives it the role of showing which features of a product answer the customer's needs.
Value proposition map
Customer profile
Gain creators
What the proposition produces beyond the bare minimum.
Gains
What the customer hopes to get on top of the minimum outcome.
Products and services
What the proposition makes available.
Customer jobs
What the customer is trying to get done, with or without the solution.
Pain relievers
What removes or reduces a customer pain.
Pains
What gets in the customer's way before, during and after the job.
The Flow Chart of Customer Value is the representation by stakeholder group. It serves when several teams work on the same initiative and the question is who gets what.
The Means-Value Chart lines up the features or activities aimed at stakeholders against the value the customer is meant to draw from them. The guide's example takes revenue and profit as the central value, which an organisation can replace with the outcome it is aiming at. The text stops at those two sentences, for a figure whose box detail overlaps with no other passage in the section, which rules out reproducing it faithfully.
The Value Model is the canvas particular to the Agile Extension. Its eight blocks sit in three bands. The guide ties it to no outside source and its list of blocks differs from the business model canvas's, which has no block for competitors and separates activities, resources, channels and customer relationships.
The people involved
Key partners
Strategic values
Key rivals
Costs and revenues
Costs
Revenues
The value customers stand to gain
Key competencies
Value proposition
Key customers
The representation depends on the horizon
The Agile Extension writes that value modelling is used at any planning horizon. At the Strategy horizon the model covers research and development, marketing and sales and the customer base of the whole organisation; the Value Model and the Means-Value Chart, which deal in revenues and competitors, find their scale there. At the Initiative and Delivery horizons it covers the development of a solution for the customers of one given initiative; the Value Proposition Canvas, which goes down to the feature, is more useful there.
What makes the technique fail
The customer left anonymous
The Agile Extension makes the target customer an element of the model, designated by name. A model written for "the user" produces benefits that hold for nobody, because the time saved for a primary care physician and the time saved for an administrative assistant are not costed at the same rate. The remedy is a named persona or a customer segment defined by an observable criterion.
The perceived benefit counted but not measured
The perceived benefit counts in the equation, which makes it the easiest item to inflate: it cross-checks against no invoice. A team that assigns CHF 200 of reputation value to a feature gets the total it wanted. Two safeguards hold: cost the real and the perceived separately, then present the model with the perceived set to zero. If the decision still stands, the debate about perceived value becomes secondary.
The opportunity cost left out
Time and travel are the items a supplier-built model forgets first, because they appear nowhere in its accounts. A free service that takes twenty minutes of data entry costs the customer CHF 13 at a rate of CHF 40 an hour, more than a service billed at CHF 10 that takes none.
Revenue mistaken for value
The revenue taken in is a cost to the customer, which places it on the wrong side of the subtraction. An organisation reading its value model as a sales forecast will draw the opposite conclusion: raising the price improves revenue and destroys customer value, up to the point where the customer walks away.
The model that grows until it no longer serves
The guide lists among the technique's limitations that it becomes too complicated for an organisation looking for quick information. A forty-item value model fed by six months of interviews arrives after the decision it was meant to inform. The counter is to fix in advance how many items the model will carry, then to keep the items set aside in case the decision stays close.
AI considerations
The sifting work can be delegated. A language model reads a corpus of support tickets, interview notes and published reviews, then draws from it an inventory of jobs, pains and gains, grouped by recurrence. That is the raw material of the right-hand column of a Value Proposition Canvas, and gathering it by hand takes several days.
The arithmetic can be checked as well. A value model fits in a spreadsheet, and a language model given the items, the amounts and the scale recomputes the subtraction, flags a total that contradicts its components and produces the sensitivity variants nobody has time to work through by hand. Verification is worth more than generation: asking for a recomputation of a value already set detects the error, whereas asking for the numbers themselves manufactures one.
Assigning the amounts cannot be delegated. What an hour of a customer's time is worth, what they pay today to do without the solution and what they would give up by switching rest on market facts and on contracts the model does not know; it will fill the gap with a sector average presented with the assurance of a measurement. A complete value model exposes the price structure, the margins and the list of competitors the organisation watches: putting it through an AI service hosted outside presupposes that the confidentiality question was settled beforehand.
Examples
A Swiss health insurer adds a teleconsultation module to its app. The module sells by subscription, with a flat fee per consultation. The product team wants to know what the service returns to an insured person and what it returns to the insurer.
All values are in Swiss francs and relate to one use by an insured adult whose deductible is not yet exhausted, so that the consultation avoided would come out of their own pocket. The model counts real benefits only; the perceived benefit, the discretion of a medical opinion obtained without sitting in a waiting room, stays out of the calculation for want of a measure. The hourly rate used is CHF 40. The frequency used is four teleconsultations a year per active subscriber, and the subscription costs CHF 9.90 a month, or CHF 118.80 a year.
| Kind | Item | Amount |
|---|---|---|
| Real benefit | Consultation with a primary care physician avoided, borne by the insured person | CHF 150.00 |
| Real benefit | 2 hours off work avoided, net of the time of the teleconsultation, at CHF 40 an hour | CHF 80.00 |
| Total benefits | CHF 150.00 + CHF 80.00 | CHF 230.00 |
| Direct cost | Flat fee per teleconsultation | CHF 39.00 |
| Direct cost | Subscription of CHF 118.80 a year, amortised over 4 uses | CHF 29.70 |
| Opportunity cost | 15 minutes of waiting before being connected, at CHF 40 an hour | CHF 10.00 |
| Total costs | CHF 39.00 + CHF 29.70 + CHF 10.00 | CHF 78.70 |
| Net customer value per use | CHF 230.00 - CHF 78.70 | CHF 151.30 |
The real benefit will never exceed the CHF 230.00 the service replaces, whatever the price on display. Since CHF 10.00 of opportunity cost remains under any assumption, the maximum the insurer can take per use before the insured person is better off going back to their doctor is CHF 220.00. The insurer takes CHF 68.70 today, flat fee and amortised subscription together, about 31% of that maximum.
Frequency weighs more than price. At a single use a year, the whole CHF 118.80 subscription lands on that one use: costs rise to CHF 167.80 and net value falls to CHF 62.20. Going from one use to four returns CHF 89.10 of net value to the insured person, where taking the flat fee to zero would return CHF 39.00. What raises net value most is therefore what brings the insured person back.
Scaling up to the organisation separates revenue from value. With 5'000 active subscribers at four uses a year, the service runs at 20'000 uses annually. Aggregate net value for the insured reaches CHF 3'026'000 a year, 20'000 times CHF 151.30. The insurer's revenue comes to CHF 1'374'000 a year: CHF 780'000 of flat fees, 20'000 times CHF 39.00, and CHF 594'000 of subscriptions, 5'000 times CHF 118.80. Everything the insured person pays goes to the insurer: 20'000 times CHF 68.70 does give CHF 1'374'000.
The ratio between the two quantities is about 2.20: every franc of revenue comes with CHF 2.20 of net value kept by the insured person. It appears on no financial dashboard, where only the CHF 1'374'000 shows.
Visualisations
The Value Proposition Canvas is read across: a box in the customer profile with no counterpart in the value proposition map is an uncovered need; a box in the map with no counterpart is a feature that answers nothing.
The Value Model is judged by its middle band, which the guide gives the function of saying whether costs stay below revenues. The two bands framing it name the parties present and the value promised, without answering that question.
Cost
| Phase | Level | Rationale |
|---|---|---|
| Preparation | High | The model rests on qualitative and quantitative research: customer interviews, usage data, prices charged in the market. This is the dominant item and the source of the assumptions the Agile Extension flags as its first limitation. |
| Execution | Low | Once the research is available, setting down the equation and the chosen representation takes a half-day workshop with the product team. |
| Documentation | Medium | The model fits on one page, but its calculation assumptions have to be recorded item by item, failing which nobody will know how to recompute it six months later. |
Tooling
The spreadsheet is the tool of the model itself. One item per row, the kind, the amount and the source of the estimate in columns, the totals computed. That form makes sensitivity free: changing the hourly rate or the usage frequency recomputes everything, which a drawing does not do.
Collaborative whiteboards (Miro, Mural and their equivalents) carry the canvases. A Value Proposition Canvas template ships with them and saves losing the workshop to drawing boxes; the Value Model is built by hand, for want of a standard template.
User research tools (remote interview tools, questionnaires, analysis of the paths users take through the product) feed the customer column. Without them, the customer profile fills up with the team's convictions.
Once the value is named, it still has to be tracked over time: see metrics and key performance indicators.
Sources
- IIBA, Agile Extension to the BABOK Guide, §7.22 Value Modelling: the purpose of the technique, its other name, the equation customer value = benefits - costs, the distinction between real and perceived benefits and between direct and opportunity costs, the three construction steps, the three stakeholder groups and figure 7.22.2 on which their value objectives are read, its use at the three planning horizons, the four representations and the role it gives each, together with the two limitations stated.
- Alexander Osterwalder, Yves Pigneur, Greg Bernarda and Alan Smith, Value Proposition Design: How to Create Products and Services Customers Want, Wiley, 2014, ISBN 978-1-118-96805-5: the original publication of the Value Proposition Canvas, whose six boxes and their arrangement in two halves are taken up here.