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

"ltr">Richie Cotton: 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, 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 you 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?

Lee Feinberg: 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 me 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.

Richie Cotton: That's fascinating. So, product managers, like there's so much sort of, expertise that I was very different from perhaps a data analyst expertise. If you're trying to make this transition to having these, like, visualization products, then where do you begin?

Lee Feinberg: 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, 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, and 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, 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, We 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 for 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 it 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.

Richie Cotton: That's kind of fascinating, the idea that just a simple standardization of language on how you communicate things, that's gonna 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 visual side of things as well, or any other aspects?

Lee Feinberg: Yeah, there's kind of a visual communication policy as well. And you can 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 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. 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, a source 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.

Richie Cotton: Okay, I do like the idea of having a glossary of just like, these are the terms we use, this is what we, we mean by the, 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 can look up what you are talking about.

Okay.

Lee Feinberg: the whole, 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,

Richie Cotton: This is fascinating stuff. And actually some of the ideas you're talking about, it reminds me that like, product design engineering teams tend to have things like a design system. So like data company of 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?

Lee Feinberg: 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 dashboard 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.

Richie Cotton: 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?

Lee Feinberg: Yeah, because I mentioned there's a, there's kind of those three pieces of it. let's tackle, tackle a couple of them. the first one's just setting the foundations. So it's, 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 one, okay, it sounds like, 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 a couple of things.

One, there's too much diversity, right? We have some of the things we already talked about. our visuals coming from the same team look wildly different whether it's just 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 function, 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 it into Excel. And so there's a lot of effort that's just not being utilized. And then they 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, May be hard to come to grips with, but that's where the real leadership comes in and says, okay, I know what we're doing isn't working as well as it could, we need to make a change.

Richie Cotton: Absolutely. So I think this is one of those sort of data team curses as president in most organizations. You create all these dashboards and then nobody looks at them. So I guess I'd love to How do 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 cares?

Lee Feinberg: 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, 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 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 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've been working at the company for a while, 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 that 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 click it and 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.

Richie Cotton: That's a very cool thought experiment. I like the idea. You go on Amazon, I'm shopping for a dashboard, for the cheap ones, but hopefully like filtering for ones four star rated or higher or something. But I like the idea of like, yeah, 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 kind of curious, it sounds like then the key to creating 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?

Lee Feinberg: 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 lot of times it's, yes, we can have those, like you said, requirements, specifications, product descriptions, specifications.

Yeah. But it's really like user story, 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 write just all 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 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 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, 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 before I spend all the time trying to get the data out of the system or maybe I have to create the data. 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 ask, you know, do you just get the requirements and go? The answer is definitely not. Because that's also one of the biggest errors that we hear from people is that 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 say, but that's what you told me, and they say, yeah, but, there's this terrible cycle, and we're really trying to break that.

From happening.

Richie Cotton: Yeah, certainly if your client asks for something stupid and then you go and build it, it's not going to be good for either of you, like, once you've created something silly and there's going to 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 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?

Lee Feinberg: so the third element I talked about. So we kind of have this foundations, we have the way you actually build the product. Obviously, we haven't talked about this in a lot of these, either any of these in a lot of detail to 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 or 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. And 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. Yeah. 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. I'm 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. It doesn't mean you're an analyst. All right, so I may have to teach you that, A, 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 it has to be some education. Typically what people do is. They think that education is like where to how to click of 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 it, 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 you 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? 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 the 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, these are, 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, right? that's not helpful. I mean, it's good. That we did that, but that's like entry stakes is to do your, your work on time.

Richie Cotton: Yeah, that's fascinating that I mean, so we talked before about how you need all these sort of ideas from product, but now it's like, well, you need all these ideas from marketing as well. You got to promote your work and then I guess there's all this sort of enablement piece as well, but you 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 the 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, it's like a line plot where the line is going up. Then there's sort of a base level.

You want people to understand. Okay, this is an upward trend, but then there's also a sort of more detailed business context. 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 relationships after persist, even after the, after the dashboard is launched, then talk me through who get who's involved in this marketing effort.

Lee Feinberg: Yeah, I think in, 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. I think it's a, 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 know, 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, I just measure this or just, market this to them.

do you do these things? So either they have to be modeled by other people, right? 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. Okay. 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 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 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 may launch your product and have no support for it whatsoever.

I

Richie Cotton: 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?

Lee Feinberg: think like anything, you have to apply it in the way that makes the most sense. It's not crossing all the D's and dotting all the I's 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? 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 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 a 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 and 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 a 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, it's not meant to be so solid that people can't diverge from it when they need to. It's meant, it's more 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, where we talked about that issue, do it with a lot less effort have that result be a lot better.

So I think most frameworks always allow for people to do things differently.

Richie Cotton: Okay. Yes. You just got to decide which things you, you want to keep standard and which things you're going to allow some flexibility in as opposed to 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.

And what sort of genre, but you know, you can still write a lot of songs with the, the, the, the. Unique. Okay. I don't know whether that analogy worked or not. Uh,

Lee Feinberg: But it makes, but it makes sense, right? There's, frameworks, I don't know any but, there's a method to doing that as well. Yet people write so many different songs.

Richie Cotton: Yeah. So, preserve like the unique identity, the creativity, but still standardize things enough so it's understandable by the audience. Alright. Now I'm wondering whether you need to think about different types of dashboard differently. So, I think sometimes well, But you can have very important dashboards that are looked 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've got dashboards for like one off analyses, or maybe it's something that props up like once a quarter is don't really look at very quickly.

Do you need to change your approach to building different types of dashboard?

Lee Feinberg: I think the approach should always be the same. be the same in the context of understanding the purpose. But 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, I think, 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. Like, let's say it's something that 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 person. 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. They're 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, it's under, 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, on those aspects, but something like you said, quarterly report or review.

You've probably got some kind of established cadence. So you're probably just go through this an 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 line 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, 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.

It's a period of the 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, 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.

Richie Cotton: that's interesting that if you're going to change the, 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?

Lee Feinberg: Yeah, I think the biggest, 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 and 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 with 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 it. expectations. I'm not saying this is a major effort, but again, it's about building trust and in that communication. So I might, there might be some notice that goes out.

They were 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 in even 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 so that when the time comes, now it's 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 anybody.

Richie Cotton: 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. Uh, 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 you're 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?

Lee Feinberg: 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 this one example and see if we, you know, I don't 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, well, what I do, I'd start taking all their data.

I would maybe show them client sales maybe how long they'd 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 to find out is, well, what does at 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 they 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've 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 a level of sales or is it frequency or, right? There's a lot of variables that go into that. As 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, are actually work than in the northeast and 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.

Richie Cotton: That's absolutely fascinating. Actually uh, talking about churn, so it was it's very close to our hearts at Datacamp. You know, we're primarily a subscription business, so 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, you know, Okay, well, now we need to enable people afterwards to understand, like, what the different scenarios they're 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 and 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 where you're the most negative person about dashboards.

Lee Feinberg: I'm interested to see how things are 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 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, It doesn't mean anything to me. In terms of how the end user interface 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 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 Power BI, 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 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 gets This is where I spend all my time.

That would be pretty cool.

Richie Cotton: 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.

Lee Feinberg: 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. 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.

Richie Cotton: Yeah. So less time thinking about the technology, more time just, get into solving your business

Lee Feinberg: Yeah, exactly.

Richie Cotton: All right. Well, yeah, hopefully the future is 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.

Lee Feinberg: Appreciate it. It's great to have the conversation.