Data teams aim to help the people in their organization make better decisions. Many data teams aren’t doing this as well as they could and are missing out on a huge opportunity, both for the organization and the team. This gap is due to teams not being set up for success, which undermines trust in the data and the insights the team generates.
There is a better way to build and run a data organization: run it as if you were building a Data Product and all of your colleagues are your customers. We believe this has the ability to transform your organization and help teams reach their true potential.
Note: While you may have heard “Data as a Product” before, we do not use it in the same way as Justin Gage does in “Data as a Product vs. Data as a Service“. Justin refers to the actual data and artifacts of Data Teams as the final product while we have a broader definition of what constitutes the Data Product.
Service-oriented data teams aren’t effective
Most data teams aren’t set up for success. For many years, data teams have been buried in the IT function. Like IT functions, those data teams handled getting data out of their systems and presenting them to the stakeholder as CSVs from which the stakeholders could work their magic and come up with conclusions.
For smaller organizations, data teams usually start when one part of the business (typically Finance or Product) realizes they need better cross-functional analytics, and they create a real data function. The first data hire remains the only data person for a while, and they spend all of their time answering other people’s questions.
When a data team emerges in a company as an afterthought, they often end up being built like service-based departments with a “submit a ticket with a question, get a very specific answer” mindset. Data folks who are bound to this model rarely spend time being proactive. Without intentional space, they are unlikely to be anything more than ticket closers.
For example, say Johnny McFinance wants to know about reactivated customers and Sally McMarketing is wondering about the performance of a retargeting campaign in digital ads. If Donny McData’s job is just to pull up the next ticket on the docket, he’ll never have time to dig into the data and see if there’s a connection between the two, even though he’s uniquely poised to see these connections.
In the service-org mindset, the opportunity is squandered. But when you start to see your Data as a Product that helps guide decisions, then you have a chance to maximize potential.
Data teams are building and supporting a Data Product
Product-led organizations are winning in the marketplace because they center the relationship between the customer and the product. Every other part of the organization is essential to build and support the product, but if the product doesn’t meet the needs of your customers then your customers will go somewhere else.
When you view your colleagues as your customer and the Data Team as building and supporting a Data Product, then you’re able to unlock the opportunity of your data and data team.
So what is the Data Product? It is the collection of every piece of data, and the tools used to generate, access, and analyze that data, within an organization.
The data are in application databases, the HRIS, the CRM, chat tools, issue trackers, and any products that your company might manage and sell itself. Every action a person in an organization is taking generates some sort of data. Whether it’s updating a customer record in Salesforce, responding to a ticket in Zendesk, or adding a new person in BambooHR, everybody in the organization does something that contributes to a large, distributed data set.
Every internal tool or app that gives people the ability to generate, access, and analyze data is also a part of the Data Product. These can be thought of as “features” of the Data Product. A simple heuristic is this: if people are using it to make decisions, then it’s a feature of the Data Product. And yes, this means that every Excel or Google spreadsheet is a feature of the Data Product.
The data and associated features have limited meaning and value within their own silo, but when integrated together within the Data Product, then superlinear value can be revealed. With this mindset, the data team’s role grows to include building and guiding the strategy and features of the Data Product. And because you’re building a product, you can take all of the best practices of product-led organizations to dramatically increase the value of the Data Team to the organization.
It becomes the Data Team’s job to tame this wilderness and enable the organization to pull useful insights out of this data flow.
Focus on the users, define success, and talk to everyone
Taming the wilderness means starting out with some of the basics of product management. A good product organization will center the users and their experience with the product. For example, the GitLab Product Team, for example, has as its mission: “We create products and experiences that customers love and value.” A user-centered focus is key.
This user focus means that much of the day-to-day of product management is coordination and communication between many different stakeholders. There is the outbound communication of what is the vision and prioritization of the product, and the inbound communication from users. When the users are your colleagues, this inbound communication can be loud and voluminous, but the strategy and tactics of product management will help.
When moving your Data Team to the product model, you should expect some pushback from other people in the organization. As a leader you must have strong 2-way communication. This will require a great deal of empathy as you’ll have to constantly balance the need to share your vision and goals with the need to integrate the feedback from your users (colleagues). You’ll need to continually communicate what you’re working on, what you’re not working on, and why you’ve made these decisions in order to bring your stakeholders along on the journey. Your colleagues will provide feedback about these decisions and your best bulwark for this is to get them involved in understanding the business impact of their needs. Make your colleagues feel heard by including them in the process in a way that’s visible and collaborative.
Tip: Communicate with your colleagues (users) proactively and hear their feedback!
Another key part of building a successful product is defining what success means for your organization and the product. In this Product mental model, success is a function of the impact you’re having on the business, measured in the number and volume of decisions you’re enabling or measured by the quality of those decisions with respect to a KPI. It is not the number of dashboards built; that is, it’s not the output of the Data Team. It’s the business impact of the work that the Data Team produces that matters, which can be difficult to measure. If you have a strong foundation of 2-way communication, it is worthwhile to align with your stakeholders on what that measurement looks like to them; for example, what KPIs is your team supporting and how are your initiatives supporting them. Like most functions, it is a worthwhile endeavor defining success and getting alignment early on.
Tip: Write this definition in a team handbook and visit it frequently. Build a culture of continuous documentation so you’re regularly aligning with your business stakeholders.
With a strong user focus, 2-way communication, and a solid definition of success, you can start to drive business impact through better decisions by using many of the tactics of product management. Much has been written about the tactics of product management (including on this blog!) but we will highlight just one that we believe to be valuable, especially early in a Data Product transformation: User Stories.
Users Stories are a simple way to define how a new feature (dashboard, chart, or metric) will provide value for the end user. User stories generally follow the framework of “As a (stakeholder), I want to (task) so that (desired result).” To write them, you’ll need to work with your user as a business partner to understand what problem they’re trying to solve or what decision they’re trying to make, instead of fulfilling a specific bar/line/pie chart request. A potential user story might be, “As a Director of Customer Success, I want to understand a specific customer’s product usage in the past 3 months so I can help them gain more value out of our product.” This user story then invites more conversation to further define what they actually mean by “product usage” and “value”. This is a good thing because it means you won’t end up building a dashboard that doesn’t actually solve the problem!
It’s easy to get bogged down in the specifics of tactics, but remember: user stories and other tactics should be deployed in such a way that you and your Data Team are focused on deeply understanding what your colleagues are trying to do. When you understand their needs and what solutions are possible, then you’ll be able to match the problem with the right solution more effectively than the requester imagined, thereby building something that will scale and have long term value.
Tip: Consider using an issue tracker (Trello, GitLab, GitHub, Asana, etc.) to help organize and prioritize inbound requests, plan work, and refine requirements with stakeholders.
The Data Product model works at any scale
The Data Product model can be done at any scale with appropriate adjustments for ambition and resources.
Here are some specific organizational tactics we recommend:
- Headcount: Data teams should be 3-10% of the total headcount, depending on the nature of the business. If data isn’t something that’s actively part of the company’s product or your Data Product is more mature, then closer to 3% might make sense. If you’re selling data or data is critical to how you generate revenue, then closer to 10% makes more sense. Also, executive representation (VP of Data or Chief Data/Analytics/Algorithms Officer) can be significant in helping the team be successful. Stitch Fix is a great example. An executive can help advocate for the breathing space your team needs to be successful.
- Multidisciplinary: Good product organizations have key roles required for the process of generating new features that will delight customers and generate revenue. Product Managers, UX Researchers, Designers, Engineering Managers, and more are all part of high functioning Product organizations. Within your data organization, you as a leader will need to consider how the equivalent roles on your team are staffed. Remember though that roles are not titles. If your team has already moved past the service model then you likely have people fulfilling these roles. This could be one person in a startup but as an organization grows you should proactively hire great people to fulfill specific capabilities. (For some more ideas read: How to best structure your data team will evolve as your organization grows and the needs around data evolve.)
- Funding: Funding a Data team can be tricky, but there are a few ways to experiment with financing this arm of your organization. If your company is forward thinking, they’ll pay for the Data team directly. You can also experiment with data funding coming from the departments who are supported by the Data team. Explain to your business partners what folks on your team do to support them and what it would take for them to get more support for future initiatives. Your business partners are best poised to talk about your data team’s ROI!
Start small and elevate the Data Profession
In case any of this too high-level and overwhelming, we also have some very specific recommendations that you can do starting tomorrow:
- Talk to a Product Manager: Having a conversation with a product professional is a good way to understand how they spend their time. Ask good questions and listen to how they work, what they prioritize, and what is a distraction.
- Ask Questions: When the next request for a very specific chart comes in, respond back with some questions to try and understand the problem they’re trying to solve. Frame it in a friendly way to see if you can help them answer the question too: “Can you help me understand what questions you’re trying to answer with this chart?” may be a good approach.
- Take Inventory: Part of managing and building a Data Product is understanding what’s in your product. Start identifying and documenting the different parts of your Data Product. This can be an excellent opportunity to talk to many different stakeholders across the company.
We’d love your feedback!
We believe that by adopting the best practices learned in building products any organization can amplify the power of their Data Team and unlock the potential within their data.
But we’d love to hear from you! Are you implementing something like this? Does this resonate with you? Chat with us on the Locally Optimistic slack in #leading-data-teams or come to our Meetup discussion on April 22.
