Three product libraries, built out

When I wrote about the catalog with five hundred and thirty-eight products in it, the responses I got were mostly some version of the same question, which is fair: right, so what does a good one look like. It is a harder question to answer than it sounds, because the answer is not a template. A product library is a set of decisions about a specific business, and the decisions are what travel — the rows are just where they land.

Still, decisions in the abstract are easy to nod along to and hard to use. So this is three catalogs, built out, for three kinds of business. Not companies I have worked with, and not anonymised versions of them either — these are shapes, and a shape is more useful anyway, because you can tell whether yours is one of them without me having guessed at your business.

Why these three

Because they are the three that HubSpot can hold today. I scored thirty-eight segments earlier this month on two things that matter more than the rest: whether the complexity is genuinely unavoidable for that business, and whether Revenue Hub can carry the money as it is documented right now. Three came back clean on both. Two of the three turn out to be the same shape wearing different clothes, so this is really two shapes and three skins.

• Sales-led software, roughly fifty to a thousand people — seats, tiers, a term, and expansion that has to end when the original agreement does.
• Equipment makers with a service arm — a machine sold once, then a multi-year maintenance agreement per asset that grows as the customer buys more machines.
• Fire, security and HVAC contractors — an install that is one-time and messy, then a monitoring or maintenance annuity per site.

The second and third are the same shape: something sold once, then an annuity attached to it that grows by unit. Nobody has published a Revenue Hub case in either, which is either a warning or an opening depending on how you feel about being first.

The one rule that survives all three

I keep leading with this because it is the decision that produced four hundred and forty-three of those five hundred and thirty-eight rows, and because it is the one that looks harmless when you make it. Every catalog below puts the count in quantity, and the last column of each table says what the number actually means, which is a useful thing to be able to answer out loud before you build anything.

Sales-led software

This is the shape the contract object was built for, and it shows. The customer buys seats on a term, adds more halfway through, and the addition has to co-terminate with the original — which is the one motion the platform does natively and does well. It is also the most crowded field; every partner has a launch guide for it. What almost nobody works on is the installed base, which is where the actual difficulty lives: the agreements that already exist, the amendments, the renewals.

Three things in there are worth arguing about. The seat row is priced graduated, which prices each user inside its own band and sums them, rather than volume, which reprices every user at the band the total reached — and those produce different invoices for the same customer, so it is worth knowing which one the sales team thinks it is selling. The three-year row is a variant of the same product rather than a note on the deal, which means the term is a property of the thing sold and the billing schedule reads it, instead of a text field that will disagree with the line item inside a quarter.

And the one-time rows are a trap I have put in on purpose, because they are in every real catalog of this shape. Onboarding, migration and training are one-time, which means they cannot be added by a change quote later. Mid-term services are a separate quote and a separate motion, and somebody has to own it. That is fine, it is just better to know before go-live than the first time a customer asks for training in month seven.

The API allowance row is a commitment, not metering. There is no rating and no credit balance anywhere in HubSpot, so that row sells a committed block annually and a genuine overage is either a manual true-up or a different system. Whichever it is, say so early.

Equipment makers with a service arm

The machine is one-time and the service agreement is the annuity, and the annuity is the part that fits. Coverage grows as the customer buys more machines, renews with an uplift, and one contract holds both the money and the record of what is installed — which for a lot of these businesses is the first time those two things have been in the same place.

The maintenance row is per machine and the quantity is the installed base, and that single choice is why this shape works at all. Going from four covered machines to six is a quantity change on a recurring line, which is a change quote, which the platform handles and prorates and mints an order for. Model coverage as a count and expansion is native. Model it as maintenance, four machines and expansion is a rebuild, every time, forever.

The bundle is worth a second look before you copy it. Closed means the rep cannot alter the components, which is right for a machine configuration that has to be physically buildable. But pricing it as a fixed bundle price stops component price changes from reaching the bundle, so margin drifts quietly and nothing tells you. Pricing calculated from the components keeps it honest and lets the rep see the arithmetic. Either is defensible; picking without noticing is not.

Dealer pricing is not in the table because it is not a product. It is a price book, and price books are per-currency and per-segment and get assigned per deal rather than per company — so the dealer discount is a book selection plus an approval rule, and nothing in the catalog forks. Two things to know before you promise that: price books carry no tiered volume pricing, and they cannot be imported, cloned, or used in workflows.

Fire, security and HVAC contractors

Adding a site is the thing these businesses do constantly, and almost all of them do it in a spreadsheet beside the system. It is a quantity change on a recurring line, which means the platform handles it natively, and that one motion is most of why this industry is on the list at all.

This is where the device-count catalog gets built, every time, because a quote for eighteen detectors genuinely feels like a thing being sold. It is one product, quantity eighteen. Get that wrong and operations reads one on every line, nobody can tell you the average number of devices per site without parsing product names, and a customer going from eighteen to twenty-two is a different product rather than a bigger one.

The install is the other half, and the install is where the limits bite hardest. A variation mid-project — extra devices, an extra floor, a rerouted cable — is a one-time change, and one-time lines cannot be change-quoted. So the install is quoted and every variation is its own quote, and somebody owns that. I would rather design that motion in week one than discover it in month three, and I do not think it is a reason to walk away from the platform. It is a reason to be honest about what you are buying.

Indexation is the other one. A contract with an annual CPI or RPI uplift is a renewal quote somebody raises with a new number, because nothing native is calculating it. Model the uplift as a renewal step, put the date somewhere a human will see it, and say plainly that the platform is not doing the arithmetic.

Where I tell people no

One sentence in HubSpot's own documentation, updated in August, decides more scoping conversations than anything else I know about this product.

Read what that does to a catalog. Everything recurring stays alive after signature — repriceable, expandable, renewable, with the platform handling the proration and minting an order for the change. Everything one-time freezes at signature, and changing it means a new quote and a separate motion. So the test for any business is one question: after the customer signs, what changes? Mostly recurring, and it fits. Mostly one-time — change orders, milestones, deposits, progress claims, retention — and it does not fit yet.

Which is why the businesses where complex quoting is most unavoidable are the ones this cannot carry right now. Project subcontractors need change orders, progress billing and retention, which is the exact three gaps. Statement-of-work consulting needs milestone billing and time tracking, and there is no time tracking anywhere in HubSpot. Usage-based software needs rating and credit balances that do not exist. Wholesale distribution needs price books scoped to a customer rather than a deal. Each of those re-scores when something specific ships, so the honest answer is a trigger rather than a maybe — and I would rather give someone the trigger than a build that cannot hold their money.

What I actually do with these

Not this. These are shapes, and the first thing in a real engagement is finding out what the business in front of me actually sells, which is not a question anyone there can answer — not because they are being difficult, but because the answer lives in eighteen months of line items nobody has ever aggregated, and what they can tell you is what they meant to build.

So I read the history first. How many rows are in the catalog, how many of them any live agreement has actually used, what share of line items were typed by hand instead of coming from a product, whether quantity is ever a number greater than one, whether a price that differs from its product has a discount recorded against it or just a different number. That read is what turns six decisions from a checklist into an argument about their business, with their own data on the table. Then a catalog like one of the three above, but theirs.

Sometimes that read says do not do this. A business with a clean catalog, a simple book, and a number finance already trusts does not need any of it, and selling them a build is how you lose the next three referrals. That is a real outcome of the work rather than a failure of it, which took me a while to be comfortable saying out loud.

If you are somewhere in one of these three and want to know what your own catalog is actually doing, the fastest thing is not to hire anybody. Pull your product list, pull the line items from the last two years, and count how many of your products the second list has ever touched. That number is usually the whole conversation.