Data as a Product vs. Data as a Service
The difference between providing “data” and providing “insights” (actually though)
WTF do data teams even do?
The job of an engineering team is to build effective, scalable products according to spec. The job of a product team is to understand and build solutions for users. What’s the job of a data team?
There’s no one or clear answer, which helps explain why the field is such a complete shit show right now. There are two broad mandates that data teams tend to get formed with (I’m being overly simplistic on purpose, bro):
1) Provide data to the company
2) Provide insights to the company
These might sound similar — and they’re certainly both important — but they necessitate completely different skillsets. In fact, I’m going to argue that the conflation of these two objectives is exactly what kills good data talent and confounds the hiring process.
Data as a Product: DaaP
Data as a Product is the simplest model to understand: the job of the data team is to provide the data that the company needs, for whatever purpose, be it making decisions, building personalized products, or detecting fraud. This might just sound like data engineering, but it’s not: Data Scientists also provide data as a product, just packaged in a different way.
In the DaaP model, company data is viewed as a product, and the data team’s role is provide that data to the company in ways that facilitate good decision making and application building. Some important characteristics of this model:
- Data has an SLA (figuratively) from the entire data team, not just data engineering
- Data flow is unidirectional, from the data team to the company
- Domain expertise has limited benefits for data team members
This model is not new at all, is a staple of what BI teams do at big companies like Microsoft, and isn’t going anywhere. But there’s no such thing as a free lunch (unless you work in tech). DaaP has some tradeoffs:
- Product-driven development, as opposed to stakeholder-driven development, limits the quality of partnerships and commoditizes relationships
- Being a member of a data team that just provides data is boring AF and difficult to hire for
- The perfect data model will never exist (sorry, optimists), and stakeholder understanding will always trail data team understanding
Over the past few years, companies have gotten wise to this, and have started using a different model (in consonance with DaaP) — Data as a Service.
Data as a Service: DaaS
In the Data as a Service model, the data team partners with stakeholder groups to tackle specific problems using data. Data team members have more functional experience, may support specific stakeholder groups (e.g. a Product Analyst and a Marketing Analyst), and are responsible for providing insight as opposed to rows and columns.
In a DaaS model, the focus of the data team is on answering questions as opposed to providing the tools to others to answer their own questions. To make this really concrete (because, let’s be honest, what does “stakeholder” even mean), a DaaS-based partnership might look like this:
- The product team has a question: how should we redesign and improve our onboarding process?
- The data team partners with product to identify what drives retention and long term value, holes in the current onboarding process, and suggestions for flow: using the data that the data team is responsible for
If the team was operating in a Data-as-a-Product model, they’d be providing access and intuitive use of the data that the product team can use themselves to answer their questions. It’s the difference between a service-oriented partnership and a product-oriented SLA.
Data Teams Grow Into Value Over Time
The difference between these two models — or in other words, the difference between providing data and insights — is twofold:
- Staff: do we hire experts in modeling and reporting, or experts in data-driven functional decision making? (background in product vs. background in data)
- Mandate: do we brand ourselves as providing insights and strategy, or as providing the data to make decisions?
For hiring in particular, DaaP and DaaS require completely different plans and head counts. 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.
In fact, the combination of these two models often changes over time: data teams start out by providing reporting and data, and grow into strategic prowess over time.
It’s rare that teams will be able to execute on DaaS without first mastering DaaP, and I’ve seen this problem first hand: data teams will try to grow into strategic decision support without rock solid reporting and data models, and it just doesn’t work. But as DaaS becomes more of a standard (and commendable) objective for data teams, this discrepancy in hiring becomes more important to understand.
Hiring The Right People For Purpose
To execute on a DaaS strategy, you’ll need to hire analysts and scientists who:
- Deeply understand the functional area that they support (product, marketing, support)
- Are able to communicate with stakeholders and really understand their needs
- Handle long term, nebulously defined, strategic research projects with little direction — the opposite of pulling tickets off of a backlog
Because these skillsets rarely overlap with excellence in data engineering and modeling, managers have a real decision to make here, which is why timing is critical. I’m going to repeat this because it’s one of the most common mistakes in data science hiring:
If you hire strategic, functional data people to do Data-as-a-Product things like reporting and modeling, they will be unhappy, they will leave, and you will fail.
Conversely, if you hire engineering oriented individuals without functional experience, they won’t be very good at partnering with stakeholders on critical decisions.
This — and failing to communicate the shift to DaaS to senior level stakeholders and leadership — is what tends to doom strategic data science. It’s actually really similar to hiring a product person as an early PM, only for them to realize that they’re really only needed for engineering work. They might be able to get it done, but they won’t be around to do it for long.
So, managers and leaders: 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.