Moving from Data as a Product to Data as a Service

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.