Journey Management

When I supported & led my Inventory Movement UX team, I was already pushing my team to work in connected experience systems.

In 2021, my team goals expected them to pair across experiences and domains, align on end-to-end experience mapping and personas, and understand how their artifacts connected upstream and downstream. It wasn’t an enterprise expectation, but it was mine.

That said, I did not require every practitioner to produce the same beautiful journey map. I was setting the expectations for outcomes, not narrowing their creative solutioning nor outputs.

Doing it this way allowed situations where, if an individual team needed a custom map, workshop, storyboard, or one-off document to solve a specific localized problem, great — that’s the job. However, the portion of the experience they owned still had to ensure it connected back into a governed structure so the larger portfolio could see the whole without issues, as well as gaining visibility into nuances if desired.

That distinction eventually became central to how I scaled the portfolio’s Journey Management practice.

At the individual balanced-team level, most people did not need to become enterprise Journey Management strategists. They needed to understand the piece they owned and keep the connected record accurate.

At the management level, the expectation was higher: understand your teams’ part of the journey relationships and make sure their work is nested correctly.

At my altitude — the whole Store portfolio, 45 applications across a number of domains — the job was horizontal: how do Inventory Movement, Store Selling, Store Returns, Order Modifications, Fulfillment, Pro Sales, and adjacent portfolios connect? Where do AX and CX intersect? Which Product capabilities participate in the same customer-back outcome? And where are we duplicating work or leaving ownership gaps?

And most importantly: what did business leaders actually sign up to deliver, and how does a given journey contribute?

With this understanding, Journey Management then only became valuable when it connected to the organization’s real accountability: customer outcomes, operational performance, sales, productivity, cost, availability, or another result somebody is expected to move. In Returns, that accountability had names: dollars of returned product back on the shelf as sellable inventory, scan volume at the service desk, the cost of a pickup phone call, vendor credit that depended on an associate choosing the right reason code, etc.

As I began expanding Journey Management across the Store portfolio, I put into operation several connected mechanisms.

• Hierarchy + governed schema — Local journey work nesting into a larger portfolio model.shared language
• Journey ownership — Making it clearer who owns each portion, where ownership changes, and explicitly identifying where nobody owns the horizontal result.accountability
• Business criticality × experience criticality — Sequenced a journey backlog that combined all identified pain, goals, etc., and ensured they were connected.prioritization
• Journey inventory / portfolio view — Made instrumentation & staffing demand visible enough to plan around.resources
• Partner Readiness — Started with the why to separate principles from tools, tailored guidance to partner maturity, and connected all available KPIs / OKRs partners were already using.adoption

The Product capability here was not "journey mapping." It was operating-model design.

It started with cataloging. Before I could manage journeys across a portfolio, I had to know what they were, so I started with my own team — fifteen UXers and the experiences we owned — and put every journey, flow, and artifact we had into Miro.

The catalog worked. The access didn’t. Everything was available, but it wasn’t equitably accessible: a business partner who wanted to see the work had to go through a UXer, or through me. A practice that depends on a person to open the door isn’t a practice yet.

When my altitude widened to the whole Store portfolio, that stopped being a tolerable flaw. Store ran as two domains — Inventory Movement (the warehouse side: inbound inventory through outbound) and Store Selling (quotes through pre & post-sale) — and a visual canvas couldn’t hold that many nested journeys and stay navigable for anyone who wasn’t already in it.

So I moved the system of record into Airtable and kept the visuals where they belonged. I built the model myself: an atomic structure where every journey broke down into its parts and every part connected to the things that owned it. Partners — who they were, what they owned, who reported to whom, which balanced teams. UX, Product, and Engineering coverage, mapped to the piece of the associate experience each group touched. Applications — every one, what it did, what core functionality it supported, which VP it rolled up to. Active and inactive projects, the targets our partners were carrying, and status. Airtable handles nested relationships well, and that was the whole point: the connective tissue was a query, not a meeting.

I was deliberate about what it was not. It wasn’t a replacement for anyone’s dashboard, and it wasn’t a place where every balanced team reported everything so every VP could see everything. That would have collapsed under its own weight. It was a director-altitude tool — my director, me, and partner leaders — showing top-line information tied to top-line journeys, with links out to the reporting each team already owned.

Data input is the bane of every journey-management practice, and this one was no different. I did the groundwork: the modeling, the first full load. Then I made maintenance an ownership responsibility for the UX leaders and practitioners. Every record linked bidirectionally to its visual artifact in Miro, so if a team changed a flow, they updated the board and the record. We didn’t have licenses for everyone, so the update path was a form submission — new research, a changed journey, a status — and it bubbled up from there.

Near the end, the results were visible enough that the wider Enterprise UX organization bought into a dedicated platform, TheyDo. The enterprise direction became TheyDo plus the visual layer, and the last phase of my work was translating the model into it — same structure, same results, now on a tool built for the job.

Shouldn’t be a surprise, but the majority of the Store technology systems were associate-facing. That made it easy for the balanced product teams to improve an associate workflow they owned and celebrate positive lifts like operational-efficiency cost savings (& rightly so!) — however, teams often had difficulty cleanly articulating how much of their changes supported the specific customer-back outcomes the business cared about.

Which is why I ensured the Associate Experience nested cleanly into the Customer Experience as connected layers.

An associate struggling to find inventory, process a return, modify an order, fulfill an item, or explain policy is having an AX problem. But that friction also becomes customer wait time, fulfillment failure, lower availability, poor service, or a lost transaction.

I ensured traceability in both directions:

That gave leaders a much cleaner way to answer: What did I sign up to deliver, and which parts of this journey are supposed to produce it?

Returns is the clearest example of success with this operationalized, because it evolved in stages.

Now, I did not own the Returns Product roadmap. I did own the Store Journey Management and Experience Measurement mechanisms that repeatedly surfaced the problem and made it easier to connect associate friction to the broader customer experience.

That said, I did work really closely & directly with the end-to-end Returns experience teams.

I partnered closely with the Returns and Order Modifications teams, helped teams interpret the experience evidence and nested journey relationships, and participated in field research. In particular, for over two months I dedicated a single day each week to working a full shift at the service desk & handling special-order / order-modification workflows.

My contribution was part of the enabling infrastructure: make the problem visible & impossible to ignore, connect it to the larger outcomes, give teams shared language, and make focused intervention easier to organize.

The Returns recovery produced a result worth talking about. Just pointing to one specific metric that poignantly highlights the dramatic shift in how much pain the associates felt & expressed when using the tools needed to handle customer returns — these are 2024 vs 2025 associate sentiment scores.

The mechanisms I owned helped surface the problem, align leaders, and create the decision infrastructure around the recovery. Product, UX, Engineering, and business teams then executed the focused investment.

By September 2025 the Returns program was reporting more than $35M of returned product recovered back to the shelf as sellable inventory, against the larger program’s goal of $50M for the year! Scan-to-Start was running more than 20,000 scans a day across Returns and Order Modifications. A scanner fix cut "scan too fast" errors by roughly a third from a baseline in the mid-teens of thousands. And the product-search pilot logged thousands of successful lookups before it expanded.

My operating model did not produce those numbers by itself — the teams did. What it did was put them on the same page, in the same journey, so the people funding the next phase could watch everything move together. That was the connection each of our vertical orgs couldn’t see on its own, and it is the reason the score was worth anything.

That is what portfolio-level leadership often looks like: build the conditions that help other teams succeed, then stay connected closely enough to help translate that success across the system.

Even with the wins noted above, they technically still weren’t operating at the fullest & truest end-to-end model. All the work was contained within a portfolio’s organizational walls rather than around the customer’s job to be done.

This system continued to call out the larger frictions — how customers were moving through various domains: My Account, Store, Pro, service channels, Order Modifications, Returns, Customer Pickup / Delivery, and other post-purchase systems.

Having the ability to connect 13 different Returns journey “flavors” enabled a broader end-to-end Returns initiative to be formed, and I was explicitly pulled in to partner & connect the work across portfolio boundaries — combining the Journey Management systems with my Store Operations AX domain knowledge.

This is where the Journey Management model mattered most: common definitions, shared phases, AX + CX nesting, system / Product handoffs, ownership, journey-level evidence, and a language the individual balanced teams could all use.

The next phase carried its commitments in that shared language. Self-service pickup was already live, with roughly 4.5% of eligible returns initiated and nearly as many completed through it, and a customer effort score around 4.5. The 2026 targets were written against the whole journey rather than any one app: pickup call costs down by a quarter, scheduled-pickup confirmations from roughly a third of customers to more than half, customer effort cut nearly in half. Targets, not results — they were still ahead of the program when I left. But they were set as one outcome across many teams, which is what the journey model was for.

The vertical teams still owned their products. The horizontal journey finally had a way to be managed.