Data Product Management: Your Data Is A Product (Part 1)

Data Product Management: What You Collect

Startup founders, product managers, CTOs, and marketers – your data is a product. Data product management serves a want and satisfies a need. It’s developed through a detailed process of identifying what the customer (your company) needs. After countless hours of iteration, it will begin to solve a problem for this customer. Specifically, these businesses find value in your core product. Over time, they will require it to evolve and continue to solve problems for them.

Data is the foundation for all business decisions. Specifically, it guides your long-term strategy, call-to-action development & A/B testing. Building the data foundations of your company – as an under-10 person startup or a company ready for scale – is easy to do as a reactive process, without the same strategic prioritization you would normally apply to a product roadmap. Data is a product, and built well will optimize you for making the best decisions for your customers and prevent the wrong internal narratives from taking hold.

Data as a product has two key components: what you collect, and how you collect it.  

Failing at either of these components makes your data more than useless. Simply put, it will become dangerous.

Within your company, it’s important to define clear roles and responsibilities.

Maybe your company is at a stage where you can hire a dedicated data product manager as it builds or evolves its internal data product. If not, your existing product team’s needs to define an owner of the data swim lane at the company and take charge of it the same way they would own a funnel or a mobile app.  The data product manager should be responsible for how you collect data in your business, and for defining and executing the roadmap for building those data infrastructures.  

For example, the data product manager can also be responsible for what you collect at a high level – the schema and naming conventions you will use. Ultimately, the “what” responsibility for individual features should be owned by the product owner that is responsible for that feature.  If you’re small, this will probably all be the same person – that’s ok! Plus, it’s still good to separate the responsibilities and think of your business in a more scalable way.

Let’s break down some areas of pain around data, and how a data product manager can tie all of your data needs together into a product your company can benefit from every single day.

How You Collect Data

The scale and resources of your business – and the complexity of where data needs to be collected – will greatly impact how you collect your data. As a product owner of the data, the MVP of how you collect your data may simply be a client application that sends events to a third party data service such as a Mixpanel or Amplitude.  

However, you should have a roadmap and a set of expected checkpoints along the way that will inform how your data collection “product” can evolve into a complex system of dozens of third-party and first-party tools, and involves numerous stakeholders across business, product, marketing, tech, and customer service that need access to high fidelity data to do their jobs. When building a product for these stakeholders, all of their needs and problems must be considered, and then synthesized into a coherent prioritized roadmap as one would do with any product.

Consider all the stakeholders and teams that depend on your product’s data.

• CEO
• Business development
• Marketing
• Product
• Data
• Customer Service
• Technology

Each one of these groups is going to have slightly different needs.

Your CEO requires a high-level dashboard that provides an immediate indication of how the business is doing. This could include some product data, but likely will include financial data from a Stripe or iTunes Connect. The business development team might need high-level product metrics to advocate for why your company’s product is so awesome.  

The marketing team needs dashboards that provide data on marketing spend, lifetime value by channel, and perhaps even leading indicators or funnel metrics by channel.

The product team – the one you know probably know the best – need deep insights into user behavior in the product.  

The data team – the team that’s going to crunch the numbers and output deeper analysis. For example, they will focus on user behavior, leading indicators, correlations between actions and payment. As a result, they will be a very big stakeholder in the data collection process.

Customer service will need to look up customers and see their product usage or account information.  

The technology team will need to understand product performance data around crash rates or errors.

That’s a ton of data floating around – and there are a bunch of different connected systems responsible for handling it.  

As the data product manager, you will need to be collaborating with each of these stakeholders. Specifically, you need to ensure what you collect, and where you collect it, can be distributed to each of these stakeholders in the format they are going to need to do their jobs most effectively and efficiently. Your best friend will likely be a backend engineer that will be a key resource in building tools to ensure that data is flowing between all these systems effectively. Speaking of systems, here are some you might see in a maturing high growth startup:

• Data aggregators like mParticle or Segment
• Product analytics tools like Amplitude or Mixpanel
• CRM tools like Braze or Leanplum
• Paid media tool like Appsflyer
• Attribution tool like Branch
• A/B Testing tool like Optimizely
• Database SAAS like Google Firestore
• Customer Service tool like Zendesk
• Data visualization tool like Looker
• Long term data storage tool like Redshift

In the end, you may not need all these tools depending on the stage of your startup. However, you should absolutely be planning your data infrastructure to be prepared to onboard these types of tools as you grow. Connecting all of this data together can be mind-numbing and takes someone dedicated to it day in and day out.

Ultimately, when decisions get made to collect something new, this person needs to be thinking of all the places that data is going to be sent. Specifically, they need to think beyond just servicing the needs of the product team launching a new feature.