Understanding Value Delivery with Three Categories of Data Products
Are you building for value or just enabling? Also, sausages.
The one thing we are really, really bad in this data & AI industry of ours is figuring out business value. This is to a large degree because of our chronic inability to cross, or in most cases to even consider, the last mile from “a dataset has been deployed” to “the company made money”; a topic I’ve written about before.
In this article, I want to explore a way of thinking - a pattern, if you like - that might help, and has helped me, to consider the value-added of the work we do. To get us started, I want to point out a failure mode that’s all too common in many, many data teams.1
The Inherent Failure of “Making Data Available”
The core problem with figuring out the business value of the data work we do is that most of this work can be summarized as “making data available”. Now, don’t get me wrong: there is obviously some inherent value in making data available. Some data that should be available is not, and some data that is poorly available could and should certainly be made more easily available. I’m not denying that there are organizations, teams, and projects in which “making data available” is a goal worth chasing.
However, making data available brings exactly zero euros in.
“Making data available” is a goal for teams that passively respond to tickets coming in. Where are the latest sales numbers? Can I see our product master data attributes? Give me a Customer 360 view!
Many teams do recognize this correctly as low-value-added work: glorified raw data ingestion, easily automated away when the AI wave truly hits data engineering2. Some of these teams react by requiring incoming demands to specify user stories. You see, user stories (”as a <role> I want to <action> so that <outcome>”) are what they use in software engineering to figure out user needs, and it works there, so surely it works in data! This has resulted in a whole lot of cargo-cult user stories that I’ve seen many times: “as a business manager, I want to see data, so that I can identify opportunities”3. The letter is followed but the spirit is gone.
Some will blame the business users: “they ask to see data, our job is to deliver what is asked!” This reaction shows intellectual dishonesty and a startling lack of ambition: we could do so much more. We could be a valuable partner, not just raw data shovelers! Besides, it’s our fault that the incoming demands are like that! We taught them to include SAP table names and filtering conditions in their tickets. If those weren’t included, we would reject the ticket as having too little information to act on.
All of this is simply to say that many, MANY data teams simply exist to take data from place A and to put it in place B, so that we can say it’s been “made available”. What happens after that is not our problem, right?
No! It should be our problem. We need to do better: we need to understand why the data is used and what is done with it, so that we can start solving problems instead of just pushing data around.
That requires us to think about our delivery not in terms of source-system tables and filtering logic, but in terms of products.
Data Product Thinking
I have written about data products before. My thesis in that earlier article was that the most valuable part of the data product approach to an organization is not a new technical capability or a machine-readable data contract or even a standardized interface. The most valuable part of the approach is the change brought by applying product thinking - considering the data solutions we create as real products, with real users, real value, real life cycles. In short, product management.
A product - be it a pair of sneakers, a cruise ship, a festival ticket, or a sausage - has a purpose. It is deliberately designed and created to serve an identified set of users. Middle-aged dads want high-quality chorizo-flavoured sausages. Enlightened youths want sausages made of non-sausage materials4. The sausage company isn’t just the factory pushing out sausages 24/7. They have vast marketing and R&D departments doing consumer segmentation analysis and running A/B tests and focus groups and whatnot. New flavours are introduced, tested, tasted, and eventually retired (except for those that become classics). Their various sausages are products in the realest sense. And the consumer does NOT care how the sausage is made5.
Our data should be like a sausage. The machinery in our sausage factory is cool but merely a sidetrack: what really matters is the quality and fit of the product. Value is created when the consumer buys the sausage and eats it, not when it rolls off the production line.
It turns out that when you start to think like this, a very simple but powerful pattern emerges: while in the sausage world the variety of kielbasas, txistorras, and ryynimakkaras is endless, in the data world we can categorize everything roughly into three types of products.
I am using here a categorization that I originally learned from Zhamak Dehghani’s Data Mesh book, where it pertained to domains. I’ve since come to consider this categorization far more useful at the data product level. There have been many a-ha moments for me along the way; one that I want to specifically mention was Kinda El-Maarry’s talk at Data Mesh Live 2025, where she expertly crystallized how this works in practice.
Source-Aligned Data Products
First, we start with “making data available”.
Hey now! Juha, you just spent so many paragraphs complaining about the uselessness of “making data available”, what is this flip-flopping about?!
Listen, I said there is some value in making data available, but the point was that this shouldn’t be the full extent of our ambition! The source-aligned data product is a perfectly valid data product; the problem is that many teams never go further.
The idea of the source-aligned data product is that buiding integrations into various operational systems is usually pretty hard and annoying work. There are tools for everything, of course, but whatever tool you have usually never has all the native connections you need, and in any case there’s always the MASSIVE pain of firewall openings and authentication and everything. So, as we know that raw data from various systems is needed for all kinds of use cases, why not do all that just once?
This is the data lake philosophy - just grab everything and stuff it into cheap cloud storage - but with a twist: we’re doing it as products.
Products have boundaries, lifecycles, and owners. Your average set of files in a data lake has none of those. The source-aligned data product replicates whatever is inside a data source, as-is, into some place from where it’s safe, efficient, and easy to use it for other, secondary purposes, and adds governance around it. No transformations, no joins, no re-modeling or calculation, but yes for product-thinking.
We knowingly and consciously deliver raw data; we label it as such, we govern it as such, and it comes with all the necessary disclaimers and instructions. The owner of this source-aligned data product is usually the owner of the source system, or of the operations run in that source system. They decide who can access this data and for what purpose - this responsibility is not delegated to an outsider data team!
Because delivering raw data is quick and easy, many teams start with these data products when first adopting data product management. And many of them leave it at that - we’re now doing products, hurrah! But here’s the trick: you should never build source-aligned data products unless you have a higher-level downstream data product waiting for it. Otherwise, you’re still just “making data available” and hoping that someone somewhere down the line figures out how to make money out of it. No; having the source data easily and safely accessible is good, but we need to get closer to the business.
Aggregate/Integrated Data Products
The next category of data products sits downstream of source-aligned data products. The refinement level increases, along with value-creation potential and implementation complexity.
This middle category I like to call “aggregate” data products. Some call them “integrated” or “intermediary” data products. The name can be whatever: the purpose is more important.
The aggregate data product combines data from multiple sources - via source-aligned data products - into a coherent whole. Its core idea is to perform such transformations that would almost always be repeated across many use cases. Generally, this means that the aggregate data product covers some area of business, usually a few business entities, and builds a reusable and understandable set of data out of it. Source-system complexities are left behind.
The aggregate data product is necessarily re-modeled and re-structured. The combination of data from multiple sources means that data must be transformed from the source system structures (used in the source-aligned data products) to something else. Therefore, data modeling! But modeling what and how?
Aggregate data products optimize for reusability. Therefore, all the design decisions we make here need to focus on that. It is simply common sense6 to model the data so that when downstream consumers (users or other data products) need data about customers or data about deliveries, the aggregate data product serves precisely that: Customers and Deliveries.
The source-aligned data product has the source system view. The consumer-aligned data product (coming up next) has the use case-specific view. What we need in between is an agnostic view of the business as it is understood by the business, cleared of system-specific idiosyncracies and use case optimizations. Therefore, the aggregate data product should model the business entities as purely as possible. Now, that is not to say that a specific logical modeling method should be chosen: I’m not necessarily advocating here for 3rd Normal Form or Data Vault or Star Schema or anything. In fact, I won’t endorse any method here! I will simply say that whatever your data model is for the aggregate data product, it needs to be directly mappable to business concepts. This ensures maximum reusability and agnosticism towards both source systems and use cases.
An aggregate data product can serve all kinds of downstream consumers. Usually, these should be consumer-aligned data products, but occasionally there are valid use cases where the end-users need to have access to something simple that just lists all the basic data about some core entity like Customer. Thus end-user interfaces (such as dashboards) are certainly possible for aggregate data products as well, but one should be very careful not to risk the product’s reusability and agnosticism.
Consumer-Aligned Data Products
Our final and most important category is consumer-aligned data products. This is where the magic happens! This is also, oddly, the most neglected category.
A consumer-aligned data product is, as its name suggests, aligned for a specific consumer’s needs. Its structure (data model), technical interfaces, content (scope, calculations, measures), and metadata (such as semantics) is optimized to serve a specific use case for a known consumer. There are no hard rules here except “consumer first”. Is it a star schema? Is it an API? Real-time or batch? It can be any or none of those; it’s whatever is needed for this particular use case. In short, the consumer-aligned data product is a one-trick pony - by design!
To design a consumer-aligned data product, we need to know exactly what information someone (human or machine) needs at a specific point in the business process to make a specific decision. By providing this information, we can help them make the right decision, or perhaps automate the decision partly or completely. We figure out what is the most effective way to deliver the exact information needed: perhaps it’s a mobile alert? An automated trigger in some process? We figure out where exactly the information needs to be delivered to, and when. And thus we ensure that additional business value is created (or costs avoided) as a direct consequence of this pinpoint-accurate information delivery. The consumer-aligned data product finally crosses the last mile.
Sounds fanciful, perhaps? This is, of course, the polar opposite of what so many data teams are doing right now!
Designing and building a true consumer-aligned data product requires an airtight connection to the data consumer and a full understanding of what the data is used for, in which situation, by whom (or by what). It involves knowing your users’ intimate desires and internalizing their world and their particular situation in it as your problem to solve.
This is exactly the category of products we should be building the most! THIS is where we start delivering value; everything else is just background noise. All the other data products exist just to make it as easy and straightforward as possible to create more consumer-aligned data products. In a way, everything else is merely “making data available” - only this last category is truly value-focused.
The harsh reality is that most data teams are still in dashboard factory mode. I can’t count the number of times I’ve asked “what is this dashboard used for” and received “uhhh they need it in Finance” as a reply. If you only have a vague awareness of who sent the ticket, you are not delivering consumer-aligned data products.
The ability to consistently deliver consumer-aligned data products requires a lot from a data team. There’s a transformation journey to be taken, in terms of technical capabilities and architecture (what if the best delivery model is a mobile alert instead of a dashboard?), but especially in terms of mindset and ways of working. Luckily, we have many great people writing about precisely this part: I want to namedrop Anna Bergevin, Gaëlle Seret and Nick Zervoudis as especially clever writers and practitioners to follow in this space (I tend to occasionally also discuss these topics on this blog and elsewhere).
But before we leave the three categories of data products behind for now, there is one particular thing regarding architecture that I want to cover for the benefit of the more technically-oriented readers. You see, this pattern of “source-aggregate-consumer” might remind you of something...
Hey isn’t this just Medallion Architecture?
NO! Medallion “Architecture” as it seems to be generally understood doesn’t say ANYTHING about how to actually organize data within the Bronze, Silver, and Gold layers. It simply states that raw stuff goes into Bronze, slightly modified stuff goes into Silver, and heavily modified stuff goes into Gold.
What is described above is a pattern for how data products are designed, not how architectural layers are built on a platform. Source-aligned, aggregate, and consumer-aligned data products are like different templates for designing cars. Medallion is a template for designing a parking lot. Yes, it could make sense to park source-aligned cars on the Bronze lot and consumer-aligned cars on the Gold lot. But you could also just decide to publish all data products, regardless of type, always from the Gold layer (so that the earlier layers simply contain the “internal plumbing” of each data product).
Designing data products is a separate activity from designing a platform on which the products live. Both are needed, but my not-at-all-humble opinion is that our current focus is badly off.
Without good products, the platform is completely worthless. Without a good platform, an individual product could still deliver value (the problems will appear when scaling up). Yet I swear 80% of the data engineering content I see online has nothing to do with product design.
What is the point of a great sausage factory if the sausages aren’t edible?
We need more data product design. I’m hoping the pattern of the three categories described above is helpful; I’ve certainly found it very helpful personally. In a later follow-up article, I will go deeper into this design process and how the three categories can be used to deliver a quick and simple map of what is needed and where.
If you want to be notified of when that article drops (I don’t even know myself yet, as I’m writing this on my summer vacation!), click that Subscribe button!
Until next time - cheerio!
This failure mode, by the way, especially concerns data teams in non-tech companies. The cultural gap between tech and non-tech companies in terms of what data work actually looks like and how it’s being managed is huge, which is the reason why copying technologies and operating models from FAANG directly to your mid-sized metallurgy company is a fool’s errand.
Yep - it hasn’t hit yet. Most of us don’t work in early-adopter FAANG-level companies. No matter the hype talk on LinkedIn, those of us in the non-tech business (i.e. the majority!) are not seeing the full effects of AI-powered automation in real life yet, as the adoption has been slower in data. But it’s coming; I like to think of myself as an AI realist, but honestly, if your job is to take data from A and put it into B (i.e. “making data available”), your career prospects aren’t good.
The term “cargo cult” refers to a post-WW2 phenomenon on some Pacific islands, where the native population had been forcibly brought to the 20th century by various militaries building air bases and ports. Once the war ended, the military need to supply these islands with fuel, food, and modern gadgets disappeared, leaving behind rusting hangars and overgrowing runways, and a very confused native population left to its own devices after much physical and cultural devastation. On some islands, the locals mixed correlation with causation and concluded that the only way to get the cargo back would be to replicate what the military people had done: march around wearing helmets and carrying sticks. I like coming back to this metaphor, because I see it all the time in data. So many teams are going through the motions of agile, data modeling, or various architectural patterns with very little understanding of the reasoning behind the methods. It’s as if they believed it was all magic: that by correctly reciting the incantations (e.g. “we organize our data in Bronze, Silver, and Gold layers”), business value would appear!
By the way, did you know that the soy sausage was invented in 1918 by Konrad Adenauer, who later became the first Chancellor of West Germany? The things you learn by reading this blog!
The enlightened youths, the barbeque-enthusiast dads, and Konrad Adenauer all care(d) what the sausage is made of. My point here is that if sausage marketing was led by us data people, it would be something like “OUR NEW FRANK-N-FURTHER-3000 HAS A THROUGHPUT OF 1500 LBS PER HOUR” without any mention of how the product tastes.
“Hey that’s the name of the blog! How clever!”