Today I’m chatting with Samir Sharma, CEO of datazuum. Samir is passionate about developing data strategies that drive business outcomes, and shares valuable insights into how problem framing and research can be done effectively from both the data and business side. Samir also provides his definition of a data strategy, and why it can be complicated to uncover whose job it is to create one. Throughout the conversation, Samir and I uncover the value of including different perspectives when implementing a data strategy and discuss solutions to various communication barriers. Of course, dashboards and data products also popped up in this episode as well! 

Highlights/ Skip to:

• How Samir defines a data strategy and whose job it is to create one (01:39)
• The challenges Samir sees when trying to uncover and understand a company’s existing data strategy (03:39)
• The problem with the problem statements that Samir commonly encounters (08:37)
• Samir unpacks the communication challenges that lead to negative business outcomes when developing data products (14:05)
• An example of how improving research and problem framing solved a problem for Samir’s first big client (24:33)
• How speaking in a language your users understand can open the door to more exciting and valuable projects (31:08)

Quotes from Today’s Episode

• “I don’t think business teams really care how you do it. If you can get an outcome—even if it’s quick and dirty. We’re not supposed to be doing these things for months on end. We’re supposed to be iterating quickly to start to show that result and add value and then building on top of that to show more value, more results.” — Samir Sharma (07:29)
• “Language is so important for business teams and technical teams and data teams to actually be able to speak a common language which has common business constructs. Why are organizations trying to train 20,000 people on data literacy, when they’ve got a ten-person data team? Why not just teach the ten people in the data team business language?” — Samir Sharma (10:52)
• “I will continuously talk about processes because there’s not enough done actually understanding processes and how data is an event that occurs when a process is kicked off. … If you don’t understand the process and how data is enabling that process, or how data is being generated and the trigger points, then you’re just building something without really understanding where I need to fit that product in or where I need to fit that workflow in.” – Samir Sharma (11:46)
• “But I start with asking clear questions about if I built you this dashboard, what is the decision you’re going to make off the back of it? Nine times out of ten, that question isn’t asked, if I build you this widget on this dashboard, what decision or action are you going to make or take? And how is that going to be linked back to the map that strategic objective? And if you can ask that question, you can build with purpose.” – Samir Sharma (19:27)
• “You show [users] a bit of value, you show them what they’ve been dying to have, you give them a little bit extra in that so they can really optimize their decisions, and suddenly, you’ve got both sides now speaking a language that is really based on business outcomes and results.” – Samir Sharma (32:38)
•  “If the people in that conversation are the developers on one side, the business team, and they’re starting to see a new narrative, even the developers will start to say, “Oh! Now, I know exactly why I’m doing this. Now, I know why I’m building it.” So, they’re also starting to learn about the business, about what impacts sales, and maybe how marketing then intertwines into that. It’s important that that is done, but not enough time has been taken on that approach.” – Samir Sharma (24:05)
• The thing for me is, business teams don’t know what they don’t know, right? Most of the time, they’re asking a question. If I was on the data team and I’d already built a dashboard that would [answer that question], then I haven’t built it properly in the first instance. What I’ve done is I’ve built it for the beauty and the visualization instead of the what I would class is the ugliness and impact that I need.” – Samir Sharma (17:05)

Links

• datazuum: https://datazuum.com/
• LinkedIn: https://www.linkedin.com/in/samirsharma1/

Transcript

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today, I’ve got my pal, Samir Sharma, out in the UK on the line. What’s up, Samir?

Samir: Hey, Brian, I’m good. I’m good.

Brian: Yeah [laugh].

Samir: Good to see you. Although, you know, the listeners won’t see us. But yeah, great to see you. It’s been a while. Really glad to be here.

Brian: It is. Yeah, CEO of datazuum. You’re always making the noise, stirring the pot about data strategy on LinkedIn, which I love that we’re getting focused on why are we doing the things that we’re doing and trying to align all this work with data towards business outcomes and—

Samir: That’s it.

Brian: —and user outcomes and not just building crap [laugh].

Samir: For the sake of it. Absolutely. Yeah. You know, I’ve been banging that drum for so long now and I’ll keep banging it because I think there’s still so much improvement to be made. So, yeah. You know?

Brian: Yeah, let’s jump in on that.

Samir: Absolutely.

Brian: So, I do pin these words ‘data strategy’ next year, and when I think of this, you’re definitely in my mindset, or as my coach calls it, a Rolodex moment.

Samir: Oh, ri—I love that.

Brian: I definitely get that.

Samir: Rolodex moment.

Brian: Yeah. I get the Rolodex moment when I think of this. But so today, I want to make some of this—strategy is often amorphous, it’s an eye-roller for people that are doing even middle management stuff, it sometimes gets an eye roll because two years into some giant project, I don’t know what the strategy is we’ve been doing; this is my life, you know [laugh] Monday through Friday. It’s lost. What exactly is a data strategy in your opinion? And can you define this within, like, one to two sentences?

Samir: Yeah. So, in my view, a data strategy is the way that you use your data to drive out the business strategy and deliver on the business outcomes.

Brian: Mm-hm.

Samir: It’s as simple as that.

Brian: Whose job is that to create a data strategy?

Samir: That also is a very good question, Brian [laugh]. And I’ll tell you why I say it’s a really good question. Because there’s essentially the business strategy is driven out by the CEO, the board, and the C-suite. They’re all there; that’s what they’ve signed up for. The shareholders have signed off and that’s literally where we’re heading with the business or corporate strategy.

Underneath that, oftentimes there is a data person in place within the organization and that data person is essentially asked to create a data strategy. And that data person, by the way, could be a Head of Data could be a Chief Data Officer, could be a Head of Data and Analytics. There’s very wide-ranging job titles around that. Where there isn’t one, primarily that’s where we come into play is typically a COO or a CFO is asked to create and manage and run a data strategy. So, one of our clients in the States, the CFO is spearheading the whole data strategy element and his team are working with us to make sure that we get all the access to the various departments and functions.

But you know, that’s the CFO driving it. To use the wonderful term, it depends on the structure of the organization, how well versed or influenced they are in terms of either appointing someone who’s there responsible for data, or somebody who’s driving it from the business side, in terms of that C-suite element.

Brian: Having worked on a fair number of enterprise software engagements and things that definitely involve data in them, a lot of times when I get involved with some of those things, it’s very hard to figure out what the strategy is. And I’m curious, in your opinion, is this because there isn’t one? Or because it’s not well done and defined such that others can translate it? Or there’s just bad communication and the upper and middle management don’t know how to communicate it down or assume that it’s there? Is that the delivery and the communication of it or is it the lack of having one or a clear one?

The answer I get back a lot of times are implementation methods, I hear, “Data mesh is our strategy.” “Snowflake is our strategy.” “We’re going to cloud.” “We’re going to hybrid cloud.” Those are all implementation methods to get to some outcome, but that’s [laugh]—I’m curious, your take on it.

Samir: I completely agree with you there, Brian. When thinking about the business strategy first, right? And that’s why I asked you about the business strategy because there are times where you will go into an organization where there is a loose business strategy that has got very high-in-the-sky statements: “We want to grow.” “We want to acquire more customers.” That’s great. That’s fine.

But actually tell me by when and by what percentage, you know? And is that revenue? Is that margin? Is that customer acquisition? Is that cutting churn? Is it building better products? Speed to market, et cetera.

So, give me the actuals; don’t give me a pie in the sky. Secondly, if I know the actuals and if I can say you want to double margin by December 2023, well, we know what it is now and then we can start to build out—and here’s the thing. I’m not even thinking about technology. I’m thinking about where are the levers that we can pull and push within that to increase margin.

Is that in the product development? Is that in the cost element of actually building that product? Is it a whole range of factors from the financial area around the profitability of working with specific clients? Can we start to look at the processes around that and see whether we can help challenge that and decrease it so that we get quicker throughput, et cetera? So, I think from my perspective, it’s building those use cases that are capability-led that really define what is it that the business right now is lacking.

And regardless… regardless of whether I go and use X tool, with X data, either that data is internally or combined with some external data, the outcome is what I’m looking for. The result is what I’m looking for. The business isn’t coming to me and saying, “Oh, did you use k-means clustering algorithm?” They’re not coming to me and asking that. They’re asking, “With the investment that we’ve made and with the product that you’ve built, or whatever it is that has been built as an enabler, has that made a impact and result on our business? And can you quantify that for me in terms of from a cost-benefit and an ROI position? And then can I tie that back to my revenue target, or to my margin target, or to my decrease in my cost?”

So, every time we build those use cases, we are always tying it back to whether it is a revenue driver, or it is a margin driver or whatever that lever that we can pull and push. So, I’m never just building a product for the sake of it, as you mentioned earlier. And that’s the way I think, if you communicate that effectively and you can show the actual outcome and results, then you are communicating that to the business teams, the operations teams, and they’re really seeing the benefit of what you’ve created through a business lens, rather than it being, “Oh, I’ve created this beautiful algorithm that will do X, Y, and Zed, but actually, I haven’t implemented it.” “Well, why haven’t you implemented it?” “Well, I don’t—you know, it’s going to take too long to implement.” “Then why did we do it?”

I always go back to the purpose. I always go back to the why. I don’t think business teams really care how you do it. If you can get an outcome—even if it’s quick and dirty. I mean, we’re not supposed to be doing these things for months on end. We’re supposed to be iterating quickly to start to show that result and add value and then building on top of that to show more value, more results.

So, instead of it being protracted long build up to, “Oh, it’s taken us eight months to do this. And wow, we finally got it into production.” Well, we could have done that within a month’s time, at least got some results, and iterated instead of building the whole thing. So, I think for me, it’s really showing that value. And that’s the bit which you can communicate down to the operations teams, tactical teams, et cetera, and still stay strategic with the feedback and measurement frameworks that will help you to show what you’re doing and where the benefits are.

And you are going to fail sometimes and you’re going to have to pivot, and you’re going to have to rethink, but you can do that on the fly. If you have the right business tools to do that to begin with, you’ll make better inroads into actually delivering something of quality and something that will make people stand up and look at it and say, “Wow, actually, that’s a really interesting thing you’ve done there.”

Brian: This is also something in the software—in the software industry with modern product teams, usually, there’s that trifecta of design, product management, engineering, sometimes data. I call the fourth leg of the stool is now data science, particularly with data products. But leadership, instead of pushing down use cases, per se, or features and functions to go build, they push down problem statements, which is like you said, “Onboarding needs to be twice as fast by December. We don’t care how you do it.” The team will figure out what are the use cases. What are the things that we could do between now and December to reduce that onboarding sequence time or whatever, or I don’t know, figuring out some workflow change or whatever it may be.

Samir: Yeah. Yep.

Brian: But they own the problem and that’s a distinction, right? They don’t own the solution space now. They’re not just responsible for deliver the solution that we were told to make. I feel like the data community is still a little bit in that area. I just literally talked to someone in revenue forecasting, I think it was, and she was saying and I had a—I think it was a C-suite person come in.

“We really want to use Bayesian clustering”—or whatever—“K-means clustering to do”—and then they start talking about it. It’s like, that’s not what’s going to give you what you want. So, they are already loading it up with statistics and we laughed. And I told her, you know, what they’re probably trying to do is to give you a well-formed problem statement and your language. We have to listen for that as actually a cry for help, not so much they’re sticking their nose in my domain which they know nothing about, or maybe they know a little bit about.

That’s not—flip side, the empathetic side of that is they’re trying to help me by telling me what implementation to use. My job as a professional is to unpack that back to why do you think you need to use k-means clustering to do this work. You think you’re going to get some better value. What is that that we’re going for? And we got a ladder back up to what you talked about, which is the outcome that is desired.

And then maybe k-means clustering is one way that you might do that, but you might tell them, well, the trade-off is that’s a nine-month project-and we have to stand up oomph-teens worth of infrastructure to do that. Or we could write some SQL queries and do blah, blah, blah, and be done with this in two months and experiment and see if we get anything.

Samir: I think you’re absolutely right. The problem is that every time I’ve seen a problem statement, it’s been written by the technical folks. And I think you hit the nail on the head because I speak about this a lot. And language is so important for business teams and technical teams and data teams to actually be able to speak a common language which has common business constructs. Why are organizations trying to train 20,000 people on data literacy, when they’ve got data teams that—ten, for example. If they’ve got a ten-person data team.

You’re trying to do it—why not just teach the ten people in the data teams business language? And actually, that will be quicker, it will be easier. Okay, there’ll be some things that will be relatively difficult as concepts to maybe understand and grasp, but actually, what you’re trying to do is you’re trying to get under the cover of the business; you’re trying to really pull back the covers and say, right, if I’m a business person, why is that thing wrong? What’s going on with that? What are the processes involved?

And I always, I will continuously talk about processes because there’s not enough done actually understanding processes and how data—you know, data is an event that occurs when a process is kicked off. That’s all it is. It’s a business event, something happens, either as a handoff, or there’s someone landed on your website. Someone’s just bought your product. And that’s an event. Or you’ve had an exchange with a customer through some complaints. That’s an event that takes place which generates some data.

Which has an interesting perspective in it. If you don’t understand the process and how data is enabling that process, or how data is being generated and the trigger points, then you’re just building something without really understanding where I need to fit that product in or where I need to fit that workflow in. That’s the thing which I find is really frustrating in the data industry. It’s never really understanding, uncovering that process; it’s more just saying, “Oh, data can really help doing this, so what we need to do is build an algorithm that’s going to detect something.”

And actually, it’s not the right way to do it. No business person that I’ve ever met, that I’ve ever worked with, has said to me has asked me or my team, “Can you build a predictive model that will use a classification algorithm that will help us understand X, Y, and Zed?” They’ve come to me and said, “We’ve got a problem. Our customers are churning. They’re leaving us.” “Why are they leaving you?” “I think it’s our product.” “What’s wrong with the product?” “Oh, we’ve got some customer feedback in our complaint system.”

“Do you know what that insight is from those customers?” “No.” Well, actually, that’s a really good place to start. Mine that data, bring that out, have the discussion. Here’s the problems: usability, the speed of it, there could be a whole range of things. So actually, then you can take that data and that insight and then start to build and tweak the product.

But it’s not about building an algorithm to really understand that insight right there. Or it’s very easy to do certain things. This is what frustrates me from when I go into organizations. Data people don’t ask enough questions. They don’t get to the root cause of what is going on. And actually, if they did that better, they could build quicker, scalable, and interesting products.

Brian: Play devil’s advocate here for a second. One thing I’ve heard fairly frequently are two things. One, the business customer does tell me what they want. It has that implementation buried in it. “We need to use AI to do”—and then they fill in some blank about something. There’s that. Or B, they don’t have time.

And I just actually just talked to [laugh] a company that approached me, they’ve got some critical dashboards for the sales team. And the sales team is saying, “We want to have best-in-class visualizations. And it needs to be”—wait for it—“Better. It needs to be… better.”

Samir: [laugh].

Brian: But we don’t have time.

Samir: What does that mean?

Brian: They don’t—well, there you go. And this is the problem that gets handed down from the VP down to, like, a principal—I don’t—data-something-a-rather, the data provi—I forget what his title is. And he’s in this trap because it’s like, they don’t have time to spend the time with us to figure out what ‘better’ means. They know something is wrong. As a designer, what I’m usually coaching or talking to a client about is, everybody’s going to point to what they can see, the visual stuff, so they’re going to talk about charts and graphs and colors, and that because that’s the language that they have.

When these teams can’t get access to these stakeholders, is it kind of like, game over and you wait for implosion? How do you talk about getting the data team not only to ask more questions but to get the business to spend the time to do this? You even talked about metrics. How much revenue lift? By what date?

And when I’m in my consulting engagements, this is stuff that we talk about as well. I don’t know if I can help you because I don’t know what the expectation is. I don’t know what a home run is. I don’t know where the target is, so are we doubling this? By when? Is this a slow change over the next two years?

We do not want to find this out at the end of the project, how we’re going to be scored on this project. We want to define that now so that everybody knows the game that we’re playing and what the scoring method is. And the score is, “Twice as much revenue by this date.” Okay. But the hard thing there is figuring out what should those numbers, be asking those questions, making the time to do this.

I hear teams struggling with getting the access, getting the time. The business sometimes doesn’t know what the metric should be. And I think they think the data team will be able to tell them. Think of it this way. Well, how much could we improve revenue if we use data science?

And the data side is like, “Well, what are your goal—isn’t that your [laugh] job to figure out how much you want to increase the revenue by December?” And I think they think the data teams can tell them what the metrics could be based on what the data is. And it’s what I call the tennis game, it’s like the ball just keeps getting poked back and forth.

Samir: Let’s just unpack that because I think the first thing is communication. The issue is here, everybody’s hungry to show their technical acumen on some new technology that’s coming out. So, oh yeah, let’s—you know, like you said, Snowflake is not the destination, or Databricks or whatever it is not the destination. The destination is hardcore results. Can you show me an uplift in the actual margins and can you show me the lineage of how we did that?

The thing for me is, business teams don’t know what they don’t know, right? Most of the time, they’re asking a question and that question might be something like, “Why are we losing margin in this area? What’s going on? We’re losing sales in this region.” That’s a fairly simple question.

If I was on the data team and I’d already built a dashboard that would be able to tell me that, then I haven’t built it properly in the first instance. What I’ve done is I’ve built it for the beauty and the visualization instead of the what I would class is the ugliness and impact that I need. In the first instance, when I’ve designed that dashboard, the business teams have given me their input. They have made the time to give me their input. In your example, they’re now coming and saying, “I want better.”

Because they probably didn’t ask the right questions back then when they actually were sitting with the customer, the internal customer, building out that dashboard. And I think this is where I’ve seen many a problem. And that’s why one of the main reasons—one of my first biggest clients we had back in 2014 was why I built what is now the 22nd or 23rd iteration of my data strategy canvas. Because that is all about sitting down with your stakeholder, your internal customer, and working through a series of questions, mapping those questions, asking simple questions about why do you need to do that. What’s the business question that you’re asking?

“Oh, I want to know what my sales are in Region X.” “Okay, what’s the next question you want to know?” “Well, I want to know what products are sold in that region as well.” “Okay, what else is the next question?” “Well, I want to know what customers buy in that region, which products they buy.”

What I’ve gone through is simple questions, but I reckon, in the first meeting with those sales teams, it was, “What do you want?” “Oh, we want a sales dashboard.” “Oh, we’ve got Salesforce and we’ve got Marketo as our marketing tool.” And we face off with the marketing teams, and blah, blah, blah, whatever it might be. And then what they do is they go and use some canned dashboards.

And maybe that’s okay, but what they could be doing is putting the dashboard in and saying, “Hey, listen, we’re going to come back to you in two days’ time because we’ve got the data, it’s been ingested, it’s from the system, it goes into this plug-and-play dashboard. Is this what you’re looking for?” “We can see sales here. We can see customers. Oh, you know, what we’re missing is X, Y, and Zed.”

If I could iterate like that. But I start with asking clear questions about if I built you this dashboard, what is the decision you’re going to make off the back of it? Nine times out of ten, that question isn’t asked, if I build you this widget on this dashboard, what decision or action are you going to make or take? And how is that going to be linked back to the map that strategic objective? And if you can ask that question, you can build with purpose.

Most of the time, developers are not building with purpose. They’re just building because of the tech and they’re just using whatever that front-end visualization is or whatever product it might be. Because they need to get more hours in it. But if they stood back and said, “Actually, what’s the purpose of doing this?” And if you look at most dashboards in most organizations, 80% aren’t even used.

You know, I’m working with one client now and I said, “Okay, go and show me how many times this dashboard has been used in the last six months.” Never. I mean, that’s an indication. Well, why is it live? Why is it still there? Have you not gone back to ask why these people aren’t using it? We’re just order takers and we’re just building this stuff and we’re going off a backlog. You kind of wonder, right?

Brian: I will push back a little bit on asking them what they want. Like, well, who are my biggest customers in the region? And you did get to what decisions you’re going to make? And I will say that that question right there, that is a lot to unpack because chances—many times I don’t think the business knows. They have a feeling that I should know who my biggest customers are in the region, but they actually don’t know why they want that.

You may need to show them that and then they’re going to see it. They may or may not be surprised by the results. And then the second question is going to be, they’re going to be wondering, why did I want to see this? And by the way, this is never going to change. Those were always been the ten biggest customers, so what was it I was really wanting to?

And I think part of the goal here is getting to the, as you said the decision, and this is why working in low fidelity, maybe not building any tools, but you design and you sketch and you work with customers because you can fake this out with realistic data, you could guess who the biggest ten are, present a design to them, and ask them, “What are you going to do now that I’ve shown you who the ten biggest one are? What are we trying to do?” And ultimately, what you might get to is we’re trying to see if there’s other customers like the biggest ten who we could also push up that would be easy to move in. We have one CPG company. Why aren’t all of them in the top ten? Why is just one of them in? Maybe we should be doing whatever we’re doing with that one.

Okay, now we have something that’s really juicy, which is you’re trying to move, spread out the industries across the ten, or concentrate the industries on CPGs because that’s part of the business strategy this year. Now, we know what you’re really trying to do. It’s not really about knowing who the top ten are. But this con—this whole thing I just made up right now, that’s usually not on the surface. That is a round of conversations that has to be gone through.

Samir: I think we’re speaking the same language. The reason why I built the tool in the first place was because I saw a gap in language and in understanding and in framing. When I did that, it was easy for me to facilitate the sessions. Because I can speak both languages: I can speak business language and I can speak technical language. When I drew the map, when I drew the canvas, instantly it was easier for a business person to be challenged slightly.

Because I can speak their language, I could immediately say, “Okay, well, if I want to know what my top ten clients are, am I thinking about the fact that I want to understand the revenue profile? And what’s happened over the last six months maybe? Has it changed? Has it gone up? Has it gone down?”

And then you start to speak to them about certain factors around that. So, actually, because I’m speaking their language, instantly, they start to think, “Oh, I see. So actually, I could see if we’re losing revenue from those customers or three, why is that?” So, then we go to the next level of detail. And I think it goes back to what you said, I like the fact that I can use the canvas, I can immediately start wireframing in a normal session and I can then start, as you said, bringing data in and really working with those individuals.

It may be it’s two days later, but saying, “Hey, we’ve got some data. We’ve ingested it. Here it is.” It’s quick and dirty, right, but we’re trying to build something up as a story. We’re trying to build that picture for you that will enable you to make those decisions. Because now we can see that customer X, you’ve lost 10% in revenue in the last six months. Then you can start to unpick that. What’s the next level that we need to go down to because the decisions will come out then?

That’s the bit which I think is missing from the conversation. I think it takes people like me and others who can do this very well to extract, to understand, and to challenge, and to bring those ideas into that mode. If the people in that conversation are the developers on one side, the business team, and they’re starting to see a new narrative, even the developers will start to say, “Oh”—like you said—“Now, I know exactly why I’m doing this. Now, I know why I’m building it.” So, they’re also starting to learn about the business, about what impacts sales, and maybe how marketing then intertwines into that. It’s important that that is done, but not enough time has taken on that approach.

Brian: You’re talking a lot about research, right, which is figuring out why people need what they need, what’s behind the need, what’s the attitude. There’s a reason that someone asked for these things. What’s behind that? I will advocate for, if you have UX researchers in your organization, this is what they’re trained to do, to help facilitate these kinds of conversations. There’s different disciplines. It’s not just UX people, in fact.

And I love that you have developers, you have technical people in the room because [crosstalk 00:24:59]—

Samir: Oh absolutely.

Brian: They ask different questions. A data scientist, a BI developer, a UX researcher, they’re all going to be looking at this problem from different angles and you get that in there with the business person, this is where good stuff starts to come out. Because we’re all framing the problem slightly differently, but we’re congealing together eventually onto, hopefully, a strategy that makes sense. But we’re getting those different perspectives that really matter.

Samir: Let me give you an example of that. So, that first big client that I had was in the postal area. And essentially what they lacked was an understanding of incoming parcels into their pipeline. When we sat down with the operations teams—and the commercial teams because we want those people to be in the room—I then got the data and the IT teams in the room as well. But what basically formed was the fact that when I asked you, “If you had this incoming view of how many parcels are coming into a mail center, what will you do with that?”

And they said, “Right, okay. Well, we would decide on where we need to place people on the supply chain. We would need to decide whether we take people off one process and put them on to this process based on the incoming demand.” “So, that’s workforce management.” “Yeah, that’s workforce management.” “Okay. What else would you do?” “If we had 10,000 more parcels coming in, we need to decide what vehicles we’re going to use because we’ve got some big weight parcels and therefore we’d need to allocate three to four vehicles for the delivery purposes.”

“Okay. Now, we know we need X amount of drivers, and we need X amount of cars and we need to have a route for each of them.” So, now we’re dynamically creating the route for each of those vehicles to go on the path that is the best and most efficient path. Do you see how quickly you can do that?

Brian: Let me ask you a question just to go with this particular example. Because we want to have an idea of our inbound parcel load or whatever you call it, whatever the term was—

Samir: Incoming demand.

Brian: Incoming demand. That’s not a problem, though. What was the problem that prefaced that someone thought, “We need good insight into our incoming demand,” what was the problem that was expressed?

Samir: The problem was that they get fined if they don’t deliver packages by a certain time. And therefore, if that compensation needs to be paid out, big corporates who are injecting parcels into their pipeline may have really high levels of insurance. So, if it’s late, this was the issue. Also manpower. Do we have enough people to manage this incoming load and therefore, do we have enough space in the warehouse as well?

So, there was a number of issues and challenges that they were dealing with. You’re right, I should have prefaced it with that, but I didn’t, but good of you to bring that up. So, these challenges can get to those outcomes. And I was just showing you how easy it is to have the conversation. And actually, we did that. In a day, we had that conversation. And we started to build immediately.

Brian: And was there a hypothesis? So, the problem was, “We think or we know we could be reducing our fines.” And someone had a hypothesis, “We’re getting fined because we can’t plan delivery with—our supply chain, our delivery process cannot be optimized based on demand. And we don’t know what our demand is because we can’t see it.” Which is a hypothesis.

So, this is right here, right, at this nugget, I think is where data teams sometimes struggle. They hear we can’t see the demand. And immediately it’s like, “Dashboard showing demand.”

Samir: [laugh]. Yes.

Brian: But that is not—that is what they said they don’t have, but that is not what the real need is. The decision point, as you clarified, is only known if you’ve gone through this process of discovery to figure out, it’s not really that I want to know what the demand is. I want to optimize my staffing, my trucks. And the only thing that matters is, did we reduce fines? That is the game we’re playing.

We’re not playing, ‘build a dashboard that shows demand.’ ‘We’re playing did we reduce the fines by this date?’ So yeah, I’m with you. We could do five things: we can change the trucks, we could change the people, we could do this, we only have budget and time for one. And this is where you have tech people in the room, operations people.

And you can together say, “You know what? The biggest opportunity, the easiest thing here, is to get the right truck. We already have the trucks and we can move them around, if we just know where to move them. Let’s start with that and see if we get some reduction. And they’re big packages, which are more expensive and bigger fines. Maybe that’s where we start.” So, then you roll out a tech project which is something to do with the trucks. But it all circles back to the did we reduce the fines? You know?

Samir: Yeah. And I think ultimately—and you do that iteratively, right? You’re not trying to eat off the whole pie at the beginning. You’re trying to get down to the nub of what that might be, and then you’re saying, “Okay, well, let’s iterate and build quickly. Let’s just look at this, whether this works. Can we suddenly give you a handheld tablet, you can have a nice pretty picture on it, but actually, it’s a functional picture.”

It was really quite an ugly picture but it really gave them what they needed. And immediately you can see them mobilizing the efforts. “Oh, we need to pull somebody off this area to bring them onto the line to make sure we can get throughput more efficiently. Okay, we need to get one extra vehicle.” You see the mail center is actually working really efficiently, operating the right way that they should be.

Not that they weren’t previously; it’s just that they didn’t have all the information. They didn’t have everything at their fingertips. What you’ve done is you’ve built that canvas in a way which helps them see, based on this business question, you’re already linking that to the decision or action. They’re almost seeing it as they’ve written it. And they’re saying, “Ah, okay, if this happens, I want to do that.”

So, it’s like a decision tree. It’s based in normal language, right? The really interesting thing is, that decision point then becomes some of the development practices that technical teams are able to build because that becomes the bit. “I know what they’re looking for. I want them to see X, Y, and Zed so that they can make this decision.”

And then suddenly, they’re speaking in that same language and they’re developing to that particular outcome. I had a developer say to me, “Wow, I actually understand the purpose of what I’m doing, why I’m doing this development.” And then we’ll have less wastage in products that have been built, the cost would come down on what we’re building. These are still problems that are out there. People are building stuff for no reason.

Brian: Another side benefit is that if you use this approach and you learn how to speak this language and you turn off some of the technical domain language of data science, over time, as you start to talk about, “I know you got to move trucks around, you got to move staff around,” we’re talking about mail, we’re talking about packages, we’re talking about the business domain. The business, the thing that pays my salary. When you start talking about that and when you deliver something that actually helps with that, they’re going to be more receptive when you say, “You know what? We’ve been thinking more about this whole supply chain problem. We can actually automate the truck movement using machine learning algorithms.”

They’re going to be more inclined to listen to your idea that they did not ask for that you think quote is cool if it’s rooted in the language and you’ve built the trust and showed what you can do to deliver real value to them, not a model that doesn’t get used or a dashboard that doesn’t get used. Now, you’re becoming an innovation partner instead of a cost center, which is, “Oh, we got to spend some money on the data team and build a dashboard, which is just another cost I got to pay before I can do anything.” Now, you’re like, “Those are the smart people that are doing—I don’t even know what they’re doing over there [laugh] exactly, but I know that they understand I’m trying to move my trucks around. My job is to get the right trucks in the right place at the right time for the right packages and John and Jane and whoever over there, I don’t know how they do it, but I’m listening now when they come knocking. I have time for them because they speak my language.”

Samir: You’re absolutely right. And guess what? That’s what they asked for. That’s what we did. And it makes sense because you show them a bit of value, you show them what they’ve been dying to have, you give them a little bit extra in that so they can really optimize their decisions, and suddenly, you’ve got both sides now speaking a language that is really based on business outcomes and results.

It’s a conversation that even I’ve seen data teams be embedded in that process and then go to the business teams to say, “I think we found some more insights based on what we discussed earlier. And this is what it’s telling us.” And they’re actually starting to speak in the way that the business would speak. So, it doesn’t take long. I think it’s just a matter of using the right tools and the methods to actually get those to really be joined at the hip in some way [laugh].

Brian: It can be done.

Samir: Yeah.

Brian: And I know that you can help with this. I know you got to run, too, so I just wanted to kind of give you the last word. But where can people find out about you? And can you tell people a little bit about what you do with datazuum and how you help do this work? Who’s it for? Who do you serve with your work and just a little bit about you?

Samir: So, you can find me on LinkedIn. I’m very active on LinkedIn as you know, Brian. Just search for me connect with me. datazuum is a data strategy and analytics business. We primarily work with the business teams. We work with the C-suite where they don’t necessarily have a Chief Data Officer or a data team and we help them to understand how data is going to help them, where it’s going to impact the business strategy, and then start to build out their insights and start to build out their organization and help them to understand what they need initially, and what they’re looking for and why they need it.

That could be working with the CFO. It could be working with the COO, but essentially it’s working with those teams to really support the delivery of better data products and build it and scale out the data that will help them deliver what their business outcomes and results are. That’s where we operate in. And we work through that value chain, from strategy to implementation to what you talked about was innovation. That’s the three pillars of what we do.

Brian: Great. I’ll just say, too, it’s datazuum, and it’s Z-U-U-M, correct? Not—

Samir: It is.

Brian: —O-O. So—

Samir: No.

Brian: Just to get that right.

Samir: [exclaims] DataZoom.

Brian: That’s right [laugh].

Samir: Zed U-U-M.

Brian: ZO-Ooom [laugh].

Samir: ZO-Ooom.

Brian: Well, Samir Sharma, CEO of datazuum, thank you so much for coming on Experiencing Data to chat with me today. It’s been great to catch up.

Samir: Thank you, Brian. I’ve had a blast. Thanks a lot. It’s been brilliant.

Brian: Cheers.