The Gap Between Data and Data Products

I think my team is about to get sick of me for becoming a broken record. At least ten times in the last two weeks, I’ve asked them to think about the difference between data and data products. This isn’t just an efficiency tip. It's central to how we work well with colleagues who have different skills and experience than we do. 

A few examples of the distinctions.

Data: Sending a list of students who have more than three absences to the school principal. 

Data product: Sending a list of “priority families to call when you have 30 minutes,” with the specific dates the students were absent, any relevant notes, and, most importantly, phone numbers to make taking action easy.

Data: The list of accounts and account balances when you open your banking app.

Data product: A display that first answers, “Do I have enough in my checking account to cover bills due over the next few weeks?” and makes suggestions for how to fix any potential issues.   

Data: Sending standard financial statements to a non-finance person. 

Data product: Sending analyses of those financial statements, calling out line items they should pay attention to and translating “accounting speak” into plain language. 

The obvious difference between data and a data product is that the latter typically includes some kind of analysis, but the instinct to add it comes from considering what the other person needs to do with the information they receive. It’s what happens when we cross the gap between thinking about our job and thinking about theirs.

That gap is why I think the issue kept coming up. For example, a colleague described how much work he put into making a spreadsheet more advanced—better formatting and synthesizing the key information in a dashboard. It was pretty slick. But he concluded the description with a complaint that he couldn’t get others to engage with it. Basically, he’d done part of the work by making it easier to find the key data once someone was viewing the spreadsheet, but the update didn't go far enough. It still required too much work for the user.

After explaining the data/data product framework, I asked whether he could create a tool that, for example, generates emails to each person with just their to-dos and, since those to-dos were mostly about following up with others, provides language they can copy and paste into emails. That is, a solution that removes the need to open the spreadsheet, minimizes confusion for anyone who’s not great at navigating spreadsheets, and reduces the time and effort it would take to act.

In my experience, this comes up most when dealing with quantitative data, but it’s actually about any communication. 

A performance review could be a data product.

A company-wide email could be a data product.

A job description could be a data product.

Fundamentally, it’s about taking responsibility. If I create a product that no one buys, it’s not the customer’s fault—it’s my fault! Yet in organizational life, we often blame others when they don’t read, understand, or act on the information we send them. And we often do so without even asking what they need, which is the opposite of how you’d build something people actually use.

Instead, we assume that the acronyms and domain-specific jargon should be understood, rather than being a foreign language. We assume that the standard frameworks that are obvious to us must be obvious for everyone else. We also assume the formats we use to send information are easy to navigate, even for people who may not spend much time using those tools.

Good products meet people where they are, and good communication should too.