Successful Data Products Represent the Customer but Don't Always Listen to Them
Have you ever taken a sigh of relief as you finish a big, complex data project that meets the requests of many across the organization? Have you also felt the frustration hit when that product you built (be it a dashboard, metric, model) sits unused just weeks later?
How could this have happened? I used to get so frustrated with downstream users of data product I built. I listened to them and reacted as quickly as possible. I asked them repeatedly what they wanted. Then I worked as hard as I could to build it. Why didn’t this work? Because the customer didn’t always know what they wanted.
What I’ve learned in building data products is that we are representatives of the customer. We are not a service organization. That means while we need to be hyper aware of what the customer wants, we shouldn’t listen to what they want at every moment. If the goal of the company was customer satisfaction, and internal customer satisfaction dramatically changed the balance sheet, then listening to customers at every moment would be the right call.
But builders of data products are trying to enable customers to make high quality decisions amidst a sea of uncertainty and changing priorities. In many cases, “what do you want us to do?” will not actually get you a useful answer. You’ll build the wrong thing. You’ll get frustrated. Relationships and trust become tenuous and real impact becomes elusive.
“Sounds nice. How do I do it, Eric?” Well, if there were a perfect recipe I’d give it to you. If you want to represent your customer and make them successful, listening to them is not enough (but you still need to do this!). Here are 5 ideas to get you started.
Listen to and know your customer. If you work with data science, product, marketing, sales or any part of the organization, you need to develop rapport and a relationship with them that builds trust. It is critical that you create a space for open dialogue, feedback and brainstorming. If you do not have this, you won’t have a “check” on your thinking or really embed yourself within the problems that exist. This setting is a must-have but is not sufficient to understand what data products are important.
Understand how your customer is connected to company or organizational success. Ultimately, your customer is trying to create and deliver value for the organization. They may not be sure how to do that or even understand the “art of the possible” from your data domain. This is where you must connect the dots between your customer and value proposition to the company. Why? If you cannot, you’ll build data products that a person wants that may not be valuable (or as valuable as they could be) to the company.
Spend time learning about the organizational dynamics around your customer. Let’s be real, knowing the org chart only tells you about 1% of how a company actually works. If you look at an org chart to understand how your customer’s structure or day to day works, you’re missing out on a whole lot. Spend time meeting others that work with or alongside your customer. Spend time understanding how those adjacent groups see the value proposition of your customer’s work. This will help you immensely in creating the right data product (or deciding not to create one at all).
Focus on collaborating with your customer rather than trying to meet the demand and inbound from them. If you work in data science, you’ve probably worked in a company that saw data science as a ticket organization rather than a thought partner. If you don’t get the dynamic right, or at least try to establish the right dynamic, data products suffer the same fate as one-off requests to data teams. A data product should emerge as a strategic solution to a problem that is agreed upon by a group. It should not be something thought of in the moment and demanded. If your customer thinks of it in the moment, you can bet they’ll forget about it a moment after you deliver it.
Say no. Saying no is something many of us aspire to do. But saying no in the moment is much harder than how it sounds in our head prior to walking into a meeting or drafting an email. Representing a customer and building data products that enable them to be more impactful to the organization means that eventually, you’ll need to say no. It takes practice. It probably will feel a bit uncomfortable. If you want to build the right thing, it means saying no to many things. Practice, practice, practice. I know it is hard.
The customer isn’t always right, but the customer’s success is critical for the organization. Building effective data products is all about the customer’s success. How and when we listen to the customer is the foundation of a successful data product.
Thanks so much for reading. It means a lot to me if you’d take the time to subscribe and share with others.
Implementing a data product is like running in a marathon but not with the scope to finish first, and not alone. You are the runner who stays behind, helping others keep up with the pace, to raise if they fall, and to drink water if they are thirsty. Hopefully, in the end, you are crossing the finish line, hand in hand with your team, like in an inspiring Oscar-winning movie.
Communication and collaboration are critical in creating bridges between people and building trust, which takes time, hence the marathon allegory. If there is no trust built, the outcome will always be under discussion.
Also, the org chart counts when you need to know the team structure and maybe guess which stakeholder has the budget to sponsor your data product but will not indicate who has the know-how and gets the job done. I often see non-executive roles having more power of influence and playing very well the "political" game, losing their focus and interest in what has to be delivered.