COGS & SKU Profitability Engine
Took an Excel MVP for product cost and turned it into a production application covering standard products and a very large custom catalog.
Cost, margin, and product-level profitability became visible for about 3,000 standard SKUs and more than 800,000 custom combinations.
- Role
- Partnered with business, operations, and technical stakeholders to design, iterate, and put the cost logic into production use.
- Scale
- About 3,000 standard SKUs and more than 800,000 custom SKU combinations.
From spreadsheet logic to production coverage
Excel was used first to validate the cost rules with the business, before the same logic was scaled in a production application.
- 1
Excel MVP
- 2
Business rules validated with finance and operations
- 3
Production data model and application
- 4
Approximately 3,000 standard SKUs
- 5
More than 800,000 custom combinations
Problem
Pricing and channel decisions depend on knowing what a product costs. For a configurable catalog, that cost is a calculation: size, shape, material, and adjustments, not a single purchased SKU.
Without that calculation, margin conversations collapsed to averages. Averages hide the custom work that is either the best or the worst business in the catalog.
Why the spreadsheet MVP was useful
The first version was Excel on purpose. A workbook let finance and operations test the rules on real products before anyone committed to a schema.
The MVP was successful because it made the business logic visible. People could point at a row and disagree with a rule. That disagreement was the requirements process.
Why the solution needed to scale
A workbook can explain 3,000 standard SKUs only with discipline. It cannot be the system of record for more than 800,000 custom combinations that are generated from dimensions and product rules.
Scale also meant more than row count. The same cost needed to show up in pricing, advertising, and executive reporting without a fresh export and a private copy of the logic.
Data-model and workflow design
The production model separated inputs that change (materials, rates, adjustment codes) from the rules that interpret a SKU. Standard products and custom combinations shared the same cost language, so a margin report did not need a second definition for “made to size.”
The workflow was: agree the rule, test it against known products, then let the application apply it. I did not publish proprietary formulas. The design principle was that a cost is explainable from product structure, and that unexplained cost is flagged rather than invented.
Stakeholder collaboration
Business owners knew which costs were real. Operations knew which attributes actually changed manufacturing. Technical partners knew what could be calculated reliably at this volume.
My job was to keep those constraints in one model and to sequence delivery so the first production slice was already useful: standard SKUs and the custom patterns that drove the most margin uncertainty.
Adoption and outcomes
The application became the place to answer whether a product was profitable, instead of a side workbook that only one analyst could run. Visibility improved for cost, margin, and product-level profitability across the standard catalog and the custom combinations the rules could generate.
That visibility fed pricing and advertising decisions. A bid or a price that ignored this cost picture was easier to challenge.
Lessons learned
Ship the spreadsheet if that is what creates a shared rule. Do not leave the business on the spreadsheet once the rule is stable and the combinations outgrow it.
The hard part was not the interface. It was agreeing what a SKU means, and refusing to calculate a cost the inputs could not support.