Products and bundles
Selling more than one thing, and selling them together.
Products group plans and features
An environment selling four things needs to say which product a plan or feature belongs to. Without that, "Pro", "Team" and "Starter" sit in one list with nothing distinguishing them.
A product (a product family) is that grouping. Plans belong to one; features belong to one.
Both links are optional. A catalog written before products existed has none, and "ungrouped" is the honest answer for it.
A bundle is a plan
There is no separate bundle object. A plan version already draws its entitlements and prices from any feature in the environment, so:
A plan whose features span several products is a bundle.
The same way a creative suite is one SKU rather than a folder of subscriptions.
That means everything else already works: billing, proration, MRR, dunning and
check treat a bundled feature exactly like any other. Nothing downstream had
to learn what a bundle is.
What it costs
A bundle has one price and one renewal date. A customer cannot cancel half of one without changing plan.
That is how a suite is normally sold. If you need per-product cancellation, sell per-product plans instead — a customer can hold several subscriptions.
Invoices group by product
A customer paying one price for three products still needs to see which part was which, so invoice lines are grouped by the product of the feature they price.
The plan's own recurring fee prices no single feature, so it is grouped on its own rather than attributed to whichever product happens to sort first.
Retiring a product
A product cannot be archived while live plans still belong to it. Otherwise a subscription would point at a product the catalog says does not exist, and its invoices would stop being explainable. Archive the plans first.
Archived products leave the picker but stay readable, so an existing invoice still explains itself.