#84 Driving to Better Data Outcomes with Collaborative Questions - Interview w/ Jean-Michel Coeur

https://www.patreon.com/datameshradio (Data Mesh Radio Patreon) - get access to interviews well before they are released Episode list and link to all available episode transcripts (most interviews from #32 on) https://docs.google.com/spreadsheets/d/1ZmCIinVgIm0xjIVFpL9jMtCiOlBQ7LbvLmtmb0FKcQc/edit?usp=sharing (here) Provided as a free resource by DataStax https://www.datastax.com/products/datastax-astra?utm_source=DataMeshRadio (AstraDB) Transcript for this episode (https://docs.google.com/document/d/1HyanBGukQ1zXUz25EOwtpClCfB-aoSYh3Aw2VZ9QAWI/edit?usp=sharing (link)) provided by Starburst. See their Data Mesh Summit recordings https://www.starburst.io/learn/events-webinars/datanova-on-demand/?datameshradio (here) and their great data mesh resource center https://www.starburst.io/info/distributed-data-mesh-resource-center/?datameshradio (here) In this episode, Scott interviewed Jean-Michel Coeur, who is the Head of the Data Practice at the consulting company Sourced Group. Jean-Michel has developed a simple three question framework that works well with people asking for data, especially business counterparts. The questions typically lead to collaboration instead of confrontation and gets data consumers to share what they want to accomplish with the data instead of what is their request. It feels more like a friendly chat than an interrogation or "prove to me why this is worth my time". He also recommends following up each question with "the reason I am asking is..." to explain specifically you aren't pushing back, merely information gathering. The three questions: Do you know what this is for? Do you know who is going to use it? Do you know how they are going to use it? Jean-Michel developed his three question framework after watching people struggle for years to properly request data and/or properly understand the use case of data consumers, often delivering solutions that did not meet business needs, wasting everyone's time. Oftentimes, the technical person wouldn't ask the right questions or they