# Case Studies: Monetizing Innovation in Practice

## Table of Contents

- [Case Study 1: From Flat Rate to Value Tiers](#case-study-1-from-flat-rate-to-value-tiers)
- [Case Study 2: Catching Feature Shock Before Launch](#case-study-2-catching-feature-shock-before-launch)
- [Case Study 3: Fixing Freemium with a Leader Paywall](#case-study-3-fixing-freemium-with-a-leader-paywall)
- [Key Takeaways](#key-takeaways)

## Case Study 1: From Flat Rate to Value Tiers

### Context

A 14-person B2B SaaS company sells project-profitability analytics to creative and consulting firms. One price: $99/month per workspace, unlimited everything. 640 paying customers, $760K ARR, growth slowing.

### The Problems

**Sales were suspiciously easy.** Win rate against the only real competitor was 84%. Prospects rarely questioned the price; several closed-won notes contained variations of "this is a no-brainer at this price." Nobody treated this as a symptom.

**Wildly different customers paid identical money.** A 3-person studio tracking five projects paid $99. A 70-person consultancy running 400 projects through the API, with finance exporting to their ERP weekly, paid $99. Support time for the consultancy was 20x the studio's.

**ARPU was frozen.** The only growth lever was new logos. Expansion revenue was structurally zero — there was nothing to expand into.

### The Intervention

**Step 1: WTP interviews (weeks 1-4).** The founders ran 22 interviews across the base — 8 small studios, 8 mid-size agencies, 6 large consultancies — using the three-point probe and feature point-allocation. Two excerpts from the script:

> "Setting our current price aside completely — for what this does for your firm today, what would feel like an acceptable price? What would feel expensive but still worth it? Where does it become out of the question?"

> "You have 100 points. Spread them across these twelve capabilities in proportion to their value to you."

**Step 2: Read the curve.** The answers clustered into three populations, not one:

| Cluster | Acceptable | Expensive | Prohibitive | Top-valued capabilities |
|---------|-----------|-----------|-------------|------------------------|
| Studios (1-10 staff) | $40-60 | $90-120 | $150+ | Core dashboards, time import |
| Agencies (11-50) | $120-180 | $250-300 | $400+ | Approval workflows, client reporting, integrations |
| Consultancies (50+) | $350-500 | $700-900 | $1,200+ | API, SSO, ERP export, permissions |

The flat $99 sat above the studios' comfort zone and at roughly one quarter of the consultancies' acceptable price — minivation at the top, mild overpricing at the bottom, in the same number.

**Step 3: Leader/filler/killer per segment.** Client-branded reporting was a leader for agencies, invisible to studios. The API was a consultancy leader and a studio killer when bundled into price expectations ("we'd never use it — feels like we're paying for plumbing"). Onboarding services (mandatory at the time, baked into pricing assumptions) tested as a killer for everyone when framed as paid-and-required.

**Step 4: Tier design.** Studio $59 (dashboards, time import, 3 seats), Agency $199 (workflows, client reporting, integrations, 15 seats), Firm $549 (API, SSO, ERP export, unlimited seats, priority support). Onboarding became optional and paid. The pricing page ordered tiers Firm-first as the anchor; Agency carried the "Most popular" badge, which the cohort data later justified.

**Step 5: Migration.** Existing customers were grandfathered at $99 for 12 months, with an opt-in offer: switch early and lock the new tier at 20% off for a year. New signups saw only the new tiers. The announcement led with two years of shipped features before mentioning numbers.

### Results After Two Quarters

| Metric | Before | After |
|--------|--------|-------|
| ARPU (new customers) | $99 | $214 |
| Win rate | 84% | 71% |
| New-customer revenue per quarter | baseline | +63% |
| Expansion revenue | $0 | 9% of ARR (tier upgrades) |
| Logo churn (existing base) | 1.7%/mo | 1.9%/mo, settling to 1.6% |
| Support load per account (top tier) | unpriced | covered by Firm margin |

### Lessons Learned

1. **An 84% win rate was the loudest data point in the company, and nobody was listening.** Frictionless sales is a pricing symptom before it is a sales achievement.
2. **One number cannot serve a bimodal market.** The flat price was simultaneously too high and absurdly low — only segmentation exposed that both were true.
3. **Grandfathering bought the right to reprice.** The feared exodus never happened; churn moved 0.2 points and recovered.
4. **The win-rate drop was the plan working.** Losing more price-sensitive deals at $214 ARPU beat winning everything at $99.

## Case Study 2: Catching Feature Shock Before Launch

### Context

A seed-stage startup (9 people, 14 months of runway) is six weeks from launching an AI meeting assistant for sales teams. The spec has grown to seven modules: transcription, action-item extraction, CRM sync, deal-risk scoring, coaching scorecards, conversation analytics dashboards, and a manager digest. Target price: $45/seat to support the surface area. A board member asks one question: "What's the willingness-to-pay evidence?" There is none.

### The Problems

**The pitch had stopped fitting in a sentence.** Each module had a constituency inside the company; no two demos followed the same path; the deck described the product as "an AI revenue intelligence platform," which described nothing.

**Price was cost-derived.** $45/seat came from working backward from burn and headcount, not forward from value.

**Engineering was six weeks from shipping the hardest 40%** — the analytics dashboards and risk scoring consumed most of the remaining timeline and all of the model-hosting budget.

### The Intervention

**Step 1: Three-week WTP sprint.** 19 interviews with sales managers and RevOps leads (the economic buyers), run on concept cards — one card per module, then bundle questions. Methods: top-5 decision ranking, 100-point allocation, purchase-probability at $25/$45/$65 per seat.

**Step 2: The curve came back flat.** Purchase-probability top-box at $45 was nearly identical for "transcription + action items + CRM sync" (3 modules) and the full 7-module platform — 32% vs 35%. Four modules added cost, complexity, and weeks of timeline for three points of stated intent. Point allocation told the same story: transcription, action items, and CRM sync absorbed 71 of 100 points on average. Coaching scorecards polarized: managers allocated points; reps' organizations saw surveillance — a killer pattern for bottom-up adoption.

**Step 3: Classify and cut.** Leaders: transcription quality, action-item extraction, CRM sync. Fillers: manager digest, conversation analytics (v1). Killer (for the land motion): coaching scorecards. Deal-risk scoring: insufficient evidence either way — deferred. The launch spec dropped from seven modules to three plus a digest email.

**Step 4: Reprice the focused product.** With the WTP probes putting acceptable at $18-25 and expensive at $40-50 for the three-leader bundle, launch pricing landed at $24/seat (Team) with a $49/seat tier (Business: SSO, advanced CRM mappings, priority support) as anchor and enterprise home. The cost model also shrank: cutting the dashboards halved inference and storage spend per account.

**Step 5: Re-spec the roadmap behind evidence gates.** Coaching and risk scoring moved to a "build when 10 paying customers rank it top-3" rule — a standing WTP gate instead of a backlog debate.

### Results

| Metric | Original plan | Actual launch |
|--------|--------------|---------------|
| Modules at launch | 7 | 3 (+ digest) |
| Launch date | 6 weeks out (at risk) | Shipped 2 weeks early |
| Price | $45/seat, single plan | $24 / $49 two-tier |
| Trial → paid (first 90 days) | — (projected 8%) | 19% |
| Infra cost per account | $11/seat/mo | $4.10/seat/mo |
| Sales demo length | 40 min | 14 min |

Eight months later, deal-risk scoring cleared its evidence gate (12 customers ranked it top-3) and shipped into the Business tier — as an upgrade driver rather than launch ballast.

### Lessons Learned

1. **Feature shock is diagnosable before launch:** a flat WTP curve while scope grows is the signature. Three weeks of interviews saved six weeks of building and a mispriced launch.
2. **Cutting reduced the price and raised the margin simultaneously** — the cost structure of feature shock is part of the trap.
3. **A killer can hide in a feature the buyer loves:** managers wanted scorecards; the users who drive adoption feared them. Per-constituency classification caught it.
4. **Evidence gates ended the loudest-voice roadmap.** "Ten paying customers rank it top-3" is a rule everyone can lose to gracefully.

## Case Study 3: Fixing Freemium with a Leader Paywall

### Context

A collaborative moodboard and asset-review tool for design teams: 380,000 registered users, strong word-of-mouth growth, and a free-to-paid conversion rate of 1.1% that has not moved in a year. Free tier: unlimited boards, unlimited collaborators, full review tooling. Pro ($12/user/month): version history, brand-kit storage, priority support. The company raised on growth; the board now asks about revenue.

### The Problems

**Free contained the leader.** Interviews and support data showed the product's purchase-driving value was running structured client reviews on shared boards — fully available free. Pro's fence was made of fillers: version history was rated "nice"; brand kits served a minority.

**Heavy users had no reason to pay.** Agencies ran 30-board client workflows on the free tier. The "upgrade" page's top feature, version history, had been opened by 7% of free users — people do not pay for what they never reach for.

**The team feared touching free.** Unlimited-everything free was credited (correctly) for viral growth; any proposal to restrict it died as "killing the growth engine."

### The Intervention

**Step 1: Find the habit point in usage data.** Cohort analysis split free users by peak active boards. Users who reached 4+ active boards retained at 68% after six months and accounted for nearly all referral invitations; users at 1-3 boards retained at 22%. Four boards was where the tool stopped being a toy and became a workflow.

**Step 2: WTP research on actual value, not feature lists.** 250 survey responses from active free teams (three-point probe plus point allocation) and 12 interviews with agencies. Result: WTP concentrated on "running multiple client projects" ($10-18/user acceptable among agencies) — board capacity, not version history, was the leader. Collaborators and review tooling tested as the viral loop: gating them would tax the invitations that drove acquisition.

**Step 3: Move the fence to the leader, protect the loop.** New free tier: 3 active boards (archive anytime), unlimited collaborators, full review tooling — the viral surface untouched. Pro at $14: unlimited active boards, version history, brand kits. The paywall now sat exactly at the habit point: the fourth board, the moment a team was provably committed.

**Step 4: Migration with dignity.** Existing free users over the limit kept all boards editable for 90 days (clearly communicated), then boards beyond three became read-only — never deleted, always exportable. The in-product prompt at the limit said what the user was doing, not what they were missing: "This would be your 4th active board — that's where teams go Pro."

**Step 5: Pre-agreed launch triggers.** Before shipping, the team wrote thresholds: if weekly signups fell >15% for four consecutive weeks, or paid conversion failed to reach 2% by day 60, specific rollback and adjustment steps would execute. Nobody would be deciding policy at midnight from a panicked dashboard.

### Results After 90 Days

| Metric | Before | After |
|--------|--------|-------|
| Free → paid conversion | 1.1% | 3.9% |
| Weekly signups | baseline | −6% (within tolerance, recovered by week 9) |
| MRR | baseline | +212% |
| Referral invitations per active user | baseline | unchanged |
| Free-user support tickets | baseline | −18% (smaller active free surface) |
| Churn of new Pro cohort (monthly) | — | 2.3% |

### Lessons Learned

1. **Freemium fails when generosity and strategy are confused.** The free tier had been designed by enthusiasm; redesigning it as engineered acquisition (loop free, leader fenced) fixed conversion without breaking growth.
2. **Usage data found the fence; WTP research justified the price.** Neither alone was sufficient — the habit point said *where*, the interviews said *how much*.
3. **Gate the leader, never the viral loop.** Unlimited collaborators looked like the obvious thing to monetize and would have been the most expensive mistake available.
4. **Pre-agreed triggers kept the team from panic-reverting** during the week-3 signup dip that later self-corrected.

## Key Takeaways

**1. The diagnosis is in data you already have.** An 84% win rate, a flat WTP curve across growing scope, a 1.1% conversion with the leader given away — each company was sitting on its own answer before the first interview.

**2. WTP research changes the product, not just the price.** Case 2 cut four modules; case 3 redrew the free tier; case 1 unbundled onboarding. The price tag was the last thing to change in every story.

**3. Segments make contradictory signals coherent.** "Too expensive" and "comically cheap" arriving in the same week is not noise — it is two segments describing one mispriced product.

**4. Repricing is survivable when communication leads with value and migration preserves dignity.** Grandfathering, read-only (never deleted) data, and value-first announcements turned feared revolts into footnotes.

**5. Decide reactions before launch.** Both launches that could have triggered panic (cases 1 and 3) had pre-agreed thresholds — so temporary dips were monitored instead of "fixed" with permanent discounts.

# Diagnosing the Four Monetization Failures

## Table of Contents

- [The Four Failures at a Glance](#the-four-failures-at-a-glance)
- [Feature Shock](#feature-shock)
- [Minivation](#minivation)
- [Hidden Gem](#hidden-gem)
- [Undead](#undead)
- [The Classification Decision Tree](#the-classification-decision-tree)
- [Running a Failure Review](#running-a-failure-review)

## The Four Failures at a Glance

When a new product misses its revenue targets, the post-mortem almost always lands in one of four patterns. Learn to recognize them early — each has a distinct symptom signature, a distinct root cause, and a distinct countermeasure. Applying the wrong cure makes things worse: discounting a feature-shocked product deepens the loss; adding features to an undead product feeds the zombie.

| Failure | One-line definition | Cure direction |
|---------|--------------------|----------------|
| **Feature shock** | Too much crammed into one product; complexity and cost destroy value | Cut |
| **Minivation** | Right product, priced too timidly; money left on the table | Raise |
| **Hidden gem** | Game-changing product the organization never recognizes or monetizes | Give it an owner, price it |
| **Undead** | Product nobody wants, kept alive past the evidence | Kill |

## Feature Shock

**Definition.** The team, trying to please everyone, packs the product with everything it can build. The result is overengineered, overpriced for the value any single buyer perceives, hard to explain, and expensive to maintain. Amazon's Fire Phone is the canonical case: loaded with novel features (dynamic 3D perspective, object recognition) that testers admired and would not pay for, launched high, cut to 99 cents within months, written off within a year.

**Symptoms checklist:**

- [ ] The elevator pitch takes more than two sentences, or differs by who you ask
- [ ] WTP stays flat in research while the feature list grows — each addition raises cost, not value
- [ ] Sales demos run long and follow different paths for every prospect
- [ ] Usage data (or beta feedback) shows most features touched by under 20% of users
- [ ] Price had to be set high to cover build cost, not because value supports it
- [ ] Buyers say "it does a lot" but cannot name the one reason to buy
- [ ] Roadmap decisions are additive by default; nothing has been cut in recent memory

**Root causes:** No segmentation (building the union of all segments' wishes); engineering pride ("we can, so we should"); consensus product councils where every stakeholder's feature survives; fear of saying no to any prospect; WTP never measured per feature.

**Countermeasures:**

1. Run leader/filler/killer analysis on the full feature list; cut or unbundle everything that is not a leader for the chosen segment
2. Re-anchor the spec on one segment's must-haves; move other segments' leaders to higher tiers or later releases
3. Reset the price to the value of the focused product — often lower sticker, higher margin, faster sales cycle
4. Institute a "one in, one out" roadmap rule until the value story fits in one sentence

**Mini example.** A 12-person startup builds an "all-in-one revenue platform": CRM, email sequences, dialer, proposals, analytics, forecasting. Target price $120/seat to cover the surface area. WTP interviews show prospects valuing exactly one module deeply (sequences, ~$40-60/seat) and rating the rest "nice." The fix: ship sequences as the product at $49, archive four modules, move analytics to a higher tier. Sales cycle drops from 45 to 12 days; the company survives.

## Minivation

**Definition.** A genuine innovation reaches the market priced like an incremental improvement — typically anchored on the previous product's price, cost-plus arithmetic, or sheer fear. The product hits unit targets, everyone celebrates, and nobody audits the money left on the table. Minivation is the quietest failure: it looks like success.

**Symptoms checklist:**

- [ ] Win rates near 100% and deals closing with zero price pushback
- [ ] Customers volunteer that the product is "a steal," "a no-brainer," "so cheap"
- [ ] Price was set as previous product +10%, or cost × target margin, with no WTP input
- [ ] Sell-outs, waitlists, or capacity limits at launch (demand far exceeding the price signal)
- [ ] Sales discounts the list price out of habit and still never loses on price
- [ ] WTP research (if any) showed a ceiling far above list, and was dismissed as unreliable

**Root causes:** Internal anchoring on old prices; cost-plus tradition; volume-maximizing incentives ("we're paid on units"); fear that a high price invites competitors or press criticism; nobody owning the question "what is it worth?"

**Countermeasures:**

1. Re-run the three-point price probe with current customers and lost prospects; map list price against the acceptable-expensive-prohibitive range
2. Raise list for new customers first (existing customers can follow with notice, or be grandfathered)
3. Add a premium tier above the current top — the fastest minivation fix, because it requires no repricing of anyone
4. Change the incentive: report revenue and margin per unit alongside unit volume
5. If raising feels impossible, capture value elsewhere: tighter packaging, paid add-ons, usage-based upside

**Mini example.** A developer-tools company prices its new CI product at $9/user to "land and expand," anchored on its $7 legacy linter. Win rate is 92%; churn near zero; users call it "comically cheap" in reviews. Interviews put acceptable at $25 and expensive at $50. The company adds a $39 tier with SSO, audit logs, and priority runners, repositions $9 as the solo tier, and lifts ARPU 2.8x in two quarters without measurable churn.

## Hidden Gem

**Definition.** Something genuinely valuable exists inside the company — a byproduct, an internal tool, a side capability — but it does not fit the core business's mental model, so nobody prices it, packages it, or sells it. Kodak inventing the digital camera in 1975 and shelving it to protect film is the textbook case. Hidden gems fail by neglect, not rejection.

**Symptoms checklist:**

- [ ] Customers keep asking to buy something you give away or use internally ("can we get access to that?")
- [ ] An internal tool would be a competitor to a funded startup if it were a company
- [ ] The capability has no P&L, no owner, no roadmap — it is "infrastructure"
- [ ] Business development conversations stall because nobody can quote a price
- [ ] The idea threatens an existing revenue line, so evaluations keep getting deferred
- [ ] Data, audience, or distribution accumulates as a side effect of the core business with no monetization review

**Root causes:** Organizational identity ("we are a hardware company, not software"); cannibalization fear; no process for monetizing byproducts; gems sit in cost centers where success is measured in uptime, not revenue.

**Countermeasures:**

1. Inventory candidates annually: internal tools, APIs, datasets, audiences, expertise that outsiders ask about
2. Appoint a single monetization owner per gem with a deadline for a priced pilot — gems die in committees
3. Run the standard WTP process on the gem as if it were a startup concept: interviews, three-point probe, pilot offer
4. Ring-fence it from the core P&L if cannibalization politics block it — separate team, separate targets
5. Decide deliberately: productize, license, spin out, or consciously keep internal. Any of these beats drift

**Mini example.** A logistics SaaS builds an internal address-validation service to clean its own data. Three customers ask if they can call it directly. Treated as a distraction for a year, it finally gets one engineer and a pricing sprint: WTP interviews with eight customers put value at $0.004-0.01 per lookup. Launched as a metered API at $0.006, it reaches 18% of company revenue in 18 months — at software-API margins.

## Undead

**Definition.** A product that should never have shipped — or should have been killed mid-development — walks the earth because of sunk cost, executive sponsorship, or motivated interpretation of bad research. Either nobody wants the problem solved, or nobody wants this solution, or nobody will pay anywhere near what it costs. Segway is the famous shape: genuine engineering marvel, priced and positioned for a mass market that did not exist.

**Symptoms checklist:**

- [ ] WTP research came back bad and was explained away ("respondents didn't understand the vision")
- [ ] The target customer cannot be named specifically — "everyone" or "SMBs" is the answer
- [ ] Pilots convert to paid at near zero, attributed to pilot execution rather than demand
- [ ] The business case survives only with heroic assumptions (adoption rates, virality, "1% of a huge market")
- [ ] The project's strongest argument is what has already been spent on it
- [ ] Each missed milestone produces a pivot in story but not in evidence

**Root causes:** Sunk-cost reasoning; senior sponsorship that makes killing career-risky; research done to confirm rather than test; roadmap momentum (the launch date became the goal).

**Countermeasures:**

1. Set kill criteria *before* the next checkpoint: "If fewer than N of 20 target buyers rate purchase probability 5 at $X, we stop." Agree on them while everyone is still calm
2. Re-run WTP research with someone outside the project leading it
3. Honor the criteria publicly when triggered — the cultural payoff (people trust research again) outlasts the product
4. Salvage parts: an undead product sometimes contains a hidden gem (a component, a dataset) worth extracting before burial

**Mini example.** A B2B startup spends 14 months on an AI meeting-cost dashboard ("see what every meeting costs!"). Demos get laughs and press; trials get logins for a week, then silence; three pricing changes do nothing. The team finally runs 20 buyer interviews: purchase probability 5 at any price ≥ $0: one respondent. The product is killed; the calendar-integration layer is salvaged into the company's core scheduling product, where it becomes a leader feature.

## The Classification Decision Tree

Use this when a product (shipped or pre-launch) is underperforming and you need to name the failure before choosing a cure:

```
START: Product missing targets (or WTP research looks worrying)
│
1. Is there validated demand at ANY workable price?
   (Real buyers, purchase-probability 5s, paying pilots — not applause)
│
├── NO → UNDEAD.
│        Set/check kill criteria. Kill or pivot. Salvage components.
│
└── YES ↓
2. Are people buying readily, with little price resistance,
   high win rates, "so cheap" remarks?
│
├── YES → MINIVATION.
│         Probe the WTP ceiling. Raise list, add premium tier,
│         or capture upside via metric/packaging.
│
└── NO ↓
3. Is the offer broad/complex — long demos, flat WTP per added
   feature, most features unused, price driven by build cost?
│
├── YES → FEATURE SHOCK.
│         Leader/filler/killer the feature list. Cut to one
│         segment's leaders. Reprice the focused product.
│
└── NO ↓
4. Is the value real but unowned — no P&L, no price, customers
   asking to buy something you don't sell?
│
├── YES → HIDDEN GEM.
│         Appoint an owner. Run WTP as if it were a startup.
│         Productize, license, spin out — or decide not to, on purpose.
│
└── NO → Not a monetization design failure.
         Look at execution: awareness, channel, sales motion,
         onboarding. Hold price steady while you diagnose.
```

Two failures can coexist: a feature-shocked flagship often hides a gem (one module customers would buy alone), and minivation frequently follows feature shock once panic discounting starts. Classify the dominant pattern first, cure it, then re-run the tree.

## Running a Failure Review

A 60-minute quarterly review keeps the portfolio honest:

1. **Prepare (before the meeting):** For each product or major feature area, pull win rate, discount depth, feature usage distribution, churn reasons, and the latest WTP evidence with its date. Stale WTP (>12 months in a moving market) counts as no evidence.
2. **Classify (20 min):** Run each underperformer through the decision tree. Write the classification down — naming "this is minivation" changes the conversation more than any chart.
3. **Assign cures (20 min):** One owner and one dated action per classification: a cut list, a price test, a gem pilot, a kill checkpoint with criteria.
4. **Pre-commit (10 min):** For anything new launching next quarter, agree now on the day-30/60/90 metrics and the thresholds that will trigger action — so the launch team monitors instead of panicking.
5. **Check last quarter's calls (10 min):** Were the cures applied? Did the classification hold? Teams that skip this step re-diagnose the same product forever.

The discipline to keep: every diagnosis must point to evidence a skeptic could check — WTP data, win rates, usage. "I feel like it's priced too low" is a hypothesis, not a classification.

# Choosing the Monetization Model

## Table of Contents

- [The Model Is a Design Decision](#the-model-is-a-design-decision)
- [Choosing the Price Metric](#choosing-the-price-metric)
- [Subscription](#subscription)
- [Usage-Based](#usage-based)
- [Hybrid: Base Plus Usage](#hybrid-base-plus-usage)
- [Freemium](#freemium)
- [Dynamic Pricing](#dynamic-pricing)
- [Outcome-Based Pricing](#outcome-based-pricing)
- [Migrating Between Models](#migrating-between-models)
- [Model Selection Checklist](#model-selection-checklist)

## The Model Is a Design Decision

*How* you charge is a bigger lever than *how much*. The monetization model decides who carries the risk (you or the customer), when cash flows, how revenue scales with customer success, and how the purchase feels. The same product at the same effective price can thrive as a metered API and die as a flat subscription — or vice versa — because the model either matches or fights the customer's consumption pattern and budget reality.

Choose the model with the same evidence used for price levels: ask in WTP interviews not just "what would you pay?" but "how would you want to pay for this?" and "what would make this an easy line item in your budget?" Buyers have strong, articulate opinions about models — often stronger than about levels.

## Choosing the Price Metric

The price metric is the unit you charge for: per seat, per active user, per gigabyte, per transaction, per 1,000 API calls, per order shipped, per hire made. It is chosen before the price level, because it defines what "expensive" even means. Michelin charging fleets per kilometer driven instead of per tire is the classic move: the metric jumped from the product to the value.

Score candidate metrics against five tests:

| Test | Question | Example failure |
|------|----------|----------------|
| **Value tracking** | Does the metric rise when the customer gets more value? | Per-seat pricing for a dashboard only two people log into |
| **Predictability** | Can the customer forecast their bill? | Per-event pricing where events spike unpredictably |
| **Acceptance** | Does the metric feel fair and familiar to the buyer? | Charging per "workflow execution" nobody can define |
| **Measurability** | Can both sides audit it cheaply and unambiguously? | "Per insight delivered" |
| **Incentive alignment** | Does the metric punish behavior you want? | Per-seat pricing taxing the collaboration that drives retention |

Most metric mistakes fail test 1 or 5: revenue decouples from delivered value, or the metric makes customers ration exactly the usage that would make them stick. When two metrics tie, pick the one the customer's budget already speaks (procurement approves "per seat" without a meeting; "per inference-second" needs a committee).

## Subscription

Recurring flat fee per period, usually per seat or per tier.

**When it wins:** Value is delivered continuously (always-on tooling, storage, monitoring); usage is steady; customers value budget predictability; you value forecastable ARR (and investors price it accordingly).

**Failure modes:**

- Value-usage mismatch: heavy users are subsidized by light users, and light users churn ("we barely used it")
- Per-seat taxing collaboration: teams share logins or restrict invites, gutting network effects inside the account
- Renewal-time scrutiny: a year of flat fees with shallow usage invites the CFO's axe

**Design notes:** Pair seats with a leader-fenced tier ladder so growing accounts upgrade rather than just add seats; consider charging only for *active* users (Slack's fair-billing pattern: credit for inactive seats) to remove adoption fear; annual prepay discounts of 15-20% trade margin for retention and cash.

## Usage-Based

Pay-as-you-go against a metered unit (calls, GB, transactions, minutes).

**When it wins:** Value scales directly with consumption (infrastructure, APIs, communications); usage varies widely across customers; buyers distrust commitments; you want a frictionless, no-negotiation landing motion that expands automatically with customer success.

**Failure modes:**

- Bill shock: one spike, one viral month, one runaway script — and the customer's trust is gone
- Revenue volatility: your ARR inherits every customer's seasonality
- Rationing: engineers optimize away your revenue; teams fear experimenting because the meter is always running
- Invisible value: the bill itemizes consumption, not outcomes, so renewals litigate line items

**Design notes:** Always ship spend alerts, caps, and budgets — protecting the customer from surprise *is* the retention feature; publish volume discounts (declining unit price) so growth feels rewarded, not punished; offer committed-use contracts (12-month commit at a discount) to swap volatility for predictability on both sides.

## Hybrid: Base Plus Usage

A recurring platform fee (which may include a usage allowance) plus metered overage or expansion.

**When it wins:** Most B2B SaaS with variable consumption. The base covers always-on value and keeps revenue forecastable; the metered component lets revenue track success. It is frequently the adult answer when the team is fighting a subscription-vs-usage religious war.

**Failure modes:** Complexity — two numbers to explain, two numbers to forecast; allowances set too high (overage never triggers, you built a flat plan with extra steps) or too low (every invoice has surprise overage, recreating bill shock).

**Design notes:** Set the included allowance around the median customer's usage so roughly half expand; name the overage unit in the customer's language ("extra active contacts," not "units"); review allowance breakpoints yearly as usage drifts.

## Freemium

A permanently free tier feeding a paid product. Treat it as an *acquisition model*, not a pricing model — the free tier is marketing spend with a conversion target, and it must be engineered like one.

**When it wins:** Marginal cost per free user is near zero; the product spreads through usage (collaboration, sharing, network effects); the market is broad and self-serve; paid conversion has a natural trigger (limits, team features, scale).

**Failure modes:**

- The free tier contains the leader feature, so there is no reason to pay — generosity becomes the business model
- Free users impose real costs (support, compute) with a conversion rate that never covers them
- "Free" anchors the category: charging later for what was free triggers revolt
- Vanity-metric management: counting signups while paid conversion stays below 1% with no mechanism to improve it

**Design notes:** Decide the conversion mechanism *before* launch — what exactly will a successful free user hit that makes paying obvious? Cap free at the habit point (just below where engaged users naturally land), keep virality-driving features free (gating the sharing loop starves acquisition to protect conversion — usually a bad trade), and instrument the free-to-paid funnel like a checkout. Healthy self-serve freemium converts roughly 2-5%; below 1% means the fence is misplaced. A time-boxed free *trial* is the better tool when value is deep but narrow and network effects are absent.

## Dynamic Pricing

Prices that move with demand, supply, time, or buyer context (surge pricing, airline seats, spot instances).

**When it wins:** Perishable capacity (seats, rides, compute hours, ad slots); demand swings are large and measurable; transactions are frequent and anonymous enough that buyers compare against the market, not against each other.

**Failure modes:** Fairness backlash — buyers who discover they paid more than a neighbor for the same thing punish the brand (surge pricing survives only because riders see the multiplier *before* booking); complexity costs (pricing infrastructure, support disputes); legal exposure when price varies by personal characteristics rather than market conditions.

**Design notes:** Vary price by transparent, situational factors (time, demand, capacity), never by who the buyer is; show the price before commitment, always; cap the range — a 10x surge generates headlines that cost more than the surge earned.

## Outcome-Based Pricing

Charging against the result delivered: per hire made, per claim recovered, percentage of savings, per resolved ticket.

**When it wins:** The outcome is discrete, attributable, and measurable by both sides; your product demonstrably drives it; buyers are skeptical and risk-shifting closes deals that ROI decks cannot. It is the strongest possible value story: you pay when it works.

**Failure modes:**

- Attribution war: whose CRM decides whether the deal "came from" the tool?
- You inherit the customer's execution risk — their bad process suppresses your revenue
- Gaming on both sides (outcome definitions bend under revenue pressure)
- Long, lumpy cash cycles tied to outcome timing

**Design notes:** Pick outcomes a neutral log can verify (orders shipped, tickets resolved in-system) over contested ones (revenue influenced); pair a modest platform fee with the outcome fee so the lights stay on; pilot with a handful of design partners to calibrate the rate before publishing it; write the measurement protocol into the contract, including the dispute path.

## Migrating Between Models

Model migrations are open-heart surgery: every existing customer is repriced at once, and the loudest reactions come before the value story lands.

1. **Model the winners and losers first.** Re-bill the last 12 months of every account under the proposed model. Know the distribution: who pays more, who pays less, by how much. If the top decile's bill triples, you have a churn plan to write before an email.
2. **Lead with the value story, not the mechanics.** The announcement explains *why the new model matches value better* and what recipients gain (alignment, headroom, fairness) before any table of rates.
3. **Grandfather generously.** 6-18 months of legacy terms for existing customers (or legacy-forever for a closed cohort) converts the angriest segment into a quiet one. The revenue cost is almost always smaller than the churn-and-reputation cost of forced migration.
4. **Sequence: new customers first.** Run the new model for new signups for a quarter or two. It debugs packaging, fences, and billing edge cases on people with no expectations.
5. **Bridge with choice where losers are concentrated.** Offer affected accounts a one-time option: keep legacy terms for N months or switch now with a credit. Choice defuses the fairness reaction even when most pick the default.
6. **Watch cohort metrics, not the average.** Track conversion, expansion, churn, and support volume per cohort (legacy, migrated, new). Averages hide a bleeding segment for months.

## Model Selection Checklist

Work through these in order; the answers usually converge on one or two viable models:

- [ ] **How does value scale?** Continuously with time → subscription. With consumption → usage. With discrete results → outcome-based.
- [ ] **Can the customer predict and control the metric?** If no, add caps/commits or choose a steadier metric.
- [ ] **What does the buyer's budget process accept?** Line items procurement recognizes clear faster than novel metrics.
- [ ] **Where is the risk best carried?** Risk-averse buyers + confident vendor → usage or outcome models close deals; risk-averse vendor → subscription with commits.
- [ ] **Is acquisition or monetization the binding constraint?** Acquisition-bound with near-zero marginal cost → freemium or free trial on top of the model.
- [ ] **Does the model reward the behavior you need?** Check that the metric doesn't tax adoption, collaboration, or experimentation.
- [ ] **Can billing actually implement it?** Metering, proration, alerts, and invoices are product features; a model your billing stack can't explain will leak trust monthly.
- [ ] **Did customers react to the model in research?** If nobody asked "can we pay per X?" and you're inventing an exotic metric, run five more interviews first.

# Packaging, Tiers, and Bundles

## Table of Contents

- [Leaders, Fillers, Killers](#leaders-fillers-killers)
- [The Classification Procedure](#the-classification-procedure)
- [Good-Better-Best Design Rules](#good-better-best-design-rules)
- [Naming Tiers](#naming-tiers)
- [The Feature-Allocation Matrix](#the-feature-allocation-matrix)
- [Designing Upgrade Paths](#designing-upgrade-paths)
- [Bundle or Unbundle: A Checklist](#bundle-or-unbundle-a-checklist)
- [Pricing-Page Implications](#pricing-page-implications)

## Leaders, Fillers, Killers

Packaging starts from one observation: features are not equal in the buyer's mind, and treating them equally destroys value. Every feature falls into one of three classes — *for a given segment*:

- **Leaders** drive the purchase decision. The buyer would walk without them; they would pay meaningfully more to get them. A package exists to deliver its leaders.
- **Fillers** add modest value. Nice to have, tip the scales in a tie, harmless to include — but nobody buys for them and nobody pays extra for them. Fillers round out a package and differentiate tiers cheaply.
- **Killers** reduce willingness to pay when forced into the package. The buyer does not want them and resents funding them. Classic killers: paid-for capabilities a segment will never use ("why am I paying for call-center features?"), mandatory services (required onboarding fees), or features that add complexity the segment fears.

The segment qualifier is everything. On-premise deployment is a killer for a startup buyer (cost, maintenance, fear) and a leader for a bank (compliance). SSO is invisible to freelancers and non-negotiable for enterprises. There is no absolute list — only a per-segment classification, which is why segmentation precedes packaging.

## The Classification Procedure

Run this before designing tiers, and again whenever a significant feature ships:

1. **List the units of value.** Enumerate every feature or capability a buyer could perceive as a thing they get — typically 15-30 items. Group sub-features (ten small report types = "reporting"). If the list exceeds ~30, you are itemizing too finely.
2. **Collect evidence per item, per segment.** From WTP interviews and surveys:
   - *Decision impact:* "Which of these would have to be present for you to buy?" / "Rank the top 5 that drive your decision."
   - *Incremental WTP:* "How much more would you pay for a version with X?" or point-allocation across the list.
   - *Negative reaction:* "Which of these would you not want to pay for, even bundled?" / "Would including X at a higher price make you walk away?"
3. **Score and classify.** A practical rubric per segment:

| Evidence pattern | Class |
|------------------|-------|
| Top-5 decision ranking for ≥40% of segment, positive incremental WTP | Leader |
| Rarely ranked, near-zero incremental WTP, no negative reaction | Filler |
| ≥20% of segment reacts negatively to paying for it | Killer |

4. **Sanity-check against behavior.** Usage data, lost-deal notes, and support requests should corroborate. A "leader" nobody uses after purchase is a marketing leader only — fine, but know it. A "filler" that churned customers cite as missing was a leader you misread.
5. **Decide the fate of each killer.** Three options: unbundle into an optional add-on (the default), move it to a tier whose segment values it (where it may be a leader), or cut it entirely if it is a killer for everyone.

## Good-Better-Best Design Rules

Three tiers is the default architecture because it exploits how people choose: extremes feel risky, the middle feels safe, and a premium anchor makes everything below it look reasonable.

1. **Design "Better" first.** The middle tier is the offer most buyers should take — the compromise effect will pull them there anyway, so build it to be genuinely right for your core segment and price it where you want your average revenue to land.
2. **"Best" is the anchor and the enterprise home.** It must contain real leaders for the high-WTP segment (not just bigger limits), priced 2-4x "Better." Even at modest volume it pays twice: directly, and by making "Better" an easy yes.
3. **"Good" is the fenced entry.** It exists to capture the low-WTP segment and to start upgrade journeys. Give it real value — a taste of the leader, not the meal. If "Good" fully contains the leader, nobody upgrades; if it is useless, it poisons trust and trials.
4. **Plan around a 70/20/10 shape.** As a planning expectation, aim for roughly 70% of buyers in Better, 20% in Best, 10% in Good. Strong deviations are diagnostic: most buyers in Good means weak fences or an overpriced middle; most in Best means your anchor is missing and you are likely minivating.
5. **Fence with leaders, then limits.** The primary fence between tiers should be a feature the higher segment genuinely values (leader fence). Quantity limits (seats, projects, API calls) are secondary fences — good for growth-based upgrades, weak as the only differentiator.
6. **Four tiers maximum.** A fourth tier (usually a free or a custom-enterprise tier) is acceptable; five or more measurably increases choice paralysis and support burden. Collapse before you add.
7. **Price gaps must be explainable in one sentence per gap.** "Team adds the integrations and approvals agencies need" — if you cannot say it, the buyer cannot see it, and the gap reads as arbitrary.

## Naming Tiers

Tier names are a self-segmentation device: a buyer should know which tier is theirs within five seconds.

- **Name by customer or use stage:** Solo / Team / Business / Enterprise, or Starter / Growth / Scale. These work because buyers identify themselves before reading the feature table.
- **Avoid opaque sequences** (Bronze/Silver/Gold, Basic/Plus/Premium) when segments differ by *kind* of need — metals only communicate "more," not "for whom."
- **Never name a tier something aspirational that insults the others.** "Professional" above "Basic" implies Basic buyers are amateurs; they notice.
- **Keep names stable.** Renaming tiers invalidates documentation, reviews, and word-of-mouth ("get the Team plan") — rename only with a repackaging worth that cost.

## The Feature-Allocation Matrix

The working artifact of packaging design — every feature, its classification per target segment, and its tier placement:

| Feature | Class (segment) | Good ($19) | Better ($49) | Best ($129) | Add-on |
|---------|-----------------|------------|--------------|-------------|--------|
| Core editor | Leader (all) | ✓ | ✓ | ✓ | — |
| Projects | Fence (limit) | 3 | 25 | Unlimited | — |
| Slack/Teams integration | Leader (Team seg) | — | ✓ | ✓ | — |
| Approval workflows | Leader (Team seg) | — | ✓ | ✓ | — |
| Advanced analytics | Leader (Agency seg) | — | — | ✓ | — |
| API access | Leader (Agency seg) | — | Read-only | ✓ | — |
| Custom branding | Filler | — | ✓ | ✓ | — |
| Email support | Filler | ✓ | ✓ | ✓ | — |
| Dedicated CSM | Leader (Enterprise) | — | — | ✓ | — |
| On-prem deployment | Killer (SMB) / Leader (Ent) | — | — | — | $ |
| Mandatory onboarding | Killer (all) | — | — | — | Optional $ |

Rules visible in the template: each tier above Good adds at least one leader for its segment; killers never sit inside a tier price; limits create a second, growth-driven upgrade trigger; every row has an explicit decision (no "TBD" rows on a shipping pricing page).

## Designing Upgrade Paths

Packaging is static; customers are not. Design the journey between tiers:

- **Place the fence where usage naturally grows.** The best upgrade trigger is success: the team that hits the 3-project limit because the product worked. Analyze usage distributions and put limits just *below* the point where committed users land (if engaged teams typically reach 4-6 projects, the free/entry cap is 3).
- **Prompt at the moment of need, not on a schedule.** "You've hit your project limit — Team gives you 25" converts; a monthly upsell email annoys. Every fence needs an in-product moment that explains the next tier in terms of what the user was just trying to do.
- **Let users preview the leader.** Time-boxed trials of higher-tier features (7 days of analytics when first opened) outperform descriptions. A leader experienced is a leader bought.
- **Never make downgrades destructive.** Losing access to premium features is acceptable; losing data or exports is hostage-taking — it poisons reviews and, in some jurisdictions, regulators agree.
- **Mind the cliff between self-serve and enterprise.** If Best is $129/seat and Enterprise is "call us" starting at 10x, mid-market buyers fall into the gap. Bridge with a transparent volume schedule or a mid tier.

## Bundle or Unbundle: A Checklist

Bundling raises total willingness to pay when the parts reinforce each other; it destroys clarity when they do not. Work through the list:

**Bundle when most of these are true:**

- [ ] Components are complementary in use — each makes the others more valuable (editor + review + publishing)
- [ ] One buyer evaluates and pays for all components
- [ ] Buyers' WTP for components is *negatively correlated* (some value A highly and B mildly, others the reverse) — the bundle averages both into one strong yes
- [ ] Buying separately would create integration or decision friction you can remove
- [ ] The bundle story is tellable in one sentence ("everything a podcast team needs")

**Unbundle when any of these is true:**

- [ ] A component is a killer for a meaningful segment of bundle buyers
- [ ] Different components are bought by different roles or budgets
- [ ] A component's natural price metric differs (per-seat product bundled with a per-volume API)
- [ ] The bundle price exceeds the prohibitive threshold of your core segment even though individual WTPs are healthy
- [ ] Competitors win by selling the one component a customer wants without the rest

Default resolution for borderline cases: tiered bundles (the core bundle plus add-ons) — keep the complementary heart together and let contested components be chosen.

## Pricing-Page Implications

The pricing page is where packaging theory meets a visitor with 20 seconds of patience:

1. **Three or four columns, one highlighted.** Highlight "Better" with a "Most popular" badge — only if it is actually true; invented popularity claims are both unethical and, in several markets, illegal.
2. **Use the anchor deliberately.** Either order tiers premium-first (strong anchor for sales-led products) or highlight the middle with the premium adjacent (standard for self-serve). Never hide the premium tier — it is doing anchoring work even when unsold.
3. **Lead each column with its leader.** The first 2-3 bullets under each tier name must be that tier's leaders for its segment — not the longest list. Bury fillers in the expandable comparison table below.
4. **State the price metric next to the price.** "$49 per editor / month, billed annually" — ambiguity about the metric ("per user? per viewer?") kills conversion and seeds support debt.
5. **Make the annual/monthly toggle honest.** Show the math; don't display annual-billed prices as if monthly without labeling.
6. **Answer fence questions in an FAQ.** "What happens when I hit the project limit?", "Can I downgrade?", "Do viewers cost money?" — every fence creates a question; unanswered questions create abandoned carts.
7. **Test packaging before price.** A/B tests that move features between tiers or change the highlighted column routinely shift revenue more than ±10% price tests — and are safer to run.

# Running Willingness-to-Pay Conversations

## Table of Contents

- [Why Talk Price Early](#why-talk-price-early)
- [Ground Rules](#ground-rules)
- [The Question Toolkit](#the-question-toolkit)
- [Simplified Conjoint for Practitioners](#simplified-conjoint-for-practitioners)
- [Interpreting the Answers](#interpreting-the-answers)
- [Sample Sizes and Logistics](#sample-sizes-and-logistics)
- [B2B vs B2C Differences](#b2b-vs-b2c-differences)
- [From WTP Data to Product Specs](#from-wtp-data-to-product-specs)

## Why Talk Price Early

The willingness-to-pay (WTP) talk is the single highest-leverage conversation in product development, and it belongs at the concept stage — when the product is a one-page description, not a beta. At that point, every answer can still change the design: which features make the cut, which segment you build for, whether the business case clears the bar, whether the product should exist at all.

Teams avoid the conversation for predictable reasons: "customers can't know what they'd pay for something that doesn't exist," "we don't want to anchor them low," "we'll figure out pricing closer to launch." All three are wrong in the same way — they treat WTP research as setting a price. It is not. It is measuring value. You are not asking customers to commit to a number; you are reading how much the problem matters to them, which parts of your solution carry that value, and how the answers differ across customers. The final price comes later. The signal is available now.

A useful reframe for the team: if customers will not tell you what the product is worth, the market will — at launch, expensively, in public.

## Ground Rules

1. **Talk to people who control budget.** Users tell you about value in use; buyers tell you about willingness to pay. In B2B you need the economic buyer in the sample, not only champions. In B2C, the user usually is the buyer — but confirm it (parents pay for teens; one partner pays for the household).
2. **Frame it as a value conversation.** Open with: *"We're deciding what to build, and I'd like to understand what this would be worth to you — there's no price list and I'm not selling anything today."* This lowers the negotiation guard that otherwise corrupts every answer.
3. **Never rely on one question.** Single answers are noise. Triangulate with at least three of the methods below and look for convergence.
4. **Treat answers as relative, not absolute.** A stated "$50" is not a price you can charge; it is a point on a curve you compare across features, concepts, and respondents.
5. **Describe the concept in value terms before any price question.** One paragraph: who it is for, the problem, the outcome. If respondents misunderstand the concept, their WTP answers are about something else.
6. **Never promise the researched price.** Make explicit that this is research; otherwise early interviewees become aggrieved negotiators at launch.
7. **Record the "why" behind every number.** The reasons reveal segments; the numbers alone do not.

## The Question Toolkit

### Direct value questions

Start broad, then narrow:

- *"What would you say this is worth to your team?"*
- *"What do you pay today to solve this problem, in tools, people, or workarounds?"*
- *"If this saved you the four hours a week you described, what would that be worth?"*

Direct questions are the weakest single instrument but the best conversation starters — they surface the customer's value logic and their reference points (what they compare you to), which you need to interpret everything else.

### The three-point price probe

Ask, in this order:

1. *"What do you think would be an **acceptable** price for this?"* — a price they would consider a good deal and pay without hesitation.
2. *"What would be an **expensive** price — where you'd hesitate, but might still pay if the value is there?"*
3. *"At what price does this become **prohibitively expensive** — out of the question, no matter how good it is?"*

Interpretation:

| Answer | What it tells you |
|--------|-------------------|
| Acceptable | The comfortable floor — pricing here means money left on the table |
| Expensive | The value zone — most healthy prices live between acceptable and expensive |
| Prohibitive | The ceiling — pricing at or above this needs a different segment, not persuasion |

The gaps matter as much as the numbers. A narrow acceptable-to-prohibitive range signals a commodity perception; a wide range signals differentiated value or a confused concept — the "why" follow-ups tell you which.

### Purchase-probability scale

After showing the concept at a specific price: *"On a scale of 1 to 5, where 5 is 'I would definitely buy this,' how likely would you be to buy at $X?"*

Scoring discipline:

- Count 5s as real interest — then discount, because stated intent overstates behavior
- Count 4s as soft maybes — worth at most a fraction
- Treat 1-3 as no

Use the scale comparatively rather than absolutely: ask it at two or three price points (across different respondents or rotated orders) and watch how the top-box percentage decays as price rises. The decay curve is the finding; the raw percentages are not forecasts.

### Trade-off forcing

The most honest answers come when respondents must give something up:

- **Ranking:** *"Rank these eight capabilities from most to least important to your purchase decision."*
- **Point allocation:** *"You have 100 points. Spread them across these features in proportion to the value of each."* Features that average under ~5 points are filler or killer candidates.
- **Would-you-rather pairs:** *"Version A has the integrations but no analytics at $79. Version B has analytics but no integrations at $79. Which do you pick?"*
- **Build-your-own:** Give a base product at a base price and a menu of priced add-ons; ask them to build the package they would actually buy. Watch what they skip — skipped-at-any-price items are killer candidates.

## Simplified Conjoint for Practitioners

Full conjoint analysis is a statistical method agencies run with specialized software. The logic, however, is simple enough to run "good-enough" versions yourself:

1. **Pick 3-4 attributes plus price.** For a SaaS tool: integrations (3 vs 20), analytics (basic vs advanced), support (email vs dedicated), price ($29 / $79 / $149 per seat).
2. **Compose 8-12 choice tasks.** Each task shows 2-3 product profiles with different attribute combinations and prices, plus a "none of these" option. Vary attributes systematically so each level appears across tasks roughly equally often.
3. **Ask respondents to choose one profile per task.** Choosing is easy and honest — it mirrors buying. No respondent sees the underlying design.
4. **Count.** Across all respondents and tasks, compute each attribute level's win rate: how often profiles containing it were chosen versus shown. Large gaps between levels = that attribute drives choice (leader). Small gaps = filler. A level whose presence *lowers* win rate = killer signal.
5. **Read price sensitivity from the choice shifts.** How much choice share does the same package lose moving from $79 to $149? That elasticity, even roughly measured, beats any direct question.

This simplified version sacrifices statistical rigor for speed. Use it to rank features and bracket price ranges; commission a proper conjoint (or use survey tools with built-in conjoint modules) when a major launch hangs on the result.

## Interpreting the Answers

**Build the WTP curve, not the WTP average.** Plot what share of respondents accepts each price point:

| Price per seat | % calling it acceptable or better |
|----------------|-----------------------------------|
| $20 | 90% |
| $40 | 72% |
| $60 | 38% |
| $80 | 31% |
| $120 | 24% |
| $160 | 6% |

Read the cliffs and plateaus. Here the cliff between $40 and $60 plus the plateau from $60-120 suggests two populations: a price-sensitive majority near $40 and a smaller group comfortable to ~$120. That is a segmentation finding — two offers — not an averaging problem ("charge $68") to solve.

**The average trap.** The mean of a bimodal market describes a customer who does not exist. Always look at distribution shape before computing anything.

**Haircut stated numbers.** Stated WTP runs optimistic: respondents are agreeable, spend imaginary money, and ignore switching costs. Treat stated numbers as the ceiling of the realistic range, validate with behavioral evidence (pilot offers, pre-orders, signed letters of intent at a named price), and watch early sales against the research before trusting it fully.

**Red flags that invalidate the data:**

- Answers clustered exactly on your current price or a competitor's list price — respondents are quoting the market back at you, not valuing the concept
- Identical answers across very different customers — your concept description is leading them
- Refusal to engage with price at all — you are interviewing users with no buying authority
- Politeness pattern: every feature "very valuable," every price "fair" — switch to trade-off forcing immediately

## Sample Sizes and Logistics

**B2B:** 15-25 interviews per target segment, done as 30-45 minute conversations. Saturation arrives quickly — when three consecutive interviews produce no new value logic, you have enough for design decisions. Below 10 per segment, treat findings as directional only.

**B2C:** Interviews (10-15) to learn the value language first, then a survey of 150-300 respondents per segment for the price probes and purchase-probability questions. Simplified conjoint needs roughly 200+ completed responses to be readable; below that, stick to ranking and the three-point probe.

**Cadence:** A competent WTP study — recruit, interview, survey, synthesize — fits in 3-6 weeks. That is shorter than one development sprint cycle wasted building a filler feature.

**Who runs it:** Product plus one finance- or pricing-minded person. Founders should attend B2B interviews but not lead the price questions — customers negotiate with founders reflexively.

## B2B vs B2C Differences

| Dimension | B2B | B2C |
|-----------|-----|-----|
| Primary method | Depth interviews with the buying unit | Surveys and panels, interviews for language |
| Who answers | Economic buyer, champion, procurement (separately) | The end consumer |
| Value logic | Quantifiable: hours saved, revenue gained, risk avoided | Perceived: convenience, identity, enjoyment |
| Distortion | Procurement gamesmanship — buyers underquote on purpose | Agreeableness — respondents overquote to be nice |
| Validation | Pilot agreements, LOIs at a named price | Pre-orders, fake-door tests, A/B price tests on real traffic |
| Sample | 15-25 per segment | 150-300+ per segment |

**B2B extra: quantify economic value.** Anchor interviews with an economic value estimate: start from the customer's next-best alternative (current tool, manual process, doing nothing), then add the monetized differentiation value your product provides (time saved × loaded cost, error rate reduction × cost per error, revenue lift × margin). WTP normally lands at a fraction of provable economic value; if your interviews report WTP *above* your economic value math, your model is missing a value driver — find it before pricing.

**B2C extra: test behavior, not just words.** Landing pages with different price points, waitlists with deposit options, and purchase-intent tests on ads give behavioral WTP signals cheaply. Keep price experiments honest: test prices on genuinely available offers and honor the best price seen by any cohort if challenged — fairness complaints travel fast.

## From WTP Data to Product Specs

The research only pays off when it changes what gets built. Three mechanisms:

**1. The feature-WTP table.** Every roadmap candidate gets a row before it gets a sprint:

| Feature | Evidence | WTP signal | Classification | Decision |
|---------|----------|-----------|----------------|----------|
| Slack integration | 18/20 rank top-3; +9 pts win rate | Drives choice, low standalone WTP | Leader | Build, all tiers |
| Advanced analytics | High WTP in 1 of 3 segments | $30-50/seat in agencies segment | Segment leader | Build, top tier |
| AI summaries | "Nice," never ranked top-5 | ~0 incremental WTP | Filler | Defer |
| Mandatory onboarding training | 6/20 said would block purchase | Negative | Killer | Make optional, unbundle |

**2. WTP gates in the development process.** Add one question to every spec review: *"What is the willingness-to-pay evidence for this?"* Accepted answers: interview data, conjoint win rates, pilot commitments. Not accepted: "competitors have it," "sales asked," "it's cool." Features can still ship without WTP (strategic, defensive, compliance) — but then the document says so explicitly, and the cost is visible.

**3. The living business case.** Maintain one page linking the chain: target segment → validated WTP range → chosen price metric and level → expected volume at that price (from the WTP curve) → cost to build and serve → margin. Update it whenever scope, segment, or price assumptions change — a business case written once at kickoff and never touched is a prop, not a plan. At launch, this page becomes the monitoring baseline: actual conversion and ARPU versus the curve you researched.