Back to resources

Moving from Data as a Product to Data as a Service

Product
Data Team

12 May, 2021

Murali Bhogavalli
Murali Bhogavalli

Group Product Manager at Wave Sports + Entertainment

Murali Bhogavalli, Group Product Manager, Data & Platforms at Tinder, discusses how he managed to move from data as a product to data as a service as internal stakeholders kept coming with their solutions.

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

Scaling a Team in Two Parts: The Product and Manager

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.

Managing Expectations
Product
Scaling Team
Leadership
Meetings
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

How Product Management Chose Me

23 June

My accidental journey into product management

Product
Personal Growth
New PM
Career Path
Michael Castro

Michael Castro

Sr. Manager, Product Management at Capital One

How Product Marketing Can (and Should) Help Product Development

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.

Goal Setting
Product Team
Product
Different Skillsets
Cross-Functional Collaboration
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

How to Successfully Rebuild Your Product

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.

Customers
Product
Dev Processes
Users
Prioritization
Adir Nashawi

Adir Nashawi

Senior Product Manager at Hibob

How to Empower Teams to Build Out a Product Portfolio During Company Growth

6 June

Ivo Minjauw, Global Product Director at OTA Insight, discusses the importance of structuring your teams when undergoing company growth.

Alignment
Goal Setting
Product
Ownership
Performance
Ivo Minjauw

Ivo Minjauw

Global Product Director at OTA Insight