Model your catalogue around how you actually sell, not how you build

Model your catalogue around how you actually sell, not how you build

The first real configuration decision is your product catalogue, and most people get it backwards. They mirror their internal product structure: every feature, every module, every SKU the engineering team thinks about. Then sales tries to quote and finds forty line items where the customer understands three.

Configure the catalogue around the buying decision. A product in your commerce hub is something a customer chooses to pay for, named the way they would describe it. If your customer buys "the Growth plan" and "onboarding", those are two products. The fact that the Growth plan internally bundles eleven capabilities is your problem, not theirs, and it does not belong in the catalogue.

Keep products and prices separate, because they change at different speeds. A product is the thing ("Growth plan"). A price is what it costs in a given currency, billing interval, and tier ("4,000 EUR per year"). You will add prices far more often than you add products, and you almost never delete a price, you deprecate it, because old subscriptions still reference it. Configure with that lifecycle in mind from day one.

Use a clear, boring naming convention and apply it everywhere. Product names match the language on your pricing page. Price nicknames encode the interval and tier so a human scanning the dashboard knows what they are looking at. Internal metadata (plan codes, feature flags, entitlement keys) lives in metadata fields, never smuggled into the customer-facing name.

The test is simple. Open your catalogue and read it as if you were the customer. If you cannot tell what you would be buying, neither can your sales team, and neither will the invoice.

INTERVIEW EWOUD: Give a concrete before-and-after of a catalogue you simplified. How many SKUs did it start with, what did it collapse to, and what did that unlock?