#285 Building an Analytics Production Line with Lee Feinberg, CEO at DecisionViz

Hi, I'm Maggie, VP of Curriculum at datacamp, and I know firsthand how overwhelming it can be to keep up with the rapid changes in data and AI. But staying ahead doesn't have to be hard. That's why our curriculum team has curated the best learning content to help you and your team stay ahead, covering everything from data and AI literacy for busy executives to cutting edge generative AI for developers, and everything in between. Whether you're upskilling yourself or your team, we make learning practical, engaging and flexible. It just works. Power your data and AI transformation journey on datacamp.com the data isn't really important, it's what are people going to do with it? What outcomes are they looking for? The whole premise of it is really about communication. That's really what all of this is about, really getting at the heart of why someone is coming and asking you to do this to begin with. I always have to understand the purpose. I have to understand the audience. Foreign.

Welcome to Data Framed. This is Ritchie. Basically, every business makes use of dashboards so the employees can understand how well things are going. But despite vast amounts of investment, somehow there were still so many terrible dashboards. Or maybe it's a great dashboard, but it doesn't quite solve the problem you wanted it to. Or it might be solving the right problem, but the units on the plot aren't what you expected and now you have no idea what's going on. What you really need is a system for creating dashboards and for analytics in general, that means you can consistently do things that are useful for the intended audience. So today we're going to find out how to create such a system. Our guest is Lee Feinberg. He's the president at analytics consultancy Decision Biz. He helps organisations improve their people process and culture around visualization and storytelling. He's a course creator for the University of Chicago, an instructor for TDWI, and an adjunct faculty instructor for the NYU School of Professional Studies. He's also a tableau certified associate consultant, four times tableau ambassador and a long term tableau partner. Previously he was a research advisor for the International Institute of Analytics and the founder of the 501c data community and a senior manager at Nokia. All right, let's find out how to get this analytics production line going. Hi Lee. Welcome to the show.

It's good to see you. Glad to be here.

Great to see you again. So, of all the dashboarding experts I know, you're perhaps the most negative about dashboards of all of them. So tell me, what's wrong with dashboards.

So just jump right into it, huh?

Absolutely. We're diving straight in there.

It's not that something is wrong with dashboards. I wouldn't really frame it that way. I think it's how people think about them and how they've thought about them for probably 30 years. Really, what I'm trying to do with my clients is change that perspective. So when you think about a dashboard, it immediately you go into this idea of, oh, I've got to get my data and make some charts and put it all together. And that's what my dashboard becomes. And especially these days when businesses are moving even faster and trying to make heads or tails of even more data than they've had before, the data, in some ways actually gets in the way. The data isn't really important. It's what are people going to do with it, what outcomes are they looking for, Even what decisions and actions are they trying to take? That's really what's important. And so when I talk about dashboards and why I don't like them, it's because people think about them in the nature of just having to display data, and that's not really what they should be used for.

Okay, that's interesting that, I suppose.

Yeah.

If you're a data analyst or you're a business intelligence analyst, like someone says, create a dashboard, you think about, well, what plots can I create, what stuff can I show from the data set? And it's not really thinking so much about what should this be used for and what's, like, the end goal of this. So this sounds like the problem is maybe more with, like, the whole flow of how you go about creating these things. So maybe just want to give me an overview of, like, what is the current flow for, like, how you create visualizations, how you create dashboards, and how would you want to change that?

I'll give you a framework. And when I said before about rethinking what a dashboard is and the role of the dashboard, if you think about it more like a product that rather than, say, the activity of. I call it the activity of making charts. Right. That's visualization. That's not really what it is. That's what it's become to mean a lot because of the software. And people just kind of hook into the software very quickly on these projects. But if you think about it like a product. Whereas if someone comes to me and asks to achieve something, they ask, even if they just ask for data, there's a reason for that. And if I can build them a product that Solves that problem, that helps them address that. That's really what they want. But maybe because they're coming from the business side or some other perspective, they're used to asking for the data, or maybe that's all they know how to ask for. And so if you start to put this in the framework of a product, it becomes very different because you have to have some foundation principles for how you build that product. You have to have a method for actually finding out what product to build and how to do that. And then you really need a way to engage your user base with that product. You have to help them understand maybe how to use it, how to measure their performance, and how to actually measure that your product is doing what it needs to do. So it requires a whole new way of going about doing this work. That's kind of the framework is this product mindset to start with.

That's fascinating. So, I mean, product managers, like, there's so much sort of expertise they have is very different from perhaps a data analyst expertise. So if you're trying to make this transition to having these, like, visualization products, then where do you begin?

There's a lot of places you can begin. And even though it's a process, when we work with clients, because it's a pretty dramatic change, and a lot of the work in transitioning to this model is really some cultural change and of course, some process change. Very little technology issue involved here, you can work with whatever tools really you have today to do that. And so I like to get clients comfortable with the part of the process that they feel they can implement at that time, rather than say, you have to start here and do it in this particular way. Because every organization is also quite different. They may do some of the pieces already in a certain way. Maybe they don't want to rattle that and change what they're doing already, even if it's not perfect, or it could work better if they've already doing something in that mode. Let's leave it alone. So it really depends where they're at. They may learn all the elements of it, but then they have to pick and choose what they think will work best for them. So, for example, let's just say that they have what I call business policies in place. This is pretty easy to conquer. But because there is no process, typically every analyst, when I say every, that's an extreme. But the analysts on the team may do things in a very different manner. And that's the point of having a process, is to bring more consistency to your team. Or to your organization. And let's just say that, for example, one analyst calls sales and another one says revenue and another one says income. They all show up at a meeting and they present their work and they start talking about it. While all three of those really mean the same thing, it starts to raise questions of, well, how is revenue different from sales? Oh, well, they're the same. Why do you call them different things? That's confusing. So if you put a policy in place that says, look, we, when we talk about parts of our business, you want to make sure that we're consistent in how we do it. So that one, we don't cause confusion in meetings, but two, we're literally all on the same page and we are raising maybe say, the data literacy of our organization because we're all talking about the business in the same way. That's very important to put these kind of policies in place. So if an organization suffers from this problem, that's something pretty easy they can tackle. Because if maybe there is some controversy in there that one person wants to call out one thing versus the other, but it's the kind of thing that you can resolve pretty easily and get some benefit from versus saying we're going to change our whole process about how we go about doing our work or fighting over using what colors, because we might say, hey, it's not so great to always use red and green together. But because it's so embedded in how we do our work, we're not going to start to try to change that right away because it'll really drive people nuts.

That's kind of fascinating, the idea that just a simple standardization of language on how you communicate things, that's going to just make things much easier to understand because you don't need to learn three different words for the same concept. You only need to hold, like, one of them in your brain at once. So I do love the idea of, like, policies for standardizing language. Would you have policies for standardizing the visual side of things as well or any other aspects?

Yeah, there's kind of a visual communication policy as well. And you could think of these policies as governance. I don't like to use that term because governance tends to mean more around the data these days. So I don't want to be confused with that. So I just kind of call it a policy. It's also a little. Sounds a little softer, but it's the same thing with visuals when everybody does the work however they want. You can imagine the same scenario that I just described where people are showing Those three things in three different ways. And what you want to do, if possible, is again, when people see a certain type of visual, have an association with it. So if they see something depicted in a specific way, they can say, oh, I know that, that is our sales against our competitors over the last year, something like that, where it might sound simple, but again, if you show it three different ways, that means your customer, your audience has to learn three different ways, understand the same thing. Now with that, if you think about communication and you think about vocabulary, where I can use three different words with the same meaning, right. That's common in language. Whereas I just said maybe from a specific standpoint, you don't want to say sales, income and revenue. And let's just say you go with sales. You might want to have different ways that you can show sales, but again, standardize those for a couple reasons. One, depending on the context, maybe you want to be able to show it differently. Or let's just say you are facing a practical circumstance with a quote unquote, dashboard. I'll say dashboard, meaning the physical thing you have to develop an author. Maybe you don't have enough space. You say, okay, when we have limited space, we can show sales this way. Or let's just say on our screen we might have several bar charts and we don't want to have another bar chart because it's just too many. We could show sales this way as an alternative. So it's almost like having that, you know, synonyms, vocabulary thesaurus that you can select from. But again, you kind of know what those things mean so that again, your audience doesn't have to learn everything over each time. And it's quicker to recognize. If it's quicker to recognize and interpret, then they can move through the information faster.

Okay, I do like the idea of having a glossary of just like these are the terms we use, this is what we mean by them. Maybe some kind of thesaurus ideas. You can say these things are synonyms within the business and this is like a standard location that people are going to look at what you are talking about.

Okay, yeah, the whole premise of it is really about communication. That's really what all of this is about, right? It's not about data, it's not about visuals or the specifics. The goal is to communicate an idea as easily as possible.

This is fascinating stuff. And actually some of the ideas you were talking about, it reminded me that like product design engineering teams tend to have things like a design system. So like at Datacamp, we have a design system called Waffles, which is publicly available, I think. Waffles.datacamp.com so there are like, standard icons we use around the site, standard components. And it seems like the data world just needs to catch up with this idea of having some sort of design system for how you create stuff. Does that sound about right?

If you think about how the work is delivered today, how people consume it, it is typically through a browser, through a website, or on your phone. And when I don't have scientific evidence to support what I'm going to say next, but if I'm consuming a dashboard on my browser, I'm in browser mode. My brain is in browser mode. And so the images I see, I expect them to be kind of in that browser mode, which is, you know, even though it's charts and things, I say, okay, it should follow some of the same principles as what I typically expect when I'm in my browser, which is exactly what you're talking about. There's some design system that people adhere to. And so it is really kind of that overlap of what are people's expectations and combined, then you have the language of visualization. Right. Then you have to also adhere to all the raw visualization policies as well. You know, in terms of what, how people consume them, what are good practices. And so it's kind of a blending of those two elements.

Okay, so this all sounds like a very good idea to me. I'm wondering, suppose you have to pitch this to your boss. We need to standardize our analytics workflows. Do you have a sense of, like, how we go about pitching this? Like, what are the business benefits for standardizing your workflow?

Yeah, because I mentioned there's kind of those three pieces of it. Let's tackle a couple of them. So the first one is just setting the foundations. So it's really looking at your, I would say, your body of work. Right. And like any, any problem you're trying to solve, you have to believe there is a problem. I'd say right before, before anybody could be convinced, there has to be something that says there's a need for doing this. So rather than just walking, okay, like you said, oh, it sounds like a good idea. So what? So typically, when an organization will look at their inventory of work and realize a couple of things. One, there's too much diversity. Right? We have some of the things we already talked about are visuals coming from the same team look wildly different, whether it's just the type of charts we use or just maybe one person goes really overboard with their design because they think it looks cool. So there's no kind of model, there's no identity and it's good to have consistency. If you think about even just other groups in a company, other functions, whether it's finance or marketing or design, they all have some kind of standard way they do their work. It really hasn't come into this area as much yet. Still it's more tool driven and a lot of time is by individual preference or skill or just what people want to do. So if you look at your work and a lot of so one is that hey, we need to consolidate. But the bigger issue that you tend to see in terms of an underlying problem and reason to start is just they either one, people realize that they're putting a lot of effort into producing this work and the engagement is low or the usage is low, or people just come in and they use it to download the data and they put into Excel. And so there's a lot of effort that's just not being utilized. And then you say, well, the question is why? And you go back to what you know, are you producing something that's useful? And that's where I think it all boils down to. If people are coming to your team and you're trying to give them an output they can use and they're not using it, or it's not helping them get to that final stage of helping them drive decision making or identifying even basic insights, that's a signal that your team is not really helping the organization. And I think that's maybe hard to come to grips with, but that's where the real leadership comes in. It's okay. I know what we're doing isn't working as well as it could. We need to make a change.

Absolutely. So I think this is one of those sort of data team curses. As president in most organizations, data, you create all these dashboards and then nobody looks at them. So I guess I'd love to hear what you think about, like how you might go about avoiding this. How do you make sure that the stuff that you create is going to be used? Like, is there a way to know in advance before you've done all the work to create these amazing dashboards and then discover no one can as I.

Don'T want to guarantee anything, but I'll give you the philosophy and the approach that we use with clients and that we teach clients how to do this. It goes back to this idea that I mentioned before about really getting at the heart of why someone is coming and asking you to do this to begin with. And sometimes the client isn't even able to articulate that very well. And you might say, well, if I'm the analyst or the practitioner, that's not my job. That's my customer's job to know that. I would say, no, it's your job. Together, really, it's a collaborative effort. Because exactly what happens is what you just described is I end up delivering to you something that's not useful. And my job is to. To get that to you in some fashion. Can't just rely on maybe the customer coming to me and being able to very clearly state what they're trying to do. So it really has to be a team effort in that respect. So it's really unraveling that and finding out what it is they're trying to do. And the expectation. A lot of times, one of the things we talk about a lot with clients is they feel like, well, I'm supposed to know if you come to me, Richie, and say, I want X, Y and Z, that somehow I'm supposed to magically translate that into some kind of real outcome. And what it is that's going on inside your head that you're worried about, that you're trying to solve for, that's completely unfair. Even if I know a lot about the business and I'm working at the company for a while, it's unfair to have that expectation. But that's how a lot of analysts feel. And so there's this hesitation even on their part to ask why? And dig into that. And I think that's a big pitfall. And we talk about the idea that if your company now, let's say, delivers some kind of product or service, you certainly go and ask your customers what it is they're really trying to do and what they want. It's the same principle. You need to go, you know, even though it's internal now, or sometimes it's external, sometimes you might be actually developing a product goes outside your company. And that's kind of this new data product idea, again, that you have to really understand. It's not about the data. It's what is it trying to help somebody do. So that's one area where you start to change how people work, is understanding what it is they're trying to do. And you even think of it as like a product on Amazon. So we'll say, imagine you were just going on to Amazon and you wanted to buy this. We'll just again, call it a dashboard. What search terms would you put in? Or what would you expect the product description to be. And so it gets people outside of their thinking about the data or the charts or that and really again more grounded in what is it that they want.

That's a very cool thought experiment. I like that idea. You go on Amazon, I'm shopping for a dashboard for the cheap ones, hopefully like filtering for ones four star rated or higher or something like that. But I like the idea of like you're creating a product description, then that's going to help decide like what's going to go into this sort of thing. So I'm counting course it sounds like then the key to creating content, great data visualization product is going to be about this communication between whoever wants this, who the client is and whoever's creating it, the data analyst or developer. So what does that communication flow look like? Is it just like you have one meeting to begin with and then you're done, you've created the specs of this and that's it, or would you need some sort of regular backwards and forwards meeting? Like how do you make sure that communication works here?

Yeah, I think that's really just the start of it and you really need to go back and it depends the complexity of what follows on that. But typically there's again, just like you would any other kind of product or service or even if you're developing software, which in a lot of ways that's what this is. It's like developing software. Sometimes it really is an application that you're developing. And especially now when things are interactive and there's buttons and switches and sliders and all kinds of other ways that customer can interact with your work rather than just developing static charts, which is what it used to be. Right. And something like a PowerPoint or Excel, right. You just bunch of charts and that's it. And it's very different now. And so it's really about the validation of the ideas and how can you do that quickly and more most effectively. And so a lot of times it's yes, we can have those like you said, requirements, specifications, product descriptions, but it's really like user stories. Right. So if you want to equate it to kind of the Agile world and a lot of the principles that are baked into this framework are taken from Agile and other areas. We just don't say that because people say I don't understand Agile. But you don't have to. Right. Just follow these approaches. And so when you, when you get to the visual side of things, it's really important. Not only that, yes, it's Correct. And the correct data is in there. But. But again, you, as the customer, as my audience, actually can understand the visual because that's. That's the communication method. A lot of times, maybe there's some words that go along with it, but that visual is what you see first, and it has to mean something to you as quickly as possible, rather than giving you something that you have to stare at and study. Sometimes you do if it's a complex set of information or. Right. It's not that you can always, at the snap of a finger, completely absorb everything, but you want that to be as smooth as possible. And so a lot of times what happens is that the analyst, because I work with the data so much, I look at something and I might create a chart, and I get it because I've spent hours with it, maybe. Right. But if I show it to you, you might just shrug your shoulders. Right. And what you don't want to happen is to go through all of that, I call it authoring process. You don't want to write the whole story out or do all your dashboards and show it to you, and then you go, I have no idea what this means. So we have to shortcut that by showing you some kind of prototype, whether it's done by hand or done potentially in software. But you want to do that in a way. So I can come to you and say, here's what we talked about. Here's what I heard you say. Here's how I like to represent that. Does it make sense to you and get that feedback early on, or for. I spend all the time trying to get the data out of the system, or maybe I have to create the data. I. I don't. Sometimes it's not even available. I don't want to spend a lot of time doing that and do it wrong. And so I have to get that feedback from you quickly and then I can proceed. That's kind of that next stage. So you asked, you know, do you just get the requirements and go. The answer is definitely not. Because that's also one of the biggest areas that we hear from people is that I get my requirements from customers. They tell me what they want, I do exactly what they say, and then they tell me they don't like it or that's not what they wanted or they can't use it. And I said, but that's what you told me. They say, yeah, but this is terrible cycle, and we're really trying to break that from happening.

Yeah, certainly, if your client asks for something stupid and Then you go and build it. It's not gonna be good for either of you. Like, once you just create something silly, there's gonna be a big blame game going on. But it sounds like. So a lot of the things you talked about there, these are all kind of well established ideas in the product field. So it's more like agile methodology, user stories, and then the idea of prototyping things that I guess. Yeah, pen and paper, or whether it's like Figma or something like that. So tons of product stuff there, I guess. Are there any other product ideas that you think would be good for data analysts?

So the third element I talked about. So we kind of have this foundations, we have the, the way you actually build the product. Obviously we haven't talked about this in a lot of these, either of the, any of these in a lot of detail, but you get the idea. The third piece is what most people haven't even thought about. So imagine you've built your product and typically what happens today is it you hit a button, right, Say, click, and it goes to the web, right. You publish it, and then you may send a link around to everybody. Here it is. Have at it. And even if you've followed, say, the best requirements, you've gone through this with them, you've gotten their validation. Yes, this is what I want. You've created this product based on that. There's still a long way to go. So if you think about it again, like a product launch, most things it's a project and it's done right. I built it, I published it, and I'm done, I go on to the next one. You really have to say, no, I'm launching this product. Well, what happens when you launch a product? You have to do a lot of other things like educate the market, maybe do some marketing training. Now, not saying that this requires a huge effort, but for example, just because I created this set of dashboards, doesn't really mean you know how to use it yet for understanding the goals that you've set out. I may have done it in a way that you understand visually, but it doesn't mean you necessarily know how to put all the pieces together either. Because again, you may not be an analyst, you are a marketer, doesn't mean you're an analyst. Right. So I may have to teach you that. Hey, when you see certain things happening, this is what they mean together. So if something happens on this chart and this chart together, it means you should pay attention, or it means you don't have to care at all. Whatever that is. So there has to be some education. Typically what people do is they think the education is like where to. How to click. Oh, if you click this, it will change this chart. Yes. You know how to do that Operationally, that's important. But more important is the meaning. So that's one part. Second part is understanding. Are people actually using your product? Right. Again, that's critical. If I put it out there, I want to understand when you're using it, how you're using it, who's using it, and that may give me some signals because if I go in and I see that you're not using it, I would probably want to go back and ask you why not. Or if you're using it in a way that's either unexpected, maybe there's a certain pattern to how you're using, because maybe we haven't even talked about that aspect of it. Maybe there's a drop off in how you use it. Yes, you used it for a while, but now you're not. Why? To find out why did your priorities change? Did something happen in the business that means it's not as useful to you anymore? And that's equally as important as maybe you need to sunset the product. Maybe it did have its use and the business never told me. But we're still maintaining it, we're still managing it, we're still updating the data, we're doing all this work, you don't care. Maybe it's not your job, but it's a lot of load on me and maybe my team. So these are important things to know. That's part two. The third part which is the most important in the end is did it help you? Just because you're using it doesn't mean it actually helped you. Yet. I need to understand, did you make a decision from it? Did you take an action from this? And how did it turn out? So you. Just because you made a decision doesn't mean that it's going to turn out good. Maybe it misled you or maybe it was missing something or did it go like gangbusters. These are all great things for me to know to either fix it or improve it, or say, great, it's fantastic that it's going really well and I can use that and go back to my team and say, look my management and say, look what we created for Richie, how well it helped the business because we want to boost ourselves as well, right? We want to say that we did a great job. Not just that we made a dashboard on time. That's not helpful. I mean, it's good that we did that, but that's like entry stakes is to do your work on time.

Yeah, that's fascinating that. I mean, so we talked before about how you need all these sort of ideas from the product, but now it's like, well, you need all these ideas from marketing as well. You've got to promote your work. And then I guess there's all this sort of enablement piece as well where you've got to make sure that all your users know how to use it and when to use it and what can go wrong. So actually maybe, maybe we'll dig into that a bit more because it seems like there's sort of different levels to what you need to know in order to be able to use a dashboard. Well, so suppose you've got like, I don't know, just like a line plot where the line is going up. Then there's sort of a basic level you want to, you want people to understand, okay, this is an upwards trend. But then there's also a sort of more detailed business context about, well, is this line going up fast enough or too slow or things like that as well. Again, that sounds like you're going to have to have some interaction between the data people and whoever is wanting to use this, whoever knows about the business side of things. So does that sort of cross team relationship to persist even after the, after the dashboard is launched? Then talk me through who get who's involved in this marketing effort.

Yeah, I think depending on how your organization is set up, it could be different people. One of the challenges here that I mentioned right in the beginning is that this is a lot of cultural and personal change. So you might find that people are like, this is very exciting. I want to take a stab at it. I'd like to try to do a little bit more marketing because it gets me out of just creating dashboards. It's something new. Right. So it's a growth area for me. But on the same side, you might have people say, I'm not doing that at all. Right. Either I'm not comfortable, I don't care, whatever reason they have as well. So it's a kind of a team or organizational, depending on how many people you're dealing with, have to recognize that these activities need to be done, not just assume that I'm going to take all of these as if I've been the person who's the practitioner, who has been the analyst delivering the work, that I'm also just going to do all these other things. It's not fair to the person. First of all, try to, I'll say, push that on them. That. Okay, now your responsibility, that you're going to even know what to do. Again, a lot of this is we're laying out the concepts, but it doesn't mean people are just going to know how to do them, especially if it's completely outside what they've ever done before. You can't just say, well, yeah, just measure this or just market this to them. How do you do these things? So either they have to be modeled by other people, they have to be taught, managed to help people along, or maybe you go to the comms group, say, look, okay, we're going to build this, but you're our internal communications group. You handle marketing and events and other things like this. Can you help us put this together or to. Maybe it's a learning and development group. Okay, we need to develop some short training videos for people. So there's this collaboration that has. Can potentially go on where you're not taking all of it on. Because those people also, I can't just say, well, okay, learning and development just do this because they don't know what it is. So there has to be a collaboration where we're working on it together. But maybe they're accountable for delivering the bulk of that now because that's their expertise is creating the videos and the language and creating the marketing around that. So depending on what the organization structure is and who's available. Right, but these are not things you should leave till the end either. Right? It's not like, okay, we're done. Who's going to create the plan for that? No, the plan is in the beginning. You have to have that lined up to go as part of the workload that gets done so that it all stays in sync. Otherwise you, you may launch your product and have no support for it whatsoever.

One thing I'm curious about is whether there's a limit to all this sort of process. So I guess the goal of this is to build up some kind of production line for your analytics, make sure everything's standardized. Is there a trade off between doing all the standardization and like having some sort of creative aspect? I know, like sometimes you think, well, I want to be creative with my visualizations or dashboards. Is there a limit here?

I think like anything, you have to apply it in the way that makes the most sense. It's not crossing all the T's and dotting all the I's in, in that very specific way. So one I would Say part of it is to manage, I'll say, the creative aspect that we talked about before. And creative, I mean, like, where there's such a divergence that it becomes difficult or more complicated for the business to actually understand everything. Which, again, that's really the goal. The goal isn't to be the fanciest or the most creative. Right. In some cases it is. Right. If you're doing something that's more of, like, infographic, certainly that's a case where maybe there's more opportunity to introduce some creativity. But let's go back to the idea of. Before I said about having this vocabulary and it should be limited. Well, there may be cases, certainly, where it makes sense to show something in a different way that might not be part of that vocabulary. Right. And you don't want to say, well, that's not in that you can't do it. You want to be. Have the flexibility to be able to do that. So it's more of, hey, this is how we'd like to do it most of the time. But we don't want that to get in the way of being better or having other newer ways of showing something either. Right. Because people might get stuck in, like, well, this is how we do it. We can't do it another way. No, you always want to be improving. That's kind of how it's been for a long time. That's not really helpful in any organization when they're too stuck on it. In terms of creativity, if you think about, say, in storytelling, because a lot of this, you know, we haven't talked about storytelling that much, but in the world of storytelling, people still use frameworks, but yet they tell completely different stories using the framework, and they're able to adapt the way they need to. So it's the same kind of thing here. This is a structure, a framework. It's not meant to be so solid that people can't diverge from it when they need to. It's more of ideas to follow so that you can start to have that consistency. And that consistency also helps speed things up. Do the work in less time. Do it with less rework. We talked about that issue. Do it with a lot less effort and have that end result be a lot better. So I think most frameworks always allow for people to do things differently.

Okay. Yes. You just gotta decide which things you. You want to keep standard and which things you're gonna allow some flexibility in. I suppose it's the same with, like, building anything. Like if you're writing a song or Whatever. Then you're probably going to decide on like which language you're going to sing it in, what sort of genre. But you know, you can still write a lot of songs with that are unique. Okay. I don't know whether that analogy worked or not.

It makes, it makes sense. Right. There's songwriting frameworks. I don't know any. But there's a method to doing that as well. Yet people write so many different songs.

Yeah. So preserve like the unique identity, the creativity, but still standardize things enough so it's understandable by the audience.

All right.

Now I'm wondering whether you need to think about different types of dashboard differently. So I think sometimes. Well, like you can have very important dashboards that look at regularly. So things like your business core financials, like what your current cash flow is and revenue and all that kind of stuff that management are going to look at most days. And then sometimes you got dashboards for like one off analyses. Or maybe it's something that props up like once a quarter. It's not going to be locked up very quickly. Do you need to change your approach to building different types of dashboard?

I think the approach should always be this, be the same in the context of understanding the purpose. So I think no matter what it is, all the different things you just rattled off, I always have to understand the purpose, I have to understand the audience. I don't know those things. It's very difficult for me to get it right. Probably going to get it wrong. So that should always be the same. Now if it's an ad hoc, I may not need to be as buttoned up in say the final product and what that looks like. Let's say it's something that if I'm just doing ad hoc, maybe I don't need to do the last phase at all. Maybe I don't need to do the marketing because it's just to one per. Maybe it's just to a small group or one person. I can just sit down with you and walk you through it. Or maybe I don't even need to make it look that great. Like, look, just get me something. I don't need you to polish it up and make it all beautiful. And so again, it's understanding again what they are going to use it for, how they're going to use it. You don't want to let the process get in the way of being effective, that's for sure. So I think it depends on those aspects. If it's something like you said, a quarterly report or review, you've probably got some kind of established cadence. So you probably just go through this in initial time. And if it's a standing meeting, maybe you have to make sure things don't aren't changing in the business. That's important to make sure. Just because you say, okay, I'm going to show up every quarter, it's probably a good idea to make sure that things aren't changing. And it also has to go back in align with the strategy. So maybe you as an analyst have to know these things and not always rely on the business to tell you because maybe they think you just know. So again, it's that effective collaboration between the two. And I think that's an area that this really helps because the more that you do this, the work this way, the more natural it becomes as well. In the beginning, it might be a little weird, especially if there's a dynamic where if I'm the business person or let's again, let's put you as a business person, you've been used to working with me in a certain way. And then I tell you, no, let's do it a different way, or we'd like to try something different. Is a period of. Is a break in period, right. Where we have to probably feel our way through how it's going to work out. And so it starts to remove a lot of assumptions as well. And you'll learn that you have to come to me with those changes, that I'm not going to assume that some of these things are happening.

That's interesting that if you're going to change how you work together, there's going to be that kind of teething time where things kind of go wrong. Do you have any advice on that change management aspect of doing things better?

Yeah, I think one of the big things that people are afraid of is that change. And it's important to discuss that change beforehand rather than, let's say we're having a meeting, you're coming in and you're ready to tell me all the new stuff. As I. Hold on a second. I'm going to do things differently now. Not the time probably to introduce my change right at that moment. Because you're like, well, I got to get stuff done, I don't have time for all this. Again, it's a different type of communication. But if you're going to look at making some change, it's good to tell your customers that you're working on this kind of change and you're thinking about it and here's what it means and here's the expectations. And I'm not saying this is a major effort, but again, it's about building trust and that communication. So I might, there might be some notice that goes out. Say we're just like, you get it from a website that you might do business with. You get them from companies all the time. Hey, we're changing this, we're changing. These days it's all about, hey, we're changing our policy about how we use your data. Right. We're going to use all your data and even more, more nefarious ways than we did before to train our AI and not just to learn everything we can about you and send you more ads. So it's that prelude to that collaboration that we're going to change it so that when the time comes now I still going to say, okay, remember, we're going to try to do this a little bit differently. That's again, why you don't try to do everything all at once. You asked that early on, like where do you, you begin at that part where it seems like it will be easiest for both parties. Right. For everybody involved to digest making that shift so that it's not so jarring. And then again, when you have small wins and people get comfortable, then you introduce another layer of that and it takes time. Right. It's not. You can't just jam it all in and say, hey, we're going to go from what we used to do before, this entirely new way of working. It's not really productive for anybody.

I say, I do like that idea of just making the easiest changes you can first rather than trying to do something hard and failing and then giving up. Yeah, I'm all in favor of doing easy things. That's good stuff. And no, it was interesting, your idea that all these companies selling you or telling you about updated terms of services, they're changing their policies for how they're working with data. I guess you're doing the same thing we talked about like changing policies or defining policies around how are you creating visualizations? That's cool. Okay, so we need a little bit of motivation to wrap up. So I know you work with a lot of organizations around this. Have you seen any success stories where companies have sort of implemented this and then they've seen some benefit?

I'm definitely not going to say no. Yeah, it's a variety again because everybody is. Every client has different problems. So I'll start with just one example and see if we can want to go any further. So one client, the problem that they were facing is they were worried about at risk clients. Now in a typical model, say, okay, what would I do? I'd start taking all their data. I would maybe show them client sales, maybe how long they've been a client. Maybe I would try to split it out by industry or geography or let them do that. That would be building the typical kind of data driven dashboard. I just got to get all the data out about clients. And then you would say, okay, now I have to go in through all that data and sift through it and figure out, well, who's at risk. That's kind of what we're trying to not do. So instead, first thing find out is, well, what does that risk really mean? And initially they said, that's a great question. They had this notion of, yes, every business has this notion of, hey, we're probably going to have some attrition or risk of customers leaving. But it didn't really define it. And then there were levels. There's really, there's like at risk and then there's kind of, yeah, on the bubble that, you know, we got to pay. But the really defining what those areas meant. And so as we went through this process and started to unravel what was behind this and how the business handled it today, well, what does your sales teams do? How do they go in? How do they figure this out? What constitutes at risk? Is it by level of sales or is it frequency or. Right. There's a lot of variables that go into that is we learned, and they kind of learned that it is complex and it's not just a number. Oh, well, if it's X, then that means they're at risk. So we literally built them an interactive model so that they could look at different scenarios and then say, okay, now we see if we do this, who's more at risk. So it gave them that ability to kind of learn a little bit more about the business as well. But it didn't, it didn't hit them with lots of data. It helped them play with what was in their head and express it. Because we don't want them trying to do the calculations in Excel or anything like that. Right. We want to give them the freedom to say, okay, well, and it might be different scenarios depending on what industry it was or what geography it was. Right. Because maybe in certain geographies their customers are actually work differently in the Northeast than in the Southwest. So to bundle them together and just make them this generic way of thinking about them in the business actually wouldn't help either. So that's where that Understanding really came in. And then helping build that model and understand what they wanted to do and what they were capable of doing, then teaching them going through all those phases to actually then be able to isolate, you know, more specifically, okay, now we have to go after this customer. And then the next part of it was building a playbook for the sales team. So it was management. And then the sales team had to execute. We had to give the sales team something different to work with because the management is saying, go after these customers. Now the sales team needs another tool to help them figure out how to deal with that customer and be more data ready with them. So giving them that tool. So it was really. So that one question turned into really multiple attack points.

That's absolutely fascinating, actually talking about Churn. So it's very close to our hearts at Datacamp. You know, we're primarily a subscription business, so we. We live in fear of Churn all times. But, yeah, that's interesting that you start with the business question. It turns out the business people didn't really know exactly what they wanted because they weren't sure what the at risk definition should be. And so you have that iteration you talked about before. And then, like, creating the dashboard wasn't the end point. It was like, okay, well, now we need to enable people afterwards to understand, like, what the different scenarios are going to involve. That's cool that it's sort of. It's not just, oh, this is a simple, let's create a dashboard, we're done. It's that full workflow there. All right, so before we wrap up, what are you most excited about in the world of dashboarding? I'm excited to go back to the.

Start of our dashboards. I'm interested to see how things are going to start to play out with some of the kind of intersection of AI. I don't quite know how it's going to be, if it's going to. Some people say it will eliminate the need for dashboards because people, the end user, the customer, will just go in and ask lots of questions, or maybe that they'll just be given constantly reconfigured dashboards. And I think some of that is possible, not necessarily today. I think it will all stem back to knowing what someone is trying to do, because you can have data come out and say that something has happened, but it may be irrelevant. So you always have to have that context of, how am I going to use it? I don't want to just react to some data point that some system has seen change that doesn't mean anything to me in terms of how the end user interfaces with the system. I think there's a danger in thinking that people will just ask lots of questions. Okay, tell me this, tell me this, tell me this. Because that's almost going back to the thing about the data before. If you just say give me answers to lots of questions without knowing how they all intersect and what the answer to one means, the answer to another, having them kind of linear, just a list, I don't know that that's going to be as effective either in terms of understanding things more holistically. So there's somewhere in between, I think maybe people being able to do more. But I also think we've seen this story already. The idea that people can query the data has been around for a long time. The tools have been there in Thoughtspot and Tableau and Power, right. Where I can come in and use natural language and just ask a question. And the uptake has not been tremendous like people thought it would. Even self service dashboards. Right. Again, that's the problem is a lot of people don't want to do this. Business people, executives, they just kind of want it to be able to do this very quickly. They don't want to sit there and have to master how to do this in the tool. Now that might be changing given the prevalence of these interfaces coming out now that like Chat GPT has instigated in the world. So maybe there's a revival of that where people are have to become more comfortable with that model. So I think that's what remains to be seen is where that plays out. So I don't know that I'm excited about it, but I am highly interested to see where it's going to go over the next few years and what it means to our industry. I wouldn't mind if there's some advancements that make the work less tedious or if I have an idea and I can prompt and have it generate the work the way I want it to be. Not the default in the tool, but the tool. Just in the same way I can say right in this tone that I could say, hey, make my visuals in my flavor or my flavor of my organization so that the tedious part gets done a lot faster and the value part is where I spend all my time. That would be pretty cool.

Okay, yeah. So all that sort of stuff around implementing like the design system aspects, if that's just handled for you so you're spending less time just doing nonsense boilerplate stuff, then yeah, you can create more dashboards faster and hopefully higher quality and.

More people in the organization could do it because they wouldn't have to worry about the quote, unquote, creative part. Like you said, it's like, look, this is just how we do it. And don't worry about that. It's good the way it comes out. We'll take care of that for you. Yeah.

So less time thinking about the technology, more time just getting to solving your business problems.

Yeah, exactly. All right.

Well, yeah, hopefully the future's bright, certainly interesting times as the technology moves on. And yeah, hopefully all these process ideas that you've had will get put into practice at a few organizations. All right. Thank you for your time, Lee.

Appreciate it. It's great to have the conversation.