How to Leverage a Data Science Background as a Product Manager

Marvel. Spiderman, leveraging his powers.

Early in my product management career, I was told I had a unique point of view because of my data science background. I was skeptical — and hard-pressed to find guidance in existing product management literature.

Since then, I’ve learned that product managers (PMs) with a background in data science have a superpower that can turbo-charge their team’s impact. Specifically,

PMs with a data science background¹ should 1) invest early to align on a proactive data culture, and 2) be beta users who provide feedback on the internal data system to make sure it is as useful as possible.

I’ll go into each of these two areas in detail below, but I want to first point out that I don’t use the word “should” lightly. PMs with a data science background have a responsibility to do the above, first because they are able to, and second because this work actually falls in the realm of their responsibilities as a PM:

Figure 1. PMs have a responsibility to use their “superpower” in data science.
  • PMs with a data science background are able to do this work because they have a deep understanding of a data system’s impact. They can articulate foresight about trade-offs eg. when surfacing data needs driven by product use cases.
  • PMs with a data science background should be expected to do this work. Outputted information from a data system is useful for making the product better — data informs learning and complements opinion in order to better serve user needs. Ensuring the product evolves to serve user needs based on different information sources is exactly the PM’s role.

1. PMs with a data science background are uniquely positioned to push for early investment in a proactive data culture.

A PM with a data science background has the foresight, access, and influence to invest upfront in aligning on a strong data culture. I think about the data culture in terms of

  • The people and processes related to data (eg. informal and formal interactions between different teams in an organization), and
  • A useful data system, or the data operations’ building blocks (eg. ELT pipelines, intermediate and aggregated data stores, documentation) to sustain that culture.

PMs with a data science background are uniquely positioned to push for early investment in a proactive data culture.

What is a “proactive data culture?”

PMs work closely with (senior) stakeholders who have data-related questions². PMs with a data science background can set, upfront, what stakeholders’ relationships are with data, and with the individuals who build the systems that serve up that data. PMs should establish a pattern of behavior where those stakeholders are empowered to access information independently, as much as possible. Tactically, this means:

This sets the tone for data-related processes early in the product development lifecycle: it reduces the product team’s incurred cost, enhancing their ability to build the right product for its users. It also sets the organization on a path towards self-service data.

2. PMs with a data science background should be beta users of the data system, and provide feedback early and often.

PMs with a data science background should invest their time as beta users of the data system early, so that it is built to be as useful as possible for consumers of the outputted data.

Figure 2. Teams need a system of building blocks to support democratic data access.

Here, “data system” refers to the technology, documentation and governance needed for everything from collecting to aggregating / labeling the data (see Figure 2). Such a system critically enables the product team and stakeholders to access, and iterate on, product analytics. Building out a data system like this is a huge body of work! In some organizations, it is driven by a Data PM.

A strong data culture relies on a useful data system. This perpetuates the culture described in Part 1. How do we ensure a data system is “useful?”

This is where a PM with a data science background is invaluable. PMs should provide feedback early and often as a beta user testing the data system. This ensures that the system is rapidly iterated on, evolving to become as useful as possible for data consumers, and built with relevant product use cases in mind.

Tactically, this work includes:

  • Deeply understanding what data needs to be collected based on the product’s use cases and business’ goals
  • Communicating feedback on the system early and often to the builders. This includes identifying edge cases
  • Providing feedback based on other data technologies they have used or are aware of
  • Pressure-testing the system documentation

There is a cost to not investing early in the culture and data system, and it is high.

Data is communicated visually, and too often, talented data scientists become “dashboard monkeys’’ because a company’s organizational model incentivizes stakeholders to throw a metric request over a metaphorical wall. This creates a bottleneck when a company needs to scale, and negatively impacts individual morale.

Eventually this culture will have to evolve into a proactive one. But changing a culture is brutally hard — humans are creatures of habit — and is more difficult than establishing the correct one upfront. At that point, prioritizing a shift in behavior becomes a trade-off between building new systems, processes, and teams, and evolving the product.

Similarly, a data system will eventually need to be built, since there will be a need to scaleably measure a project’s success over time. The data outputted from the system may be most in the spotlight when a product launches or a feature ships, but the building blocks used to surface that data take time and effort to build. If PMs do not invest time in ensuring that the system is useful and relevant given the product’s use cases, the engineering team will be put in (the tough) position of having to prioritize between iterating on the data system, and evolving the product.

Figure 3. Product managers with a data science background should invest early in proactive data culture, and be beta users of the supporting technical system.

In conclusion, although an analytical mindset is critical for all PMs, PMs with a data science background can turbo-charge their product team’s impact.

We already know an analytical mindset is critical for all PMs. Quantitative evidence aids in evaluating trade-offs, and is helpful when quickly establishing or substantiating a point of view.

We also know that PMs with a technical background / know-how can shorten the time to robust conversations with stakeholders, like technical customers, and engineering and infrastructure partners. This is largely because they use the same jargon and mental models, which means they can speak one language. Such PMs can probe on estimates of scope of work (even though this is a really hard thing to do). Ultimately, this helps a PM drive building a product that more effectively solves users’ needs.

Figure 4. An analytical mindset is critical for all PMs.

A PM with a data science background may be inclined to double-down on axes familiar to them by, say, defining data schemas or building machine learning models for analysis. However, this is dangerous. The cost of continuing to do data science work as a PM will outweigh the benefit, because then the PM is unlikely to be doing the job of product.

Instead, we’ve learned that PMs with a data science background should leverage their skills in two critical areas:

  1. Pushing for investment, early on, in a strong data foundation;
  2. Being beta users of data engineering infrastructure and tools that the data team is building.

By prioritizing investment in data operations’ building blocks and being beta users of the tooling, PMs with a data science background can ensure that they are greasing the motor that powers the product lifecycle and truly solves users’ pain points.

¹ This piece is about the general PM function, but you can read more about Data PMs specifically here!

² Data-related questions can include questions about metrics, trends, anomalies and experiment results.