- Tags:: 🗞️Articles , Data Team Vision And Mission
- Author:: Justin Gage (Growth at Retool)
- Link:: Data as a Product vs. Data as a Service | by Justin Gage | Medium
- Source date:: 2019-07-14
- Finished date:: 2021-05-01
Awesome article that documents the evolution of data maturity from a unique perspective: starting with data as a product, finishing with data as a service.
You start as a product team because:
- is the simplest model to understand
- there is a need to provide a foundation, with data talent, so that the rest of the company can do stuff with data.
- Requests at the beginning of the journey are “simpler”, and can be self served.
But over time, as the foundation is laid out, the data team has time to do more advanced stuff, and at the same time the questions other times want to answer with data become more complex. So the data team partners with stakeholders (maybe even embeds within them) to directly tackle strategic business projects.
The author ask us to clearly explain this evolution to stakeholders, and to keep in mind that every stage requires different individuals on your team.
The terminology is a bit confusing, because I wouldn’t call the beginning of the team “Data as Product”: you start as with “Data as a Service”, since there are no building blocks yet for anybody, so you support other teams directly, in a reactive way. Then, you juggle that we providing a building blocks, a platform, there you act as “Data as a Product”. And eventually, you are back in “Data as a Service”, but with a way more advance service, not reactive but strategic. So I’d say the timeline is: DaaS (basic) → DaaP → DaaS (advanced). In any case, these recommendations match the canonical platform team definition of Team Topologies.
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 (View Highlight)
the conflation of these two objectives is exactly what kills good data talent and confounds the hiring process (View Highlight)
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. (View Highlight)
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 (View Highlight)
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 (View Highlight)