Since Datanova: The Data Mesh Summit and our in-person executive discussions on data products and Data Mesh, we’ve been validating the data product approach — starting with identifying value and then selecting smaller use cases — that really resonated with the audience.
If you haven’t had a chance, you may still download the Data Products workbook. The workbook gently nudges you to think about your candidate data product because we’re going to be thinking about the why. More specifically: Why should the business create that data product? Identifying key performance indicators that will help the business get the most out of creating and building data products, help you fill out the workbook, and get the most out of this series.
In my last post, we identified five key KPIs to measure from an I.T. and business standpoint to anchor data-driven organizations. The next step is to scope out what a data product looks like, knowing that origins of a data product parallel a commercial product with a multi-stage lifecycle.
What is the data product lifecycle
The data product lifecycle begins with ideation, then design, manufacture, roll out and manage in the marketplace. Lastly, as the need for a data product narrows, the product retires, integrates, and/or absorbs into future concepts or products.
Ideate and align data products with business needs
This phase of the data product lifecycle requires a deep understanding of the business needs, along with key use cases. This creates assurances that the data product will meet the needs of data consumers while consummating business value.
Data product design
During the design stage, a data model is created, while the data product is defined. At this point, a determination is made as to whether the data product is a core product for broad use or limited product. Keep in mind that a data product shouldn’t be too broad (limits appeal) or too granular (increases workload). Keep your users in mind to help identify that middle ground which may require packing in different form factors (just like any other product).
Manufacture the data product
Once a data product is defined, a data product is created. A cross-functional team — composed of data analysts, data engineers, data product architect, data scientists, governance, risk and compliance, etc — is encouraged to create and build the data product together.
Rollout, iterate, and optimize usage
After a preliminary minimum viable data product is available to a select group of users, this group can put the MVP into production, arrange support, train users, and calculate utility. Over time, the team can iterate on the data product, while optimizing it via versions.
Provide data product support and service
Operational data products require monitoring, support, and services. The overall Data Mesh strategy should advise users on how to best use the data product. Domain and data owners should continue to oversee product quality, while operations should supervise data product usage.
Retire unused data products
Lastly, as data products retire, improvements gleaned from retired data products inform future data product ideation and design stages.
From data sets to data products
When you’re defining a data product, you’ll need distinct details. It’s important to have specific definitions about the vision, the user, the value, the technology, the usability and how you’re going to communicate and roll out the data product. Not all data is data products, and a good way to identify the products begins with looking at your existing data use.
Have a vision for your data
As you’re identifying and thinking about your data product, there will be a few points of differentiation as you think about your vision. Examine how the data product will enable end users and how it will align with the business objectives. First, consider the uniqueness of your data. Afterall, the uniqueness might be the business insights or analytics you’d leverage to consider strategic recommendations. The uniqueness might also be in the labeled datasets because it’s clean and has a great quality. And lastly, the uniqueness might be in the business model of what you’re able to certify.
Consider the end user’s needs
When it comes to users, know your end user by design for how they work and what they want.
Finance teams often love content in Excel. Business users might prefer a dashboard. Data scientists might prefer raw data as a starting point. Also, have definitions that are easy to understand, in the language that people use. Documentation is key. Lastly, have user support, training, and coverage across geographical locations so that your users really feel supported.
Track value with data
Value is being able to track your business value and your KPIs with data. Identify whether it is to: reduce costs, improve efficiency, innovate, collaborate, and monetize.
Differentiate on the technology
As always, technology is one of the ways you’re competing and how you’ll create a better data product. Here are some ways to differentiate your organization with technology: look at the ease of integration; how easy it is to create a technology interface; the speed and scale of processing; adding more semantic layers to the technology; and making all of it secure and privacy protected.
Focus on usability and delivery as your competitive advantage
When designing for usability and delivery, consider who the users are. For instance, for a user to have access to data and with context make a decision about metadata, master data management, quality, consistency, timeliness, lineage, standards, and adherence. All of these can make your data much easier for that end user to use.
Communicate with your users and stakeholders
Communication is your ability to manage your users and stakeholders — to help them find the data and empower them to use it. For instance, making data discoverable via a catalog or through search; having event-driven notifications about changes and updates; having support mechanisms: L1 through L3 support feedback; a roadmap and versions of your data product; and community management.
Roles and responsibilities with data products
As with most business critical initiatives, creating data products will require ownership and stewards. Consider the different stakeholders you should include and the different roles required to make the most of data products. Below are a few roles and teams that you should involve in your design and ideation phase:
Data product owner
The data product owner is concerned with versioning, the vision, the success, the rollout of the product, and how it aligns with the identified use cases. The data product owner will often start from the conceptualization phase, participate in the manufacturing as well as the rollout. They also ensure that the end users are using the product as it was designed and iterate as needed.
Data business sponsor
The business sponsor is accountable throughout the data product lifecycle. This role values data as an asset and something that the sponsor will be measured against, based off of the business metrics.
Central team
The central team takes a multifaceted role of consultant, design authority, and facilitates the process; this is especially true at the beginning of your Data Mesh journey. This role will likely enable the data product architect team, the product team, the operations team — within each domain. Ultimately, this role is meant to be a guide and someone who is providing oversight across the entire data product lifecycle.
Data product architect
The data product architect ensures that the product is worthy of deliverance in the manufacturer stage and adheres to the organization’s governance and management strategies.
Data product team
The data product team entails your data scientists, your data engineers, your system architects, and ultimately, these are the professionals who bring the product to life.
Data operations team
Just like any other product or any other application, there should be a service level agreement associated with the deliverable. Even if the service level is defined: best effort or no service level, that needs to be very explicitly thought through. This role will be played by members of the domain. You’ll also need an escalation owner if there is an issue with a data product, someone can be notified. That owner can also routinely monitor events and make updates.
Recap: The why and the what
Over the last two posts, we’ve discussed the why and the what of creating data products. We started with the first and most important reason: why the business needs to create data products. And in this post, we deepened our understanding of the data product lifecycle along with critical roles to support each stage. In our final post, we’ll cover how to adopt a data product mindset.
