Data Product Should Focus on Depth, Not Breadth

If you’ve spent any time around an organization using data, you can probably close your eyes and hear the words “the data” ringing in your head. “The data isn’t right”, “the data isn’t easy to find”, “the data doesn’t make sense”. This triggers a feeling that “the data” needs to be fixed, or easier to use, or more reliable. So data product managers (and the organizations that support them) try to tackle “the data” in aggregate. But here’s what I’ve learned: you cannot win all at once. You can’t broadly succeed in a data transformation all at once - you must go deep in a specific area.

Why does this matter? Because as I see organizations start to tackle data as a product, they start by hiring product managers to handle entire platforms, entire practices (like machine learning, experimentation, and analytics). Whether we intend for it to happen or not, the feeling in the organization when a product manager comes in with a broad title is that they’ll “fix” or “address” all the ills and issues in that domain. The problem is, this sets up data product and the data product manager to almost certainly fail. It takes years to build a platform, to transform an area of practice and to get things clicking on all cylinders.

My proposal isn’t earth shattering, but I think it is practical: start narrow and start deep, rather than starting broad. Do you want to hire a product manager for analytics? Specify which part of analytics you mean, including the team, the datasets and the specific personas you want to affect within the organization. Do you want to hire a product manager for machine learning? What, specifically, do you want them to transform in ML? Is it feature stores, monitoring, deployment, or potentially bandits to evaluate models?

I get it. The temptation to create a data product organization brings with the desire to show how transformational a data product group can be. This creates a desire to speak to the big possibilities and transformational practices that can arise from building a strong team. But that takes a bigger team, a bigger practice, and won’t allow you to get things off the ground. Here are 5 ways that going deep and narrow benefit you and your organization:

1. Depth requires specificity and specificity requires prioritization. It is easy to say that you’d like better ML, experimentation and analytics. It is harder (and more useful) to say exactly what you’d like to improve about those practices or platforms at your company. Prioritization forces you to speak to the specifics that most benefit your company in the stage it exists at that moment in time. At the same time, it also helps leadership understand that a specific area of practice gets better by hiring for a specific outcome, not a general platform.

2. Depth enables you to tell candidates (both internal and external) exactly what they’ll be doing and what they’ll be responsible for. It is really hard to hire good data product managers, not just because the skillset is hard to find, but because good candidates are hesitant to walk into something entirely ambiguous (though some ambiguity is a natural part of this type of role). Imagine how powerful it is to say “you’d own this dataset, this monitoring process, with these KPIs” compared to “you’ll have to figure out how to make an entire platform operate well”.

3. Depth creates more natural swimlanes and enables you to build a stronger data product organization. For the 20 or so data product organizations that I know well, they started off by hiring a group of people in data product and then figured out where to put them as the group grew. This created some friction and confusion because people wanted to know the where their role and responsibilities start and where they end. I’ve faced this challenge myself, and I can’t say there is a perfect solution. But by being specific, you can build a team faster with more separated (and clear) desired outcomes.

4. Depth enables you to speak to your wins and impact in a way owning an entire platform often does not. There will always be issues with “the data” or with “the platform”. No data or platform is perfect or works in the right way for everyone. But by defining goals and outcomes that are specific, it is much more likely a data product manager can show success and impact in a space. The conversation moves from “why didn’t they address this other stuff?” to “they hit the change targets we had in this area”.

5. Depth enables expertise in a way that breadth often does not. I believe that it is not possible for a data product manager to be an expert in every area of ML, experimentation or analytics, yet expertise is exactly what is required in some highly technical spaces for a company to succeed. If we continue to try to make someone responsible for an area of practice (like ML) that even the best people in the world can’t fully keep track of, we’re setting PMs up for failure. By narrowing their scope, it is more likely we create a path to success, impact and that they feel empowered to “own” their area.

I’m not sure we’ll ever get away from the phrase “the data” coming up in meetings. We can’t easily expect others to have a nuanced understanding of the tech stacks, platforms and datasets that comprise “the data”. But if we want to create a path toward truly changing the narrative around “the data”, we can’t have product managers tackling everything related to the data. Defining a deep, specific area of practice not only helps PMs, it helps the organization at large.