Two new roles have emerged in the world of data in the past few years, roles that are providing a softer touch in a world of technical data. These roles are aimed to fill a clear gap in a function where juniors are plenty and senior few and bring product and project leadership in a world constrained by the lack of analytical leadership talent.

Data-Science Product Owner

The role was created by companies like Booking.com, heavily involved in Agile, and employing over 200 data-scientists. Nowadays, the role can be found in companies hiring only a couple of data scientists.

Ignoring the ill-fit that data-science has with Agile (where the Product Owner title comes from), there are preconditions and drawbacks to having data-science specific product owners.

Overall the company and team need to have a certain technical orientation and composition, critical size, and focus on making efficient use of a data product owner.

Technical Orientation: In a similar vein that some companies have TPMs, Technical product managers, to cope with the degree of technicality of the role, data-science product owners should have a technical background. Preferably this should be within the field of data-sciences. Booking.com notably used to hire ex-data-scientists for this role. Product Owners are meant to set the strategic vision, roadmap and prioritize the feature for development. This is not possible in a data-science team without a deep understanding of data-sciences, its constraints, how to set up an MVP and to be able to differentiate what can add value and what would likely bring minimal improvement.

Team composition: Some of the issues that often happen with data-science teams staffed with a product owner is that of team composition. It is very unusual, for instance, to have a data-scientist put model into production by itself. They tend to leverage the expertise of Data Engineers, and often of Backend Software Engineers for that purpose. In the team composition, it is also worth making the distinction between what people usually call type “A” (A for Analysis) and type “B” (B for Build) data-scientists. The difference is worth considering as the work of a type “A” data-scientists would be ported with more difficulty to production and might need additional engineering support.

Critical size: For it to make sense to have a dedicated product owner for a data-science team, there needs to be a critical mass of data-scientist in your organization that can be lead through a single vision. For this to apply, you need to have enough data-scientists focused on a single product area.

Team Focus: One of the issues having a product owner focused purely on data-science, is the focus that it can give to the team. Most often than not, a data-science problem is more easily solved by changing the different business or product processes to provide more signal in the data. Having product teams purely focused on data-scientists can hinder their output by limiting their scope.

Analytics Translator

Back in early 2018, McKinsey noticing a gap in the market, coined the title of “Analytics Translator.” They described the role as required in-depth domain knowledge to help better prioritize business opportunities.

Prioritization: Both the analytics translator role and the product owner role help prioritize the work carried out by the different members of the team.

• Event-triggered. The segmentation engine evaluates the segment conditions when events are triggered. This evaluation can happen, for instance, with front-end SDKs, or when leveraging event-based architecture. Some of the use cases for event-triggered include geofencing or A/B testing eligibility checking.
• Domain Knowledge: Both the role of an analytics translator and product owner requires business domain knowledge. Although it is only stated as a hard requirement for the analytics translator.
• Interface: The analytics translator is meant to bridge the gap towards the business and make sure that the business can leverage upon them, be it an insight or a product that is being built. The role of the product owner similarly is to act as a representative of the business to the development team, and of the development team to the business.

There is some difference in the roles, however. While the product owner role, tends to have more of a focus towards building products, the analytics translator has a role more geared towards the business and generating insights.

• Product / Project orientation: The role of the analytics translator is defined as being a more oriented project rather than towards product. It encompasses the full delivery of insights and the leverage of the information provided into action, as I had described into the 4 Pillars of analytics, Analytics Translators are responsible for the Last Mile.
• Technical fluency: McKinsey describes the skills needed for an analytics translator as “general technical fluency,” they need to have some general understanding of the technical concepts used in analytics. However, not necessarily be able to apply them themselves. This is a much higher level of technical data competency than a general product owner, but would likely be lower than most data product owner from large technological organizations.

Wrap Up

Both role aim to fill the gaps in a field that is becoming increasingly technical and where certain actors are detaching from their business roots. They can help compensate for lack of more senior analytics talents, such as a Head of Data Science, by providing more product/project guidance.

We need to however, be very particular on the conditions that we bring about these roles, as they need a certain critical mass of technical data talent to be truly beneficial and only introduce them in an organization that would provide the right context for these roles.

‍