Pricing & Packaging Canvas

The Problem

Pricing decisions usually start in the wrong place: a spreadsheet with dollar figures and tier names, filled in from a competitor's pricing page or a gut-feel number. That skips the actual sequence that pricing depends on: what customers pay for, how that scales with the value they get, and what they'd actually pay for it. This causes the resulting price table to be defensible to no one, and it will get re-litigated every time a deal needs a discount. A pricing table is the last artifact in the process, not the first.

The Framework

Pricing and packaging decisions follow a fixed sequence, and skipping steps is what produces indefensible pricing:

1. value metric (the unit customers pay for — seats, usage, API calls, outcomes)
2. pricing model (flat, per-seat, usage-based, hybrid)
3. tier structure (how features, limits, and entitlements bundle into plans that create a natural upgrade path), and
4. price points grounded in measured willingness to pay. Packaging creates the upgrade path; pricing captures willingness to pay along that path and conflating the two is a common source of tiers that don't actually correlate with what customers value.

The test for a good value metric: it should tightly correlate with customer-perceived value, be easy to understand and measure, and scale naturally as the customer succeeds with the product (more seats for a collaboration tool, more API calls for infrastructure). If you can't explain what a plan costs without first explaining how the metric works, it's probably the wrong metric.

The Process

1. Map how customers actually get value, before naming any metric. Walk through the customer's job-to-be-done and identify the moment value is delivered. This is where a real value metric comes from, not from what's easiest to instrument.
2. Shortlist 1–3 candidate value metrics and score them. Evaluate each against value alignment, predictability, measurability, and expansion potential before testing any with real customers. Don't commit to the first plausible metric.
3. Design tiers around customer segments, not stacked features. Start with a simple three-tier (good-better-best) structure built around distinct jobs-to-be-done or customer segments. A tier ladder built by just piling on more features in ascending order rarely maps to how different customers actually buy.
4. Gate features deliberately, with transparent limits. Each tier's premium features, usage limits, or support level should be a clear, explainable reason to upgrade, not an arbitrary line drawn to hit a price point.
5. Measure willingness to pay before finalizing price points. Use a method matched to your timeline and stakes: Van Westendorp price sensitivity (roughly 1–3 weeks) for a fast directional read, conjoint analysis (4–8 weeks) for a more rigorous tradeoff model, or live A/B price testing (4–12 weeks) when you can run it safely. Aim for 200–500 respondents per segment for a statistically useful result.
6. Revisit the canvas on a cadence, not once at launch. Companies that revisit pricing quarterly grow meaningfully faster than those that set it once and leave it. Treat the canvas as a living document, updated as the product and market shift.

Template / Checklist — The One-Page Canvas

Fill in each box before building an actual pricing table:

• Value metric: the specific unit customers pay for, and why it scales with value delivered.
• Pricing model: flat / per-seat / usage-based / hybrid, and the reasoning for that choice given the value metric.
• Tier structure: 3 tiers named for the customer segment or job-to-be-done each serves, not just "Basic/Pro/Enterprise" by feature count.
• Feature gating per tier: the specific, explainable reason each tier costs more than the last.
• Willingness-to-pay evidence: the method used (Van Westendorp / conjoint / A/B) and the resulting price range per segment.
• Anchor and presentation plan: which tier is highlighted as recommended, and price-table ordering (e.g., highest tier shown first to anchor perception).
• Review date: the next scheduled pricing revisit, not "whenever it becomes a problem."

Common Pitfalls

• Starting from a price table instead of a value metric. Pricing set before the value metric and tier logic are defined tends to require constant special-case discounting because it was never grounded in what customers actually value.
• Stacking features instead of designing for segments. A tier ladder built by adding more features to each successive tier, rather than mapping to distinct customer jobs, produces plans that don't match how people actually decide to upgrade.
• Skipping willingness-to-pay research. Cost-plus or competitor-matched pricing set without measuring what customers would actually pay leaves revenue on the table or overprices against real demand.
• Treating pricing as a launch-time decision. Pricing set once and never revisited drifts out of alignment with the product and market it was built for.

When Not to Use This

1. Very early-stage products still searching for product-market fit don't have enough usage data or customer volume to run rigorous willingness-to-pay research. A simple, easily-changed flat price is more appropriate until there's a stable enough value proposition to justify the research investment.
2. Highly regulated or enterprise-only products sold purely through custom negotiated contracts may also get limited value from a tiered self-serve canvas, since the real pricing mechanism is deal-by-deal negotiation rather than published tiers.