This article collect different insights for Data Platform Thinking and reflecting some of my latest experiences in this field. The content:
Data Platform Thinking
Data Platform as a Product
Data Product Platform – Approaches
Data Platforms are becoming more and more important. It is not just a database nor is it even something technical. It is a concept, enabling the usage of data in the best possible way. More and more i recognize the orientation on typical product principles. In this sense Data Platform is nothing you just buy. It is rather about the evolvution for the best possible Platform, serving your needs and helping to create value with data.
Data Platform Thinking
Data Platform Thinking is a mindset that applies platform-oriented design to the development and evolution of data systems—treating the data platform as an ecosystem rather than just technology.
A data platform brings data providers (data producers) and data consumers together
The better the range of data products (qualitative & quantitative), the more attractive the platform is for both participants (network effect)
Requirements for the data platform are developed in a future- and benefit-oriented manner via the requirements of the data product teams
The data platform team with the data platform owner as the main responsible party takes care of (further) development, operation, architecture, data observability and the optimization of existing platform resources
The composition of users tends to be broader
Data consumers: Internal and external consumers
Data producers: Data team, specialist department (managed self-service), external service providers
Fig. 1: Classical Data Storage (like Data Warehouse) vs. Data Platform with Data Products
Data Platform as a Product
Data Platform as a Product is an approach where the organization treats its data platform not as a one-off IT project or static infrastructure, but as an evolving product with defined owners, a clear roadmap, measurable value, and a focus on meeting the needs of its users. This means applying product management principles—such as user research, feature prioritization, continuous improvement, documentation, and support—to ensure the platform consistently delivers reliable, accessible, and high-quality data capabilities for the business.
While “Data as a Product” is already a thing, I try to understand how this concept can be transferred to Data Platforms. These are some of my findings:
Understanding the data platform as a portfolio of products: Manage the entire data lifecycle, from ingestion and storage to transformation, access, and serving.
Prioritizing users' needs: The users of a data platform are diverse, including data analysts, engineers, scientists, operations associates, and leadership—essentially, anyone who utilizes data. It's crucial to view these internal users as customers and ruthlessly focus on user-centricity, building solutions with them rather than just for them.
Aligning with business objectives: The platform's goals must be directly linked to overarching business aims, driving value through aspects like cost savings, improved performance, enhanced data quality, and promoting data democracy within the organization.
Adopting a product mindset: This means fostering an organizational culture where the entire team embraces product management as a mindset for finding what works and reliably delivering value, rather than adhering to a rigid set of prescribed actions. The platform should also be designed for continuous evolution and iteration, allowing for ongoing improvements.
Addressing common challenges: These include the necessity of change management to ensure platform adoption, making strategic "build vs. buy" decisions (often favoring a hybrid approach), navigating the complexities of internal customers (e.g., small, captive audiences, conflicting incentives), and avoiding the "Feature Shop Trap" by focusing on solving generalizable problems rather than just bespoke requests.
Measuring success: Success is quantified through relevant Key Performance Indicators (KPIs) that demonstrate tangible impact and value, such as efficiency gains, cost reductions, decreased lead times, and improved data quality. Frameworks like DORA metrics, the SPACE framework, and the DevEx framework can be instrumental in this measurement.
Iterative development: It is recommended to start with a Thinnest Viable Platform (TVP), focusing on delivering a "good enough" initial version to validate hypotheses and gather early feedback for rapid learning and subsequent iterations.
What is your experience with “Data Platform as a Product”?
Data Product Platform – Approaches
When it comes to Data Products, to handle them can mean to handle some complexity of your data platform. Possibly you need a flexible and highly automated data platform, supporting different data workloads, different kinds of data, different serving options and concepts to automate the provisioning of the infrastructure (like Infrastructure as Code), supporting certain processes and guaranteeing security and compliance, to make it easy for data product teams to make their work effectively.
To understand you choices, we can see 4 options in general, to get a more differentiated perspective:
Do It Yourself – you go typically to a cloud platform of your choice, put the services all together or rather start with a thinnest viable platform and build on it on demand. You really need a great platform team to do that successfully. But gives you the maximum fit for your company.
Trying On Whatever Platform You Have – first – don’t get me wrong – Power BI is not a platform. But I see many customers, starting with what they already have as they assume value comes form organization, ownership or how we handle the data. While this ins not wrong, on the long term it will not be enough. Not every “platform” is right for data product if you – change my mind!
Buy a Data Product-capable Platform – vendors like Snowflake, Databricks, Microsoft, SAP and others deliver you the more or less complete platform to integrate, process and serve data and wrap it into data products to offer it by a catalog or marketplace. It is like standard software. You can adapt things to your need, but have to live within the frame given by the vendor.
Buy a Data Product Platform – which means rather having a solution on top, working with your data platform(s) and helping you managing the complete data product lifecycle like Witboost, One Data , The Modern Data Company, Nextdata OS, among others. While this looks fine, you have a separate solution to handle and really need to care about it.
There is not the one right (maybe the one wrong) way. And you can always do a little bit DIY, if it is helpful. But be aware, going for Data Products is typically more than just having any data platform and applying product thinking on your data. Doing it right means, to think about the right delivery infrastructure.
What do you think about Data Platform Thinking? Do you have any experiences here?
This article is a fusion from different insights I share weekly on LinkedIn.
Very good article, Peter.
To add on—I think adopting a data product mindset is essential but incredibly hard to inculcate. I was surprised by how much change management was needed just to get the data team itself onboard.
A big part of the resistance came from reluctance to release a TVP (great term btw, can I steal this? 😆) and a desire to achieve perfection before release.
My mantra - progress beats perfection. The faster you release, the faster you learn—and that’s where the real maturity comes from.
Keep the articles coming....
You can find much more about TVP in thr context of Team Topologies. They have greate insights about how to set up teams and make them work.