How do we get the most breadth out of design and designers when building data products? One way is to have designers be at the front leading the charge when it comes to creating data products that must be useful, usable, and valuable.
For this episode Prasad Vadlamani, CDW’s Director of Data Science and Advanced Analytics, joins us for a chat about how they are making design a larger focus of how they create useful, usable data products. Prasad talks about the importance of making technology—including AI-driven solutions—human centered, and how CDW tries to keep the end user in mind.
Prasad and I also discuss his perspectives on how to build designers into a data product team and how to successfully navigate the grey areas between various areas of expertise. When this is done well, then the entire team can work with each other’s strengths and advantages to create a more robust product. We also discuss the role a UI-free user experience plays in some data products, some differences between external and internally-facing solutions, and some of Prasad’s valuable takeaways that have helped to shape the way he thinks design, data science, and analytics can collaborate.
In our chat, we covered:
- Prasad’s first introduction to designers and how he leverages the disciplines of design and product in his data science and analytics work (1:09)
- The terminology behind product manager and designer and how these functions play a role in an enterprise AI team (5:18)
- How teams can use their wide range of competencies to their advantage (8:52)
- A look at one UI-less experience and the value of the “invisible interface” (14:58)
- Understanding the model development process and why the model takes up only a small percentage of the effort required to successfully bring a data product to end users (20:52)
- The differences between building an internal vs external product, what to consider, and Prasad’s “customer zero” approach. (29.17)
- Expectations Prasad sets with customers (stakeholders) about the life expectancy of data products when they are in their early stage of development (35:02)
Quotes from Today’s Episode
- “The question is, who leads first? The designer or the product manager? The answer is both of them. I go back to how to build an enterprise AI team; what are the skills needed in order to create a product and to enable them? It requires everybody. It requires designers. It requires product managers. It requires data engineers. It requires data analysts or business analysts. It requires quality engineers. It requires application developers to take it to the end. You need everybody in there. The thing is, if you have a product manager and not a designer, most likely the product manager and the business analysts are doing the work of a designer. If you don’t have a product manager, the designer is probably doing the work of a product manager.” -Prasad Vadlamani (6:13)
- “We always go with the customer-zero approach. As in, we are the first customer of our products. So, any product that we build, we want to build it in such a way that at any point of time, we [could] to take it [external] ” -Prasad Vadlamani (30:12)
- “Design is everyone’s job because a lot of what we’re doing is facilitating the work of others. We’re bringing people together to work on the solution together since one person’s competency is rarely sufficient to deliver a data product that is useful, usable, and valuable.” – Brian O’Neill (@rhythmspice)
- One thing I want to re-emphasize about no visuals and design is that when we think about user experience, especially in the context of B2B and enterprise design, I’m a big champion of the invisible interface, the design that we don’t even notice is there” – Brian O’Neill (@rhythmspice)
- “Designers should know how analytics products are used and what the value of analytics products are to companies. If they haven’t done any data product design in the past, that’s a skill that can be picked up, but there will be some learning that they need to do.” -Prasad Vadlamani
- “If you consider model development as software development, if you want it to run seamlessly, you have to have software practices in place. I would say model development is less than 10%. Everything else that you take to the end-user is 90%. So we have to focus on making sure that model is absolutely correct […] but in order to push it out, it takes a village.” -Prasad Vadlamani (28:01)
Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today I have my pal, Prasad Vadlamani, from CDW on the line, how’s it going Prasad?
Prasad: Going great, Brian, and how are you?
Brian: I’m good. I’m really interested in talking to you today about, we’re going to talk about data products, we’re going to talk about integrating design and designers with data science and analytics. So, you’re the director of data science and analytics at CDW, we met at my seminar recently, and one thing that you mentioned that’s different for a lot of maybe not so much with digital natives, but with data science teams and analytics teams, they don’t have designers on the teams. You do. Fairly uncommon, so tell me a little bit about where you first got exposed to designers and how do you use design and product in the context of the work you do?
Prasad: Absolutely. So, you know, I came across this special group of talent called designers maybe four or five years ago, when it was talked more about human-centered design, and we were using a specialist designer in our team to help with our story building, data storytelling, and not just about visuals, but trying to understand the empathy aspect of it, like, why you are building something for a particular pain point? Who is the end-user going to be? What is the persona of the end-user? We used to go through the whole exercise with her while we were trying to do this data storytelling. But it was more of a we built the product, now please help us tell the story.
That’s how I got introduced to the designer aspect of it. But then last year, when I joined CDW, this is a new enterprise AI team, about two-plus years right now. I mean, there was a limited scope of data science work that needs to be done here, so probably there is one or two products built around that, but when we went to scale and try to give this particular outcome value to the whole corporation, then it has to lead with design, a designer in the front talking to a human, the end-user. So, we did not start off saying that we need designers in the team; we did not say that we need to specifically hire designers into the team. But we have some business analysts and data analysts who are expert in understanding the empathy and understanding how the end product should look like.
And then we started, some of them are trained as designers, and then we started bringing in designers to help us navigate from the beginning, to the launch, and post-launch. In your design seminar, you make it a very salient point that the launch is not the end of it, it is the beginning of it. So, that design aspect of it is extremely important in the product management culture because the difference between a project and product is project has a definite timeline, a beginning and a end, but as a product, there is no end. It actually begins when you actually release a product. And the designer has that competency that’s going to keep the product alive and relevant for a much longer time within the organization. So, that’s the nature of design work that we have in our organization.
Brian: Got it. Got it. You’re doing a lot of machine learning and AI work—as I recall—there. Is the way you integrate the practice of design or the designers in that work, is it different than how you would do it with traditional analytics, historical descriptive analytics, or is it more or less the same and it doesn’t really matter what the back end technology will be?
Prasad: No. If it is purely ten years ago when we were building dashboards, and now when we are building data products, the designers are the ones who are actually making the biggest difference. So, I wouldn’t say it is anything traditional. It is truly groundbreaking. I mean, these are probably aspects considered by other product groups, like in the consumer group where you have to worry about is the perfect packaging done?
Does it make the ruffling of the noise that the—you know, they consider all these things. Because it says a tangible product that you’re putting in the hands of humans, whereas this data products, you’re putting in the hands of humans who are consuming it through either through their smart devices or a mouse clicks. So, I think definitely this design element now—for me—I feel it’s a new trend, but it’s very essential in order to have a great data product. And what we do is not dashboards; what we do is not reports. What we actually do is data products. That means the data will tell them story with each and every screen that is painting in front of them. And for that, designers are our absolute must.
Brian: Got it. This product versus design thing I remember on one of our conversations, you said that there’s a lot of confusion about these roles. Can you talk a little bit about, if you do have dedicated product or data product managers versus designers, is that confusion between them or is that confusion between you and them? Can you talk a little bit about where the lines are gray? And there they are gray, in my opinion, most of the time, and they’re kind of tied at the hip; I always see those two as a pair, really a trio with engineering or a technical lead, the power trio as I call it. But tell me a little bit about this from your perspective.
Prasad: That’s a great question [laugh] I remember asking you during a seminar. Because the terminologies that people use, both of them use this terminology, so it’s very easy to get confused as a product manager and designer are the same. It could be in certain aspects of product development, but the question is, who leads first? Is it the designer first, or is it the product manager first? The answer is both of them has to do.
And the thing is, I go back to how to build a enterprise AI team. What are the skills needed in a team in order to make, build, get create a product, and to enable them? It requires everybody. It requires designers, it requires product managers, it requires data engineers, it requires data analysts or business analysts, it requires quality engineers, it requires application developers to take it into front end, you know, you need everybody in there. So, the thing is, if you have a product manager and not a designer, most likely the product manager and the business analysts are doing the work of a designer. If you don’t have a product manager but you just have a designer, designer is probably doing the work of a product manager.
So, it’s basically the empathy aspect that I’m—this is not something I’m just letting it go, but I’m letting it loose, but at the same time, I’m going to make sure it is going where I want to go, the product. If you are talking about launch, the biggest thing I think about is a space launch—it’s not a space launch, right? It’s basically I look at it as a long tethered kite flying in [laugh] the sky more than its space launch because these are our data products and you have to constantly navigate choppy winds and things like that you need to make sure that you know how the business is moving, the kite also should be moving towards that, the product should manage. So, I feel like there is a confusion, but the more I work with the designers, I work with product managers, the blurred lines become more and more clearer. This is a question, a designer can help you.
A product manager should do research, but the designer can help the product manager do better research. They will be able to say, “Okay, this is the type of question that needs to ask. This is how you should ask. Instead of leading them, you should make them answer the actual question that is intended.” So, those kinds of research things a designer can help product manager there.
A product manager can lay down the plans of enablement, product enablement plan from a product marketing hat and say, “Okay, this is what I want to do. Can you help me design the process of enablement, also.” As you have made it pretty clear in your seminar, design is not just designing products. Design is about managing each stage of product development, including product enablement, the communication around it, the collaboration around the development of it, the quality of it, each of it should be considered from a design point of view. That’s where I was able to differentiate the two different roles.
Brian: Talk to me about the challenges that you see sometimes, maybe, within your team or that you’ve seen in past experiences between data scientists working with product and/or design UX people. Where do things sometimes break down? The way I often see it is—a lot of times—I’ll say there’s a correlation between the more education you have in technical background, particularly in statistics, math, et cetera, the more you don’t want to have anything to do with the downstream outcome part and you just want to work on the modeling and all this part, and the less you have of that, and you have a more broader skill set, those data experts tend to fit in better, I guess I would say, at least naturally. It doesn’t mean you can’t correct for that a bit, and sometimes you do need technical people just doing technical work because it’s hard; some of this work is really difficult, and we need that. How do you manage that relationship? Are you having challenges that? If you’re not, that’s great, can you maybe talk about how you make sure there [laugh] aren’t those challenges? How do you do it?
Prasad: I have to say yes, I do have those challenges, but it goes both ways. You know, where you said that the extremely technical people, they just want to do what they want to do, and everything else needs to be supported. So, I’ll give you, maybe five, six years ago, when we were building this data products—a little bit of data science, but more of analytics—back then, yes, you know, the technology, people were like, “Let me just build what I’m building and you take care of everything.” Right?
Brian: Right. “Make it look nice.”
Prasad: Right. “Make it look nice.”
Prasad: I even remember, we built these dashboards, and then my marketing VP, she said, “I want to see it to be the year of beautiful dashboards.” So, I didn’t understand what she mean by that, but now I get it. She wants it to be something that she can go and place it in hands of human users. She’s talking about the design; she wanted us to design something really nice. But that’s probably five, six years ago.
And then we have this constant struggle, “Okay, just let me do my thing. Don’t bother with me, anything else.” But in recent times, I’m actually—there is a lot of data science education happening out there, and there are some good data scientists who understands the value of understanding business. So, for those folks, it is also possible that as a data scientist, you might be focusing too much on business and less [laugh] on the model, also. It is possible.
So, I’ve seen that problem also. When the classic case of it is, a team of couple of data scientists might have built a product, and they definitely probably would have spoken to some end-users, and based on that, their feedback, they might have build a product, a great MVP. Releasing the MVP into the next mode would require that soft-glove approach of a designer and a product manager to come into picture. At that point, when you are introducing these new players into the team, you will find some kind of hesitancy, like, you know, “Why am I not doing a good enough job speaking to the business?” Like, “Why should we have these other players come into picture?”
So, you have to manage those questions also. So, I’ve seen both aspects, but it is a constant push and pull. It’s never black and white. In our talks, there are these captive data science teams in large enterprise companies like ours, and then there is small data science in small companies, and there is also product people done by startups. So, if we say—think of ourselves as a startup, right?
Yes, at this moment, you should focus on core competency, but you still need to have a little bit of skill outside of the competency because we are playing as if we are a startup kind of mindset. When you have that, a data scientist is mostly data scientist, but is partially designer, partly engineer, partly product manager, et cetera. And vice versa. So, the product managers cannot be purely business product managers, we need sometime to be technical. Also, designers should know how analytics products are used and what is the value analytic products bring to the companies.
If they are purely non-data, if they haven’t done any data product design in the past, that’s a skill that can be picked up, but there will be some learning that they need to do. Same how people ask me what is the difference between a business analyst and a data analyst. There are stark differences, but when you are working in a data organization like mine, they are more or less the same. So, you know, each and every role will have different definition once you put data tag on top of it. Yeah.
Brian: Sure. Yeah. I think that core idea of the team has a shared understanding of what the outcome is that we want, and then it’s management’s job to make sure that all the work is getting done, even if it’s not your core competency. You might have to wear different hats and obviously this is classic startup mode, which is like, “Oh, we’ve spilled coffee. Someone needs to clean up the coffee,” even if your title is COO. [laugh].
And then over time, you hire more specialists, and there’s a little bit less of that cross-pollination. But I do think design is everyone’s job because a lot of what we’re doing is facilitating the work of others. We’re bringing people together to work on the solution together as opposed to it’s one person’s competency to just do that stuff. It doesn’t work, the tech especially with this kind of stuff. We don’t even know what’s possible sometimes, especially with machine learning and what the data sets.
We kind of know what the objective is, but we don’t know if the data can support any of that yet, and the cakes we need to try building—the recipes—we don’t know until we land on one what might be possible. So, it’s very iterative process there and so it’s very gray, as you said. It is a great way to put it, I think design is gray, so I’m with you there [laugh] on all of that. I did want to ask you, you made a distinction earlier about UI-less product design, no interfaces. But there is an experience, there is a human experience, whether it’s an API endpoint or whatever it may be. Can you talk about this idea of designing something that doesn’t have screens, or it doesn’t have charts and the things that we maybe default to when we think about interfaces, data visualization, et cetera. Talk to me about that, designing that kind of data product is.
Prasad: Yes. This is an interesting challenge. One of the products that we have is an intelligent process automation product. Basically, it looks at the various activities and communication, collaboration that happens within our company, and then we intelligently try to do some non-sales-related tasks off our account managers. And that is a big pain point; if you ask a lot of account managers, like, maybe 40 or 50% of the time is actually selling and another 50%, or the rest of it is about documenting the activity itself.
And then they will be about audit taking and more mundane tasks. So, we have some [IPA 00:16:10] applications right there, but the output of it is, it’s just an API call into the system of records where our sellers are used to. So, we cannot design anything visual out there, and that has, that is a challenge. Because of that, we are not able to ask them to come to one particular application or one particular to screen to see, “Hey, this is all the tasks that we have done for you.” But we have collaborated with that particular application team and say, “Can these are API calls and these are the tasks that have been completed for them. Can you show them?”
But they still need to go to their particular screen and look at it. And for a long time, they didn’t know what’s happening because we keep creating those tasks, doing the tasks for them; they need to go and check it and release it, but that particular application where they are consuming it, it’s not refreshing because it refreshes every ten minutes or fifteen minutes or something like that. But what we are doing it, like, on the fly. So, we really had to go understand what’s the problem thing, and then we were able to have some kind of solution to that. But that was only a partial solution.
It’s still something that we don’t have control over the visuals. So, what we have done is we are sending these emails to these account manager saying that, “Hey, by the way, we have done this job for you.” So, when we do that, we were sending an email to them. So, now we said, “Okay, wait. This communication is our product now.”
Because they can’t see anything else, and they can only see the email of it, how can we make it look like the product? How do we make sure that we get the maximum attention possible from them, make them read it, make them understand it, and also then subsequently go and appreciate or take action on the task that we have created for them. So, now it’s like a static product, but it’s a dynamic. Behind the scene, it’s a lot of [unintelligible 00:18:18] AI. That’s probably the biggest AI complicated models that we have, but that’s the one which has the least human visuals.
So, that’s the challenge that we was—I can’t say that I’ve completely solved it, but that’s where we have focused and we are putting more and more efforts and we are getting much bigger appreciation because of those efforts. We want to do dynamic emailing, we want to get feedback directly from the email because there’s no product for us to expect feedback from. And they can’t always go back and support it, whatever. They want send emails, if you have to send feedback right, they’re not going to go up in or outbox mailbox and send an email. Maybe 10% of them will give feedback.
But with this new interface that we are putting in front of them, we are getting more feedback. And the other thing is, probably thousands of sellers have this capability enabled already, but many of them doesn’t even know. Why? Because there is no visuals in front of them. So, these are the challenges that we are facing and we are trying to solve.
Brian: So, one thing I want to re-emphasize about what you’re doing when you’re talking about no visuals here and design is that when we think about user experience, especially in the context of B2B and enterprise design, I’m a big champion of the invisible interface, the design that we don’t even notice is happening to us. And in this case, we’re just getting an email which maybe sounds plain and boring, but if it’s the right information at the right time—and an emphasis on the time, that the temporal part of design—when do they need this information or this automation or whatever you’re doing—that’s really important stuff. And if you can take away a lot of the tactical work the user had to do and use intelligence to do that kind of work, you may end up with a lot less screens, but packaging that up into an essentially invisible interface that doesn’t feel like something new I have to go learn, that can be really valuable, and that very much is a design exercise there. It’s just low on user interface and it’s high on user experience if you do it right. So, I think that’s a great framing that you talked about here with this invisible or no UI component here.
And then you can iterate on these emails, and you rather low overhead in terms of the UI piece, actually, to work on. So, I think the notifications is a great—it’s another touch point, what we call a service touch point or something in the user experience language, but that’s very much a part of design as well.
So, talk to me about the model development, et cetera. This stuff can take a long time to get right. And then it’s like, “What’s the new fire?” All of a sudden, last year’s thing and you wanted to do this big strategic initiative, and by the time you’re ready to roll something out, it’s, like, “New fire. This is the new thing, now.”
How do you manage this at CDW? I mean, you guys are pretty big digital company—at least I think of you guys as a digital company—how do you manage that when you know that these things are going to be large initiatives and the business priorities are changing, and you know what that runway is that’s required to get something out? How do you manage that? Is it different than traditional enterprise software when we’re talking about machine learning and AI?
Brian: Talk to me about that.
Prasad: In this world, if you build, they will come, absolutely… doesn’t work. [laugh]. Right? It doesn’t.
Brian: Yeah. [laugh].
Prasad: Yeah. Full stop.
Brian: Full stop, yeah.
Prasad: It’s not the utilitarian product. Yeah.
Brian: That’s Hollywood, man.
Prasad: This is value-added. And value-add is much harder to actually even build and also enable because it’s not a table stakes; they know that this they have to do, but they don’t need to use the products that we build because some sellers or marketers might be rockstars and they probably have a method to their madness, and they get it done, get the work done, so they don’t need to use our products. But the ability to show the value of why our products are going to be beneficial to them have to start with their pain point. So, if you go and look at—primarily at CDW, we are a seller-focused organization, sales focusing. How can we make seller experience better?
How can we make customer experience better? These are the only two things. So, when you are trying to build it, and if you go what are the AI use cases on [unintelligible 00:22:50] seller, if you go to Gartner or any other of those things. There are literally 150 ideas out there. So, it’s not like we go pick, like, one, two, three, four out the one-fifty list and go build it; we can’t do that.
So, we have to start with the sellers—what is your pain point?—and then come up with the use case that will solve that particular pain point, spend time with them to understand it, now you’re empathizing with them. This is one of the main point of your design, like empathy. And where you’re saying, “Okay, I understand that. So, can I give you a solution or not?”
Sometimes they just want to talk about it; maybe they don’t really needed a solution for it. But try to find something that is painful to them, and then you are trying to provide a solution to that. Get it by [unintelligible 00:23:36], then you go against as if this is a user, if I have a product, if I put it in hand in your hands, how should it be? How often can I communicate with you? How much available could you have to collaborate with us?
All these things should be considered. And then once you walk them along with us in the journey, it becomes their idea, it becomes their product. And again, we have 3000-plus sellers, we don’t go about saying that, “Hey, I’m building product for all 3000 people.” I’m only building product for three people at a time. It might take me 1000 attempts to get to 3000 people, but we are building to three or four people at a time, and then we listen to that, and then we’ll get the feedback, and then we go back and saying, “This set of three people, you have given us four different ideas, but it looks like these two ideas are the most common thing, so can you go about it?”
And then bring the three plus three times three—nine people together—and we build for those people, and then focus group, and then we release it to their managers first or their readership first. And then once we get their buy-in and their feedback, and then we go to the sellers across those nine people. So, it’s not, “We spoke to three people and we’re going to give it to everybody.” So, at CDW we have multiple segments, we have multiple regions, we have few countries. So, we go segment by segment, region by region, asking to them and building just for them and releasing for them, and then add another group of people, another group of people.
Doing that, we are not, as you said, they are paid, already paid to use our products. So, there is no money exchanged out there other than the initial investment and constant investment in building the products. But we tell them upfront that they’re paying for it with their time, which is much more valuable than any subscription costs. So, we take that very seriously. So, we want—even before we send out a survey, we go through a lot of effort in making sure that we are asking the minimum important questions.
We don’t need to ask them twenty questions, can we distill it to maybe three? Can be distilled to two, whatever. And come up with a really good survey model, and then take that answers, distill it, that’s part of the research, and then go and build something. So, it’s a very iterative process, and it’s never-ending, right?
Brian: Yeah, yeah. Do you do like user experience-driven qualitative interviews? So, one-on-one type of sessions or two-on-one sessions, is that an ongoing practice or is it just, kind of ad hoc as needed? Can you talk about that—
Prasad: It’s ongoing.
Brian: —research with the customers.
Prasad: It’s ongoing. We are not at the scale where we are trying—we are making deployments, like other companies, they make, like, 100 deployments a day or something like that. We are not there yet. We’re not there yet. We want to do one major release a quarter and maybe couple of minor release per quarter.
For each and every release, that means that we have to speak to people. So, but we have multiple products in our roadmap, in our pipeline, in our catalog, so at any point of time, there is some product that is going to releasing every month. That means three months before that, we are talking to users specifically about that particular feature, or that particular release. So, it’s an ongoing process. So, the product management team is really busy, the designers are really busy, and then our analysts, they’re working on multiple products, our data scientists are working on products.
Some of the products are not about data science, but some of the products are about data science. We will say, “Okay, this is a data science-heavy, so let the data science team be the delivery leads, but this is more of analytics product so lead analytics people take the lead.” So, we differentiate between those two. In your previous question, you talked to me about ML model development specifically, and my answer was not to the point that, so just to go back on that, the models are just a part of the puzzle. It’s just like how, in a traditional software engineering development organization, the software written is probably only 10% of the effort.
So, if you consider model development is software development, if you want it to run seamlessly, you have to have software practices in place. So, I would say model development is less than 10%. Everything else that you take to the end-user is, 90% of it is taken to the user, right, that particular piece of software. So, I will say model is only 5% of the effort, so we have to focus on making sure that model is absolutely correct and valid and we do all quality on it, but in order to push it out, it takes a village. Does that answer?
Brian: Yeah. And I think what you just said is not a given for a lot of people, especially I think the really, we’ll call them traditional data scientists, a model is the 80% in their head. And so what you just said, I think you should state that again [laugh] to emphasize it because I very much agree with it.
Prasad: Besides it, you know, I would say model would be 5% of the total effort of taking a good product to the end-user. It’s less than even taking a regular software product at the end-user because, you know, it that’s how much work it takes.
Brian: There’s a lot of other stuff that goes into it. The one thing we—when we talked about doing this episode, I know you are working on externalizing some of these data products, so you’re working a lot for your seller market, et cetera. I know you have some initiatives I know you can’t talk about, some of it totally in the open, but I wanted to broadly understand, what’s different when we start building stuff, not for our colleagues and employees or vendors or partners, but we’re pushing it outside, something we want to get paid for, a revenue-generating SaaS or something along these lines that uses data. Can you talk about that process? Is it the same? Is it different? What needs to adjust in the culture of how you guys create—
Brian: —those things?
Prasad: Go to market to the external market taking our data products out, I think it’s a different challenge than starting out to build a product for our external customers by itself. So, but at the same time, we always go with customer-zero approach, as in, we are the first customer of our products. So, any product that we build, we want to build it in such a way that at any point of time, we want to take it outside. So, if you go and see some of the notices that CDW, at least, says, we talked about the capabilities, AI capabilities that we give to our sellers. So, naturally these things, our customers, our vendors, or partners, they ask about it, and we explain them what we do, and then they are interested in saying, “Can we have it?”
They’re willing to buy it. So, you asked me not just about technical but the non-technical aspects of it is, the first thing is, when you have—when you’re building a product for yourself, you have these people that you can talk to, that you can develop for. Whereas the customers, we don’t even know who they are. So, that itself, the research aspect of it is completely different, finding the thousand prospects. This is a newsletter that you sent very recently, and the very first point was that, like, the finding the thousand prospects as opposed to 20 users, that’s a big challenge.
The other thing is even when our customers are in this, they say, “Can you give this product to us? We’ll pay for it.” You don’t even know how much the price should be? Should it be $1,000 per year, or is it $10 per month per user? We don’t know, right?
The other thing is, the biggest difference in between a internal product and external product is, if you feel like there are some features of that particular product that are not beneficial anymore, or not use used as much, I can shut it down. But the moment you release that out, you can never shut it down. Even if it is only one paying customer paying you a dollar, you still have to maintain it until, you know, the stipulated time. And then you need to talk to them and figure out a way to say, “Hey, this is not working out.” You see some small companies going down under.
So, we don’t want to make that kind of mistake because now it’s a large company releasing a product for others. So, these are the considerations that we have to take into view. The other thing is, in the way did we build it. Is it built on your native servers, or is it built on a cloud? Is it specifically your data that’s getting in there?
Did you build the data pipelines nimble enough that it can take any data from anywhere? These are the technical considerations. But the challenges go from pricing to marketing to shrink-wrapping it, and also, how do you have the sales? Now, how will you sell it? Yeah, it is okay, you might be able to sell it to five customers, but the space that we are in, if you’re not going from ten customers to a hundred, and a hundred to a thousand every year, you will go under.
Because there’s so much money that needs to be spent in marketing and selling enterprise software, that again, it the budget-wise, again, the model will only be 5% of the budget. So, do you have that kind of budget to do that? So, that is to the point of sale. But post-sale, how does the customer success team work? Will this product be part of their business system or will they be part of a external tertiary ecosystem?
That depends on how much support the client will be able to do for the product itself? Do you need to support it from outside or do you need to have a service organization to support this particular product for your client? So, there are a lot of things that you need to consider before you take these products outside. And these are the things that we are considering right now. And we’ve worked with some partners to identify a GTM strategy with some customers to identify which features are most important. Because we cannot take all the features that we have outside; it will probably be a skinnier product when we first take it out to a customer. So yeah, a lot of things to consider.
Brian: Right. Yeah, that’s just—I mean, this is precisely for those that don’t come from software; this is why we have product managers and this is the work that they do with initial positioning, pricing, the marketing strategy, go-to-market all of that, not just the product part and prioritizing feature development and all that kind of stuff. So, it is a whole ‘nother beast for sure, to do that and the challenges can be different. So, thanks for sharing that. You’ve had a lot of broad experiences here working with data, obviously, and machine learning and AI, and designers, and product people, and engineers, and all of this, is there any big lesson that you’ve learned that you want to share, something that you’ve maybe have changed at CDW. Like, you know, “New rule, I’m not doing that again.” [laugh]. “I’m not going to go—I’m doing in a new way, this time.” Anything that’s change that you can think about that has made a big difference for you in being successful with data product development?
Prasad: Yeah, one thing we are not doing is we don’t use the terms like dashboards or reporting here because that’s not what we’re doing. I mean, in previous jobs, or things, people will say, “Hey, can I have the dashboard,” or, “Can I have the report,” or something like that. It’s a static—you know, it gives a very—it’ll change when I go there kind of concept. But the ones we have moved into the product management part of it, we’re going to manage this like a product, I would never want to go back to the project aspect. That’s definitely there.
The other aspect also, start with the design. In the past, we have built some products—I have—by only speaking to the business liaison person, but not actually the end-user. There is always this lost in translation because the end-user might say, “I want this particular pain point,” business user understood the pain point is slightly different, but by the time it got to you, there is a third variant [unintelligible 00:36:30]. The solution that you would jump into solution right away because you know that’s a pain point that must be fixed because it came from some high-level business strategist asking you to do something. We take a very slow approach right now.
And the other thing that we are also considering thinking of is, do the products that we build, does it have an expiry date? Anything that’s put in your hand comes with a manufacturer date, and say, three years of expiry, or it comes with an expiry date in saying that this is the best use-by, whatever. So similarly, the products that we build, we are building for the pain points of the current users. The current users in companies like CDW are both digital natives, and also non-natives, and people who are in the transition. So, the pain points that we might be solving are mostly say saying for the non-digitals.
I mean, it may be not, but let’s say we are doing that. But over a period of time, if there are more and more digital natives coming in, then basically this pain point doesn’t even exist. So, how do you consider, when you approach the executive leadership and asking for money, we don’t want to say, “Oh, we are building this application that is going to last for 20 years.” Yes, the name of it might be there, but the features of might be completely different. Similarly, the same product that is running on XYZ technology stack, might need to go to a different technology stack which is going to do things ten times faster.
And that is part of it; be prepared to write the check to us in two or three years because we will definitely move from this platform to another platform. So, having that kind of expiry date mentality, I think it gives us a fresh instead of saying that I’m going to build something that’s going to last forever because nobody’s going to use anything forever. So, that’s something that I’ve definitely understood that, in order to keep things fresh and also novel.
Brian: Is that an expectation that you set? That’s really interesting framing to kind of set that up at the beginning, like, “Yes, we can do this. Yes, we can make that change. For the next two years, this will work, et cetera, et cetera, and then after that we’ll need”—[laugh]. Are you kind of planting those seeds early with the business so they understand you don’t get 20 years of life out of this one initiative? Is that kind of what you’re trying to seed early?
Prasad: No, it won’t be the ultimatum or dictum or—
Brian: No, not an ultimatum—
Prasad: —[crosstalk 00:39:13] like that, saying that—yeah. Right.
Brian: —but setting expectation.
Prasad: But it will be an expectation—
Prasad: —that we do. We’ll say you know, “I can’t tell you, but there is a feature that we built in the IPA product.” Within our data science team or our team, we know that feature can be taken away if a particular—a CRM that we might change, or whatever come, it might come with that feature. That means this feature doesn’t need to be here at all. So, you need to take it away.
So, by having that kind of understanding ahead of time, it could be six months, it could be two years, three years, but eventually, it will be gone. The surprising thing about [laugh] corporate also is, the products that you build that you think are going to be temporary are the ones that are going to be [laugh] there for the longest.
Prasad: [laugh]. So, the Band-Aid solutions have been going to be there for 12, 15 years, but the nice, shiny, the perfect solutions will be kicked out in two years. So, because there is a disruption happening in, you know, you don’t see this disruption in Band-Aid, but you see the disruption in MRI machines, right? So, same thing. So, you have to be very open about that, and you have to communicate to your upper leadership, you have to communicate to your stakeholders, you have to communicate to your team that be prepared that the things that you’re working on right now, in two years it won’t be there, but you might need to build something else to replace it.
And the other thing, also, from a expiry point of view from a product is, I believe that products will have—there is only so many features that you can pack into it. So, when you want to add a feature, my challenge is considered as a real estate, what feature are we taking out? Yeah, you might end up getting some bad feedback, some from few users in favor of building something for a larger set of users who have a bigger pain point to solve. So, I think this whole thing is around that expiry date concept. [laugh].
Brian: Yeah, no, I understand. I think that’s a great place to leave it, but I want to give people a chance to follow you. Are you on LinkedIn or Twitter? Or where can people follow your work and connect up with you?
Prasad: I’m on LinkedIn. You can look up on my profile, Prasad Vadlamani, CDW. I think my tag is ‘coachp’. I got it long time back, but you can reach me.
Brian: Great, awesome. I will definitely put that link in the [show notes 00:41:35] and Prasad, it’s been great to catch up with you, and I wish you guys really well, especially with that new external-facing product you guys are working on over there. And best of luck.
Prasad: Thank you.