Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

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 Tinder, Inc.

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

Preparing Your Team for the Remote Workplace

29 November

Vadim Antonov, Engineering Manager at Meta, dictates how he brought a brand new team into the remote learning process by ramping up onboarding and creating a mentor system.

Alignment
Remote
Internal Communication
Coaching / Training / Mentorship
Data Team
Cross-Functional Collaboration
Vadim Antonov

Vadim Antonov

Engineering Manager at Facebook

How to Pivot a Product Idea at the Right Time

23 November

Adi Purwanto Sujarwadi, VP of Product at Evermos, shares how he diligently managed a product in one of the biggest eCommerce companies by being an individual contributor.

Innovation / Experiment
Product Team
Product
Embracing Failures
Adi Purwanto Sujarwadi

Adi Purwanto Sujarwadi

VP of Product at Evermos

Overcoming imposter syndrome through focusing on your strengths

19 November

James Engelbert, Head of Product at BT, recalls when he had to battle imposter syndrome when managing a new team.

Product Team
Product
Health / Stress / Burn-Out
James Engelbert

James Engelbert

Head of Product at BT

The Right Way to Ship Features in a Startup

11 November

Matt Anger, Senior Staff Engineer at DoorDash, shares how he took the risk and shipped features in a startup.

Alignment
Product
Dev Processes
Matt Anger

Matt Anger

Senior Staff Engineer at DoorDash

How Data-Driven Products Help Customers and Increase Sales

11 November

Richard Maraschi, VP of Data Products & Insights at WarnerMedia, shares his insight on incorporating data science, AI, and product management to overcome slowing growth of the company.

Product
Conflict Solving
Users
Data Team
Performance
Richard Maraschi

Richard Maraschi

VP Data Product Management at WarnerMedia

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.