"Please, no ad hoc data requests any more"
Business and data teams can stop fearing them... how?
A request from the marketing unit to its data team often looks like the following. Does this remind you of something?
EVA:
Hello Tom, I hope you're doing well! I just came out of a marketing meeting, and they're asking me to provide a vision for the children's accessories in the new collection as soon as possible.
Can you extract the data on the products from this list for me? It's urgent, do you think you can send it to me before noon?
Thank you so much!!!
TOM:
Hi Eva, what data do you need? Since when?
Your product codes are not very clean 🫤
EVA:
Store, product, revenue, volume, margin, the number of stores selling the product, we also want to know if they have ordered them properly…. I don’t know, include everything you can!
TOM:
That's quite a lot, Eva... I would need a bit more context and specs…
EVA:
I know, but you're the data science pros 😉 For now, we'll manage with raw Excel. Can you put this in our tracking Excel for next week? Thank you so much!!!
<kpis_newco_v3_def.xlsx>
TOM:
We'll see what we can do, we'll get back to you...
It might be a caricature, but it’s not so far from reality.
We call it an ad hoc request. What happened here?
A business question arises due to recent results, the recognition of a trend, or a new business context...
The business translates it into a data need - or tries to.
A data extraction request lands in the data teams in the form of an extraction request, not always contextualized, and often poorly received.
And in a large organization, the unexpected happens daily!
Eva's position is not simple.
Management implicitly asks Eva to provide a critical view of the new collection's performance. She may have some impressions and personal opinions from store colleagues, but nothing more, and she doesn't know what questions she'll be asked at the next meeting.
Tom has access to the data. Eva may have limited access to certain predefined aggregates, through a tool she doesn't master. Or she may not have access to the data at all.
Her colleagues told her that the data team exists to provide this kind of services, so she asks.
Plus, she doesn't have much time because she also needs to prepare a brief for the communication agency by 2 PM.
Tom also finds himself in a very uncomfortable situation.
By definition, the request was not planned.
It's urgent.
Eva is unaware of the number of sources involved in each of the requested metrics.
Several assumptions are not expressed and can lead to misinterpretations.
Eva presents a static list of product codes to consider. Are they valid? Will they change next week?
Eva hasn't tried to explore the business issue with Tom, preventing him from being more relevant and autonomous for the next request.
Tom's sentiment is expressed by Seth Rosen in a tweet that has been widely circulated in the data sphere:
Them: Can you just quickly pull this data for me?
Me: Sure, let me just:
SELECT * FROM some_ideal_clean_and_pristine.table_that_you_think_exists
What could happen after this conversation?
Tom will reluctantly perform an extraction, making assumptions himself.
Eva will realize that it's not exactly what she needs and will ask Tom to redo the extraction. Potentially multiple times.
The list of product codes will change next week, and Tom will have to implement a pipeline based on a manual, more or less well-maintained Excel file.
Tom and his colleagues will try to control these types of requests by establishing a request description interface that will be incomprehensible to the business, widening the gap between the two teams, and making the relationship even more dehumanized and transactional. Maybe Eva will have to provide a budget code for Tom to process her request.
Eva will no longer have the desire to work with data and will struggle to justify their added value.
So… let's rewind and imagine a new conversation between Eva and Tom:
EVA:
Hello Tom, I hope you're doing well! I just came out of a marketing meeting, and they're asking me to provide a vision for the children's accessories in the new collection as soon as possible.
Can we take a look at it together?
TOM:
Hi Eva, okay! Has management already specified a measurement axis? A collection to compare this one to? We launched a children's collection before, but it was a collaboration; I'm not sure if it's a good reference.
EVA:
No, you're right; we won't use it as a reference. Instead, we'd like to compare this launch to the women's accessory collection we launched at the same time and look at the cross-selling of accessories with the rest of the children's fashion.
TOM:
Okay, I understand! Can you give me the scope for this study: the period, products? For cross-selling, we'll use the metrics from the wiki, right?
EVA:
Yes, yes, we won't show cross-selling numbers without including Confidence and Lift.
Everything is maintained by the product teams; you have the start and end dates and the active assortment in the data they provide.
TOM:
Perfect, I have everything I need! In what format and how often will you need to consume this data?
EVA:
For this collection, let's see how it goes like this. If you can update a datamart every week with the weekly volumes per product and the accessories > fashion cross-sell, that's perfect. I'll make adjustments in PowerBI as needed based on my managers requests.
If it works well, though, can we take some time to see how to make it more sustainable?
TOM:
With this information, we can provide you with a first version for last week's data before noon. Okay for the next steps, my schedule is up to date!
What just happened between Eva and Tom? How is it better than the first chat? Share your thoughts, and I'll discuss it in the next article, “Anatomy of an Ad Hoc Request”
To end this first article, as requested by Juan Sequeda from the famous Catalog & Cocktails podcast, here is the Business Value Box for today. I will do my best to include one at the end of each article, and it sums up:
The TL;DR (Too Long, Didn’t Read) of the article
How today’s topic is linked to increased revenues
How today’s topic is linked to reduced costs
How today’s topic is linked to mitigated risks
================== !!!BUSINESS VALUE BOX!!! ================
TL;DR
In today’s article, we showed what a not-so-caricatural ad hoc request looks like, why it’s bad and inefficient for business and tech teams. We drafted also what a much better conversation around an ad hoc request should look like.
How is this topic linked to increased revenues?
Cross-fertilization between business topics
Tech workers likely get requests from all around a business unit or even the whole business. Getting higher exposure to business contexts enable them to connect the dots between different requests. Like in, “We are talking about setting store pricing levels for various regions, but did you know that we worked on a multi-feature segmentation of stores for the product folks? Wouldn’t it be an even better approach?”
Reduced time to insights > reduced time to market
When designing your next actions, you (should) need insights. By cultivating an effective communication between business and data teams, insights are built faster and you can iterate faster towards your new actions. I bet that if every iteration is a never-ending ping-pong game of bad communication, you will go the quick and unexplored path, statistically leading to more bad decisions.
How is this topic linked to reduced costs?
Less misunderstandings > faster convergence > reduced costs
How is this topic linked to mitigated risks?
More effective communication doesn’t exactly mitigate risks per se, but we will dive deeper later in how the foundations of a more effective communication - knowledge management (including data catalog & company documentation), master data management - support less error-prone processes and a reduced exposure to risks.
================== !!!BUSINESS VALUE BOX!!! ================
See you soon!
Make sure not to miss the next article by subscribing right now:
And if you've experienced this, share this article: