Building a Data Product Organization, Part I

As a data consultant, I’ve had the incredible opportunity to understand the mechanics of a wide variety of data teams at different companies. I’ve seen very successful examples, and also organizational patterns that lead to mediocrity, failure, and in some cases, pure chaos.

In this series, I’ll discuss a theme that I have seen lead to success when adopted by organizations of various sizes and industries. My goal is to convince readers to consider moving away from a traditional data team setup, in which the data team operates as a services organization, and to adopt a new mindset that leads to a data team functioning as a product organization.

Background:

Many of you reading this may be part of a data team that is operating in a model commonly referred to as a “data services organization”. This describes a team who has an intake process for data requests, most commonly for dashboards or specific data questions (e.g. “What was our average weekly ad spend by channel over the past 6 months”). The team sifts through the data requests, prioritizes them, and works through tickets in a sprint-based fashion. If you’re reading this and thinking, “Huh, that sounds like my company”, you’re definitely not alone. This is the way that many companies’ data teams operate. And it works, for a while…

Why move away from this model:

There are four cascading consequences that are a direct result of this having a data services organization.

1. Lack of scalability. Meme culture in the tech world has smashed that word into the ground, but it’s a real consequence of not adapting to a better model for your data team. When the business scales, so does the demand on the data team. This seems obvious — as the business grows and generates more data, there will be an increased demand in the volume and complexity of your data requests — but what’s not so obvious is how to enable your team to handle this increased demand. All too often I see organizations throw more money and people at this problem in hopes that the data team can at least scale linearly with the business, leading to the data team being a slow moving cost center.
2. Inherent lack of innovation. This type of data team is fulfilling requests from (in many cases) non-technical people, and making sure that the solutions they deliver are meeting the requirements to spec. This does not drive creative solutioning in the way that experienced data professionals — yes, I’m speaking for us all here — like to be challenged. This confinement quickly leads to a decrease in morale and stagnation in career development opportunities for your team. At risk of generalizing, most data analysts started their career because they realized at some point in their prior career that they loved playing with data and solving complex problems, and made the switch. Think about it — very few of us graduated from college with a degree in SQL and just continued on to their career in data. The point is, we all love diving into the data with our heads down and figuring out new patterns and sharing them with others. And if we’re focusing on building new dashboards and spending 2 days trying to figure out how to make our BI tool format a date in the right way, we lose out on that.
3. The detrimental effect on the rest of the business. Consider the folks who are submitting data requests… Perhaps a finance stakeholder needs to understand forecasted revenue for the next 3 months from the brick and mortar business in advance of a budgetary meeting. Without a quick answer to this question, they’re unable to make a valuable recommendation in the next meeting. Or perhaps a supply chain manager needs to know the typical demand of a certain product in November to begin making purchase orders. When the people that run the business rely on the data team to supply them with information to make key decisions, and with a backlog inhibiting the data team to meet that demand, the entire business suffers.
4. All of this leads to cost. Without changing your operating model, the increased demand on the data team is going to require more and more staff to fulfill. With a decrease in morale comes an increase in turnover — the ability to quickly onboard new team members and ensure continuity of knowledge transfer is going to be diminished. Of course, there are many ways to address issues with morale and turnover — an easy way is to just pay your team more money. But in lieu of changing your operating model, you’re putting a bandaid on a gaping wound and it’s going to cost the business more money than it would cost to address the root of the issue.

The solution: Productize your data org.

What does it mean to productize your data org? In essence, it means building new features and tools to allow your business to answer their own questions, instead of asking the data team to answer questions. It also means developing empathy for your stakeholders and respecting their expertise in their business domains.

Productizing your data team can also be hard. It requires dedication and buy-in from leadership, and it requires making some short term investments and concessions in favor of long term payoffs. That said, the earlier you make the shift in mindset the quicker you will realize the benefits. There are many strategies you can consider to help transform your team away from a service model.

To start discussing the “How” of productizing your data team, stay tuned for the next part of this conversation, lead by Hannah Galloway, our Director of Product Design, and Andrea Ramirez, our Director of Product Management.