Building Data Products: The Three Questions You Should Ask When Spec’ing Out A Data Product

This post is the first in a series about building data products (customer-facing products based on data generated by your primary product). If you’d like to be notified when another post in the series comes out, fill out the quick form below!

Building data products can be tricky: they require the product manager in charge to not only be a domain expert in their own product, but also to have intuition and empathy around how their users might want to consume and act upon data.

We’re by no means experts here, but we’ve picked up a thing or two from working extensively with product teams, data teams, and data PMs – and from our own backgrounds as product leads and data owners. We’ll be sharing these tips in this series.

Look, we’ve been there. You just spent a quarter building great in-product analytics: you conducted user interviews, scoped out the KPIs that matter most to users, and worked with the engineering team to ship a beautiful, polished dashboard. Yet somehow, you’re noticing more tickets being filed by users asking for custom reports. Your team of analysts can barely keep up with internal requests, and they’re now getting crushed by the external load too. You see users attempting to export data any way they can – maybe they’re scraping your API so much they’re taking it down. They’re asking you to integrate with a host of other tools so that those in-product dashboards you built can be even richer.

What’s happening? In-product analytics aren’t meeting all the jobs-to-be-done of your users. They’re definitely meeting some (nice work!), likely around getting a high-level view of KPIs. But there’s much more they want to do with the data from your product. These users might have been better served if they’d been given a way to sync their data to their own data environment.

To help you get ahead of this, here are a few questions to ask when considering building a data product. They will help you determine what product to build, and how it should function. In some cases, in-product analytics will be perfect. In other cases, you’ll want to offer something like data warehouse syncs. Spoiler alert: these questions are not particularly novel or insightful. Rather, you can think of them as a way of applying classic product wisdom to the realm of data.

To make it all more concrete, we’ll use two imaginary payments products* as examples: Circle, a point-of-sale solution for small mom & pop bakeries; and Ribbon, a subscription solution for software companies.

* any resemblance to real products, living or dead, is purely coincidental.

1. Is the data useful and actionable on its own? Or is it most valuable if analyzed in conjunction with other data?

Rule of thumb: if the data generated by your tool is useful and actionable on its own, then in-product analytics are a great fit. If it’s most useful when analyzed in conjunction with other data, then your customers will likely want access to their data so they can perform more complex analysis. For those customers, data warehouse syncs might be a great fit.

Examples

Data from Circle is useful on its own. It can show the baker how much money they’ve made in a given month. Not only that, but it can surface actionable insights – for example, that bread generates most of the revenue made during the week, while cakes and pastries generate the majority of the revenue collected over weekends. The baker can then use this to inform how much of each good they bake.

It’s hard to think of other datasets that would make this data more useful or actionable to the baker. Based on this, the product manager at Circle might conclude that in-product analytics are a great way to meet user needs, and make sure to surface these insights within the Circle product.

By contrast, data from Ribbon is most useful when considered alongside other data. Sure, it has value on its own: it can show important KPIs, like churn rate, or the net number of new customers in a given time period. But that data is most actionable when joined with other data. For example, by analyzing it alongside customer success data, a Ribbon customer might uncover that most of their own users churn after filing a ticket for a specific type of problem. That customer can then go ahead and fix that issue, or at least provide stronger support around it, to remedy their churn problem.

Another Ribbon customer might join that data with their marketing data, and uncover that users acquired through ads have a lower LTV than users acquired through content marketing. This will then inform their channel strategy moving forward.

As a result, the Ribbon product manager might realize that they are better off giving customers access to data rather than trying to meet every single one of the analytics use-cases directly in the tool.

2. Who’s the audience for the data? Are they used to working with specific tools to consume or generate insights?

Rule of thumb: if the person who consumes the data is also the person who is the primary user of the product, then in-product analytics are a great fit. However, if the person who wants to derive insights from the data is not the main user of the product, then it makes more sense to allow users to consume the data outside of your product. The easiest way to do that is to give them access to the data (data warehouse syncs anyone?).

Examples

At the bakery, the person who cares about the data and insights is most likely the same person who set up Circle in the first place – the baker/owner. As such, they can easily log into Circle and consume insights directly from there. This makes in-product dashboards a great fit for the Circle product.

With Ribbon, the story is a little different. The tool was likely set up by someone in engineering. Yet many different people need to access the data it generates: the finance team, the sales team, and the exec team to name a few. As discussed earlier, other teams like product, customer success, or marketing, might also want to leverage the data it generates to inform their own work.

Instead of getting all of these stakeholders to log into the tool, it makes more sense to centralize that data to a place they already all have access to: the data warehouse. They can use their BI tool – something they’re familiar with – to analyze the data (perhaps alongside other datasets) or consume high-level KPIs. Those KPIs can be also rolled into standard executive dashboards which show metrics from across the board. In this regard, in-product dashboards are not sufficient for the Ribbon product. The product manager in charge may want to consider other approaches, like data warehouse syncs.

3. What market-segment do your users belong to? Are they SMB or mid-market/enterprise? What is their level of tech and data sophistication?

Rule of thumb: if your product caters to smaller companies – typically SMBs, or lower mid-market – then in-product analytics are likely sufficient. If your product is geared towards larger co’s, eg upper mid-market and enterprise, your users will likely have a) more specific analytics needs and thus more demanding requirements and b) the ability to leverage data if you give them direct access to it.

Examples

Small bakeries aren’t particularly tech-forward organizations. Their analytics and reporting needs are fairly simple: they generally care about how much revenue they’re pulling in, their margin, and what sells best. They’re unlikely to file lots of requests with Circle for complex analysis and custom reports.

Even if Circle gave them access to raw data, it’s unlikely they would be able to leverage it. They probably don’t have a data team, or a data warehouse, or a BI tool. The extent of their tech stack is likely the Circle product. It would be a waste of time for Circle to try and offer them a data warehouse sync capability.

Ribbon customers are the polar opposite. They’re typically tech-savvy since they themselves are software companies. They most often have a data team, and a data warehouse already in-place. If Ribbon were to offer a mechanism for accessing their data (such as data warehouse syncs), those teams would be able to (and probably delighted to!) leverage that capability.

Summary

Data products are, in many regards, just like other products: the single most important thing to keep in mind when designing one is who the user is, and what their job to be done might be (ie what function the product fulfills).

Asking questions about how the data will be used, who the user is, and what segment they belong to will help inform which data product to build, and whether in-product analytics are sufficient or whether customers might need more.

If you’re building a product that

• surfaces data which can be analyzed in isolation
• relevant stakeholders regularly log into
• caters to SMB or non-technical organizations

then you’re probably all set by offering in-product analytics.

On the other hand, if you’re building a product that

• surfaces data which is most useful when joined with data from other sources and tools
• offers insights which need to be consumed by executives
• is geared towards mid-market and enterprise, or tech-forward organizations

then in-product analytics probably won’t be sufficient. You’ll need to give customers access to their data in one way or another. We’re a little biased, but we strongly believe the best way to accomplish that is to offer data warehouse syncs.

If you’d like to learn more about those, or you want to offer them without writing a single line of code, get in touch by emailing us at hello (at) prequel.co or sign up on our website!