Your Operating Model is Your Real Tech Spec
Stop evaluating tech in isolation
Here’s something that happens all the time in fashion tech buying: two brands, similar size and revenue, both get pitched the same tech. One brand implements it and loves it. The other implements it and it becomes a nightmare. Same software, same implementation partner, completely different outcomes.
The difference isn’t the tech. It’s the operating model the tech has to survive inside.
“Best-in-class” is only meaningful inside a specific context. Tech that’s perfect for a brand running two clean seasonal buys can be a disaster for a brand pumping out thousands of SKUs with constant trading changes. The limiting factor isn’t the tool. It’s whether your operating model can actually feed it.
When the operating model can’t feed the tech
I spoke with a mid-market brand that implemented a new ERP system. Full training program, everyone signed off, change management done properly. Three months after go-live, the buying team was still raising purchase orders in the old system.
Not because they didn’t know how to use the new one. They’d been trained. The problem was that the new ERP needed structured data files to create POs efficiently. Their buying process produced inconsistent spreadsheets that different buyers formatted differently. The tech worked fine. Their operating model just couldn’t feed it properly.
The operations team ended up manually copying data from the old system into the new one. Every. Single. PO. They’d paid for automation and ended up with more manual work than before.
That’s what happens when you evaluate tech in isolation.
Operating model inflection points
Most brands can tell you their tech roadmap. Fewer can tell you how their operating model might change in the next two years. That creates a problem, because operating model changes invalidate tech decisions faster than anything else.
Here’s what actually changes how you operate:
Volume inflections. Going from 200 SKUs to 800 SKUs per season changes everything about how you work. Data management that was manageable with a small team becomes impossible. Review cycles that worked for dozens of products break down at hundreds.
Channel shifts. Adding wholesale or marketplace channels doesn’t just add sales volume. It adds data requirements, different pricing structures, different lead times. A system optimised for pure DTC can struggle badly when you suddenly need to manage trade orders and EDI feeds.
Speed changes. Moving from two seasonal collections to monthly drops or weekly launches isn’t just doing the same thing faster. It’s a different operating model. Systems built for considered, sequential development don’t cope well with constant parallel workflows.
Regulatory requirements. Government and industry changes force brands to think differently. EPR schemes require detailed material composition data. Tariff updates mean country-of-origin tracking becomes critical overnight. Supply chain due diligence legislation demands supplier documentation and audit trails. These kinds of regulations essentially force brands to decide: are we a “spreadsheet plus human” business or a “system plus automation” business? That’s an operating model question, not a tech question.
Ownership changes. PE acquisition, merger, new leadership with a different philosophy. These change operating models overnight. Your carefully chosen tech stack might not match the new parent company’s ways of working at all.
Most brands know one of these changes is coming. They rarely know which one or when.
The build for tomorrow trap
Common scenario: a brand doing 200 SKUs per season has ambitious growth plans. They target 1,000 SKUs within two years. So they buy an enterprise PLM with every feature turned on, ready for that future state.
Their current team is three people. The enterprise system was designed for teams of 15. They drown in complexity. Features sit unused. Workflows designed for high-volume operations make simple tasks take longer. Two years later, they’ve hit 350 SKUs, not 1,000. They’ve paid enterprise pricing for capability they never needed.
The miscalculation wasn’t about the tech. It was buying tech for a hypothetical future operating model instead of their actual operating model trajectory.
The perfect fit today trap
The opposite happens too. A brand picks a lightweight system that matches their current operations perfectly. It does exactly what they need right now. Eighteen months later, an acquisition doubles their SKU count and adds a wholesale channel. The system can’t handle the volume. It has no multi-channel logic. Now they’re facing a painful migration, losing configuration work, and dealing with data transfer headaches.
They optimised for today without any flex room for tomorrow.
So what do you actually do?
You need to evaluate tech against both your current operating model and the operating model changes you can reasonably predict. Not the operating model you aspire to or the one your investor deck describes. The one you actually have, and the changes that are likely (not just possible) in the next 24 months.
Start by mapping your current operating model honestly. How many SKUs do you develop per season? How often do those numbers change? How many people touch product data? What formats do they work in? How structured is your buying process? How much trading happens mid-season? Do you have one channel or multiple? One market or several?
Then look at what’s actually changing in the near term. Not “we might expand to the US someday.” Look at contracts already signed, channels already launching, headcount already approved. What operating model changes are already locked in?
That gives you a range. Your tech needs to work for your current operating model today, and still work for your operating model in 18-24 months based on changes you’re confident about.
Building in optionality
Some brands approach this differently. They architect with integration middleware from day one. When they needed to swap their WMS two years later, it took six weeks instead of six months. When they added a marketplace channel, the new system plugged into existing data flows.
It costs more upfront. But it creates optionality. If your operating model changes in an unexpected direction, you can swap out components without rebuilding everything.
The challenge is that most mid-market brands don’t have the budget or technical sophistication for that approach. So they need a different strategy.
The good enough plus known exit approach
This is gaining traction: pick tech that fits your current operating model well, but ensure it has a clear upgrade path or accept that you’ll migrate in three years. Budget for that migration from day one. Treat it as operational reality, not failure.
One brand we know did this deliberately. They knew their lightweight PLM wouldn’t scale past 500 SKUs. They were at 200. They bought it anyway, used it productively for 2.5 years, then migrated to an enterprise solution when they hit 450 SKUs. Their total cost over five years was actually lower than buying enterprise from day one, because they got 2.5 years of high productivity instead of struggling with over-complex tools.
They made the migration decision with open eyes, not as a rescue operation.
A simple framework
Here’s how to think about it:
If your current operating model is stable and you have high certainty about how it will change, you can buy for that future state. But not too far ahead. One major inflection point ahead, not three.
If your operating model is stable but you have low certainty about future changes, buy for today but prioritise integration flexibility. Make it easy to swap components later.
If your operating model is currently changing, wait if you can. Use interim solutions until things stabilise. Implementing new tech into an unstable operating model usually fails.
If your operating model is changing and you have low certainty about where it lands, go modular. Pick tools that can be swapped out without breaking everything else.
What this means for your next tech decision
Stop evaluating tech in isolation. Before you start vendor demos, audit your operating model. Get specific about SKU counts, development cycles, buying frequency, channel complexity, team structure. Not the version in your pitch deck. The version that actually exists today.
Then get specific about what’s actually changing in the next 18 months. Channel launches with signed contracts. Regulatory requirements with known deadlines. Ownership changes already in motion.
Match the tech to that range, not to some aspirational future state that might never happen.
Your operating model is your real tech spec. Everything else is just features.