In our experience at Secoda working with many data teams, we've seen most data teams do not have the tools they need to succeed. For growing organizations, the data function is usually an afterthought. The first data hire is brought on before raising a Series A and is expected to manage the workload that comes afterward with little to no support. This means that this first data hire usually spends all of their time answering other people’s questions. These teams tend to be overworked and are likely to remain a reactive function for the foreseeable future.
This is because most data teams are understaffed and misunderstood. Instead of reacting to employee data requests, working with data requires the data team to treat employees as their customers and their data as the product.
An organization's data product is its collection of all of its data knowledge, along with the resources used for accessing, creating, and analyzing that data. Making the data product more self comprehensive, accessible, trustworthy, accurate, and secure should be the goal of the data team and the data team.
Additionally, the data PM should help direct resources towards the highest leverage areas of the business. When products are built with everyone in mind, they usually don’t accomplish what they need to for any specific subset of users. Data PMs should think about their data products the same way. Building data products for specific levels of technical capabilities and specific persona’s of data consumers should be the goal of the data PM.
A good data product manager understands the company ecosystem of people and data. It is crucial to understand the different segments of the organization and document the requirements and knowledge from both data producers and consumers to generate and manage clean, reliable, and meaningful data. A good data product manager will apply product management practices to guide the roadmap for the data team by displaying some of the competencies below:
We think about data PMs as the bridge between the data team and the rest of the organization. It takes time, tooling, and measurement to make sure that all stakeholders can access the right data, but when it’s achieved, organizations can increase enterprise value by up to 5%.
Think about how difficult it would be for a product manager to manage features without critical information about how people are using the product. Today, many data teams are operating in this same way. It’s very unclear which tables, dashboards, metrics, and charts are used frequently and which should be depreciated. PMs can empower themselves and their teams with the information they need to make decisions to improve data products by adopting a tool that enables them to measure the most used data knowledge.
It should be possible for data PMs to see how often teams use data, whether they are using the right data, and whether they aren't using any data. By understanding how people use analytics', data PMs can focus on the most important tasks that drive data literacy across their company.
Over the next three to five years, we see the product-management role continuing to evolve toward a deeper focus on data as a product. Data product managers of the future will work with the data team to produce high-quality data products that can help drive self-service across the organization.
To communicate data with the rest of the organization, data PM's might choose to implement tools like dbt, Looker, and Secoda. As we continue to help data PMs for the organization share their knowledge, we hope to be able to offer a greater depth of assistance and support to all employees trying to use data to make decisions. Data interactions are becoming increasingly complex, and Secoda hopes to simplify the interaction with data for every employee.
One reality that many companies face when adopting cloud technology: designing data infrastructure for business in a cloud computing environment is just different. Legacy stacks can indeed suffice for many companies. But as business requirements grow and use cases increase, both in number and complexity, the models and assumptions that worked well enough in the data center become problematic.