Designing Products and Variants the Obelaw Way

When teams outgrow spreadsheets, the first real pain usually shows up in the product catalog.

At small scale, “product” feels simple: a row with a name, SKU, and price. But very quickly you need sizes, colors, regional pricing, bundles, and channel-specific rules. If the underlying model isn’t right, every new requirement becomes a hack—and your team pays the price.

In the Obelaw Stack, we take a clear, opinionated approach to products and product variants so your catalog stays flexible, consistent, and fast.

Product vs. Product Variant

We start with a simple distinction:

Product – the conceptual thing you sell. E.g. “Classic Hoodie”.
Product Variant – a concrete, buyable instance of that product. E.g. “Classic Hoodie / Black / M”.

Why separate them?

Clarity for humans: Merchandisers think in products; operations and warehouses think in variants.
Clean data: Shared data lives on the product; specific data lives on the variant.
Performance: Search, merchandising, and inventory each query the data they actually need.

In Obelaw PIM, you can safely attach logic, workflows, and integrations to either level without mixing concerns.

What Belongs on a Product?

The product is your canonical marketing and merchandising container.

Typical examples of product-level data:

Name, short name, and marketing description
Brand and collections
Default imagery and media
Category placement and attributes shared by all variants
Global status (active, archived, preview)

This is the data buyers see on listing pages and detail pages before choosing a specific option.

In the Obelaw Stack, these attributes can be extended using flexible schemas and systems like Attrify, so you can model exactly what your catalog needs without schema churn.

What Belongs on a Variant?

Variants hold everything that makes a specific offer unique and buyable.

Common variant-level data:

SKU and barcodes
Option values (size, color, material, region, etc.)
Inventory and availability
Cost and price overrides
Shipping weight and dimensions

This is the level your warehouse, WMS, and order management care about. In Obelaw, this variant view connects directly with stock, locations, and other WMS concepts so inventory always belongs to the right thing.

Options and Attributes: How Variants Are Generated

Most teams start with a mental model of “Size” and “Color” and quickly discover they need more. Think “Fit”, “Region”, “Voltage”, or even “Subscription Term”.

We model this via:

Option Types – the dimension (e.g. Size).
Option Values – the choices within that dimension (e.g. S, M, L, XL).

Variants are then generated as combinations of option values, with the flexibility to:

Generate all combinations for simple catalogs.
Curate specific combinations for complex catalogs (e.g. only some colors in some sizes).

Because options are first-class in Obelaw PIM, you can keep option logic central while still allowing rich, per-variant attributes.

Pricing: Product-Level vs. Variant-Level

Pricing is often where a good model breaks down.

In Obelaw, we encourage a layered pricing model:

Base Price at Product: A default list price that applies when nothing overrides it.
Variant Overrides: For sizes or materials that are more expensive (e.g. XXL or premium fabric).
Contextual Rules: Channel, region, or customer-segment pricing layered on top.

This lets you answer questions like:

“What is the price of this hoodie in EUR for retail customers?”
“Which variants are discounted in this campaign?”

All while keeping your catalog readable and maintainable.

Inventory and WMS: Why Variants Matter

From a warehouse and inventory perspective, the variant is the star of the show.

Your WMS cares about:

Which exact thing is stored at a location
How many units exist and in which status (on hand, reserved, damaged)
How movements, picks, and counts affect stock

By treating inventory as attached to variants (not generic products), Obelaw WMS keeps stock movements precise, which in turn powers accurate availability in your channels.

Bundles, Kits, and Virtual Products

Real catalogs often need more than simple single-item SKUs:

Bundles: Pre-configured groups of products sold together.
Kits: Assembled at pick/pack time from underlying variants.
Virtual Products: Access, subscriptions, or services.

In Obelaw, these are modeled on top of the same product/variant foundation. Bundles and kits reference other variants, while virtual products can still use the same pricing, availability, and attribution mechanisms.

Common Anti-Patterns (and How We Avoid Them)

We see a few recurring pitfalls in product modeling:

Encoding options in the SKU: Makes reporting and integrations brittle.
One row per size/color with no parent product: Catalogs become impossible to merchandise.
Hardcoding extra columns for every new attribute: Schema changes for every category.

The Obelaw Stack avoids these by keeping products and variants separated, options structured, and attributes extensible.

How This Fits into the Obelaw Stack

Products and variants don’t live in isolation. They connect to:

PIM: For rich product information and flexible attributes.
WMS: For precise stock, locations, and movements.
Pricing & Promotions: For layered, context-aware pricing.
Twist & Flow: For publishing to channels and automating workflows.

Because everything shares a consistent product/variant model, data can move cleanly between systems without endless mapping and glue code.

Where We’re Going Next

We’re continuing to invest in:

Smarter variant creation tools and helpers
Better bulk-editing flows for large catalogs
Deeper integrations between PIM and WMS around availability and reservations

If you’re designing or rethinking your catalog, a solid products-and-variants model is one of the highest-leverage decisions you can make.

We’ll be sharing more deep dives into PIM, WMS, and pricing in future posts. If there’s a specific scenario you’re struggling with—like B2B pricing, multi-warehouse setups, or complex bundles—we’d love to hear from you.