Willingness to Pay — map the desire, commit to what to own
Economists use "willingness to pay" to mean the highest price a customer will
tolerate. That single number hides the thing that actually matters: why the
customer pays. Two companies can have the same willingness to pay and completely
different futures — one whose customers advocate for them and cheer when they
profit, and one whose customers are praying for a competitor to rescue them.
This skill separates those two companies. It maps the desire behind the price
and helps the founder commit to the one or two kinds of desire worth owning.
It answers "why do they want this, and which kind of wanting is it?" — not "what
should the price be." That distinction is the whole point, and this skill holds
it: it never sets or raises a price. It ends at a committed strategy that
other work — pricing, positioning, retention, the roadmap — then consumes.
The three kinds of desire
Desire comes in three kinds. All three make a customer pay, so an economist
treats them as the same. Strategically they could not be more different. They
rank in ascending value:
| What it is | What the customer does | Strategic value |
|---|
| Love | Buying something bigger than the product — a mission, a community, an identity, a company they root for. | Forgives weaknesses, does not comparison-shop, advocates in public, wants you to charge more and thrive. | Highest. A non-linear growth engine competitors cannot copy — advocacy grows you at no added acquisition cost. |
| Utility | A rational, functional reason. The problem is solved, the ROI is clear, the choice is safe. | Stays for logical reasons, expands usage as they grow, but will make a rational switch to something better or cheaper. | Real, but switchable. Grows existing customers; neutral-to-positive on new ones. |
| Coercion | Trapped against their will — contracts, switching costs, data lock-in, monopoly. | Pays begrudgingly, warns others away, flees the instant a viable alternative appears. | Lowest. Inorganic, temporary retention. An anti-multiplier long-term. |
The fragility test that cuts through all of it: "If a good alternative
appeared tomorrow, who leaves immediately?" The answer names your Coercion and
separates it from real loyalty. Cable customers did not comparison-shop the day
streaming arrived — they fled. That is what fake willingness looks like.
The truth this skill tells, plainly and without preaching: strong companies
often run all three at once (Apple earns Love through design, Utility through
convenience, and quietly leans on Coercion through lock-in). Examine all three
seriously. But Love is the most durable and the best thing to invest in;
Coercion is the most fragile and the worst thing to rely on. A couple of honest
coercive mechanics are fine. Building your retention on them is a warning sign.
What this skill produces
One committed willingness-to-pay strategy: the one or two Love drivers you
will authentically own, the one or two Utility attributes worth deepening, and
a clear-eyed plan for the Coercion you currently mistake for loyalty (what to
drop, and the couple of honest mechanics to keep). Recorded in a working file, in
the customer's terms, backed by evidence rather than aspiration.
That is the finish line. The order matters: you create the desire first, and only
then decide how to capture it — as advocacy, retention, and growth, or as a higher
price. This skill does the first half. What you do with a stronger Love driver —
raise the price, drive advocacy, cut churn, reprioritize the roadmap — is downstream
and out of scope (see "What this skill does NOT do").
What this skill does NOT do
State these hand-offs plainly when they come up; do not drift into them.
- It does not set or raise the price. This skill decides which desire to own.
Turning a stronger desire into a higher number — the target, the case, the moves
— is a separate task. This skill's output is an input to that work, not a
substitute for it.
- It does not pick the pricing strategy. Choosing among More-for-More /
More-for-Less / Less-for-Less, and aligning the company behind one, is the
self-consistency half of pricing and its own method. This skill is the desire
half. It may note that a strategy choice is missing and point to it, but it does
not run it.
- It does not define the ideal customer. The map is sharper when you know who
your best customer is. If you do not, that is upstream work this depends on (see
"Optional companion skills").
- It does not rewrite marketing copy. It may conclude "own the community
driver," but writing the headline that expresses it is downstream positioning
work.
Optional companion skills
Name these as helpful pointers when the moment fits; never require them. Each has
a fully-specified fallback here, so this skill works standalone.
- Grilling the commitment (Phase 3). If a devil's-advocate skill such as
Rude Q&A / is installed, invoke it with the Phase 3 brief below.
If not, run the interrogation yourself with the same posture — it is fully
specified in Phase 3.
- No ideal-customer definition. If the user cannot say who their best customer
is, they can build it with an ideal-customer method (such as the
skills) or an interview method (such as the skills), then
return. Fallback: work from the user's best plain-language description of who buys
and why, and mark any conclusion that rests on a fuzzy customer picture as
lower-confidence.
Where this output goes next. When the strategy is committed, the file becomes
an input to downstream work: a price-raising exercise can use the owned Love and
Utility drivers as the ready-made case for a higher number instead of re-deriving
them; positioning work turns the owned driver into copy; retention work replaces
the dropped Coercion with the real reason to stay. Name whichever of these the
user is heading toward; do not do that work here.
How you work: posture and pacing
Be clear, not clever
Write to be understood, not admired. These are already slippery ideas — Love and
Coercion hide behind soft words like "loyalty" and "stickiness." Say plainly what
you mean. State the point instead of gesturing wittily at it.
Facilitate — do not play oracle
This is the single most important rule in the skill, and the one it most easily
breaks. You are a facilitator, not an expert delivering verdicts. Your job is to
surface the framework's full menu and draw the answers out of the user — not to
study their business, decide the two drivers you think apply, and hand them your
conclusion. A run where you named a couple of drivers yourself and never made the
user react to the rest has failed, however smart your picks were. When in doubt,
show more of the menu and ask more of the user.
One thing per message
Open small — acknowledge the input, name the one or two things that jump out, then
start. Do not open with a wall of plans or a batch of drafts. Work one item at a
time: one segment, one proposed change, one decision per message. Propose any
merge, grouping, or skip and get agreement before acting on it. Settle a point,
write it to the file, then move to the next. A user who cannot react to your message
is being performed for, not facilitated.
The one sanctioned batch is the Phase 1 inventory menu: you present a full
palette of desire areas at once, so the user can scan the whole landscape and react
to it. Everywhere else — every proposed change, every commitment — is one item per
message.
Match your attitude to the phase, out loud
The three phases ask three different questions. Keep them separate, out loud, and
hold the line when the user jumps ahead.
- Phase 1 (map what's TRUE TODAY): honest, curious, and above all facilitative.
Draft a first read if you like, but then put it in front of the user and pull the
rest out of them: "what am I missing? what should be here that isn't? what am I
overstating?" You may have to tell the user that what they call loyalty is really
lock-in — do it gently, but do not soften it away. Guardrail: Phase 1 is only
what is true now. When the user reaches for "we could add a community," stop them
kindly: "Hold that — here we're only inventorying what's true today. We get to
what we'd change next."
- Phase 2 (what we'd do DIFFERENTLY): generous and expansive. Now the question
flips forward — of what you have, and what you could authentically build, what
would you own, deepen, or drop? Judgment is light; surface possibilities, do not
grade them yet. Say so.
- Phase 3 (validate): skeptical and strict. Say so: "Now I push back — a change
survives only if you can genuinely own it, with evidence, not wish it." Double-
check every proposed change is real, then commit.
Confirming facts about the outside world
Parts of the map rest on claims about the real world — whether customers actually
advocate for you, whether a competitor could copy a mission, what review sites
say. Where you make such a claim, confirm it with current information from your
search tools — do not rely on internal or training knowledge, which is stale and
often wrong about a specific company. If you have no search tools, ask the user to
paste the evidence and mark any conclusion that rests on unconfirmed outside facts
as low-confidence. The user's own description of who buys and why is ground truth
and needs no confirmation — but a claim of Love ("our customers love us") is
exactly the kind of thing to check against real advocacy, not accept.
When the user reports advocacy you cannot independently verify, treat it as a claim
to confirm, not a settled Love finding: record that area's Love as provisional,
name the specific evidence that would confirm it (public reviews, unprompted
referrals, defending you against a competitor), and keep it out of the committed
strategy until confirmed. Do not agonize over a numeric confidence label — "Love,
provisional — confirm with X" is enough.
The working file
First, settle where the file lives — before creating anything. If the user
already pointed you at existing files (a pricing page, a positioning doc, an
ideal-customer definition), use that same directory. Otherwise
ask where the
file should live, offering the current directory as the default. Suggest
.
Then, as soon as Phase 1 produces its first real content, actually write the file
to disk — do not merely say you will — and update it the moment each piece
settles, not at the end of a phase. The file is the memory, not the chat. Long
sessions forget and contexts get compacted; only a real, current file on disk lets
the user leave, resume, or correct the record mid-exercise.
The lists in the file are edited in place, not appended as history. When you
sharpen an item, rewrite that line. Do not keep a running log of every version.
Two rules keep a half-finished file legible to a session that resumes cold:
- Tag each item's state. In the Phase 1 inventory, mark each area ,
, , or — the map of what is true today — and
for an area you have not walked yet, so a session that resumes mid-palette can tell
"not asked" from . When an area is true for one segment but not another,
mark it and name the split in a note (" — have for agencies,
none for solo freelancers"). In the Phase 2 change list, mark a freshly surfaced
idea and one you have examined with the user . A resuming
session reads these directly instead of inferring.
- Keep a short "considered and set aside" note by default, rather than silently
deleting. One line each. This exists so a cold resume does not regenerate and
re-litigate an item the user already dismissed.
Structure:
markdown
---
phase: 1 # 1=Map what's true today, 2=What we'd do differently, 3=Validate & commit, done
status: "⚠️ IN PROGRESS — Phase 1: inventorying the Love areas with the user"
committed: false # true ONLY when the WTP strategy is locked
started: <date>
---
# Willingness to Pay — <company / product>
## Current reality (Phase 1)
### Who pays, and the segments
### Why they pay now — first read
## The desire map — what's TRUE TODAY (Phase 1)
### Love — which areas we have <!-- [have]/[partial]/[none]/[unsure]/[todo] per area -->
### Utility — which areas we have <!-- same markers; [todo] = not yet walked -->
### Coercion — what is actually operating <!-- the lock-in currently holding customers -->
### Parked for Phase 2 <!-- could-build ideas raised during inventory; also mirrored as [raw] in the Phase 2 list -->
### The fragility test — who leaves the moment a good alternative appears
### First read — where our willingness to pay actually comes from today
## What we'd do differently (Phase 2) ← a LIVING list, edited in place
### Love — to own or build <!-- [raw] / [explored] -->
### Utility — to deepen or build <!-- [raw] / [explored] -->
### Coercion — reliance to drop & replace; honest mechanics to keep
### Considered and set aside
<!-- one line per dismissed idea, so a cold resume does not regenerate it -->
## Validated & committed strategy (Phase 3)
### Love driver(s) we will own
### Utility attribute(s) we will deepen
### Coercion — what we drop, what we keep honestly
### Handoff — what consumes this next (not in this skill)
The
line records exactly where the walk stopped — name the
specific open
thread or next item, not just the phase — so a fresh session can resume from disk
alone.
The status line must also record the posture (e.g. "Phase 1 — inventory,
walking Utility areas with the user" or "Phase 2 — judgment LIGHT, awaiting reaction
to a community idea"), because nothing else on disk tells a cold-resuming session
whether it is inventorying, exploring, or ready to grill — opening in Phase 3 mode
over an ungraded list would break the skill's core rule.
stays
until the Phase 3 strategy is locked; it is the machine-readable record of the one
big state change this skill drives toward. Remove the
note only when
the exercise is finalized.
If the file already exists, read it, tell the user which phase it is in, and resume
there — never restart from Phase 1 over a map or a committed strategy already
recorded. When you resume, re-state the current posture aloud (inventory in Phase 1,
light judgment in Phase 2) before continuing, so a cold resume does not slide into
grading.
Phase 1 — Map what's true today
Goal: an honest, user-generated map of who pays today and which desires actually
operate — walked area by area across the full palette, not guessed at by you. This
is inventory, not strategy: only what is true now. The most common way this skill
fails is the wielder quietly deciding the answers itself and naming a driver or two;
your job is the opposite — surface the whole menu and pull the truth out of the user.
1a. Collect the current reality
You need two things. Accept them however the user wants to give them — a bulk paste,
a file, links to the pricing and homepage, or your questions if they would rather be
asked. If the user hands you a URL or file, read it in; work from their real
words, not a paraphrase.
- Who pays. The distinct segments who buy — and, if they differ, how each uses
the product. Which are the profitable ones. If the user has an ideal-customer
definition, bring it in; if not, note that a fuzzy customer picture weakens the
map (see "Optional companion skills").
- Why they pay — the user's first guess. In their own words, why does each
segment buy and stay? Do not correct it yet.
Reflect back what you found and write it into the file. Do not prescribe drivers to
build yet — finish the picture first.
1b. Inventory the desire, area by area, WITH the user
This is the heart of Phase 1, and the step the skill exists to force. Walk the full
palette of each kind of desire and, for every area, get the user to say whether it is
true of them today: have it, partly, don't, or not sure. Do the three kinds in
order — Love first (it is the most valuable and the most overlooked), then Utility,
then the Coercion actually operating.
How to run it so it facilitates instead of lectures:
- Show the whole menu, grouped and scannable — do not pre-filter it. Present all
the areas of Love at once (then Utility) so the user can see the full landscape and
spot what is missing. Handing the user only the two or three you guessed is the
exact failure to avoid; the value is in making them react to areas they would never
have raised.
- Draft a first read if you can, then hand it back for correction. It is fine to
pre-mark a few from what you already know ("from your site, Design and Community
look like have"). But immediately put it to the user: "That's my first pass —
what am I missing? What should be on here that isn't? What am I overstating that
really isn't true?" The user's edits are the point, not your draft.
- Mark each area / / / and write it to
the file as you go. A quick "no, not us" is a complete answer; move on. Dwell
only where the user says have/partial — get the specific evidence ("you said you
have Community — where does it live, who's in it, what do they do there?"), because
a claimed area with nothing behind it is not a have.
- Hold the line to today. If the user says "we don't have a mission but we
could," welcome it and park it: "Good — that's a Phase 2 move. Right now I'm only
marking what's already true." Record it right away as a line in the Phase 2
change list, tagged "(parked in P1)", so it is waiting there when the question flips
— then keep inventorying.
The palette of Love areas — read all of these to the user:
- Mission — supporting a change bigger than the product; a movement customers
want to see win.
- Community — a place members belong, learn, teach, and help each other.
- Reciprocity — you give before you take, or give more than you take.
- Transparency — openness about the ups and downs, even the embarrassing ones.
- Design — a pleasure to use, made by a team that visibly sweats the craft.
- Quality — the relief and pleasure of reliability.
- Personality — customers use your brand to express their own identity.
- Culture — supporting an organization that treats its people and vendors well.
- Ecosystem — belonging pays: members earn more money or standing inside the
group than outside it.
- Authenticity — the genuineness is itself the draw, not a performed mission.
The palette of Utility areas — read all of these to the user:
- Unique — a capability no competitor has that customers need.
- Quality — a seamless, flawless experience.
- Simplicity — surprising ease, itself valuable.
- Integrations — works with what they already run (and raises switching cost).
- Convenience — saves effort worth paying to avoid.
- Training — once staff are trained, switching is costly.
- System-of-record — critical data lives here; risky to move.
- Risk-reduction — lowers the chance something breaks.
- Familiarity — a paradigm they already know.
- Market-leader — the safe, nobody-gets-blamed choice.
- Onboarding — an easy start correlates with higher willingness to pay.
- Location — you are already present where the customer works.
- Cheap — a low price is its own reason to buy.
(Quality appears in both palettes on purpose — as Love it is the relief of
reliability that earns devotion; as Utility it is a flawless experience the buyer
rationally pays for. Mark it in each place; it is not a duplicate to delete.)
Then the
Coercion actually operating — not a wish list, what is genuinely holding
customers against their will today. Its forms: contractual lock-in, data you will not
let them export, switching costs, an effective monopoly, price-fixing, bundle-
stuffing, raising the price only once they are at scale, corporate policy, legal
fiat. Some Utility areas double as mild Coercion — integrations, training, and
system-of-record all raise switching cost — so where the user marked those
,
ask honestly whether they are a real reason to stay, a trap, or both.
1c. Run the fragility test
With the inventory down, run the single most clarifying question in the method, on
the whole base:
"If a good alternative appeared tomorrow, who leaves immediately?"
Whoever leaves was held by Coercion, whatever you were calling it. Name them. Do not
let "they're locked into a contract" pass as "they're loyal." This is what separates
a real
in Love from Utility-plus-lock-in wearing its costume.
Name where your willingness to pay actually comes from today. The common,
uncomfortable finding: "You thought you had loyal customers; you have a useful
product plus switching costs, and the moment Linear-for-your-market ships, a third of
them are gone." State it plainly and write it to the file. That honest baseline is
exactly what Phase 2 works to change.
Gate to Phase 2: the full palette is inventoried with the user (every area
marked, the live ones evidenced), the fragility test is answered, and the file names
where today's willingness to pay really comes from. The question now flips forward:
what would we do differently?
Phase 2 — What we'd do differently
Goal: a generous set of changes — which desire to own, deepen, or build, and which
Coercion to drop — working from the Phase 1 inventory. Now the question flips from
"what is true" to "what would we do differently," so judgment is light. Announce it:
"We inventoried what's true today. Now we go forward: given that, what would we
build, deepen, or drop? I'll surface possibilities; nothing is committed here." Do
not grade yet; grading now kills the idea you want.
Two sources feed the change list, and you should draw from both:
- Deepen a or . The strongest candidates are usually areas
the inventory already marked true — an existing Community you could invest in, a
Utility you could sharpen. These are ownable because they already exist.
- Build a you could authentically earn. A missing area is fair game if
the business could genuinely earn it — genuineness is the gate, because an
inauthentic mission or community invites backlash (as Skechers found when it copied
TOMS). This is where the "we could add X" notes you parked in Phase 1 come back in.
Go one idea at a time: propose, let the user react, tag
when freshly surfaced
and
once examined together. Point at specific inventory findings ("you
marked Community
partial and it has real people in it — that's the obvious one to
own"). You do not need to re-read the full palette — Phase 1 already walked it; here
you work from what it surfaced plus the authentic could-builds.
Frame every change by the value the customer measures, not the cost it removes.
This is where the biggest gains hide. The same capability described as "save money"
versus "grow your revenue / leads / pipeline" can carry several times the willingness
to pay, because customers value growth far above savings. So phrase a driver in the
customer's own success metric — "generates $40,000 in additional leads a month," not
"cuts your cost per lead." Do this as part of how you describe the change; it is a
framing discipline, not a separate step. (Some Love drivers benefit too — "join a
community that makes you more money" beats "join our forum.")
One caution on Cheap. If the inventory marked Cheap a real
, do not turn
"deepen Cheap" into a change here. Leaning into low price as the reason to buy is a
pricing-strategy choice (the "Less for Less" path), which belongs to the strategy
method, not this skill. Note it and hand it off; do not turn this exercise into a
race to the bottom.
The Coercion you rely on is a change target, not an asset. For each place the
fragility test showed retention resting on a contract, switching costs, trapped data,
or a lack of alternatives, the forward move is to build a Love or Utility reason to
stay in its place (the T-Mobile "Un-carrier" reversal: they dropped the contracts
and the termination fees and won the market by earning loyalty instead of enforcing
it). Know the stakes even in cold profit terms: of two identical companies, one held
by Love and one by Coercion, the Love company is the better investment — its
customers grow it for free while the coerced company's customers lobby to leave. So
the anti-Coercion case does not rest on ethics; it is the smarter bet. Record two
things: the reliance you'll aim to drop and replace, and the couple of honest
mechanics you'll keep (a positive bundle discount, an annual commitment the
customer chooses for a real benefit — legitimate, entered into with eyes open; do not
moralize those away).
Gate to Phase 3: there is a set of proposed changes the user recognizes as "what
we'd do differently," plus the Coercion drop/keep list. Now warn them the mode is
about to change.
Phase 3 — Validate and commit
Goal: double-check every change proposed in Phase 2 is real, narrow to a committed
strategy — the one or two Love drivers you will own, the one or two Utility attributes
you will deepen, and the Coercion plan — and lock it in. Announce the switch:
"Now we change gears. In Phase 2 I accepted every idea; here I push back on each one,
and most will not make the final cut — that's the point. A strategy is what you say no
to."
The bar: can you genuinely OWN it?
Willingness to pay is not built by claiming a driver — it is built by being it,
credibly and consistently. So the test for a surviving change is ownership, not
appeal. Apply it to every Love and Utility candidate:
Can you own this — for real, better than the alternatives, consistent with what
you already do — such that a customer would feel it? Or are you wishing it were
true?
The four questions behind that bar:
- Is it already true, or credibly buildable? Where is the evidence you have this
driver, or a concrete path to it? Strike "we could seem more…". A Love driver
especially must be genuine; a performed one backfires.
- Is it self-consistent with the rest of you? Does the driver fit your product,
your price, your other signals — or does it fight them? (A "premium design" Love
claim on a product that ships buggy is not self-consistent; customers feel the
contradiction and none of it lands.)
- Can few competitors copy it? Love drivers resist copying because inauthentic
imitation invites backlash; a Utility driver may be more easily matched. The
harder to copy, the more durable the willingness to pay.
- Is it worth concentrating on? You are choosing one or two to own, not ten to
dabble in. A driver you will pursue at only half-effort is not a commitment.
Concentrate. The finish line is one or two Love drivers and one or two Utility
attributes — not a long even list. Owning one driver to an extreme beats being
slightly-above-average at six. Force the choice; do not let the user keep everything.
The interrogation
If a devil's-advocate skill such as
Rude Q&A /
is installed, invoke
it with this brief:
"Grill each proposed willingness-to-pay change. For each, attack
whether the company genuinely OWNS it or is merely wishing: is there evidence it is
already true or a credible path to it; is it self-consistent with the product, price,
and other signals; can competitors copy it; and is it worth concentrating on versus
the alternatives? Be especially hard on Love claims — an assumed 'our customers love
us' with no advocacy behind it is the classic self-flattering error. Force the company
down to one or two Love drivers and one or two Utility attributes. Do not let them keep
everything." If it is
not installed, run the interrogation yourself with the same
posture: sharp, specific, unfair-if-useful questions with a collegial frame. Attack
the
claim, not the person. Use the Opposite Test — if the opposite of a claim is
obvious nonsense, the claim said nothing ("customers want quality" — nobody wants low
quality, so it is empty). Do not accept "it depends" or "we'll figure that out later."
Dwell when the answer is fuzzy; move on when it earns it. Stay on one change until
it is genuinely defended, honestly cut, or moved to "considered and set aside." Three
rounds on one driver is not a reason to wave it through.
Settle the Coercion plan
From the Phase 2 findings, commit to: which coercion reliance you will drop (and
the Love/Utility reason to stay you will build in its place), and which honest
mechanics you will keep. Be concrete. "Stop holding data hostage; ship an export
and win the stay on Utility instead" is a commitment; "be less coercive" is not.
Lock it in
When the strategy is settled, confirm it explicitly with the user — this is the one
big state change the skill drives toward. Write the owned Love driver(s), the Utility
attribute(s) to deepen, and the Coercion plan into the "Validated & committed strategy"
section, set
, advance
to
, and remove the
note. It does not matter
how many drivers survive — one strong, genuinely
owned Love driver is an excellent result. What matters is that each is real, ownable,
self-consistent, and worth concentrating on.
Then write the handoff — the work that comes after this skill and is not part of
it. Name whichever the user is heading toward: turning the owned drivers into the case
for a higher price (a separate price-raising exercise), turning a driver into marketing
copy (positioning), or replacing dropped Coercion with the real reason to stay
(retention and roadmap). This file is the input to that work; it is not that work.
Refusal and edge conditions
- No real customers yet. With no paying base to audit, the Phase 1 inventory is
thin — you will have few real s. Say so, keep it light, and let the weight
fall on Phase 2, where the question becomes which desire to build toward, while
flagging that every read is a hypothesis until real customers confirm it. Two
adjustments follow. The fragility test has no base to run against — do not force it;
ask it as a thought experiment about the customers you intend to win, and mark the
answer hypothetical. And the Phase 3 ownership bar softens from "where is the
evidence" to "is there a credible path," since you are committing which desire to
build. Say so plainly.
- "Just tell me what to charge." This skill does not set or raise the price. Map
the desire and commit the strategy; hand the pricing decision off as the next task
rather than guessing a number.
- "Our customers love us" with nothing behind it. This is the most common
self-flattering error and the reason the fragility test exists. Do not accept a
claim of Love without advocacy evidence; if it is really Utility propped up by
switching costs, say so — gently, but say it.
- The user wants validation, not scrutiny. In Phase 3 especially, if the user is
seeking a rubber stamp for a driver they cannot actually own, name that and hold the
bar. The value of this phase is the friction.