This is the Three Data Point Thursday, making your business smarter with data & AI.
Want to share anything with me? Hit me up on Twitter @sbalnojan or Linkedin.
Let’s dive in!
Introducing product management to data teams is called “product data teams,” yet few companies realize this is a complex organizational change.
So, following our deep dive into Analytics Engineering as organizational change, let’s dive into the concept of “data product teams” and whether this fits you.
Data Product Teams As An Organizational Change Summary
The idea of “product data teams” can be summarized into three simple words:
“Bringing business into data.”
Let’s ask Tim; he’s the head of data at a mid-sized company. Tim likes how his three data teams do their work, and when there’s one thing they are great at, it is efficiency. They turn ticket after ticket into a report and dashboard.
They know how to talk to their end users, all those Tableau-using marketing & salespeople.
But somehow, Tim feels things are off. Efficiency is excellent, but “Are we really creating value?” he’s asking himself too often lately.
There are signs this isn’t the case: In the budget rounds, his department often gets passed over in favor of software teams that, as people say, deliver more value. Tim is lacking the support to back his position up.
So, Tim speaks to the marketing and sales leaders. In fact, they share his feelings. Sure, they like the Tableau stuff and demand fast turnarounds, but when push comes to shove, they will favor more software developers over more dashboard monkeys (their words, not Tims).
Enter product data teams
Tim decides he might be unable to solve this problem with a top-down approach. His data teams are already close to the departments, so he decides to take the senior data engineers and send them to a product management workshop.
Their mandate from now on: “You’re responsible for shaping your product, not just making sure the issues are delivered fast. I want you to think about what makes the most sense for the company, not just for 1-2 individual end users.
In particular, I want not just to question each ticket, report, and dashboard; I want you to ask whether you’re doing the right thing in the first place by creating reports & dashboards.”
The three of them take this seriously. Soon, team one started to shift focus; they realized that the marketing department would benefit the most from more data education, not more reports. Because only 5% of the marketing people actually use data, they make it their mission to lift that percentage to the 30% industry standard. They hold workshops and teach people to use Tableau, but also how to use Google Analytics and Google Sheets.
The other teams take similar routes while still working on dashboards and reports; both collaborate to create a data platform & training programs to help analysts inside the sales department and the rest of the company to have an ever greater impact.
That sounds like an excellent idea for everyone, right? No, it isn’t, not for everyone. But let’s not get ahead of ourselves.
Defining “product data teams”
Introducing the concept of product data teams means installing a product leader into some/every data team. The crucial part is that this product leader can change the team's roadmap in a way he sees is best for the department and the company, in collaboration with all potential customers inside the company, but without many constraints.
The product leader is also responsible for covering the What, not just the How of the work.
This is usually done by providing product management education to a senior/lead data person on the team or by installing a new product manager.
The trade-off, yes, there’s always one
All organizational changes are trade-offs. Product data teams are the opposite of service data teams, which think of themselves as primarily focused on efficiency.
Service data teams, including their leads, get dictated the What. They get a roadmap handed to them.
Product data teams have the responsibility to find a good roadmap themselves.
Service data teams are optimized for efficiency, while product data teams are focused on effectiveness.
It’s a simple question: Do you need your data teams to be effective or efficient? Efficiency is usually needed when:
The problem is apparent, clear, and well-defined.
There is a step-by-step solution to the problem.
The tasks need quick implementation.
Think of customer service teams, apple support, iPhone repairs,... If that’s not the case, then maybe effectiveness is what you’re looking for.
Is this an urgent change?
The more data pushes to the frontier of products, the more getting value out of data is becoming important.
If your company feels it doesn’t extract enough value from its data, you should consider this change urgently.
What do you do about this trend?
You can use a simple process to decide whether this trend makes sense for you:
Make a list of all of your data/ data-related teams (include analyst teams, even if they are in one department)
Classify them in their current status into service/product teams
Identify whether they have a lead/senior person in them.
Identify whether you think this team should lean more towards effectiveness over efficiency.
When to skip this trend/ not to follow up on this one
Although most data professionals disagree with me, service data teams are valuable in the right situations. Organizational changes are expensive, and there’s no need to disrupt a working system.
The linchpin for this change is the availability of a good team lead, a team lead that has learned two key skills: a sense of the higher good that enables her to create a good roadmap that fits into the company, as well as a reasonable degree of moderation, that helps her to pull the change process of.
If you want more information, you might take a look at these two articles:
Run Your Data Team Like A Product Team (by Emilie Schario & Taylor Murphy)
Really Interesting Update on Product Data Teams.. But just really curious as to why the data teams always get hit when push comes to shove. Across many countries and industries.