Structured Data Nobody Uses Is Just Storage

Getting a business to adopt a data model is mostly not a modeling problem. A clean schema takes days. The months go into getting people to trust the new structure enough to make a real decision with it: retire a duplicate, consolidate a catalog, switch a login. I've done this three times, in three domains, and the same four things decided whether the model stuck.

Count what people actually built

At Zendesk I led product for Custom Objects, the feature that let a business model its own data (assets, warranties, subscriptions) inside the support platform. When I joined, the beta was API-only, and the working assumption was that customers needed more object types and more power.

So I pulled the beta data. 240 customers. The median customer had created 65 objects, and the median number of relationships between those objects was zero. 134 customers had no relationships at all. Another 19 had exactly one. Usage didn't track with ARR or agent count either.

That changed the problem. Customers were using Custom Objects as storage. They loaded data and never connected it to the tickets and users their agents worked with every day, so it never showed up where a decision happened. Where people did build relationships, the top ones were Assets, Cases and Warranties, which told us what the starter templates should be.

We rebuilt the admin experience around that finding: a schema builder admins could use without an engineer, templates like Product Catalog, Subscriptions and Vendors, and relationship fields up front. I ran clickable prototypes with small-business admins who had no engineering team, since they were exactly the people an API-only product locked out. In the beta we tracked three numbers: adoption, the share of objects related to system objects (versus orphaned), and integration integrity, meaning duplicates and discrepancies eliminated.

The second number was the one that mattered. A related object is a model the business uses. An orphaned one is a spreadsheet with extra steps.

Prove usage before you ask anyone to consolidate

Early this year I led the Asset Library MVP for a public learning platform, via Artium. Its customers were training companies running dozens of courses with several content creators each. Every time someone duplicated a course, every video and document inside it doubled too. Progress tracking broke. Analytics split across copies. Nobody could say which version of a file was the real one.

The evidence was clear before we wrote code. I synthesized 15+ recorded customer interviews, and content scale showed up as a structural churn driver: 32% of the platform's 2025 churn and at-risk signals cited it, alongside 429 support tickets in the content-management category.

The MVP order is the part I'd reuse anywhere. Inventory and search came first, because nobody consolidates what they can't find. Then usage tracking, so a creator could see every course a file appeared in. Then safe deletion, which is only safe when usage tracking is right. Duplicate-upload prevention closed the door so the mess stopped growing. The adoption target was a 20% asset reuse rate, because reuse is the behavior that proves people trust the library more than their own copies.

Offer a "merge duplicates" button before people can see where each copy is used, and they won't press it. They'll keep their copy, just in case.

The blocker is usually the org chart

At The Home Depot, through Pivotal Labs, I paired with two client PMs on the vendor portal used by 50,000+ supplier employees. The data problem looked technical. About 550 different login configurations across vendor apps. Suppliers holding multiple P-Vendor and M-Vendor numbers that couldn't be reconciled, so people shared credentials. Contact records that were perpetually out of date. We cataloged 973 vendor-facing app entries just to know what existed.

One login per person was the right model. Getting there meant other application teams had to change their authentication, and nobody on our team controlled those teams. The job was showing each of them what the status quo cost, in support tickets and in suppliers who couldn't get into their own reports, until changing was cheaper than staying.

An earlier Home Depot engagement, Items United, had the same shape: merging Home Depot's catalog with that of a recent acquisition, with no end users to show a screen to. I told the integration as the story of one hammer moving through both companies' systems, which let non-technical stakeholders weigh the architecture. Then we proposed proving the leaner path with a flat-file test carrying exactly one item.

One item was enough evidence to make a real decision, and cheap enough that being wrong cost almost nothing.

Set the accuracy bar by the decision it supports

Every one of these projects had someone who wanted the data perfect before anyone used it. That bar sounds rigorous, and it stalls everything. The useful question is narrower: what decision does this data need to support, and how wrong can it be before that decision changes?

A consolidation call on a product line can tolerate some noise in a field nobody prices on. It can't tolerate a missing variant. So I write acceptance criteria early (coverage, field completeness, an error threshold for QA) and tie each one to the decision it protects. Writing them down before the deadline pressure shows up is what makes them possible to hold when it does. That's why integration integrity was a tracked number at Zendesk and not a vibe.

The order matters here too. Hamel Husain and Shreya Shankar make this case for AI products in a recent Lenny's Newsletter guest post: review real outputs and find the failures before you write the metric, or you'll measure the wrong thing. The same goes for an AI that reads drawing sets or product sheets into structured fields. Sit with a sample of what it got wrong, sort the errors by which decision they'd break, and only then pick the threshold.

What I'd bring to the next catalog

The pattern holds across support data, supplier logins and course libraries. Count what's really there before you design. Show people where their data is used before you ask them to give any of it up. Find the team whose change you need, and make the cost of the mess visible to them. And decide how clean is clean enough while you still have the calm to decide it.

If you're staring at a catalog like this right now, I'd love to hear what's in it.

Related: Modernizing a Legacy System Without Breaking It, The Content Architecture Problem Nobody Talks About, and Centralized B2B Vendor Portal for Home Depot.

Sources

• Hamel Husain and Shreya Shankar, "Advanced evals: How to find (and fix) hidden AI failures in your product" via Lenny's Newsletter: error discovery before metrics