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

Hiring a Data Team With a Stubborn Manager

24 May

Liz Henderson, an Executive consultant at Capgemini, shares her experience hiring a data team with a manager who was difficult to work with.

Managing Up
Building A Team
Conflict Solving
Hiring
Data Team
Liz Henderson

Liz Henderson

Executive consultant at Capgemini

The Art of Asking Why: Narrowing the Gap Between Customers and Users

24 May

Jord Sips, Senior Product Manager at Mews, shares his expertise on a common challenge for product managers – finding root causes and solutions.

Customers
Innovation / Experiment
Product
Personal Growth
Leadership
Stakeholders
Users
Jord Sips

Jord Sips

Senior Product Manager at Mews

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

Navigating Disagreements When It Comes to Priorities

9 May

Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.

Innovation / Experiment
Product Team
Product
Dev Processes
Conflict Solving
Internal Communication
Collaboration
Convincing
Strategy
Prioritization
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

Why You Should Take Technology Risks in Product Development

25 April

Matias Pizarro, CTO and VP of Residents at ComunidadFeliz, recalls a time in his early career when he took a technology risk that had wide-ranging benefits to his product's user experience.

Innovation / Experiment
Product
Scaling Team
Dev Processes
Matias Pizarro

Matias Pizarro

CTO and VP of Residents at ComunidadFeliz

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.