Data Demystified: Data IS the Product

My last article in this series focused on common attributes of a product in the marketplace and how data teams tend to not deliver on those attributes due to the pervasive mindsets found in organizations who place the data function under IT leadership.

Before I published that article, I knew I'd have to write another because while I stand by my conclusions, I also have a somewhat different view on product development and delivery when it comes to data.

For a couple of years now I've been struggling with what one of my former employers called the "right to left" approach.  Advocates of this view like to quote Steve Jobs, who stated that "You've got to start with the customer experience and work back to the technology - not the other way around."

While I agree in principle, what I've seen in practice is a perversion when it comes to data.  Instead of working all the way back to the beginning, most data teams try to skip to the end with easy button technology.  They place dashboard developers and project managers in front of customers, then write checks against a non-existent data supply chain that someone else has to cash.  Short-term gratification rules the day, and solid foundations necessary to sustain and scale are never built.

More than five years ago, I approached my leadership during the runup to an Agile transformation and advised them to define data as a product.  That's it.  Just data.  No downstream dependencies.  Consumers of data would be the customers.  We would be the suppliers who would build a factory to ensure a steady and uninterrupted flow of a minimally viable product to that customer base.

My proposal was only partially accepted and what resulted was a stilted supply chain that resulted in unnecessary delays, complex communication challenges between skill-based teams, and frustrated stakeholders who ultimately didn't trust the products they were given.

Why?  Because the product focus was diluted and an efficient supply chain was never built.

In 1990, the Nutritional Labeling and Education Act mandated that packaged food products be labeled to include all ingredients listed in order of the percentage of the product's net weight.  In 2025, it should be no surprise that the types of ingredients routinely appearing at the top of each list are sweeteners, flours, and fats.

These ingredients are also products.  This is how I manage data as a product.  It's not glamorous or flashy, but it's essential to having successful outcomes for any data program.

Data as a product is about creating a manufacturing, packaging, and distribution process that satisfies ANY foreseeable need for data as an ingredient to a more refined, consumable, "data product" that generates business impact.  Data producers shouldn't get bogged down in details outside of basic demand requirements.

For example, there are several types of flour.  Whole grain, refined all purpose, cake or pastry, and gluten-free alternatives like rice, almond, or buckwheat.  Each type serves a specific customer type and satisfies a specific need or demand.  However, the flour producer does not need to understand their customers' recipes to successfully make or sell their products.

HJ Heinz built an empire based on one simple principle:  "To do a common thing uncommonly well brings success."  He started by selling horseradish in clear glass jars to highlight the purity of his ingredients, as opposed to the practices of his competitors who hid their products' flaws in opaque, brown glass jars.

In a corporate culture that constantly seeks the acclaim of a Steve Jobs, let's recognize our need for an HJ Heinz.  Let's be humble enough to define data as a simple product with transparent packaging and be satisfied with "doing the common thing uncommonly well".