Case study — platform strategy
Unified Tasking
A shared work system for the store floor — sized honestly, funded one phase at a time.
- The problem
- Store Associate work tasks arrived through 22 channels across 9 business units, with no shared definition of a task and no way to compare priorities.
- What I did
- Built the task inventory (349 supervisor tasks, 25 apps), built the normalization and prioritization model, reframed the goal to reducing exposure to app-jumping, and carried the $3.3M multi-year investment case with Store Operations.
- What shipped
- Common task repository, ML task generation, first integration — and exception tasking live in every store.
Listen & read this case study
Opening
- 1×
- 1.25×
- 1.5×
- 2×
- 2.5×
- 3×
Loading audio
This starts with understanding the pain of a store Department Supervisor — Jessica. She's been newly promoted, six years in, and now she's expected to be fluent in almost 20 different applications while carrying 52 daily tasks, all noted as "High Priority!", and whereas 25 of them are hers specifically to execute. Yep. That's a lot.
Jessica isn’t real. Her workload was. Every number in her day came straight out of a task inventory I had just finished building, and the inventory said something no single application could see: the store had a work problem, not an app problem.
An associate walking the floor has one question that matters — what’s the most important thing I should do next? — and the technology ecosystem could not answer it. Not because any application was badly built. Each one was rational inside its own boundary. It couldn’t be answered because there was no shared definition of the work, so there was nothing to compare.
The obvious move was another app. A task manager to sit on top of the task managers. That was the one thing I refused to build — dropping one more application into a store already carrying a large portfolio of them would have proved the critics right on day one. The other obvious move, consolidating the portfolio, fails slower but just as surely: at the realistic pace of one or two app updates per team per year, that’s a decade of work with nothing to show in year one.
So the strategy had to be a third thing. This is that story — including the part where I told leadership the complete vision was roughly a decade out, and the part where the work stopped exactly where I said the hard part would be.
First, count the work — the Problem
Strategy decks about fragmentation are cheap. I measured it instead.
Work reached associates through 22 different channels across nine business units — system-generated tasks, scheduled routines, leader delegation, real-time customer needs. Across every Department Supervisor role in the store, I inventoried 349 distinct tasks supported by 25 in-aisle and reporting applications. 143 of those were specific to a single supervisor role. 206 were shared across multiple departments’ supervisors — and that’s the number that matters, because shared work with no shared owner is where duplication lives.
For the Universal Associate — the flexible, cross-department role the store leans on hardest — I counted 122 task types across roughly two dozen applications.
I also classified every task by how it reached the associate: 30% system-directed, 59% system-supported, 11% system-independent. That split decided the scope. Only the system-directed band can be orchestrated by a platform; the rest is roles, routines, and judgment. Pretending otherwise produces a roadmap you can pitch but can’t deliver. I scoped it to the 30%.
And the inventory wasn’t a slide. It was a populated data set with a fixed ten-field schema — task name, type, group, roles and routines, departments, personas, applications, classification, primary trigger, position in the SKU journey. Every task in the store, described the same way, for the first time.
That schema is the actual product. Everything downstream depended on it.
Everything is a task — and every task is normalized
The organizational language was the first thing to fix. “Task” was a loose word each application defined for itself, and you can’t prioritize objects that aren’t the same kind of object.
Without normalizing each task, it becomes impossible to prioritize tasks properly across roles, job functions, and departments.Task Normalization, internal architecture documentation
The normalization model I built gave work a common anatomy — parent, child, and stand-alone structures — plus two conditions the system had to tell apart: overlapping work, which is deliberate and fine, and duplicate work, which is accidental and the thing we were there to kill.
The rule that made it durable: build new tasks from the bottom up, reusing established types, instead of minting a slightly different task every time a workflow varies. That’s the difference between a taxonomy and a list.
Priority is computed, not inherited
This is where most task systems quietly fail. They accept whatever priority the originating application assigned — which means the store’s priority is whatever the loudest integration says it is.
Every normalized task carried four required inputs — when, value, time, trigger — scored against a repository describing the associate: role and department that day, physical capability, certifications, familiarity, current location in the store. A rules engine moved that logic out of the individual applications and into shared infrastructure, so priority stopped being a property of whoever generated the task.
The goal wasn’t a universal static ranking. It was a rules-driven answer to what matters for this associate, in this context, right now.
Reduce exposure to app-jumping — not the app count
This was the reframe that made the whole thing executable, and the reasoning is written into the architecture documentation in so many words:
The language here is purposeful. We absolutely do need to reduce the total number of apps — but we also need a realistic path of execution, so the focus starts with reducing the exposure to app jumping.Tasking architecture, internal documentation (lightly condensed)
If an associate doesn’t need to know they’re switching applications, the experience is already fixed — years before any consolidation program could finish (the Common Associate Store Experience use case). A decade-long rationalization effort suddenly had value it could ship in year one.
That last anti-pattern mattered more than it sounds. Associates were being asked to memorize a product catalog in order to do a job they already understood.
And a policy question most teams skip
Is the associate allowed to disagree with the system? We answered it explicitly. Where an associate shouldn’t be choosing — directed, time-critical work — the system surfaces one top task and holds everything else back. Where they should have discretion, it dials back its own inference and presents the outstanding set. And every task is skippable, for real reasons: equipment down, wrong area of the store, physical limitation, customer interruption. A system that treats every skip as non-compliance gets gamed fast — and then you’ve lost the data too.
The bet, and the honest number
The business case was a joint venture between Store Operations and the merchandising execution organization, with named executive co-sponsors on both sides, requesting multi-year funding beginning in 2021.
The model behind it: consolidating overlapping bay visits took a representative recovery sequence from 82 minutes to 68, and 425 yards of travel down to 235. Pack down and general service alone were generating roughly 3.7 million duplicate bay visits a year; eliminating the overlap freed about 14.3 minutes per occasion. These were modeled figures and I presented them as models — the point was the shape of the opportunity, not a promised return.
Now — the roadmap was the fundable version. When the conversation turned to the complete vision, every application connected, every task flowing through one prioritized experience, I gave leadership a different number: 2031. And I put the assumptions on the slide underneath it.
I labeled it a SWAG, because it was one. But a decade-long estimate with its assumptions exposed isn’t pessimism — it’s a specification of what would have to change. Every line on that list was a lever leadership could pull. Announcing a two-year transformation would have been more popular, and it would have collapsed on contact.
That slide is the piece of this program I’d defend the hardest.
What shipped
By the January 2022 executive review — the COO’s management agenda — the crawl stage had delivered its foundational technology:
- ✓The common task repositorybuilt
- ✓A machine-learning task-generation algorithmbuilt
- ✓Integration with the newly built in-aisle task sourcecomplete
- ·Integration with the legacy freight-directing systemin progress
- ·Native prioritization logicin progress
- ·Systemic duplicate removalin progress
The same review laid out the next test-and-learn sequence: two previously separate operating groups working from a single shared SKU-directed list in a live store, then bay-level, then multi-type pack down — the first real test of two organizations trusting one list.
Separately, exception tasking went live in every store, averaging twenty exception tasks a week against operational shrink drivers — routed through the associates’ existing task hub rather than a new destination, exactly as the strategy called for.
The taskforce that carried this work to the COO was a leadership coordination body — the product directors whose balanced teams owned each application’s delivery, operations leaders, engineering, finance. Its operating model had three columns: operations, technology, and user experience, and I was the experience name on the core-team roster.
Worth being precise about when that happened. Through the strategy years — the inventory, the model, the investment case — my title said UX Manager, and I was managing a fifteen-person UX team at the same time. The portfolio work happened on top of the day job, in a room where every other function was represented at director level. My title caught up (somewhat) in January 2022, the month this review reached the COO, when I accepted the new role & promotion as a UX Sr. Principal.
My job in that room was the portfolio layer: the shared strategy and research, and carrying what the taskforce decided out across the UX groups and their balanced teams. The deep delivery — each application’s design work, its research — belonged to those teams, and that split was deliberate. It’s also why the taxonomy, the prioritization model, and the routing architecture came out of the experience column rather than out of any single product team: no balanced team had the altitude to build them, and no other column had the reason to.
Where it stopped — and why I’d already named the spot
The repository, the generation algorithm, and the integrations were the foundation phase of a roadmap that ran through 2023. The later phases — cross-product prioritization, personalization, capacity management — stayed on paper.
I want to be precise here, because the easy version of this story is that a delivery team narrowed my strategy, and that isn’t what happened. The team built the funded foundation, in the sequence we’d published, and built it well.
What actually happened is that the later phases depended on conditions no engineering team could deliver. I wrote them down in the November 2022 ecosystem strategy, while those phases were still unfunded, as the ownership the full vision required:
a task intake process at scale · access to who each associate is and what they’re capable of · assignment ownership · a prioritization process · and governance to keep ensuring prioritization stays appropriateStore Tasking Ecosystem strategy, November 2022
Every one of those is an organizational commitment, not an engineering ticket. A repository can be built by one team. Deciding whose task loses when two products both say theirs is most important cannot — that takes decision rights sitting above teams that each had good reasons to keep ranking their own work. Those decision rights were never granted, and the resourcing behind them never materialized.
So the platform stopped where the unresourced conditions began. It could describe the store’s work in one language — real, durable value that outlived the program. It could not yet arbitrate it.
What I’d do differently
Make the governance experiment part of the foundation phase
I documented that shared decision rights were required. Documenting a dependency doesn’t fund it. If I ran this again, the first release would take two task sources with genuinely competing priorities and test whether shared criteria can reorder one team’s queue against another’s — small, cheap, socially difficult, and it tests the assumption the entire platform rests on. The repository tested an assumption I was already fairly confident about.
What this work proves
A fragmented operational problem became a measured one, then an enterprise-backed platform initiative with executive sponsorship and funded delivery. The organization gained a common language for store work that outlived the phase that shipped. One capability built on it reached every store in the chain.
And the thing the program stopped short of was the thing its own strategy documents had named, in advance, as the hardest part.
The vision materials closed with a line I used more than once, and still stand behind: