Brief

Around the start of the previous decade, data teams started moving into the mainstream. It became increasingly common to see data teams in small and medium enterprises, while originally this had only been the domain of tech giants like Google, Facebook (et al.). This was the same time everyone and their cat started talking about “Big Data”, or “Aha moments” and how data was about to do wonders in the world of information technology. Within such statements, you could already begin to see the kernel of a problem that has continued to plague CEOs to this day: What are the expectations of a data team within an organization? Today we’d like to share some of our reflections on this question.

Origins

In the beginning, the terms “Data Team” and “Data Science Team” were used interchangeably. A lot of these teams came up in the startup ecosystems around the world in a very short period. This growth spurt was fed by Big Tech organizations talking about how they had discovered actions or behavior patterns that made their applications “sticky” and helped them gain more customers quickly - like when Facebook said that any user that added 7 users in their first 10 days ended up staying on the platform. Before you even knew it, every data team in the world had started looking for these “Aha moments”.

As the world would soon discover, these “Aha moments” were few, far between and mostly obvious. The focus then started shifting towards Multivariate (A/B) testing and tracking the marginal impacts of Product UI changes on user behavior. However, since we weren’t sure what actions to look at, most of us defaulted to looking at ALL of them and this is when the big data engineering explosion began. Volumes of data tracked grew exponentially, and cloud service providers like AWS began offering new infrastructure solutions targeted at enabling the transport, storage, or computation of large volumes of data.

As this trend continued for a few years, organizations started realizing that it was not sustainable to continue investing considerable amounts of money into the development of such “black box” teams without knowing what they expected to gain in return. This is how the role of a “Data Product Manager” first came into being.

The Product Driven Approach

Data Teams are Product Teams. A data team is responsible for the development of tools and solutions to help the business move forward along its objectives. While they may rely on data to furnish these solutions, this fact is purely operational and should have no bearing on how you evaluate such a team. Their performance should be measured objectively in terms of the additional contribution the team makes to the organization’s capabilities.

As such, we can apply a lot of basic principles of product management to guide the actions of a data team.

  1. Impact, Usage, and User Satisfaction should be measured.
  2. Return-on-Investment should be expected.
  3. Time to market is important
  4. Quality and Availability should adhere to relevant thresholds.

How does a Data Product Manager help?

A Data Product Manager should help the data team deliver more value to the organization by using these principles for decision-making.

Manage User Relationships

Arguably, the first role of a Data PM is to understand their users. While we cannot help but generalize problems for the sake of an article like this, organizations can vary vastly in their composition. Business leaders at one organization can have very different levels of technical know-how or understanding of data. It is the Data PM’s job to gauge the technical acumen of these business leaders and use this information to define the dynamics of the relationship they need to build with their “users”.

For example, business leaders that don’t have a great understanding of data or technology may need a lot of guidance to understand how they can employ data to improve their respective functions. On the other hand, leaders who have prior knowledge of having put data to work in the past may only need you to help as a project manager, or at best to help them tailor their ideas to your current organizational context.

In all cases, this role doesn’t end with solution-ing or project management. A Data PM needs to constantly measure the adoption or usage of these solutions and keep reaching out to business leaders to understand if they have any problems or ideas.

Create an ROI Strategy

A data team can create value both directly or indirectly. Directly, by building solutions that help the business optimize operations, improve the product, increase revenues and reduce costs. Experimentation frameworks, automation suites, or anomaly detection are some examples of how a data team can add value directly.

Indirectly, a data team can help an organization by adding capabilities that would not exist in its absence. For example, the automated reporting of all important business metrics and KPIs. Building reports that allow managers to dissect the performance of their teams etc.

Further, you also have the classic Risk-Reward matrix to classify the various activities a data team may engage in.

Here’s an example:

Reward.webp

It is a Data PM’s job to use their understanding of the nature of these activities and the needs of their organization to create a strategy to maximize the value that the team delivers.

Prioritization and Roadmaps

In a situation when multiple stakeholders are vying for limited data engineering bandwidth, a Data PM can help with the prioritization of activities to ensure a healthy balance between the “Quickest Time to Market” and the “Most Value”.

A Data PM should also be conscious of the organization’s strategy to have an understanding of how the data team may be expected to contribute in the months to come. This can help you ensure that things are set in motion at the right time so that when the organization plans to start a new activity that relies on the data team, the data team is aligned and ready to act when called upon.

Challenge or Guide Engineering Decisions

Some value delivered now is better than the promise of amazing value after X months. A lot of data engineering teams fall into the trap of building the perfect experimentation framework, or the most capable data platform without adequately considering the time that will be spent to build these solutions.

The problem is compounded by the fact that data engineers are often far removed from the people who end up using the solutions they build. By acting as an advocate for the data user, the data PM should challenge engineering decisions taken by the data engineering team and help the team develop the data platform iteratively.

Conclusion

As we move towards the next generation of technology companies, there needs to be a greater focus on organizational maturity. Data teams are no different than product teams and must be held accountable for the resources they consume. A Data Product Manager can help your organization ensure that the data team stays true to this directive and hence, your next data hire should be a Product Manager.