Moving from Data as a Product to Data as a Service
12 May, 2021

Group Product Manager at Wave Sports + Entertainment
Problem
As a data PM, I work with cross-functional teams in the B2B2C space. I don’t interact with end consumers; I interact with internal stakeholders who are building features and products for end consumers. We provide data products to internal teams that are used to generate customer outcomes.
Our data process can be classified as providing data-driven insights (AI and analytics) and data-powered solutions (AI and machine learning algorithms). Typically, other teams would come to us because they would need more data, data in a specific format, data with a certain SLA, etc. However, they would often come to us with their own understanding of the solution -- how that solution should look or how it should be delivered. While internal stakeholders may be subject matter experts, I am proud to say that we know better how to solve their problems.
Actions taken
At first, my team was trying to address all the problems coming from different teams. We were taking their requests at face value without asking probing questions that would allow us to understand the underlying problems beneath what was obvious. At that time, we rarely challenged their solutions and didn’t spend much time investigating if those solutions could be used to solve problems troubling other teams. By doing so, we became captives of a “data as a product” mindset.
However, a distinction between data as a product and data as a service is becoming increasingly important in the data world. When you approach data as a product, your job is completed once you hand over the product. But, when you approach data as a service, you are creating something of more significant value that could be used multiple times by different stakeholders. That should be the mindset we should acquire and which should drive our efforts. Instead of taking for granted what a team has to present both in terms of problems and solutions, we should deep dive into the problems and keep digging, asking them additional questions that would help us understand the underlying causes. Addressing underlying causes would enable us to develop a far better solution than what the team was asking for. Over time, we would be able to bring in knowledge amassed from trying to solve problems for different teams. Therefore, we would be able to provide holistic solutions that could solve a multitude of problems.
What critically impacted our mindset shift was that we were repeatedly working on the same old problems. We would get a data product request that would strongly resemble a request for which we already developed a solution a few years or months before. We soon realized that there were many requests that were much one and the same thing, though different in flavor. If we could combine the two or more and deliver only one solution, we would save significant time. But since we didn’t thoroughly investigate underlying causes the first time, we had to create a new solution from scratch. We experienced an enlightening moment once we realized we were not approaching the work with the right mindset.
Our mindset shift impacted our relationship with our stakeholders. We would still listen to them and their problems, but would disregard the solutions they were proposing. Perhaps, we could use them as some starting points for a brainstorm, but not as something we would rush to implement. That resulted in much-enhanced solutions that were useful to many more consumers.
Lessons learned
- Ask your stakeholders what their problems are. Even if you decide to listen to their solution, keep it in your pocket, and don’t feel obliged to implement it. Instead, identify commonalities cutting across multiple problems and build solutions to solve multiple problems different teams face.
- Keep a repository of the problem statements. If there is no registry or any other mechanism to log requests, you will never have a source to go back to and trace if someone worked on it three years ago. There is a constant influx of people, and those who worked on problems will develop institutional knowledge that will go with them. Instead, everyone on the team should document its work, have access to the repository and be able to look back at past solutions.
Discover Plato
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Related stories
2 August
Viswa Mani Kiran Peddinti, Sr Engineering Manager at Instacart, walks through his experience scaling a team, product and his skills as a leader.

Viswa Mani Kiran Peddinti
Sr Engineering Manager at Instacart
23 June
My accidental journey into product management

Michael Castro
Sr. Manager, Product Management at Capital One
20 June
Pavel Safarik, Head of Product at ROI Hunter, discusses the frequently overlooked role of product marketing in getting high user adoption rates for your product.

Pavel Safarik
Head of Product at ROI Hunter
6 June
Adir Nashawi, Senior Product Manager at Hibob, shares his insight and experience from rebuilding a product to handle many feature requests and offerings.

Adir Nashawi
Senior Product Manager at Hibob
6 June
Ivo Minjauw, Global Product Director at OTA Insight, discusses the importance of structuring your teams when undergoing company growth.

Ivo Minjauw
Global Product Director at OTA Insight