Ferguson data · V2D hero · NOTE: year/role/team/timeline need Whitney's confirmation before publishing Read the editorial memo →
Ferguson Enterprises · 2023 Service designer · Harmonic Design

The system nobody had ever seen end-to-end

A 275-step experience map across twelve roles that reframed a product-data team's tooling problem — and produced a four-year roadmap · funded next phase.

The case in six moves

  1. A back office that couldn't keep up with the front
  2. The reframe: data as a service, not a database
  3. Mapping a system nobody had ever seen end-to-end
  4. A future state designed with the people who'd run it
  5. We were hired to fix a tooling problem
  6. A roadmap that funded itself
275+
steps · 12 roles
290+
capabilities enumerated
4-year
roadmap · funded next phase

Ferguson's product-data team was drowning. The easy story: replace the database, automate the enrichment, buy a better platform. This case is about what happens when you map the whole system before recommending any technology. The 275-step experience map across twelve roles was the first time anyone at Ferguson had seen the full path a single product record travels — from a vendor's hands to a customer's order. What the map showed changed the question from "how do we fix the tool" to "how do we design a service that treats its internal customers like customers." The roadmap that came out of that question funded itself.

Chapter 01

A back office that couldn't keep up with the front

Ferguson is the largest value-added distributor for residential and non-residential construction in North America: plumbing, HVAC, appliances, lighting, PVF. The front of the business had grown for two decades. The back office hadn't. A small product-data team was hand-keying spreadsheets for tens of thousands of vendors and hundreds of thousands of products. Every product needed enrichment, normalization, vetting, and uploading into an inefficient database. Seasonal updates piled on top. The infrastructure was undersized and the people running it were burning out.

The easy story is a tooling story: replace the database, automate the enrichment, buy a PIM. The harder story is what happens when the bottleneck isn't the tool. What was actually happening was that no one in the company saw product data as a service that other parts of the business depended on — with its own users, its own service levels, and its own failure modes.

'Job for Data' workshop board
"That's a Job for Data" — every function across the company doing some version of the same work, separately, with no shared vocabulary or service model between them.

Chapter 03

Mapping a system nobody had ever seen end-to-end

The mapping work started with the core product-data team and deliberately widened the room: to sales reps who depend on accurate listings, enterprise architects responsible for the platforms underneath, customer-facing reps who answer the calls when data is wrong, and vendors at the upstream edge. Twelve roles. Two-hundred-seventy-five steps. The experience map was the first time anyone at Ferguson had seen the full path a single product record travels from a vendor's hands to a customer's order.

Two findings from the map did the most strategic work. Two of the team's main workflows overlapped in ways that hadn't been visible until the map was on one wall — merging them was the first concrete cost-out the engagement delivered. And the 290+ capability count was large on purpose: not a bloated backlog, but the actual size of the transformation, named so the organization could plan against it rather than underestimate it.

Data Types — enterprise diagram
The data domains behind a single product record — each bubble a domain that touches the same record but rarely shares a vocabulary with the others.

The reframe

We were hired to fix a tooling problem

We were hired to fix a tooling problem. The tooling was a symptom. The product-data team's platform was undersized and inefficient, but replacing it without changing the service model would have produced the same coordination failures on better infrastructure. The real problem was that no actor in the organization — not the product-data team, not the sales function that depended on them, not the vendors at the upstream edge — had a shared picture of the service they were running together. Making that picture visible was the move that made everything else possible. A PIM doesn't fix an organization that doesn't know what it's asking the PIM to do.

What stays behind

A roadmap that funded itself — and a team that could advocate for their own transformation

The handoff isn't "here is a roadmap." It's that a small, overworked team walked out of the engagement with the language and the artifacts to advocate for their own program, internally, in front of the people who controlled the budget. They didn't need a consultant to explain their situation. They could explain it themselves, in business terms, with evidence. High-level estimates built during the engagement became the foundation for the business case. The roadmap funded the next phase. A second engagement built on the methods this project established.

The team went from "we're drowning in the backlog" to "we know exactly what it would take to change this" — and they knew how to say it.

Roadmap funded — 4-year transformation
The 275-step map became the spine of the data-platform roadmap.