“I spent 20 hours building this dashboard and no one ever used it. How can they not see its value? It is so awesome.” - Eric Weber, Data Scientist, circa 2015, making one of many embarrassing conclusions he has made in his career.
When data science hit the mainstream in 2013-2014, companies rushed to call themselves “data-driven”. They hired data science teams. They built dashboards, models and insights. After all, the clearest path to getting value from data was clearly to use scientists who work with it, right? They asked “how do we become data-driven?” But they weren’t asking the right question.
The right question was “how do we get sustainable value out of data?” Put another way, “how do we make data an valuable asset?” For many companies, including many I worked with and at, data science became synonymous with building short-term and short-lived data assets.
From dashboards, to metrics, to models, to platforms, the investment of both time and money was high. Yet when I asked any data scientist about the use of their dashboards and models, two responses occurred the most:
“I’m not sure what people ended up using it for after I built it.”
“It barely lasted because the business priorities shifted.”
The more I talked to data scientists and data professionals, the more I started seeing a graveyard of well-intentioned data products. While some of products weren’t sustainable because of the technical decisions the creators made (or did not make), the vast majority of these products did not survive because they were not built to evolve, they were built to solve a specific problem at a specific time
The answer to “how do we get long-term value out of data?” is “make a data product that solves a real problem for your customer”. While it seems simple to say that long-term value comes from finding real, sustained problems, that is much easier said than done. Why? We often don’t have the luxury to focus on long-term problems. Here’s an example:
Imagine a Monday morning where you walk into the office and the VP of Marketing is furiously preparing for a board presentation and asks you for a way to see conversion over time. You go heads down for 8 hours and send the dashboard over, perhaps never to think about it again. In that moment, you can’t possibly think about the long-term, you’re thinking about things in that moment.
If we want to make a data product that solves a real, sustained problem for the customer, we cannot do it in a vacuum. The customer (either internal or external) needs to understand that our goal is to help them. We need the customer to trust us enough to expose their problems and goals. We need to show value and impact to that customer.
Honestly, for many of us in data, it sounds scary to talk to and engage with a customer. When I was in my first data science role, the idea of talking to other parts of the business was pretty intimidating. After all, what did I know about business? The good news is you don’t need to be a product manager to do this! You just need to be willing to engage with others and learn about their experience.
Here are 5 tips to get started on understanding your customer:
Define what your product is, from your customer’s perspective. What do they think the product does? Why do you think they choose to use it? What do they see as the limits of the product?
Write down who you think your customer is (either internal or external). Write down everything you can that defines them as your customer. This includes characteristics, behaviors, areas of focus. Share this with a couple of other people on your team for feedback.
Interview 3 of your customers. But don’t make it all about your data product. Just ask them to talk about what they are trying to accomplish on a given day. Ask them what success looks like in their role. Ask them about how they use your product? When do they not use your product?
Revisit the steps you’ve gone through in items 1-3. Focus on answering this question: What problem is your customer trying to solve? This answer doesn’t need to even mention data. But try to cleanly articulate what your customer is trying accomplish or solve in their role.
Define how your data product is helping your customer solve that problem. Write this out. Create an elevator pitch or 2-3 sentences that describe how your product currently (and could in the future) solve your customer’s problem.
You might be reading this saying “yeah, yeah, yeah, Eric, I get it, but I already know who I support.” Rewind a few years and I would have said the same thing if I had read this advice. In that time, I’ve learned the hard way that we tend to oversimplify our customer, we tend to assume we know more than we do, and we think our data products work much better than they actually do.
We cannot learn about our product’s weaknesses alone. We need our customer to give us feedback. To do that we need to know what the customer is trying to do. To do that, we need to get to know them! We need to know who they are.
Knowing your customer might seem like a small step. It is not. It is the most critical step you can take. If you don’t get this part right, everything that comes after it is far more likely to fail.
Want to start off on the right foot with a data product? Don’t start with the data - start with the customer.
———
Thanks for reading!
Eric
I love your perspective, and I couldn't agree more with the customer perspective. I'll challenge this: back in 2013 when companies rushed to form data science teams, was that the right organizational model? Building the ideal data product requires a split perspective: 1 foot in the technology, and 1 foot firmly grounded in the domain you support.
To anticipate the "customer" needs, should you simply be part of the customer business processes from the start? Can you build sustainable, agile, or automated data products without being fully immersed - and part of the team organizationally?
I've seen it both ways. The de/centralization debate based on technology skills and overlapping requirements (a customer is a customer if you're in marketing or finance, right?) hasn't been settled. I lean toward function-specific roles, sitting in those teams, but I'm open to being wrong on that...
As always, when I am reading your post, it is like taking a trip down memory lane. Where was this post three years back?