3 shades of data science

Fellow data scientists, have you ever wondered what drives you the most? Is it getting through that pesky target right before the submission deadline? Or is it implementing and testing that fancy but obscure algorithm you saw on KDD?

Data science in the wild

More often than not, you will find yourself in a situation where you are presented with those opposite scenarios. That feeling is probably even more present when you apply to your first data science (DS) job right after graduating. Consulting companies usually focus more on the first aspect: delivering something data science-y that achieves some well-defined criteria. On the other hand, there are companies that have data scientists that are mostly focused on applying (or beating!) state-of-the-art algorithms in their own realm.

So, the question is, can we have a little bit of both?

The perceived great chasm of data science: delivering results or paving the new way ahead. Photo credits: the Internet.

Enter what we call the product data scientist.

Try to put yourself in other people’s shoes, and reflect on the kinds of responsibilities associated with those working in these areas and how their tasks are perceived from different angles (with a funny ring to it):

Delivery data scientist

• What customers think I do: hero that solves all problems while the clock is ticking.
• What other DS teams think I do: attack problems by brute-forcing more features and all the models.
• What I actually do: reply to customer emails regarding weird data issues (data archaeology?).

Research data scientist

• What customers think I do: crazy scientist at the forefront of AI, building algorithms that will take over the world and make all jobs obsolete.
• What other DS teams think I do: scribble advanced math completely detached from the actual problems and reality.
• What I actually do:

And probably raise an exception right after.

Product data scientist

• What customers think I do: provide them with a polished product, beautifully wrapped.
• What other DS teams think I do: put on a façade.
• What I actually do: spend a substantial amount of time in front of a whiteboard with post-it notes, voting on priorities.

It seems like we tend to create these buckets when it comes to our perception of of the skill set a person has. Search for job postings for any of these 3 areas, and you will see what I mean. I must say it made me chuckle when I noticed that “perform A/B testing” was the most common skill asked of “product data scientists!” 🤭

Now, if instead of focusing on the people around you, you think about the organization, the differences becomes clearer. And why is that? Because what distinguishes the different types from one another is what they do and not how they do it.

The main differences between these types has more to do with the contributions they make toward the goal of the company, and less to do with how they do it. Think about what drives each type of data scientist and what their output is.

In the end, isn’t this all the same?

One important aspect to mention is the fact that these 3 types look very similar from a technical standpoint. Zooming in, the tasks done by any of the three, at a given point in time, might be exactly the same. Regardless of the area, the data scientists’ skill-sets do not substantially differ. One can be perfectly good in any of the 3 types of roles! However, when we zoom out and see how these data scientists are contributing to the company, the differences are much clearer. Which is to say that there is a big technical overlap, but a big functional difference.

But where does this all lead to? If you feel that there are now more questions than answers, rest assured. Everything is going as planned. Oftentimes, that’s precisely what happens when working on a product.

In the next instalment of this 3-part blog series, we will discuss what the focus should be when doing data science on a product team — practical examples included!