The insight behind Plait & Pattern
Bad data isn't a technical failure. It's a service design failure. Fixing it requires understanding both the architecture and the human systems that create it.
What seven years at Zoro taught me
I spent seven years at Zoro watching a $500M business grow past $1 billion. I also watched us scale our product catalog from 2 million SKUs to 14 million.
That growth exposed something most distributors don't talk about openly: the systems and processes that work at 2 million SKUs collapse completely at scale. Not because the technology fails, but because the incentive structures that govern data quality were never designed for the velocity of a marketplace model.
Merchant teams were rewarded for assortment growth. Onboarding teams were measured on speed-to-market. And search teams were left to deal with the resulting mess. Everyone was hitting their numbers. The system was still failing.
The same pattern repeated with every acquisition, every new supplier integration, every catalog expansion. The symptoms varied—search abandonment, conversion drops, customer complaints—but the root cause was always the same: operational design that treated data quality as someone else's problem.
That's the insight that drives Plait & Pattern. Data problems are system problems. Solving them permanently means redesigning the system, not just cleaning the data.
Background
Before Zoro, I learned information architecture for technical products at McMaster-Carr—an organization legendary for its catalog design and the standard against which industrial distributors measure themselves.
I hold a PhD in English, which may seem unrelated until you realize that product data is fundamentally a language problem: how do you describe 14 million products in ways that let customers find what they need? The analytical frameworks I learned studying how meaning is constructed translate directly to taxonomy design and attribute architecture.
Product data is fundamentally a language problem: how do you describe 14 million products in ways that let customers find what they need?
Over 20+ years, I've led multi-disciplinary teams across UX, product management, and content strategy. I've seen what works, what doesn't, and—most importantly—why the same problems keep recurring in organization after organization.
How I work
I'm not interested in engagements that generate reports and gather dust. Every project is designed to create measurable change—whether that's recovered revenue, reduced operational burden, or systems that prevent problems from recurring.
That means I spend as much time understanding your organization's dynamics as I do analyzing your data. The technical findings matter, but they're useless without a realistic plan for implementing them given your specific constraints, politics, and capabilities.
I work collaboratively, not prescriptively. You know your business better than I ever will. My job is to bring pattern recognition from seeing these problems across multiple organizations and help you design solutions that will actually stick.
Beyond the work
I'm based in Chicago. When I'm not thinking about product data architecture, I'm probably reading, cooking, or trying to convince myself that this is the year I'll finally learn to play piano.
Want to talk through your situation?
I'm always happy to spend 30 minutes helping you think through a product data challenge—whether or not it leads to working together.