Data Products Need Empathy, Not Just Pipelines
A data product is not successful because it loads. It is successful when a real person makes a better decision.
We celebrate green pipelines. The DAG ran. The freshness check passed. The data loaded. And then we wonder why nobody uses the thing we built.
A pipeline that runs is the floor, not the ceiling.
Adoption is not usage
A login is not a decision. We measure "active users" because it is easy, and we avoid measuring whether anyone's work actually got better, because it is hard. The hard metric is the real one.
What happens after they see the number?
This is the most important and least asked question in BI. The user reads the metric — then what? Do they know what to do? Can they explain it to someone who pushes back? Can they find the exception that matters to them?
Watch users work before you design for them. You will be humbled, and your product will get better.
The hidden product work
Empathy in data products is not a soft skill. It is concrete work: shadowing users, learning their vocabulary, understanding the decision and the workflow around it, and respecting the messy reality they operate in. That work is the difference between a dataset and a product.
Related essays
You Cannot Sell Freshness as a Setting
Offering different data refresh speeds sounds like a clean product decision. Fast for customers who need it, slower for workloads that cost more to process. But once freshness varies by dataset, metric, or package, timing becomes part of the meaning of the data. The product now has to explain not only what a number means, but which version of reality the user is looking at.
The Architecture You Ignore Eventually Becomes Your Process
Most operational processes are not designed. They emerge as workarounds for systems that cannot represent reality. Every spreadsheet, exception list, and recurring meeting is often evidence of an architectural decision that was never made.