When I first read the term data product manager on Udacity (a training website), my interest was instantly piqued.

I have a background in data science and product management. What is this strange hybrid? I asked myself. Can knowing about it help my career?

I began researching.  

The answer, it turns out, is painfully obvious: a data product manager is a person who manages a data product.

But what is a data product? How is it different from a standard product? How does managing a data product differ from being a data scientist, data engineer, data architect, product manager, product owner, or any other jobs floating about the data world?

I needed to know.

First, I tried to learn the answer for free on the internet (because I'm a cheapskate). Then I decided to bite the bullet and buy Udacity's course. Then, I realised I (sort of) already was one.

I'm writing about what I've learned so that you won't have to go around in circles as I did. In this article, I'll explain the following:

1. What is a data product
2. What a data product manager does

Here we go.

What is a data product?

The term 'data product' combines two nouns: data and product.

Given these clues, let's approach this question by inspecting the one at a time to determine what they mean.

Then, we'll put them together to see what emerges from the combination.

What is the 'data' part of a data product?

What is data?

Actually, the question should be, 'what are data?' since data is plural (apologies, the geek within longs to be heard).

Warning: We're about to get philosophical.

Before reading on, take a moment to think of the definition of the word 'data'.

Not so easy, right? Definitions are difficult.

Here's my definition: Data are symbolic representations of the state of the world.

Data is not really in the world (try and answer the question what is data made of? and you'll understand what I mean by this). It isn't made of any substance. That's why it's so amenable to digitalisation.

So, to be about data, the product primarily symbolises something in the world.

Erm, Dan, can you be less abstract?

Sigh.

Google Analytics draws a line representing the number of people visiting your website. It's the 'line representing' bit that makes it about data.

What is the 'product' part of a data product?

Is data by itself a data product? If I emailed you a csv file with the previous ten years of stock market fluctuations, have I handed you a data product?

Good question.

The definition of a product is an article or substance that is manufactured or refined for sale. The idea is that you take something in its natural state, refine it in some way, and then you sell that refined thing.

The same goes for data.

In its raw form, data has no meaning. Or, instead, it has no intrinsic meaning. It's just symbols. It's like an uncut rock. It only becomes meaningful when used to answer a question. It must be refined.

Unless you're a data engineer or data scientist, you probably won't interact with raw data. Instead, the data you interact with will be made useful for you.

What else makes it a product?

Well, to interact with data, users will need an interface. This interface raises design and user experience questions.

It's the harmony of these elements together that makes it a product.

Back to Google Analytics. The 'product' part is the experience. Google could have spit out all the logs to you, so you could figure out how many people came to your site. But that would be a bad experience. Instead, they represented it in a nice bar and even put that bar next to other bars, so you can see if the number of visitors had increased or decreased.

So, what is a data product, then?

A data product is designed to show users a symbolic representation of the world to help them understand it better.

Internally or externally facing?

Some data products are internally facing, and some are externally facing.

An internally facing product might take all the data within your organisation and feed it to various departments for reporting (though that's not the only use).

An externally facing data product might allow users to input data themselves and give them access to various analytical tools.

I've worked on both kinds of products (though we didn't call the internally facing one a 'product', it was), and from a product management perspective, there isn't a great deal of difference between the two.

What does a data product manager do?

The development team of a data product is made up of specialists.

These specialists usually are only good in one or two areas.

That's fine, but these teams need coordination. That is, they need to point at a goal. We are teleological (goal-setting) creatures. Without clear goals, teams quickly fall apart.

So, as any product manager, that's your first responsibility: set goals and define success.

But it's not enough to merely set goals. I could put the goal to go into the car park and dig a big hole. But it probably isn't going to help much.

So, your second responsibility is to figure out the most valuable goals.

You must journey out of your cave and talk to the people using your products. You must ensure that you're adding value.

I've been part of teams where management gave me resources before I'd done any research. I fought them to reduce the size of my team to give me time to learn about the customer. They wouldn't have it. They just wanted me to implement their idea. I implemented it, and it didn't sell. Why? Because it wasn't valuable.

The third responsibility is to set the pace.

Move as quickly as possible, documenting everything and sharing your ideas openly. Time is money, and you have a big team of expensive developers waiting on you. Feed them as much as you can as quickly as you can. I'm not saying to rush this stage–far from it–but don't dawdle.

I like to get feedback quickly and often, both when I'm managing and developing. If I have an idea, I write it down, share it, and get feedback. The same goes for a manager. It isn't valuable if it isn't written down, shared and discussed.

This constant and quick feedback will do several things:

1. Reduce the risk of doing the wrong thing.
2. Give the feeling of a lightning-fast pace.
3. Improve the team's skills (who get feedback on any mistakes they make).

Go quickly.

The next responsibility is to coordinate the team.

You're in an unusual position when working with specialists in different fields (in one project, I worked with data engineers, data scientists, machine learning engineers, front and back-end developers, designers, dev ops and roboticists). You know less about each area than every other team member but more about the project as a whole.

A coordinating role only requires you to know some of the tech as thoroughly as your engineers do, so get used to communicating with your team at a relatively high level of abstraction. You need to know enough to stop them from pulling the wool over your eyes.

Another responsibility is helping communicate between upper management and the development team. I can't count the awkward conversations I've overheard between upper management and the engineering team. Management speaks in broad strokes; engineers in detail. It's like overhearing a conversation between an eagle and an ant trying to describe an elephant to each other.

You have a foot in both camps–much of your time will be spent translating between them.

The final responsibility is knowledge of the possibilities of tech. The degree to which this is important depends mainly on how technical the role is. I've met some extremely tech-savvy product managers. I've met others who specialise in their fields and pass the details on to business analysts and product owners.

Either way, understanding what can and can't be done and how difficult it is can help save vast amounts of time and discussion.

As a data product manager, you must understand data. You must understand the economics of it. You must understand how it's accessed and stored. You must understand what services exist to help you move data around. If you're using machine learning, then knowledge of that field will help. The more you understand, the better you'll become.

To summarise, these are what I think the main responsibilities are:

1. To define goals and measure success,
2. To find the most valuable goals,
3. To set the pace,
4. To coordinate the team,
5. Helping to communicate between upper management and the engineering teams,
6. Knowing the tech space, especially around data.

I hope that was helpful!