On-Shelf Availability

Retail evidence gave us an external sanity check before we ever got to Home Depot-specific economics. The long-running out-of-stock research published in Harvard Business Review puts the cost at roughly 4% of sales — and traces roughly 72% of stock-outs to in-store execution rather than supply. Major retailers still tell investors the same story: Target's 2026 earnings calls named in-stock availability the single biggest friction point for its guests.

Inside The Home Depot, the OSA business case made the scale specific to our portfolio: roughly 1 percentage point of OSA was modeled at ~$500M in annual sales opportunity; about a 1% improvement in freight and pack-down productivity was modeled at ~$15M in annual cost savings; and roughly 40% of directed tasks, including customer-order fulfillment, were being blocked by an inability to find product.

Working with Store Operations leaders, field associates, Product, Engineering, and data-science partners, I led the research synthesis and cross-functional framing that turned those disconnected symptoms into a technology problem we could actually attack: On-Shelf Availability was not something one single Product team could “own” into existence.

The problems underneath it included:

• inventory that existed but could not be located
• product sitting in overheads while the shelf looked empty
• multiple task sources competing for the same labor
• duplicated Store and MET work
• bad or stale assumptions about on-hand inventory
• fulfillment work failing because the physical product could not be found
• and associates spending time searching instead of recovering sellable product

The business value was large enough to force a portfolio question: which combination of product capabilities, Store processes, and investments would actually move the outcome?

The story started earlier than the formal OSA taskforce.

Around 2020 / early 2021, a balanced team I supported had capacity because the initiative it had originally been funded to support was not ready. I had already been doing Store Operations visioning around inventory accuracy, product movement, and OSA. Rather than let the team wait, I proposed and drove a deliberately small experiment.

At that point, much of the team I managed was still early in their career. Some practitioners had come directly from internships, school, or UX feeder programs; others had only a year or two of experience. So my job was not simply to assign strategy work to a mature team. I was teaching the discipline while we practiced it — research methodologies, Double Diamond framing, facilitation, Product thinking, measurement, visioning, storyboards, storytelling, and how to work credibly with Product, Engineering, and business partners.

I often worked at two altitudes at once: I was still in the field and in leadership strategy sessions myself, then I brought those problems back to the team and used the real portfolio work as the environment in which people learned to operate.

How I scaled the capability

Over time, that organization matured: people rotated across Store product areas, grew into stronger mid-level, Senior, and Staff practitioners, and carried more of the tactical and strategic work independently. That growing capability is what created room for me to keep increasing my own altitude.

We called the experiment ShelfOut Scanner.

The minimum viable product (MVP) was intentionally simple: when an associate saw a shelf-out or visible “hole,” they used ShelfOut Scanner to take a photo of the condition. Data-science and business partners combined those images with stock-keeping unit (SKU) movement, inventory, and predictive signals to create more directed recovery work for the next day.

That sounds obvious now, however, it was a meaningful change in operating behavior then.

The analog philosophy in stores had long been “see a hole, fill a hole.” It worked because experienced associates used judgment constantly. The digital opportunity was not to erase that judgment. It was to ask a harder question:

If labor is limited, is the hole I can see the highest-value thing I should work on right now?

A low-velocity item with plenty of substitute product might matter less than a fast-moving SKU, a customer-order risk, or a product the system believed existed but nobody could find.

ShelfOut Scanner became a Trojan horse for making invisible Store recovery work visible. The pilot created enough traction — stronger labor direction, better recovery visibility, faster feedback on bad inventory assumptions, and strong field adoption — that leadership let the team continue the work when the originally funded initiative became ready.

The decision signal was operational: recovery work was becoming more visible and steerable, and the field was engaging with it.

That experiment became part of the lineage that evolved into an app called Sidekick.

A directed tasking system is only as smart as the feedback it receives.

I drove bidirectional communication into the Sidekick product strategy and execution. I worked through Product, Engineering, data-science, and field partners to get the behavior aligned, prioritized, and carried into the roadmap because directed work could not become trustworthy if associates had no structured way to correct it.

For me, the reasoning was simple. Associates were being told to recover, pack down, or inspect specific product, and sometimes the system was wrong: there was no inventory, the work had already been done, the item was somewhere else, or the instruction was simply not actionable. If the associate could only skip the task, the system learned almost nothing, and we'd have robbed an opportunity for the associate to step up in various ways.

We designed the experience so the associate could say, in structured terms, “the reality in this aisle disagrees with your model.” A photo, a “no inventory” outcome, or another reason code could feed the next round of task generation instead of disappearing as silent non-compliance.

That feedback loop mattered because the underlying system was already moving toward predictive work. The prioritization logic underneath was concrete: the product looked at sales, SKU information, shelf size, when product was last believed to be packed down, and other signals to predict whether a SKU or bay needed recovery — then considered sales impact before deciding whether the task was worth sending.

Optimize the work without optimizing the human out of it

As tasking became more data-driven, I saw a second Product risk: associates could start to feel like robots executing an algorithmic queue. Home Depot leadership had made a deliberate choice to preserve a human-touch Store model, so I wanted the software to reinforce that operating philosophy rather than undermine it.

Across field research spanning roughly 20–30 stores, three recurring motivation patterns kept surfacing. That gave us a practical design constraint: the same system had to support efficient task direction, human judgment, and visible contribution for associates with very different reasons for being there.

That is why recognition and personal analytics mattered. Sidekick was the mobile execution surface, and recognition was built into it as a benefit — associates logged their work so they received credit for it. MyView, a responsive web application used heavily on desktop but also accessible on mobile, increasingly became a broader “start your day” hub where profiles, dashboards, contribution metrics, and recognition could be surfaced. Gems added a lightweight gamification layer around meaningful execution rather than treating raw speed as the only signal of performance.

The two-way strategy therefore served both sides of the system: the model learned from the associate, and the associate gained a more visible record of what they contributed.

How I actually ran it

My role was not to sit above the team and wait for a finished design review. I worked across three layers at the same time:

1. Business framing — what Store leaders were trying to improve: availability, recovery, labor use, and customer confidence.
2. Product behavior — what the associate had to see, do, report back, understand, and get credit for so the system was useful.
3. Team leverage — build practitioners who could increasingly carry the work themselves: first by modeling the method, then co-creating, coaching, and eventually delegating ownership inside balanced teams while I connected strategy across Product, Engineering, Operations, and leadership.

That combination became important later. The technology got more sophisticated, but the operating loop stayed recognizable:

detect → understand → prioritize → execute → report reality back → learn → recognize contribution.

Store Operations leaders already understood OSA as a business system. Working closely with the Store Operations VP who sponsored the strategy and his leadership team, I drove the translation of that operating strategy into a technology portfolio system — a clear Product, UX, and Engineering structure with shared priorities, dependencies, experiments, and investment paths.

By 2022, that technology strategy organized the work around three coordinated drivers:

1. Freight productivity — improve end-to-end inbound execution.
2. Common Tasking (the Unified Tasking use case) — reduce duplicate work and address more OSA opportunities with the same labor.
3. Inventory Visibility — increase visibility to SKU locations so associates could recover product faster.

That structure mattered because each lever lived across different organizations and products. Sidekick and BOLT, the Merchandising Execution Team (MET) execution application, were important execution surfaces. Store Operations and MET often touched the same bays. Data science produced signals. Common Tasking could normalize and prioritize work. Inventory Visibility and Computer Vision could improve the signal itself.

The goal was not to collapse all of those products into one application. The goal was to make them behave like parts of the same operating system around availability.

This is where my leadership altitude changed most visibly. In my new role, the scale and leverage is what shifted. I moved from primarily developing practitioners and operating with individual balanced teams to working more consistently with senior leaders across the Store portfolio.

The question became less “How should my team solve this workflow?” and more: Which capabilities should exist across the Store portfolio? Where should products converge? What dependencies have to move together? Which experiments deserve investment? And how do separate roadmaps stay pointed at the same business outcome?

My role was horizontal: portfolio strategy, dependency and investment framing, executive influence, and product-system judgment across vertically owned products. My Product-leadership contribution was making the outcome coherent enough that separate roadmaps could move in the same direction.

We formed a three-person strategic tiger team: a product director, a distinguished engineer, and me. We worked as strategic peers to frame the value, pressure-test feasibility, and run quick experiments strong enough to justify an initial pilot investment.

Once those tests proved enough viability to earn funding, the initiative expanded into a broader strategic task force with VP sponsorship on both the technology and Store Operations sides, alongside Product, Engineering, UX, Store/MET, Finance, and data-science leaders. The sequence mattered: first prove there was something worth investing in; then build the larger operating structure needed to scale it.

The technology hypothesis was straightforward: use image capture plus machine learning to understand what was physically happening in the bay — shelf-outs, product location, overhead inventory, aged orders, and missing product — then turn that intelligence into action.

Accuracy and trust had to advance in parallel

Recognition accuracy was non-negotiable. If the model could not reliably recognize labels, products, and locations, the product would fail. At the same time, associates already had years of frustration with inventory accuracy. The Inventory Management System (IMS) and the emerging SKU Depot experience could show home, secondary, or tertiary locations, but Store reality was messier: product lived in overheads, lockers, cages, temporary locations, “No Home” status, or wherever freight teams could physically fit it at the end of a shift. A SKU could be three aisles away from where the system implied it should be.

I drove a parallel Product requirement with the tiger team: we had to improve recognition accuracy while rebuilding credibility with the field. A technically strong model dropped into an experience associates already distrusted could still fail in adoption. The system needed to earn trust through evidence, freshness, transparency, and the ability for associates to correct it as the model improved.

That principle changed the experience from “the system says the SKU is here” to “this is where we believe it is, here is why, and you can help us make the next answer better.”

Image capture was a labor-design problem

I also hypothesized early that associate capture would create friction. Store work rewarded speed: move through the aisle, recover product, serve the customer, keep going. Good computer-vision input required the opposite behavior — pause, find the right angle, manage distance and lighting, hold the phone still, and sometimes back up in an aisle with nowhere to go.

The early tests proved that concern out. Older handheld devices had limited cameras; long SKU strings blurred easily; lighting and angle created false positives and false negatives; and the last thing we wanted was to tell a strong associate that they were suddenly “bad” at their job because they were not taking pictures correctly.

I drove guided capture into the experience, similar to mobile check deposit: move closer, back up, improve the angle, get more light, confirm that the image is usable. That made capture part of the workflow instead of a new source of stress.

We optimized the capture cadence, not just the model

Working with the data-science team, I helped define the operating model around coverage and freshness: How long does full-store coverage take? How fresh does an image need to be for a fast-moving SKU? When is opportunistic capture enough, and when should image capture become a directed task of its own?

That mattered because most Sidekick recovery work clustered around specific parts of the day and Store leaders still expected associates to protect customer-facing power hours. We did not want to bolt image capture onto every task simply because we could. The capture frequency had to reflect SKU velocity, predicted movement, prior freight activity, and the value of having a fresher signal.

We also worked the problem from the physical side: improving label readability with merchants/vendors, getting labels to face outward in overheads, testing robotic and stationary capture, and learning where associate phones were good enough versus where hardware itself became a dependency.

Engineering and data-science partners were effectively building our own Computer Vision capability on the Google technology stack. As the models improved from optical character recognition (OCR) and label detection into richer object recognition — eventually including handwriting and messier real-world signals — the experience and the Store operating model had to improve with them. The broader “every scheduled associate has a device” program became part of the dependency chain because image intelligence could only scale if the hardware in associates’ hands could reliably capture what the model needed.

Over time the model and capture experience improved together. Associates could see the photo, understand when it was taken, see where the system believed the product was, and correct the system when reality disagreed. That participation is what helped turn Computer Vision from another inventory claim into a capability the field could trust and get excited about.

Every year, Home Depot Technology ran a hackathon. I had encouraged people from my team to participate for years, and that year I signed up myself before I knew what challenge my team would receive. It happened to land unusually close to the OSA / inventory / tasking world I was already working in — which gave me a rare chance to actually get my own hands dirty and make something again instead of only leading through other people.

During that event, I built a future-state concept called Bay Intelligence as a Service (BiAS). The BiAS Bot was mine end to end: the concept, prototype, little robot character, sticker, and the full future-vision video.

The prototype connected shelf capture, bay health, sales context, issue reporting, inventory intelligence, and task creation into one continuous story. It leaned into an augmented-reality (AR)-style future more aggressively than the actual products eventually did.

And that is exactly why it was useful.

Home Depot did not broadly deploy the full AR workflow, however, it's also not me to just create something and pretend it's others' responsibility to drive action or wait for other people to discover the meaning. I used the video, prototype, and story as I've done many times — in conversations across Product and leadership to sell the pain points, align people on the connected future, and help vertical owners see where their roadmaps could absorb pieces of the solution — shelf intelligence, structured task creation, location context, inventory imagery, Sidekick, MyView, SKU Depot, and task management.

That operating style came from more than design craft. Storytelling is one thing, however, regarding the 'hackathon' model, I've actually won a number of different hackathon events via external settings. One of those was Atlanta Startup Weekend, where the winning concept became my last startup prior to Home Depot, TripLingo; shortly afterward, we won roughly $50K in seed investment through a fast-followup pitch competition. Those experiences taught me how tightly product story, economics, identity, social proof, and organizational momentum reinforce each other. And I was able to leverage all those skills.

I brought that startup muscle into enterprise work deliberately. A good internal brand was not “swag.” It gave a complex idea a name, visual identity, and social life. Stickers on laptops, people asking for more, leaders repeating the name, and teams asking “why aren’t we building this yet?” created pull around an idea that already had research, economics, and a credible product path behind it.

That is how I used vision: make the future tangible, give people language to rally around, sell it actively, connect it to the business case, and keep working the organization until the strongest pieces became roadmap, prototype, funded experiment, or production capability.

One of the clearest intersections between OSA and the broader Store ecosystem came from a SKU-finding problem.

Internally, the "intuitive solution" was YANA (Yet Another New Application): build a dedicated SKU Finder app and give associates one more place to go when they could not find product, and have other teams figure out how to integrate if they wanted to.

I immediately led the push to reject the standalone-app answer and worked with Product and Engineering partners to get a different model aligned and executed: SKU finding as a reusable service/capability that existing workflows could consume.

The value was not the app. The value was the capability: show where the SKU was last seen, identify the aisle and bay, provide a visual marker, show the underlying image when useful, and make it clear when the location signal came from Computer Vision.

Getting there required more than an experience preference. It challenged the existing ownership model. Everyone internally liked a clean box — one balanced team, one application, one roadmap. Whereas a service/component model created more dependency and coordination up front, it would let multiple products reuse the same intelligence and make the associate experience dramatically more coherent.

That meant an associate who was already doing recovery work should not have to stop, remember a different app name, leave their current app, go to the launcher, find the app amongst all the others, and then launch it, just to rebuild the context the system should already have. The SKU-finding intelligence should have instead arrived where the work was happening.

The field response was strong. More importantly, the decision expressed a portfolio principle that showed up repeatedly in my Store work: do not force the associate to carry the architecture in their head. Let separate products and services exist underneath; make the capability available inside the workflow that needs it.

This was the same technical/Product direction I drove in the Common Associate Store Experience (CASE): move away from app-centric architecture toward reusable components, shared services, deep linking, and eventually teams thinking more about journeys than application boundaries. The transition was not frictionless — teams initially tried to “own” the service like another app — but the SKU-finding work became a concrete proof that the model could work and that the field preferred intelligence delivered in context instead of another application to learn.

That is how OSA connected to Sidekick, BOLT, Common Tasking, inventory management, and CASE without becoming a duplicate of any one of those initiatives.

By the later Inventory Visibility pilots, the program had moved from strategy and vision into measurable operational proof.

In an 18-store Computer Vision / Inventory Visibility test, we produced three concrete operational signals:

Those results show the mechanism doing what the business needed: reveal product that Store systems and associates were effectively treating as unavailable, then turn that visibility into more actionable recovery work.

The visioning work connected directly to investment

With the Computer Vision pilots, the work had matured into a cross-functional investment decision. I worked across the same leadership table — Product, Engineering, Store/MET, Finance, data science — to turn technical dependencies and pilot evidence into explicit investment thresholds and a modeled scale case near $100M a year. My role was not simply to make the vision understandable; I connected the experience strategy, technical feasibility, operating model, and financial case tightly enough that leadership could decide what deserved the next investment.

That was the maturation I wanted from the work. The conversation could move from “Computer Vision is interesting” to:

What signal did we create? What work did it unlock? What business outcome could it move? What would we have to prove to justify the next dollar?

Delivery status

• Sidekick — scaled to chain: the ShelfOut Scanner experiment grew into a full in-aisle tasking product.shipped / scaled
• Common Tasking — shared repository and machine-learning task-generation capability established, with integrations continuing across Store/MET products.implemented / continuing
• Inventory Visibility / Computer Vision — multiple capture methods and progressively larger tests produced measurable recovery/findability signals and a funded investment case for expansion.piloted / expanded
• Bay Intelligence as a Service (BiAS) — influential future-state concept that helped align product conversations; the AR-style interface itself was not implemented as shown.vision / influence
• SKU-finding capability — moved away from a standalone-app concept toward reusable intelligence inside existing workflows and was strongly received in the field.shipped capability

OSA remained a shared enterprise outcome. Freight, Sidekick, BOLT, Common Tasking, inventory accuracy, Computer Vision, Store process changes, and other initiatives all contributed. My claim is the portfolio system I helped shape, the investments and product decisions I influenced, and the measurable results those mechanisms enabled — not sole attribution for the company's total OSA movement.