What Fashion AI Taught Me About Data Quality and User Trust

The trust problem is always the same

In fashion recommendation, the model's job is to predict fit — a measurement problem with real stakes. Get it wrong and the customer returns the item. Too many returns and the retailer loses confidence in the product. Too many lost sales and the retailer churns.

What I found, working closely with retailer clients, is that the trust problem wasn't primarily about model accuracy. It was about model transparency. Retailers wanted to understand why the model made a particular recommendation. They wanted to know what signals it weighted. They wanted to be able to explain it to their customer service team when a shopper called to complain.

This is identical to what brand managers want from insights products. "Why does the AI say sentiment on this location declined?" is the same type of question as "Why did the model recommend a size M here?" The underlying need is the same: if I'm going to act on this recommendation, I need to trust the reasoning, not just the output.

The AI products that fail at adoption — in fashion, in customer insights, in virtually every domain I've seen — almost always fail for the same reason. The model got smarter but the explainability stayed opaque. Users don't trust what they can't interrogate.

Data quality is a product problem, not an engineering problem

The fit recommendation model was only as good as the product catalog data it was trained on. If a retailer's size chart was inconsistent across categories, the model produced inconsistent recommendations. If product dimensions weren't properly maintained in the backend, the model had nothing reliable to work with.

Early on, I made the mistake of treating data quality as a prerequisite — something the retailer needed to fix before we could deliver value. The better frame, which took me too long to find, was that data quality is part of the product. We built tooling to help retailers identify and fix catalog inconsistencies. We built feedback loops that surfaced data gaps. We designed the product so that improving data quality was the path of least resistance, not an extra project.

I've applied this same thinking to NLP and text analytics. The insights product can't be divorced from the quality of the feedback ingestion pipeline. If the data coming in is messy — duplicate reviews, malformed text, sources with inconsistent coverage — the insights coming out will reflect that. A good product design builds feedback loops that surface data problems to the people who can fix them, rather than quietly producing outputs that look plausible but aren't.

What Berlin added

Working at a company being acquired while you're mid-product cycle is a useful kind of chaos. Fit Analytics being acquired by Snap meant that product decisions I had made for a standalone API product suddenly had to coexist with a much larger platform strategy.

What I took from that experience is a deep respect for keeping product commitments to existing users even when the company's direction is shifting. We had retailer clients who had built customer-facing features on top of our API. They needed continuity. That obligation didn't go away because we had a new parent company.

It's easy, when a product pivot is exciting, to underweight the cost to the people who built on what you promised before. The discipline of honoring those commitments — of migrating carefully, communicating proactively, not leaving customers to discover breaking changes — is one I'd carry into any product role.