Data products are all the rage. Based on the hundreds of recent conversations I’ve had at data events and online so far in 2023, the implementation of data products is being strongly considered by many data leaders from across the globe.
For many, data products represent the first phase of a broader program focused on the deployment of a data mesh architecture. For others, data products are a milestone for some form of a data and analytics organizational transformation — often tied to a broader digital transformation.
Some data leaders are considering data products as a part of the deployment of a data catalog, or in support of some form of data monetization or data marketplace.
While there are many different programs involving data products — and different types of data products — there remains significant ambiguity in our industry on what exactly defines a data product. This confusion isn’t necessarily a bad thing, but it does highlight a significant difference between how data leaders view data products and how product management professionals would view the same.
These are material differences that I’ll discuss in greater detail below.
Data Products in a Data Mesh
Data products within a data mesh are extremely well-defined and share several key features:
- Support analytical use cases only
- Have domain-centric ownership but can be used cross-domain
- Value determined by usage or consumption
- Created and managed by data product owner
- Automated governance (via what is called federated computational governance)
- Terms of use governed through data contracts
- Provisioned through a self-service data platform
When viewed through the lens of a broader product management focus, products in a data mesh are only a small subset of everything that could be “productized” by a CDO.
The idea that the only products a data organization could offer to its clients would be analytical solutions that can be automatically provisioned and governed by a strict set of rules within a data contract is extremely limiting.
A “product” in a data mesh is a very specific construct with technically complex dependencies that I have yet to see any company fully implement — at least insofar as the mesh defines data products.
Other Data Products
Data products outside the construct of a data mesh include products, services, capabilities, tools and just about anything that could be created in a data team and provided to somebody outside that team — for both internal and external consumption.
These products could be fields, schemas, APIs or reporting dashboards — and this variability in product form is a source of massive confusion for the average data person who lacks any sort of formal product management training.
This confusion around what is (or isn’t) a data product is made worse by the fact that most data and analytics teams seem to be embarking on data product initiatives without hiring skilled product managers or leaders.
Rather than follow well-established and well-documented approaches to operationalize product management functions in an organization, many data leaders are approaching the implementation of data products as grassroots, DIY efforts primarily focused on technology.
Data products are being created (typically in the form of analytics, reports and dashboards), systems acting as product storefronts are being implemented (often data catalogs) and the products are being offered for consumption.
In many cases, the fundamentals of product management, a supporting product operating model and the importance of other enabling capabilities — such as product marketing — are often being completely ignored, which is problematic.
A combination of a focus on technology, little focus on people, and practically no focus on traditional product management practices, creates a situation where the implementation of data products will have very few, if any, tangible benefits for the average company.
Data leaders may say they are “doing” data products, but all they are really doing is slapping a new label on something they’ve probably been doing for a long time: building dashboards and enabling easier access to them. The fact that dashboards are now called products doesn’t itself drive any value for your organization.
Worse yet, customers of these data product initiatives know better. They can see that very little (if anything) has changed in their ability to realize value from data.
They are the same dashboards and the same insights. These reports may be easier to access through new virtual storefronts or catalogs, but the benefit of easier access to data is far from what most would consider transformational.
The Data Product Disconnect
So, for many companies, there’s a disconnect. They initially considered data products to be something that could fundamentally transform how they service their customers, especially those considering the data mesh, but the only tangible benefits are easier data access.
The reason for the disconnect is that data and analytics leaders have focused on the output (a data product), and not the processes needed to create the output. And when it comes to creating products, this process is product management. And when done correctly, product management can be the difference between successful products and failed products.
Product management defines the processes needed to create, manage and market products that best meet the needs of your customers, and in the most efficient ways possible.
If you’re a data leader serious about implementing data products, then by necessity you should also implement data product management. A focus on only creating products is just half the puzzle, but to gain the full benefits that data products can provide, you need to manage products correctly.
This focus on product management represents the biggest opportunity for data leaders when considering data products.
So, the question then becomes, “What are the major differences to a product management approach to data products that many data teams are not currently focused on?”
Consider the following five key disciplines of product management, which today are missing from data teams focused only on data product ownership.
- Product or Product Line Strategy
A key function of a product manager is product strategy, not only for a given product, but also for all products in each product line. In other words, there should be continuity between an overall data strategy and the various products supporting it. A part of the strategy also includes product lifecycle management — and managing a product across all major phases — from ideation to sunset.
- Design Centricity and User Experience
Product design and usability are critical weapons in a product manager’s arsenal. Understanding the overall user experience of a given product and applying design-centric approaches to defining product requirements help improve the likelihood that consumers will derive value from a given solution.
A focus on product usability and design would also not assume that users lack skills or knowledge (which is a core assumption of data literacy) — and instead ensure that the product requirements are such that even an average user could drive value from the product on day one.
- Distribution
A critical aspect of product management is product distribution. With every product launch, a product manager will ensure there is proper alignment between customer needs and habits and the channels being used to deliver products to them.
- Cost and Benefit
Product pricing is a key aspect of product management and will include all cost factors in product development, including any launch or go-to-market costs and ongoing support. Will the demand and willingness to pay for a product be sufficient for the organization to justify an investment in it?
This level of analysis is completely missing in all but an extreme minority of data and analytics teams who are implementing data products, but it’s sorely needed. The inability of data leaders to understand the quantifiable business benefits (which is a proxy of the price that consumers would be willing to pay) is a major factor in the failure of large-scale data initiatives — often caused by the inability to sustain ongoing funding or stakeholder support.
Skilled product professionals know how to estimate profit and loss for a given product, which is something all data professionals serious about data products should also be doing.
- Go-to-Market (GTM)
This is arguably the biggest benefit that traditional product management can bring to the world of data products. A typical go-to-market for a product would include:
- User training and enablement. User training and enablement are critical aspects of any product launch — but the effort required here could be considerably reduced when the product requirements consider usability and design as critical to success.
- Product marketing and positioning. All product launches need some degree of marketing, and data products are no different. Here, data products could combine a traditional marketing focus on the communication of a value proposition with data storytelling narratives.
- Ongoing user support. How will you offer support to your users after the launch?
- User feedback. How will you capture input from your customers on your product? What metrics will you use to define product launch success?
If data leaders are seeking more transformational benefits of data products (regardless of if they are focused on a data mesh strategy, or not), then these five key aspects of product management should be integrated into their data product strategy. Hiring an experienced product manager, rather than trying to develop these skills from scratch, would be a great way to accelerate this effort.
I talk more about how to unleash the power of data products in episode 28 of the CDO Matters Podcast, the only show dedicated to helping leaders become more data-driven — available wherever you get podcasts.
