Pricing Tier Design (Good / Better / Best)

What this does

This skill turns a product with a pile of features into a packaged three-tier lineup — a Good/Better/Best structure built to answer "which package does each customer buy, and what makes them move up a tier" — not an open-ended pricing consult that answers "what should our pricing philosophy be."

The bare-model default, asked to "package this into tiers," is a rambling consult plus a generic feature grid: paragraphs on willingness-to-pay, personas, and competitor benchmarking, then a Basic/Pro/Enterprise table where features are sprinkled across tiers with no logic — each tier is just "the last one plus more stuff." That grid does not tell a buyer why they'd upgrade, and it meters different tiers on different axes.

A packaged lineup makes four deliberate moves the default skips:

1. One value metric meters every tier.
2. One fence feature guards each upgrade boundary.
3. The top tier anchors the whole lineup.
4. The result is one three-tier table, not prose.

The four moves

1. Pick ONE value metric — the single axis usage scales on

The value metric is the one unit a customer buys more of as they get more value: seats, projects, monthly API calls, GB stored, contacts, tracked assets. Pick exactly one and let it climb across all three tiers. Every tier is metered on that same axis (5 seats → 25 seats → unlimited seats), so the buyer reads the ladder in a single glance.

Choose the metric that tracks the value the customer gets, not the cost you incur. "Seats" works when value grows with team size; "records processed" works when value grows with volume. The wrong metric charges a solo power-user the same as a hobbyist, or caps a team on something they don't care about. Pick one and commit — do not meter Good on seats and Best on data volume. If two axes both grow with value, pick the one the buyer already uses to describe their own scale, and mention the other only as an add-on.

2. Place the fence feature at each boundary

A fence is the ONE capability a customer hits, needs, and cannot get without moving up a tier. It is the reason the upgrade happens. Each of the two boundaries (Good→Better, Better→Best) gets exactly one clearly-named fence — the single most-wanted feature just out of reach.

• Good→Better fence: the feature a growing individual/small team hits first (e.g. team roles &

shared workspaces, integrations, the automation the free-tier user keeps asking for).

• Better→Best fence: the feature that only the largest / most-regulated buyer needs (e.g. SSO/SAML,

audit logs, SLA & dedicated support, advanced permissions).

Everything else is filler that can sit in whatever tier; the fence is load-bearing. Do not scatter five half-features across a boundary — name the one that does the pulling. A boundary with no fence is why "Basic + more of the same" never converts anyone upward.

3. Make the top tier a deliberate anchor

Set the highest tier (Best / Enterprise) intentionally high — richer and pricier than most buyers will pick. Its job is not primarily to sell; it is to anchor, making the middle tier read as the sensible, reasonable choice by comparison. The middle (Better) is the tier you actually want most buyers to land on; the anchor exists to steer them there. Say plainly which tier is the anchor and which is the intended default — that intent is the whole point, and the default grid never states it.

4. Output ONE three-tier table

Deliver a single table with three columns (Good / Better / Best — rename to fit the product), rows for the value-metric level, the fence feature at each boundary, the key included features, and the target buyer per tier. One table, readable top to bottom. Prose only for a two-line note on which tier is the anchor and which is the default.

Working from what you're given

• Package only the features present in what the user gives you. Do not invent capabilities (no

fabricated "AI assistant" tier) to fill a column.

• If the user hasn't said what their value metric could be, infer candidates from the product and

name the one you picked and why — don't punt the decision back.

• Setting the actual dollar prices is out of scope; use relative placeholders ($, $$, anchor)

unless the user supplied numbers. This skill designs the structure, not the price points.

• Three tiers is the default. Only add a fourth (e.g. a free tier) if the user's context calls for

it, and still keep one value metric and one fence per boundary.

Example (shape only)

For a project-management tool, value metric = projects:

| | Good (Solo) | Better (Team) — default | Best (Business) — anchor | |---|---|---|---| | Projects | Up to 3 | Up to 25 | Unlimited | | Fence in | — | Shared workspaces & roles | SSO + audit log | | Includes | Boards, basic reports | + automations, integrations | + advanced permissions, SLA | | For | Individuals | Growing teams | Regulated orgs / IT-led buys |

Note: Team is the intended default; Business anchors the lineup so Team reads as the reasonable pick.