When the Perfect Future Becomes Your Biggest Competitor

PR doesn’t just sell products.

Sometimes it sells a vision of the future so convincingly that it stops people from buying a solution that already works today.

I learned this lesson firsthand.

A few days ago, it was announced that Tiv Taam is beginning to replace its checkout systems with a solution from Supersmart.

I have a particular connection to that story.

Before COVID — which now feels like retail-tech prehistory — I worked at Supersmart and led the company’s machine learning team. A significant part of our work focused on one of the least glamorous but most important aspects of automated checkout: making it reliable.

The basic idea behind Supersmart was relatively straightforward from the customer’s perspective. Instead of scanning every product individually at a traditional checkout, customers scan items as they put them in the cart, and the system validates the entire shopping cart at checkout in a single step — within roughly two seconds.

But making something like that work reliably in an actual supermarket is very different from making a good demo.

Real customers don't behave like your test cases.

Products overlap. Packaging changes. Products look similar. Stores have thousands of SKUs. New products appear. Weight varies. Sensors produce noise. Hardware behaves differently from one installation to another.

And when you're dealing with checkout, mistakes matter.

A recommendation system can occasionally recommend the wrong movie and nobody cares very much. A checkout system that regularly misses products or requires an employee to intervene every few transactions isn't really an automated checkout system.

So a lot of our work was developing machine-learning algorithms for detecting checkout errors in both directions: false positives and false negatives.

The goal was to build a system that could survive millions of real shopping carts.

Today, it does, in hundreds of stores around the world.

And while we were trying to build that system, we had a rather unusual competitor.

Not another startup.

Not another checkout machine.

The future.

Amazon Go Was Right Around the Corner

At the time, selling automated checkout technology to retailers was difficult for an obvious reason:

Amazon Go was coming.

And if you've forgotten how futuristic Amazon Go seemed back then, the pitch was incredible.

You walked into a store, took whatever you wanted from the shelves, and walked out.

No checkout. No scanning. No stopping.

Somewhere behind the scenes, cameras, sensors, computer vision, and machine learning would figure everything out, charge your account, and send you a receipt.

It wasn't simply a better checkout.

It was the disappearance of checkout.

And it had Amazon behind it.

That created two problems for companies like ours.

The first was obvious: good luck competing with Amazon.

But the second was much more interesting.

We weren't only competing against Amazon's actual product.

We were competing against Amazon's promise.

Imagine you're running a supermarket chain and someone comes to you with a practical automated-checkout solution.

It works. It can be installed. It solves a real problem.

But implementing it still requires money, integration, training, hardware, and management attention.

Then you look at Amazon Go.

Why invest in an imperfect solution today when the perfect solution is apparently two years away?

The rational thing can suddenly feel like waiting.

And that is where narrative becomes economically important.

A sufficiently convincing vision of the future can freeze purchasing decisions in the present.

Then Reality Happened

Years passed.

The frictionless retail revolution did not spread across every supermarket.

The technology turned out to be much harder and more expensive to deploy at scale than the original vision suggested.

Eventually, Amazon announced that it was closing its Amazon Go stores.

Meanwhile, retail technology kept developing.

But much of the technology that actually reached stores looked considerably less magical: smart carts, assisted self-checkout, computer vision, weight verification, fraud detection, and systems where automation handles most cases while humans handle the exceptions.

They don't completely eliminate checkout.

They make checkout better.

And many of them work.

That distinction is important because we have a strange habit in technology: comparing real products with imagined ones.

The real product has errors, integration costs, operational constraints, and ugly edge cases.

The imagined product has none of those things.

Unsurprisingly, the imagined product usually wins.

Until someone actually has to build it.

Reliability Is a Feature

One of the things I took away from working on Supersmart was a much stronger appreciation for reliability as an engineering goal.

In research, we often focus on model performance.

Accuracy improves from 96.2% to 96.8%.

AUC goes up.

False positives go down.

A new architecture beats the baseline.

Those improvements matter.

But production systems add another dimension.

The customer doesn't care how elegant your model is.

They care whether the system works.

For us, that meant questions such as: How often can a transaction complete without intervention? How often do we flag a valid cart? How often do we miss an actual discrepancy? Can the system survive the technical and performance tests of a retailer's loss-prevention team?

And, most importantly, what happens when the system fails?

A system that is 99% accurate but fails catastrophically 1% of the time may be much worse than a system that is 97% accurate but handles its failures gracefully.

That kind of work rarely looks as impressive in a promotional video as a customer simply walking out of a store.

But it can be the difference between a technology demo and a product.

Building the Product Isn't Enough

There are two broader lessons I take from this story.

The first is about narrative.

We usually think about PR and marketing as something that happens after the product is built. Engineering builds the thing; someone else tells the world about it.

I think that's the wrong way to look at it.

Amazon's narrative was powerful enough to influence purchasing decisions long before its vision became a broadly deployable product.

That means that if you're building the less magical solution — the one that actually works — explaining it properly is part of the job.

This is especially true for engineering and technology leaders.

Our responsibility isn't only to make the system reliable, scalable, and economically viable. We also need to make sure customers, executives, investors, sales teams, and other stakeholders understand what we built, why it matters, and why the supposedly imperfect solution may actually be the better one.

Good engineering that nobody understands has a real disadvantage against a beautiful promise.

We sometimes dismiss this as “marketing.”

We shouldn't.

Communicating our work correctly is part of delivering it.

If the market thinks your competitor has solved the future while you're quietly solving today's actual problem, technical superiority alone may not be enough.

"Good Enough" Is Often an Engineering Achievement

The second lesson is about perfection.

Engineers naturally like elegant solutions.

We want the architecture that solves the whole problem. The model that generalizes everywhere. The automation that eliminates the manual process entirely.

But the theoretically superior system is not necessarily the better product.

A product has to exist inside a messy environment: existing stores, employees, supply chains, customer behavior, economics, and operational constraints.

The best solution is often not the one that removes every imperfection.

It is the one that chooses the right imperfections.

A system that automates 90% of a process reliably and provides a sensible workflow for the remaining 10% can be far more valuable than one promising 100% automation under ideal conditions.

And importantly, that doesn't mean settling for mediocre engineering.

Quite the opposite.

Making an imperfect system into the best production system is often much harder than building an impressive prototype.

Build Something That Can Exist Today

Looking back, the interesting part of the Amazon Go story isn't that Amazon failed and someone else didn't.

Technology doesn't develop that neatly.

The more interesting lesson is what happens when we confuse a compelling technological direction with an actual solution.

As engineering leaders, we constantly need to ask ourselves more than:

“Does this solution look good in the presentation?”

We need to ask:

Can we get it into customers' hands at the right time?

Will it perform reliably when it gets there?

And can we communicate its value with the same clarity and excitement with which someone else communicates the perfect future?

Because ultimately, you don't need to build the perfect future.

You need to build something customers can use today.

And you need them to understand why they should want to use it.