The pricing architecture and its three decisions

The frame

Pricing a software product is three decisions, and they come in an order. The first is licensing: what the customer may use, on what terms, and which unit your price attaches to. That unit is the value metric, what you count on an invoice. The second is packaging: which capabilities go together, as editions and add-ons, for which Customer Groups, the clusters of buyers who get value from the product in different ways. The third is pricing: the number, and the rulebook that turns a list price into the price each customer pays. Each decision depends on the one before it. You cannot package rights you have not defined, and you cannot price a package you have not drawn.

Most companies argue about the third decision while the first two are unmade or inherited. The unit came from a competitor’s pricing page or an earlier product manager. The editions follow the way engineering organized the roadmap. Then every deal needs a custom configuration, discount approvals drift, and the pricing rulebook takes the blame. If you were just handed pricing, the request will arrive as a number: raise it, hold it, discount it less. The decision in front of you is usually one level up. Ask which unit the price counts, and whether the editions match how customers get value, before anyone touches the number.

How to price software argues that a price is an architecture and shows which symptoms point at which of the three decisions. B2B pricing strategies argues that the price is the last decision and traces what breaks when the sequence runs backwards. Software monetization argues that subscription, usage-based and hybrid are billing labels, and that choosing one leaves the architecture undecided.

Which of the three decisions is in front of you right now: what your price counts, what goes together for whom, or the number itself?

Three things to say in the room this week

• Before we debate the number, which unit does our price attach to, and who chose it?
• Our editions should group capabilities by how customers get value from them, and the feature roadmap is the wrong guide.
• When discounting looks out of control, the cause is usually one decision upstream of the discount rule.