Enterprise Field Notes · Issue #16
Home Depot Had AI in 600 Stores Six Weeks After ChatGPT Launched. It Was Not Watching ChatGPT.
Most of what I know about this I learned by getting it wrong at scale.
New here? Subscribe to Enterprise Field Notes, one new issue every week.
On January 12 2023, Home Depot announced an app called Sidekick. It ran on a phone in a store associate's apron pocket, and it told them which shelf to restock next and where to find the product to do it.
ChatGPT was forty-three days old. Sidekick was already in more than 600 stores.
So Home Depot was not responding to ChatGPT. They had been working on this for years, with computer vision and inventory data and task routing, and the timing was a coincidence.
I spent a long time leading teams building systems like that one. Mostly we built them from a conference room.
One thing before I start. I sell AI for a living. I am COO at Swa Technology, so weigh this however you like. The tooling matters, and I would not be doing this if I thought otherwise. What decides whether it lands is the planning and the implementation around it, and that is what the rest of this is about.
I wrote the version where somebody got that right back in June. Walmart did the planning first and then built for it, and you can see the result in the numbers. That piece is here if you want the encouraging half. This one is the other half.
The returns system
For years I led reliability engineering for a very large retailer.
Our returns system is the one I would start with. We were proud of it. It made a single return easy to process, and by the measure we had chosen, it worked.
Then we went and looked at a store with high returns. An associate there was running every item through that clean process, one at a time, and it could take most of a day. More than nine hundred separate actions, by one person, while the floor went uncovered.
The system was excellent at a return. Nobody had designed it for a day of returns.
So we watched how the associate actually worked and rebuilt it around that. Hours became minutes, and the person went back out on the floor, which is where the sales are.
Nothing in that required better technology. It required somebody standing in the store.
You almost certainly have a system like that one. Something that scores well on the measure you picked, and that nobody has watched anyone use for a full day.
The one where we knew about most of the stores
It happened again with incoming product.
We had a system that told a store manager when shipments would land so they could staff for it. For most stores it was accurate, and we were proud of that one too.
Discount stores were the hole. Their product arrived as transfers from other stores rather than from a distribution center, and that path was never modeled. Those managers could not tell whether Tuesday meant ten pallets or a hundred and fifty.
They were running the hardest version of the job with the least information, and we did not know.
Both times we had built around the flow somebody had written down. Whatever you are rolling out right now works beautifully for the population you modeled. It is the other one I would go and look at.
The one where we took the manager out
Then we put in a new hiring system. A good one on paper.
It took the store manager out of the loop. Before it, a manager who needed people on the floor used their own judgment and moved. After it, any hangup meant calling support and opening a ticket, and hiring that had taken days took weeks. Stores ran short handed while they waited, and a store that is short handed on a Saturday is not selling what it could sell.
Nobody decided to remove the manager. The goal was standardized hiring. That judgment had never been written down anywhere as a step in the process, so it did not survive into the new system, and it turned out to have been carrying a great deal of the weight.
If you are replacing something this year, that is the question I would put to your team. What are we about to remove that nobody ever wrote down, and what has it been holding up?
The expensive version
The pattern got bigger than one system.
None of what follows is about somebody else's blind spot.
We designed operations systems the way you would expect a serious engineering organization to design them. Careful architecture, real talent on it, whatever was current at the time. What we did not do was sit with the people who would run them.
I have shipped excellent engineering to a team that could not use it. I have replaced something that was working better than what we put in its place. The engineering was not the problem either time. It was a solution looking for a problem, and nobody had gone and found the problem first.
So the question I would ask is when your architects last sat with the people who will run what they are designing. A requirements workshop is not that, and you already know it is not.
What the store visits turned up
Ask a store manager what is costing them sales and you do not get a technology answer.
You get wifi dead spots, because there are corners of the store where an associate cannot look something up while standing next to a customer. You get temperature, because people do not linger somewhere uncomfortable.
More than once someone was holding a shirt that could not be sold at all, because a data field never got filled in somewhere far upstream in the supply chain, and now two people at the register are working around it while a customer waits.
None of that is in a process document. All of it is in the work.
We did eventually put a model against one of these. We used camera counts to predict when a store would be busy, so support callbacks stopped landing during a rush and pulling associates off the floor. That is not a faster answer to a question. It is a decision about when to interrupt somebody.
It is also the only one of these where the technology was the interesting part, and it was the cheapest of them to build.
What the stores knew
The people standing in the work could already see all of this.
The manager knew about the pallets. The associate knew where the day went. Somebody in that store could have told us about the shirt long before it reached a customer's hand.
None of them were in the room where we decided what to build, and none of them had a job title that said their read on the work was part of the design.
Then somebody ran the experiment
In March of this year, three researchers put a number on it.
Hyunjin Kim at INSEAD, with Dahyeon Kim and Rembrand Koning at Harvard, took 515 high-growth startups and randomized them. Every company got API credits and frontier model access, plus technical training. Every company sat through workshops. The only difference was the subject: one group studied how other companies had reorganized production around AI, the other studied general entrepreneurship.
Same tools, same money, same hours in the room.
The first group found 44 percent more ways to use AI, and the extra ideas clustered in product development and strategy rather than in the support queue. They completed 12 percent more tasks. They were 18 percent more likely to acquire a paying customer. They generated 1.9 times the revenue.
That last number needs its caveat sitting next to it. The authors report the gains were largest at the 90th percentile and above, so the 1.9x is a mean being pulled hard by the top of the distribution, and the median company in that treatment group did not double anything. It is a working paper, not peer reviewed, measured over about ten weeks. I have read the abstract and not the full text.
There is a second result that got less attention. Their demand for external capital investment fell by just over $220,000, a 39.5 percent drop, while their demand for labor did not change at all.
If you are building an AI business case, this points the other way from the one on your desk. The only randomized trial anybody has run here found faster growth with labor demand flat. The Census study, which I get to in a minute, found the opposite thing happening at incumbents: labor shedding arriving alongside falling productivity, not because of it. Neither of those supports a business case underwritten by headcount, and one of them is evidence against it.
The authors call the thing they measured the mapping problem: finding where and how AI creates value inside a company's production process.
I have a plainer version of that, and it is not mine and it is not clever. It is a question I still ask myself and everyone around me, and it is one of the first ones I ask. Is this a solution to a problem we already have, or is it a solution looking for a problem?
I put it first because I have watched too much time and money go into the second kind. The question is free. What costs something is asking it early, out loud, while the answer can still change what gets built.
What the study did not test
The treatment was exposure to other companies' redraws. Four workshops of case studies. It was not somebody sitting alone with a blank grid mapping their own process, and the paper offers no evidence the solo version works.
So the stories above are closer to the tested intervention than anything I am going to hand you at the end.
What it costs before it pays
There is a second reason to be careful, and it is the finding that changed how I read all of this.
In April 2025, Kristina McElheran, Mu-Jeung Yang, Zachary Kroff and Erik Brynjolfsson published work with the Census Bureau on American manufacturers, using real plant data from 2017 and 2021. Adopting AI hurt productivity and profitability in the short run. In their words, it increased work in progress inventory, investment in industrial robots, and labor shedding, while harming productivity and profitability. A one standard deviation increase in their AI index tracks with a 1.33 percentage point drop in productivity, and the losses landed hardest on older establishments.
Then they found a mechanism. Among older establishments, abandonment of structured production management practices accounts for roughly a third of those losses.
The technology was not the whole of the damage. A third of it was companies discarding management practices that were already working, on the way in.
That is the hiring system. That is the manager whose judgment was not written down as a step and therefore did not survive the upgrade. I did not have a citation for it at the time. I just watched the stores go short staffed.
Older firms lose more because they had more to throw away, which is a different story from the one where enterprises are slow. And it raises a question worth asking before you start rather than after. Who has agreed, by name, to hold a position that is going to look wrong while your numbers get worse? The paper does not estimate how long the trough runs, which is its own kind of answer. The companies that end up as cautionary tales are usually the ones that quit at the bottom of it.
None of which is new. Brynjolfsson and colleagues were writing in 2002 that computer-intensive firms looked measurably different in how they organized work, with more teamwork and decisions pushed further down the org. Twenty-four years later the same co-author is still finding it.
Davenport's objection
It comes from Tom Davenport, an originator of business process reengineering who by his own account wrote the first article and book on it, and who has better standing here than I do.
His argument, from May 2026, is that most companies cannot do this. "Most companies (particularly in the US) aren't process-oriented. They don't have clarity on what their processes are, who is responsible for them, how they are currently performing, etc." So they take the cheap path: "It's much easier to 'AI wash' than to redesign and reimplement new ways of doing work."
Then he says this. "There were several companies I was familiar with that claimed to do reengineering, but were really just laying off people. It's not surprising that companies are doing that now with AI."
And his second objection is aimed straight at what I am about to recommend. "Implementing a new process design is much more difficult and time-consuming than designing it in the first place. For a major cross-functional process the implementation effort can stretch into many months and many millions of dollars."
He is right, and I am not going to argue him down. Going and looking is a diagnostic, not a program. What comes after costs what he says it costs. But I would rather spend many months and many millions on the thing ops is actually struggling with than on a masterpiece nobody can use, and I have paid for both.
Back to the apron pocket
Which brings me back to Home Depot.
The interesting thing about Sidekick was never the machine learning. You can buy better than that this afternoon with a credit card. It was machine learning wired into inventory and point-of-sale data and into a task dispatch system, running on hardware in the aisles, with the work around it rebuilt to use what it produced.
What they had was a decision about what an associate does next. That took years and it does not show up in a procurement line.
Home Depot ran $41.8 billion in sales last quarter with comparable sales up six tenths of a percent, and 470,000 people work there. Their first quarter earnings release does not mention AI once. Three years in.
Who is paid to draw the map
Your CIO owns tools. Your business units own outcomes. Go down your org chart looking for the person whose job is the shape of work that crosses three departments, and most of the time you will come up empty.
But somebody in your organization already knows. The associate running nine hundred returns knows where the day goes. The store manager knows whether the pallets are coming. They are not in the room where the roadmap gets written, and the shirt that could not be sold made it all the way to a customer's hand before anyone with a budget heard about it.
The gift
So this is what I would do with an afternoon, and you do not need a budget or an approval for any of it.
Go stand where the work happens. Pick the workflow that hurts most, not the one that is easiest to describe, because easy to describe usually means somebody already mapped it. Then ask the person doing it what is in their way, and write down what they say without arguing with any of it.
Four columns is enough. The step as it actually runs. Who does it today. What a machine would do there, in a sentence. Who still has to be standing in it, and why.
If they tell you only things you already knew, you have spent an afternoon and lost nothing.
If they tell you something you did not know, you have just found, for free, what my old employer spent years and a great deal of money learning, and what 515 startups had to be shown in a classroom.
The going and looking is the whole thing. It was available the entire time.
The four columns are on a one-page worksheet if you want it: benpickett.com/map. Fair warning, the worksheet is my extension of the research and not a finding from it. The tested version was being shown how other people redrew their work, which is what the first half of this issue was.
The one page worksheet from this issue is here: benpickett.com/map. It is my extension of the research, not a finding from it.
References
- The Home Depot. "The Home Depot Launches New In-Store Application to Help Associates Provide Better Customer Experience." January 12, 2023.
- Kim, Hyunjin, Dahyeon Kim, and Rembrand Koning. "Mapping AI into Production: A Field Experiment on Firm Performance." INSEAD Working Paper 2026/20/STR, March 2026. Working paper, not peer reviewed.
- McElheran, Kristina, Mu-Jeung Yang, Zachary Kroff, and Erik Brynjolfsson. "The Rise of Industrial AI in America: Microfoundations of the Productivity J-curve(s)." US Census Bureau, CES-WP-25-27, April 20, 2025.
- Davenport, Thomas H. "Why It's Hard to Redesign Work Processes with AI." May 4, 2026.
- Brynjolfsson, Erik, Lorin M. Hitt, and Shinkyu Yang. "Intangible Assets: Computers and Organizational Capital." Brookings Papers on Economic Activity, 1:2002.
- The Home Depot. "First Quarter Fiscal 2026 Results." May 19, 2026.
About the author
I'm Ben. I write Enterprise Field Notes, and by day I'm COO at Swa Technology. Before that I was Global Director of Site Reliability Engineering at a Fortune 500 retailer, running reliability, data protection, and database operations at global scale.
Header art created by Swa Solo.
Read more of Ben's Enterprise Field Notes at benpickett.com.
© 2026 Ben Pickett · Enterprise Field Notes