Reckitt is one of those companies that is probably part of your daily life even if you rarely think about the name behind the products.
Behind brands such as Durex, Finish, Lysol, Dettol, Mucinex and Nurofen sits a global operation that depends on something far less glamorous than a major advertising campaign or a breakthrough product launch: making sure the right product is available, properly placed and correctly promoted across thousands of stores.
In a consumer goods company, a decision made in an office can travel a long way before it becomes revenue.
First, someone decides which product to push, at what price, in which market and under which promotion. That decision then moves through distributors, retailers, commercial teams and merchandising staff. Eventually, it reaches the shelf.
It is in that final stretch that a perfectly sensible strategy can fall apart.
A product may appear as available in inventory and still be out of reach for the shopper. A promotion may already be live while the corresponding display has never been installed. A store may receive a commercial visit and yet the limited time available may be spent on tasks that barely affect sales.
Reckitt knew this problem well.
The company had already worked on improving how it made commercial decisions around pricing, promotions and assortment. Better planning, however, did not automatically solve what happened inside each store.
That became the starting point for a collaboration with McKinsey that would eventually become Smart Execution, a system supported by advanced analytics and artificial intelligence.
The interesting part of the case is not that it eventually used AI.
It is how they got there.
A forty-minute visit
In the United States, Reckitt relies heavily on brokers and merchandising teams that visit stores to make sure products are available and properly executed.
A visit may last anywhere from thirty minutes to an hour.
During that time, there can be dozens of things worth checking: inventory, promotions, displays, product placement, planogram compliance, pricing and issues affecting specific SKUs.
Viewed as a task list, the problem seems straightforward: there is too much work and too little time.
Viewed as a business problem, it becomes much more interesting.
Every visit costs money.
Every minute inside the store is a scarce resource.
That means not every task has the same value.
The important question stops being whether the merchandiser completed everything assigned. It becomes whether the person spent that time on the actions most likely to improve the business outcome.
That distinction was critical.
Reckitt could see how much it was spending on store execution. It was much harder to understand how much value each visit, task or intervention was producing.
A conventional reaction to a cost of that size would have been to reduce it.
Fewer visits. Fewer people. Lower spend.
But that was not necessarily the best question.
There was another possibility: perhaps the issue was not how much the company invested in execution, but how that investment was allocated.
The problem hidden inside the problem
When a company frames the wrong question, even an efficient answer can make things worse.
“How do we reduce merchandising cost?” naturally leads toward cuts.
“How do we make every visit produce more value?” forces the organization to look at the system differently.
To answer the second question, Reckitt needed to know which stores deserved attention, which products had a problem and which specific action could change the outcome.
Much of the necessary information already existed.
Sales data.
Inventory.
Promotions.
Historical performance.
Product characteristics.
Planograms.
Retailer information.
Results from previous visits.
The problem was not that the company was blind.
The problem was that turning all of that information into a useful recommendation took too long.
A human analyst could investigate why a product was selling below expectations in a particular store. The analyst might discover that inventory was available, a promotion was active and the product was supposed to appear in a special display.
The conclusion could be simple: the product was probably in the store, but not where it needed to be.
That conclusion has value because it produces a concrete action.
Check this product.
Verify this display.
Fix this problem.
But doing that analysis for one store is very different from doing it continuously across thousands of stores and thousands of products.
That is where the real bottleneck appeared.
Human intelligence was not missing.
Scale was.
When the right answer arrives too late
This detail of the case deserves attention.
Much of the analysis that was eventually automated could already be performed by people.
The difficulty was time.
An analysis could take days. By the time the conclusion arrived, conditions inside the store might already have changed.
In operations, the quality of a decision does not depend only on whether it is correct.
It also depends on when it arrives.
An excellent recommendation about a problem that has already disappeared has little operational value.
Seen this way, Smart Execution did not begin primarily as an artificial intelligence project. It began as a way to reduce the distance between a signal and an action.
The technology started evaluating large amounts of information continuously and turning them into more specific priorities for field teams.
Instead of treating every store the same way, it could indicate where an opportunity deserved attention.
Instead of presenting a long list of tasks, it could reduce that list to the actions most likely to create an impact.
AI did not necessarily replace the person visiting the store.
It removed part of the hardest work: deciding, among too many possibilities, where attention should go.
Productivity is also about choosing better
There is a simple idea behind all of this that often gets lost when we talk about automation.
A person can work faster and still work on the wrong things.
A process can be completely digitized and continue wasting resources.
A company can have better dashboards and still make decisions too late.
I have seen smaller versions of this problem in software projects: teams asking for a new screen, an integration or a dashboard because it feels like the natural solution, while the real issue sits one step before or one step after. Sometimes the information already exists, but nobody knows what decision should follow from it. Sometimes the process is automated without first asking whether it made sense to preserve the process as it was.
Experiences like these have made me suspicious of solutions that arrive too early.
Digitizing an inefficiency still leaves you with an inefficiency.
Productivity is not only about doing more.
It is also about choosing better.
That was one of the fundamental changes in Reckitt.
The conversation moved away from focusing exclusively on how much store execution cost and toward how much growth better execution could produce.
That is an important conceptual shift.
A budget that once looked like a cost to control can begin to look like an investment to optimize.
And when the economic question changes, the decisions a company is willing to make change with it.
What made the consulting work valuable
The technological outcome of the case is interesting, but I do not think it is the most valuable part.
McKinsey did not simply arrive with a tool to install.
The important work was helping connect several layers of the business that could easily have been treated as separate problems: commercial strategy, data, field work, store behavior and economic return.
That requires looking at an operation as a system.
Poor execution on the shelf is not simply a merchandiser problem.
It may be the result of bad prioritization, fragmented information, analysis that arrives too slowly or a flawed way of measuring work.
And if the intervention focuses only on the last visible part of the problem, it is possible to improve the symptom without changing the cause.
This is one of the reasons I find projects like this more interesting than software development as an isolated delivery exercise.
The starting point is not a specification.
It is an investigation.
How does the operation actually work?
Where is value being lost?
Which decisions are repeated?
What information do people use to make them?
What information exists but arrives too late?
Which constraints prevent a better outcome?
In my experience, the earlier this work happens, the better the technical result tends to be. Many architecture, scope and rework problems appear because a team starts building before it has clearly understood which part of the business actually needs to change. Engineering can execute a poor hypothesis with extraordinary precision.
Only after that does it make sense to decide whether the answer requires software, integration, automation, analytics or artificial intelligence.
A different way to think about technology
For years, much of the technology industry has been organized around a fairly comfortable question:
What does the client want to build?
The client arrives with an idea. The team estimates scope, time and cost. Development begins.
That work is still necessary.
But it is not always where the most value is created.
A company can ask for exactly the wrong software to solve a perfectly real problem.
It may request an application to digitize a process that should first be redesigned.
It may ask for a dashboard when what it actually needs is a decision.
It may ask for artificial intelligence when the real problem is data quality.
Or it may assume that new technology is required when the bottleneck is organizational.
That is why I am increasingly interested in working one step before the solution.
Understanding the business well enough to discuss what should change before discussing what should be built.
My background is in technology, but I do not see technology as the final product of this kind of work.
I see it as a tool for changing the economics of an operation.
Reducing time.
Eliminating waste.
Allocating resources more effectively.
Increasing capacity.
Improving a decision repeated thousands of times.
Turning fragmented information into useful action.
The Reckitt case is a good reminder that some of the best technology projects do not begin with a software idea.
They begin when someone studies a business closely enough to find a better question.
Source: McKinsey & Company — How AI-enabled execution became Reckitt’s tenfold game changer.
