In Practice: E3 — Storing Logic in SKUs

15d (edited) • In Practice

On the production floor, I learned something by watching a company try to grow:

When specs and cost logic get blended together, you eventually build yourself into a corner.

I saw it happen when SKUs slowly became information storage.

Instead of simply identifying a product, they started carrying meaning like fabric color. It worked for a while. I was even convenient in a lot of ways...

Until growth required clarity and separation.

When information lives inside identifiers instead of clean documents, every change becomes a workaround. You’re not adjusting the system, you’re navigating through it. Scaling gets heavier than it needs to be.

That’s a lesson I’ve been thinking about as I rebuild Dragonswood.

Seperation leads to clarity, and you need clarity to scale.

Spec Sheet: What the product is. Dimensions. Deliverables. Variants. Limits.

BOM: What the product costs. Materials. Quantities. Current pricing. Time test. Labor rate.

Different jobs.Different documents.Clear lines.

Not flashy. Just structural.

In Practice — Assignment:

Do you use SKU's yet?

Do your SKUs carry more meaning than they should?

Where does pricing logic actually live?

What part of your system depends on memory?

1 comment