A Product Manager’s View on “Data Products”

As a former Product Manager, I get it when people in the data space talk about how data should be considered a product, and delivered as one.

This really resonates from a Product Manager perspective. A lot of work needs to happen in the design, communication, strategy and coordination before any kind of technology is impactful to an audience of people.

The same goes with data: businesses are all sitting on a treasure chest full of insights, but unlocking it properly to allow for maximum adoption is tricky, and requires a lot of effort. It's less about writing optimized data pipelines than getting the right processes and tools in place for people to use and trust the data.

In my 4 years as a Product Manager at a SaaS company, I built and released a lot of APIs and UI-based products. In the process, I learned a few tips that apply to the data space, that can help improve the adoption of your data products across all consumers in your organization, from the most technical users, all the way to the least.

Define your personas

It goes without saying that you should know the audience of what you’re building. It’s almost too obvious, however, to the point where we often overlook this part.

Before building anything, defining your persona is really important, and will help you understand:

• Who are the users of what you’re delivering: what are their backgrounds and skills? How do they structure their time? What other tools are they using, and what is their typical workflow?
• What are their main responsibilities: is their main objective to make customer happy? To find way to push your company’s bottom line? To make sure that everything is tracked properly? To find out a clever ML model to make predictions?

Among your audience, there will undoubtedly be different personas. Don't try to create an “all-in-one” persona that would be a strange hybrid of everyone in your audience, that doesn’t really exist as one person. This would be a big mistake.

Rather, take the time to really define all the different segments and groups that exist in your audience and define them properly. This will be key to targeting them later on when building/deploying your product.

Find the right balance between simplicity and flexibility

When designing an interface, as an API or as a visual interface, you need to decide in which layer of the technology stack your product will be plugged. Should this be an http call to be made? A REST or a GraphQL one? A library full of functions to be used directly in your user’s code? A script to be run on a computer? A web page with a nice UI? The possibilities are endless.

However, some will have a much greater impact that others. That's because they will achieve the right balance between empowerment and simplicity for your target persona.

Each interface is located on a spectrum. On one side, you have the low-level interfaces, exposing the tiny bits of your product, giving maximum powers to your users at the cost of simplicity. On the other side, you have the highest level interfaces that offer simplicity and efficiency at the cost of flexibility.

In data, the spectrum goes from a warehouse table (low-level) to a PDF snapshot of a dashboard delivered by email (high-level), with everything else in between (Notebook, Exploration, Dashboard, SQL runner, etc.)

Your personas will all have a preferred range on this spectrum, one that is the right balance between how flexible they need the data access to be, and how simple it should remain for them to operate in their “zone of genius.”

Every time you design a data product, the form it will take and how you will package it will be critical. Hopefully, your existing stack should give you the ability to produce and deliver data products at each layer of your stack.

Don’t underestimate the importance of documentation

When using a technical product, the first thing people do is look for the user manual.

It’s the same with everything “new” that’s introduced to your life. Maybe that you can start using your new laptop or TV without referencing the manual because it's your 5th consecutive one and they all work in similar ways, but when people do something new, they go back to discovery mode, and that begins with picking up the manual and reading through it.

In my previous job, we saw first-hand how effective a documentation update could be. When it was published, more users were accessing it and learning from it. We noticed that users were trying harder to make things works, achieving more as the end result.

Documentation is also the reflection of the care that was put into a product. The better the documentation, the more trust people will have in your product. They may not admit it, but that’s the reality.

There is a common joke that claims that the real product behind Ikea furniture is the user manual.

In the data world, it means that tables, columns, metrics, explorations and charts should be described. Exposing tests is also a good way of demonstrating how things should work.

The first element of documentation - and a highly important one - is naming. With the proper naming of labeling of things, half the work is already done. Don't overlook this step.

Track usage per user

While working as a Product Manager, I discovered a powerful analogy: building a product is like raising a child. The initial release is like giving birth. It’s truly a magical moment for the whole team, your product/feature is “alive” and you’re incredibly proud.

However, that’s just the beginning of the road. It surely doesn’t end there. Now you have to make sure that your product can walk, become independent, get a good education, and be equipped with everything they need to succeed in life.

Don’t stop looking after it right after the initial release or your product, otherwise it will never become what it could have been. This “raising” of the “child” (product) through care/education can only be done through an understanding of what is in its life, where it’s at, who it’s surrounded by.

In a product, this is done by tracking its usage. Deep diving into usage and leveraging that as a feedback loop to know whether it's going in the right direction or not.

This usage has to be trackable “per user” because you’ll need to be able to contact your top user to understand the value that they are getting from your product and their feedback. You’ll also need to contact people whose usage has dropped or never took off, to understand what was missing from your product for them.

Most insights are not derived by looking at charts, but by talking to your users. Usage reports will help you discover which users you should be speaking with.

Another great thing about having user-based usage reports is that you know your current active users, and you can start sending them updates on what improvements you’ve recently made to your product. As they are active users, they will care and provide you with proper feedback.

Not knowing who is using your product is what can leave you alone in the dark.

In the data world, this means having a per-user log of queries / dashboards loads / exploration usage, etc. A Google analytics tag will only give you aggregated statistics, with no capabilities for per-user reporting, so don’t settle for that. Actively look for how you can track on a per-use basis.

Build trust by communicating reliability

As scary as it sounds, products break - and that’s a reality we need to embrace. Yes, we can always try lower the occurrence (and we should!), but we shouldn’t lose sight of the fact that it will happen, and we need to react quickly when it does.

Great relationships are not forged when things go well, but when things go wrong, and you go through obstacles together. That’s the same between you and your users. Depending on how you manage failure, people will start trusting you or doubting you. And as you know, proper data adoption relies on earning the trust of Data Consumers.

So, when things go wrong, your users need to know right away. If your “error mode” default is to display stale data, that’s fine, but you need to place a big red message on your product interface to let people know that your product is currently experiencing an outage, and may not be working as expected.

It won't solve the underlying issue that the product is broken and can't be properly used in that moment, but users will feel less negatively in that situation. If it breaks and they have to realize the issue on their own, this would be worse, so it’s on you to actively communicate and build trust. In this case, you are training their brains to look for any clues that could demonstrate that your product is currently broken. You don’t want that.

In the data world, it means that whatever your form your product comes in (dashboards, table, notebook), the end user should always have a way to check the system status. The less effort they need to go through to get the information, the better.

Make sure it’s fast by tracking latency

Users loves speed. They really do. If you want your product to be used, make sure it’s fast, and you’ll have a much better chance of gaining strong usage momentum.

However, performance (which = speed in this context) is a tricky topic as a Product Manager because:

• It's a “premature optimization” trap. Often, you start shipping the wrong features at the start and if you optimize it right away, the whole technical design is now more complex, which makes it harder to make functional iterations on it. So you’re stuck with something broken that you can no longer push in the right direction.
• It's a nice-to-have, and not a big blocker. Performance is generally not something that’s so important when you're still trying to validate if you built the right thing. If people don't see value in what you built, making it faster won't make it more useful.

Because of that, performance tuning often ends up at the bottom of the backlog. But it shouldn’t be overlooked!

In the data world, this means that when dashboards have a good initial usage, you should invest time into making them faster.

Then, you should track their performance by time. There is nothing less reliable than the human perception of time. Having proper latency tracking will help you understand if things are really getting faster or not.

Empowerment/limit exposure

The best products are the simplest ones. But at the same time, the best products are the ones that get the job done. Therefore, it’s important to strike a good balance between “everything is configurable” and “it’s super simple and works just like that.”

People love to continuously make tweaks on their product to make it their own, but they don’t want to be confused by certain configurations that they don’t understand.

In the data world, this means that you should think in advance about the range of insights that your product should serve. Should people be able to change the vizualisation? To run a different query? To join with arbitrary data? Finding a good balance will empower your personas without frustrating them.

After a period of time, if a configuration is never used, or if a column is never read, remove it. If people are consistently asking for the same thing, add it.

That said, it's best to not deliver things as fast as people are asking them. Time and recurrence of request is key to help you identify what should really be added that will add value.

Also, the less you offer at the start, the less you have to provide support for. In the early days of a product, you are still trying to gain trust from your users, so pushing too many features that won’t work and creating too many bugs is not the right approach.

That’s all for now, folks! The road to creating and distributing a solid product is long, and there’s a lot to it. That’s also how you should be thinking of your data product. Keeping these tips in mind and following this product management path is the only way to maximize your impact and boost data adoption across your organization. Only when people use and trust your data product, will there will company-wide trust in data.