Summary: Data as a Product vs. Data as a Service by Justin Gage

The job of a data team is either DaaP or DaaS

Original article: Data as a Product vs. Data as a Service by Justin Gage

Motivation: the job of a data team can be divided into two categories: DaaP and DaaS.

DaaP: Data as a Product

Data is viewed as a product, and the team provides that data to the company in ways that facilitate good decision-making and application building.

• This is a staple of what BI teams do as part of self-service analytics - they provide data to functional teams who can then build their own dashboards and figure out how to answer specific business questions

• Tradeoffs of this approach:

  • Product-driven development, as opposed to stakeholder-driven development, limits the quality of partnerships

  • Work that just provides data is boring and difficult to hire for.

DaaS: Data as a Service

Data team partners with stakeholders to solve problems using data and provide insights, not just data.

• The data team’s work is dedicated to a specific domain (e.g., Product)

• They work with stakeholders to provide insights as opposed to rows and columns

• They answer questions as opposed to only providing data

Example: a DaaS-based partnership might look as follows:

• The product team has a question on how to improve the onboarding process

• The data team partners with a product team to identify what drives retention and long-term value using data that the data team is responsible for

• If the team were operating in a DaaP model, they’d be providing access to data that the product team could use to answer their questions themselves.

My commentary: this illustrates why self-service analytics rarely works.

Impact of choosing DaaP vs. DaaS on hiring

“It’s extremely rare to find exceptional data talent and exceptional functional talent together in the same human being. That’s why, in practice, these models are always mixed, but rarely well.”

To execute on a DaaS strategy, you’ll need to hire engineers who:

• Understand the functional area they support (product, marketing, finance, CS)

• Can communicate with stakeholders and understand their needs

• Handle long-term, nebulously defined, strategic projects with little direction — the opposite of pulling tickets off of a backlog (DaaP)

These skills rarely overlap with excellence in data engineering and modeling, so common hiring mistakes are:

• You hire strategic, functional DaaS people and let them do DaaP; those people are then unhappy and leave

• You hire engineers without functional experience, they aren’t good at partnering with stakeholders on critical decisions - the functional teams are unhappy, and business outcomes suffer.

You can start with DaaP and gradually transition to DaaS. Bad hiring decisions and failure to communicate the shift to DaaS to senior leadership tend to doom data teams.

Core message & CTA

“Be intentional about the purpose of the data team, your roadmap for changing that purpose, and who exactly you’re going to hire to get it done”