The system nobody had ever seen end-to-end

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.

Most data-strategy work focuses on the plumbing: data lakes, metadata taxonomy, platform efficiency. This engagement started somewhere else. Who is the product-data team actually serving? And what would change if those internal customers were treated as customers?

Sales, merchandising, content, enterprise architecture, store operations, and the vendors who supply the data each had a different relationship to the same product record. None of those relationships had been designed. There were no service level agreements. No mechanism for surfacing upstream the signal from customer-facing reps who answered the calls when data was wrong. No shared visibility to vendors about what was expected of their submissions. The shift — from product data as a database to product data as a service — meant the team had users, not requesters. Service levels, not ticket queues. It meant designing the work, not just running it.

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.

The blueprinting sessions put the operators who would have to run the new system at the design table. A future state designed in private and presented to the team is a plan. A future state designed with the team is the beginning of a commitment. The blueprint was honest by design: wherever the workshop group couldn't resolve a question, the unresolved question stayed as an explicit open item rather than being smoothed over.

The team came out of the engagement with three things they hadn't had going in: an end-to-end picture of how product data actually flows through Ferguson; a phased four-year plan sequencing 290+ capabilities into something a leadership team could read in a meeting; and the high-level estimates they used to build a business case and secure funding for the next phase.