The Retail Tech Risk-A-Tron

How the anatomy of retail combines to give its tech projects a unique risk profile

Disclaimer

I’ve tried not to make this a piece about how special and complex our challenges are and how smart and brave we are for facing them every day…

What this hopefully is, is a proportional analysis of what is unique about delivering tech change in retail, what makes it difficult, and how to make it easier.

And, when I say ‘a unique risk profile’, I don’t mean ‘more risky than everything else’, I mean ‘risky in a way which is unique because of its context’. It’s not saving lives, we know that. It’s not as complicated as running a government, we know that too.

Enough disclaimer.

Why are retail tech projects different?

The Direct-to-Consumer Relationship

Often intimate. Great brands evoke strong emotions.

Most retail tech is built for consumers to use directly. Unlike in healthcare, pharma, defence, energy, and others — the organisation that delivers the project (the retailer) is the same organisation that fronts up to the end user (the consumer). No go-betweens. No protective layer. No masks.

And, it’s not a great risk/reward balance. The consumer expects the tech to work. So, it’s not like the risk of immediate negative consumer feedback if the tech is flawed is offset by the opportunity for immediate consumer gratitude if the tech works perfectly.

The rewards for a project well done are revenue-based (retention, growth) for the retailer, and professional pride for the project team. These are far less tangible benefits than the very tangible un-benefit of hyper-critical social media shit-blizzards (‘shitstorm’ feels tired) when things go wrong.

The Problem of Scale

An ostensibly cosmetic issue, like neglecting to test each special character to determine which a WMS can accept and missing that it has some rather Brexit-y preferences (“ß? What is this… Das Kapital??”), could mean that a surge of orders from Europe’s biggest economy will see hundreds, nay thousands of orders not reach the warehouse. Not be shipped on time. Social media turdnado incoming.

What I’m getting at, for fans of more direct rhetoric — a small problem magnified over 5k, 10k, 50k, 100k orders is no longer a small problem. Minor mistakes can be punished major in retail tech.

Inventory Complexity

The retailer with multiple 3PLs, perhaps even a warehouse of their own, or a central DC, an armada of bricks and mortar stores, stock on consignment with 3rd parties, stock at franchises which they might buy back, stock unsold at popups being ‘warehoused’ at a founder’s house, wholesale distributors in several countries and wholesale stock pools in some of those 3PLs — stock on multiple continents, subject to different tax legislation, managed by different 3PLs on multiple systems and serving different sales channels (sometimes simultaneously). The objective — never oversell, never undersell. Easy.

And if a new project so much as tickles this delicate house of cards; breathes near the wobbling CX jenga tower — it can all come crashing down. Alert reverberating off the jigs and jags in the rubble — barely audible over the human air-raid sirens — says: “Inaccurate stock levels — oversells reported — wholesalers miffed — consumers triple-miffed”.

The Robustness Delusion

A lot of business leaders — a lot — simply don’t think that a bad software project is a real threat to their interests. “What’s the worst that can happen?”, they say. I don’t criticise. The bravery is admirable, really. We, the normies, nervously fidget and twitch in awe at your microscopic amygdalae, oh fearless ones.

But this thinking can mean retailers pushing ahead with projects with more red flags than a Chinese military parade; launching things before they’re ready; blasting off to the inhospitable planet of ‘live’.

Nothing unique about that, right? That’s not industry-specific. Lots of business leaders ignore the informed advice of their specialists and do what they think best.

True. But in retail, selling product is the lifeblood, and in a worse case scenario, a badly delivered project can stop you selling product. Then you’re a body without blood, which tend not to last very long.

That is different to other industries. Fintech, for example. If a dodgy update gets deployed to a banking app there’s consumer blowback, but the bank still has the consumers’ money, they’re still getting paid for premium accounts, they’re still making their NIM, and if they’re an ‘old-school’ bank, their customers can still go to a physical bank if they need to.

Just like humans live most of their lives blissfully neglecting awareness of how fragile life is, retailers go day-to-day without living in fear of losing their lifeblood — sales of product. This is the robustness delusion.

The Hyper-Competition Environment

A bad software project delivered for the public sector is backed by a long and gnarly contract, so the unlucky end users’ best course of action is probably just to deploy patience.

A bad software update to a social media app is inconvenient but, again, as a user, are you really going to switch to using a different platform? What about all of your previous posts, followers, etc. You’re baked in. You wait out the problems.

Even projects which affect products post-purchase — a bad update to Peloton (for example), do you really take the bike back? Maybe, but it’s a bit of a pain to do that, isn’t it? May as well just wait until they release the patch.

But in retail, if the consumer can’t buy from you, the retailer, unless they have elite brand loyalty they just go and buy from one of the many, many alternative options. Makes sense, right? It’s a helluva lot easier than moving from Twitter to Threads, returning a Peloton, moving banks, cancelling a government contract, etc.

Alllll of that money, time and creativity that goes into getting a customer into a buying position with you in the first place — to waste that opportunity… it’s a cardinal sin of retail.

The upshots for tech change project teams: you may be re-tracking as the trains continue to run, but any passenger disturbances are (understandably) unacceptable.

Count them up

It’s these 5 aspects—

• DTC relationships

• Problem of scale

• Inventory complexity

• Robustness delusion

• Hyper-competition

—that can (though not always) create a risk profile heavily weighted on the wrong side: lots of immediate risk, little immediate reward.

Classic examples:

• ERP migration

• iPaaS implementation

• Website overhaul

In all three of these endeavours, for predominantly DTC retailers, the risks are stacked in such a way as to exacerbate each other and compound.

One small technical mistake in the project can be exposed over and over again by a high volume of transactions. The delicate equilibrium of cross-system inventory accuracy can be easily disturbed. Against good advice, projects can be pushed to completion faster than is advisable, exposing even more technical issues to the outside world. The hard-earned bonds a retailer has with its customer base can be damaged. And, swathes of competitors are ready to swoop in and capitalise if that happens. Even the camels are sweating now.

Lots of tech directly affects consumers. Lots is challenged by huge volumes of users and data. Lots has inventory complexity to deal with. Lots is used by leaders’ who occasionally steer their ships unwisely. Lots is used to power vital perpetual selling. And, lots exist in hyper-competitive industries. But does anywhere other than in retail tech risk having all of those be at play in a single project?

“Sounds terrible — What Can We Do?”

First of all, don’t fret too much. Not all projects have this potentially lethal mix.

Maybe the classic Pareto ratio. 80% of retail tech projects won’t bite your head off and chew. It’s just the remaining 20% that could. Nay, will, if you don’t get your shit together.

And re getting said shit together. It’s pretty simple, actually.

1. Have the right people running the project.
   
   People who really understand this stuff. People who are so scarred by projects that went wrong they’ve become totally militant on details and organisation. People who know all the edge cases to test. People that know what can happen if you don’t test the edge cases. People you trust. People you can have difficult conversations with. Top collaborators.
   

2. Listen to them.