The Rise of the Data Product Management Discipline

This guest post is part of our Continuous Product Design (CPD) Evangelist series.

Steve Harris is an experienced data product, data science, and data analytics leader in digital transformations and data transformations across industries. He has developed multiple large-scale, self-sustaining data platforms and ecosystems, and built multiple cross-functional global data organizations from the ground up.

In this post, Steve lays out and promotes the idea of data product management as a way to build more effective, usable, scalable data assets that are adopted, heavily relied upon and are seen as a true asset.

Product management continues to become one of the most elevated and important positions in many organizations. This is a great thing—it’s great to see the discipline of building better products being recognized, and this results in better, more usable products that impact the bottom line.

Any product manager worth his/her salt spends a lot of time thinking through the metrics that define a product’s success. What need are we working to meet? What steps do we want a user to take? What are conversion metrics? How does success metrics compare to those of other products? How does this impact conversion events for our company?

Producing good data requires product management itself: Data product management

As a data, analytics and measurement professional, chances are that you’re constantly engaged in these types of conversations. Your job is to come up with the strategy to measure, capture, report and analyze this data. But how do you go about this work? Are you a product manager too?

Data product management is how we deliver for our stakeholders and represent our users. We measure and build data, analytics, data products to understand the importance. We can also apply product management principles here.

How product management principles apply to the data product manager role

Product management is a discipline that has been developed, iterated on, elevated, and honed. The core tenets of product management provide a great way to guide our thinking.

Work backward from stakeholder needs—Proactively and intentionally understanding the needs of your stakeholders is paramount. It’s not just about having someone giving you a list of what to track, but it’s more understanding why something needs to be tracked. This involves an understanding of what’s driving your stakeholders’ behaviors. The best measurement plans I’ve seen involve a thorough understanding of the motivations and needs of stakeholders.

Empathy/Design thinking—Product managers regularly use design thinking with a set of users to elicit an empathetic understanding of user behavior. We can and should do the same! Design thinking is a codified way to bring things out in users that they might not easily know or have access to describe. We’re trying to do the same thing. We’re trying to understand how our users use our data/tools, what they need, how they need to get to data. Everyone wants to be understood!

Speak the language of your stakeholders—Agile product managers live their lives in continuous product design, scrums, EPICs, stand-ups, t-shirt sizing, story points and other well-established rituals. Chances are that you’re already part of a few of these with the products you work with. When we start to do the same with our data products, not only do we instill discipline into what we build, but we also start speaking their language. How much easier is it to tell a stakeholder in product management or IT that you need some of their time for this sprint rather than asking them to come to a bunch of meetings?

Data-focused in how we use data—Are you part of the “scorecard” for your business? In data and measurement, we tend to tell everyone else how they’re doing. Your stakeholders’ performance, even their bonuses, are likely dependent on how the metrics that you implement and report on turn out! But how do we measure our own performance? Measuring the performance of a data team is often really difficult, but we have to do it! To do this, we can include some of the same agile metrics, data usage, stakeholder surveys, etc. But I’ll admit, I haven’t found a perfect way to do this and to drive real apples-to-apples measurement for the output of a data team.

Adopting modern technologies—The things we can build, the technologies we have, the power of technology—all of those are expanding at an exponential rate. We can do today what wasn’t imaginable 10, 5 or even 2 years ago. Sometimes, this presents a challenge. It’s one thing to build a consistent tracking platform for a bunch of web-based funnels, but when our users can interact with our products through web, mobile, chatbots, Alexa, IoT and who knows what else, making comparisons becomes ever more challenging, and our jobs become more difficult (and much more fun!).

We have to be able to measure things built on these new technologies, and we have new technologies ourselves to use to measure, track, process, govern and report. With many packages, especially cloud-based offerings, there is a lot of data and measurement things built right in. For instance, AWS can include ElasticSearch, which not only can make parsing of data easier, but it can also provide countless ways to better compute and understand your data. In a sense, this is analogous to core economics principles—experts doing the things they’re good at (why cloud computing is so powerful, among the arguments)

Atomic-level approach—Microservices architectures are the core of a modern technology platform. Data products can and should function in the same way. If something changes, or if something fails, we can’t re-build our entire system. Change is the only constant, and we need to design our systems to embrace that change. We can actively drive a constantly re-usable system that is primed to be iterated on by looking at one problem at a time and treating our platforms as a collection of atomic pieces, each with their own best practices.

Now what? How to advocate for a data product management discipline

Data groups often suffer from an identity crisis. Many big organizations spend a lot of effort investing in product managers and IT. They build training programs, they elevate concepts, they train leaders to think like these groups and to talk like these groups.

But, as a data leader and practitioner, who does the rest of the organization think you are? Sometimes, data groups can be everything to everyone, or nothing to no one. A product manager might be asking you for capacity and story points—treating you like they treat IT. IT, on the other hand, wants to know what you want to build and wants you to give them intent. They treat you like Product. This can put you in the middle. The question is how you respond. You don’t have to be a taker of how people ask for something. You can and should put in rituals, etc.—this makes you into a product manager. Embrace it!

Now how do we get there?

OK, so I’ve convinced you! You’re ready to take the plunge! Now, how do we do this?

First off, recognize that change doesn’t happen overnight, and that’s not just a cliché. Think about your organization. Look back 1 year, 2 years, 3 years if you can. Things are likely very different than they used to be. But day-to-day, change happens gradually. So don’t expect to make this change immediately.

Three questions to ask to drive forward data product management

Question #1: Who can you partner with?

Find the stakeholder that can be your best partner, hopefully someone in product management. Sit down and plan with that person. Talk to them and tell them what you’re doing. Exercise your empathy muscles. Seek to understand—really understand—their needs, both what they say and what they don’t say. You’ll have to work to get that out of them.

Question #2: How are things adopted in your organization and who do you need to influence?

Then build something and bring them along for the ride. Product management, especially in the modern world of continuous product design, thrives on constant test and learn. You should be doing that too. Do something deliberate, and then learn from it. Then do it again, and do it better. Before long, you will get yourself in the habit of treating data like a product. And don’t forget to celebrate success—not just your success, but your stakeholders’ success as well. Make sure to elevate your partners and share your wins with their leaders as well as your leaders.

Think of something that was a new concept in your company and how it became an integral part of how the company does things. At one company where I used to work, something was truly part of the company once it was in place everywhere. First, you had to demonstrate success, but then, if others carried the mantle, you knew you had really moved the needle. How does change happen in your organization?

Question #3: How do you get and then iterate on feedback?

Finally, make sure you’re constantly getting feedback along the way. Simply put, feedback is the greatest gift someone can give you in an organization. Feedback helps you understand the impact that your work, and you, have on another. Build, get feedback, and then use that to guide your continuous iterations.

What do you think? Have you tried any or all of this at your company? What makes sense for you, or what above would you improve? I’d love to hear your thoughts and feedback.

Please comment on this LinkedIn post or feel free to email me at sharris@gmail.com. I am currently seeking new opportunities, and I would love to hear from you!