We have many data products at Collibra, all of them are properly governed in our Data Intelligence Cloud platform. There, users can easily see a description of each data product, the metrics it contains, what data sets it is based on, and finally shop for it if they are interested. But having a data product built doesn’t necessarily mean that users automatically see value from that product.
Let’s take the example of a data product that I built for my colleagues in the BDR (Business Development Representative) department called the Test-Drive Intelligence Data Product. This data product helps the BDR team see how well our Test-Drive (a tool prospects can use to easily get hands-on experience with our Data Intelligence Cloud) is performing. The goal of my data product was to inform the Test-Drive team on how well it is being used, and provide insights to our BDR team on prospects using the tool so they can engage in relevant conversations.
Evolving the product
The project and the data product went live rapidly, and because of our monitoring phase (see the 8 step process) we quickly realized that we could improve the dashboard’s usage. Our hypothesis was that we had to bring the insights closer to the BDRs’ work context.
A BDR has to perform 3 steps in order to get to the value (typically caused by a specific action) of the Test-Drive Intelligence Data Product:
- The BDR (or the data product consumer) has to navigate to the dashboard.
- The BDR has to process the data by digging through the dashboard and come to an appropriate decision (e.g., which follow-up action to take).
- The BDR has to perform the chosen action (e.g., plan a follow-up conversation with the Test Drive participant).
The evolution of a first generation data product
From my perspective dashboards are the first generation of data products; they are fundamental, interactive and they allow you to dive deeper when needed. I believe that the second evolution of a data product should remove the first step: why should the BDR go find the information in the report when we can bring the information directly to their work context? This can be solved by having the analytics embedded in the tools where those consumers live (sometimes also referred to as Embedded Analytics or Reverse ETL).
Because we monitored the data product’s usage, and because we kept in close contact with our BDR colleagues, we quickly identified that Reverse ETL was a low-hanging fruit for improvement. We added 2 key metrics (already available in the dashboard) directly to their work context (our CRM system: Salesforce), including a link to the dashboard so that they can drill into the data when required because the detail in that dashboard still provides additional valuable context. The first and second-generation data products go hand in hand.
The evolution of a second generation data product
Our study on the “Valuation of a Data Product” prioritized the creation of this second generation, there we saw that the usage of the data product is essential for its value (obviously). The more the data product is being used, the higher the value. We could even envision tracking the usage of this field in Salesforce and test how much quicker leads move in the pipeline.
We succeeded in shortening the path to value by removing the first step, but the BDRs still had to perform the second step (making an appropriate decision based on the information).
The evolution of a third generation data product
Could we get to value faster by evolving our data product into a 3rd generation?
This would mean we’d need to turn the data into a decision (or better: an action) automatically, which we could achieve with an AI model or predefined rules. In our case we could, for example, envision a churn prediction model that sends automatic messages to the BDR suggesting which Test Drive user in their portfolio has the highest potential to need help, ideally together with suggested support (e.g., a training course, a short live demo of a specific feature,…).
Thinking ahead we could see how those messages might quickly overwhelm the BDRs (or their Customer Success colleagues). What if they get dozens of Slack messages or emails per hour – on top of their already packed inboxes?
We could consider automating some of the tasks: for example automatically inviting users that show a pattern of being “stuck” to training sessions. In an ideal situation, the data product offers both human action as well as automated options (as displayed in the image). So the third evolution can be improved upon as well, but we should always remember there is no substitute for human interaction.
Conclusion
Ultimately we all want to get to value (actions) with our data products. The quicker we get there, the more valuable it experience. Working with Data Product evolutions proved to be successful for us — we start with the dashboard, add the data to someone’s work context and finally, predictive power removes the need to process data in order to come to a decision. In this way, there is full focus on taking the appropriate action. The evolutions are not there to replace each other, if there is doubt about a prediction, one can always return to the dashboard or metrics to double-check or add human instinct.
