The Lean AI Podcast presented by Eric Ries · 2025-04-10 · 39 min
Key moments - from our scoring
Substance score
65 / 100
Five dimensions, 20 points each
Getting senior leadership alignment on AI initiatives requires fundamentally different positioning than many data scientists attempt. Supreet Kaur, drawing from her experience building AI solutions at Morgan Stanley (which generated 6x new assets) and her current role at Microsoft, emphasizes that successful projects start with business problems, not technology. She advocates for connecting executives through regular elevator pitches that demonstrate progress, avoiding overwhelming them with technical details while instead translating AI outcomes into business metrics and ROI. A critical pitfall is providing too much technical depth while neglecting business value metrics - Kaur recommends translating productivity gains into dollar figures leadership can present to boards. Her approach emphasizes data strategy as a prerequisite to AI strategy, ensuring teams have the right talent (app developers, .NET engineers, not just data scientists), and setting realistic phased expectations rather than promising moonshot outcomes. The 'art of the possible and not possible' frames how copilots and AI products require 3-12 months to show productivity gains, robust evaluation with subject matter experts, and acknowledgment that models may hallucinate or underperform due to data quality or user behavior shifts.
Focus on business metrics and ROI translation rather than technical depth. For example, if an internal copilot saves developers 15-20 minutes, calculate and present the dollar value to the organization. This frames the project as revenue-generating rather than a cost center, giving executives talking points for the board.
Providing too much technical information about the technology while completely omitting business metrics and evaluation methods. Leaders need to understand what they're selling and how success will be measured, not how the algorithm works.
AI projects fail when teams haven't validated data quality, ownership, and availability upfront. Starting with a data strategy means mapping use cases to data assets, ensuring data is in the right format and quality, and planning necessary migrations before building AI models.
Use a phased approach to set realistic expectations: phase one achieves X, phase two achieves Y, and final product achieves Z. Be transparent about what technology cannot do and that productivity gains typically take 3-12 months to materialize, not days.
You need app developers, .NET developers, and Java developers for integration with legacy systems. Overlooking this causes delays when it comes time to integrate AI products into existing enterprise applications.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode delivers several concrete, non-obvious insights about leadership buy-in (tie tech to business problems, create phased roadmaps, do pre-work before pitching use cases), though it cycles through some familiar themes (elevator pitches, stakeholder management, data strategy) without aggressive depth. There is meaningful density in the middle sections on expectations-setting and the risk/reward matrix, but the ending devolves into generic encouragement about embracing AI and holding hackathons.
Tie the, I would say the technology with the problem. See how AI can enable you to solve the problem rather than the other way around, like trying to find a problem just so that I can use agents.
If you can give me a matrix of low risk, high reward use cases, let's start with that.
The guest repackages standard product management and lean startup principles (phased delivery, stakeholder involvement, data strategy first) without substantial novelty. The framing around 'art of the possible' and 'art of the not possible' is mildly fresh, and the specific advice on pre-work before pitching (researching prior failed attempts) is sensible, but the core frameworks (2x2 matrices, elevator pitches, ROI calculations) circulate widely in corporate innovation spaces.
Start with your data strategy, see where those gaps are.
You basically choose that emotion whether you want to get scared of it or you want to embrace it.
Supreet has legitimate credibility: started as a data scientist in healthcare consulting, built an AI engine at Morgan Stanley that generated 6x new assets and earned patents, and is now at Microsoft (7 months in as of recording). She has done the technical work and navigated executive alignment in regulated, capital-intensive environments. However, she is relatively junior at Microsoft and the 'education sessions' role suggests she may not be driving major product strategy at scale, and there is some humble-bragging evident.
I started my career as a data scientist in the healthcare space. I was in consulting, so working with different pharma companies mostly, uh, around demand planning, launch strategies, leveraging AI and machine learning. Then I pivoted to finance, uh, at Morgan Stanley, had a very successful run, uh, built AI personal engine, got patents for it, and also the results were phenomenal. It was 6x new assets.
And now I'm on the other side where I hold education sessions for the C suite and educate them on the art of possible.
The episode includes some concrete numbers (6x new assets at Morgan Stanley, 33 trillion market size for small business, 15-20 minutes of developer time saved) and named organizations (Microsoft, Morgan Stanley), but lacks depth in most examples. The guest frequently speaks in generalities ('productivity benefits might take 3, 6, or 12 months,' 'there is so much noise right now') and avoids specifics about actual use cases she has deployed or their outcomes beyond the Morgan Stanley example. The small business prospecting example is mentioned but not developed.
It was 6x new assets. Ah, that was what the solution bought.
This is a 33 trillion market.
The host asks solid questions that probe the guest's logic (e.g., 'Are you suggesting developers are not the best at change management?' and pressing on how to handle C-suite mandates), and does push back on some claims. However, many of the host's follow-ups are more confirmatory than challenging ('I love that,' 'That's a great point'). The host occasionally pivots away from depth to move the conversation along, and there are few moments where the host genuinely presses Supreet on contradictions or limits in her advice. The conversation flows but lacks the friction that would elevate it.
Are you suggesting that developers are not the best at change management?
One of the things in our work that we've seen is if you're failing for $10,000, you're really learning. It's not really a failure. But if you spend a hundred million dollars over seven years and that doesn't go well, that's a failure.
Computed from the transcript - who did the talking, and the words that came up most.
In this episode of The Lean AI Podcast, host Ben Hafele is joined by Supreet Kaur, AI professional at Microsoft. Together, they discuss strategic approaches for securing leadership buy-in for AI initiatives, the importance of aligning AI with business problems, and how to effectively communicate AI progress to maintain momentum and support from executives.
Transcribed and scored by The B2B Podcast Index.
Speaker A: Welcome to the Lean AI Podcast, where we're flipping the AI conversation on its head by focusing on holistic strategies and tactics that drive AI adoption, rather than focusing solely on overcoming the technical challenges of AI. Uh, in every season two episode of the Lean AI Podcast, we talk with corporate AI leaders just like you, who've uncovered the secrets of driving successful adoption with far less wasted time and investment. Our guests challenge established views and offer disruptive perspectives, providing you with new, actionable insights. Supreet, welcome to the show.
Speaker B: Thank you for having me. I'm excited for our conversation.
Speaker A: Yeah. And I've really enjoyed speaking, uh, to you before this, uh, kind of catching up on all the different topics that you've been, uh, writing about and, you know, posting about on LinkedIn. So excited to have this chance to speak with you again. So, uh, today we're going to talk about how to get senior leadership on board, uh, with what you're doing in the AI space. Uh, before we do that, maybe if you could provide a brief overview for our audience on your background.
Speaker B: Sure. So I started my career as a data scientist in the healthcare space. I was in consulting, so working with different pharma companies mostly, uh, around demand planning, launch strategies, leveraging AI and machine learning. Then I pivoted to finance, uh, at Morgan Stanley, had a very successful run, uh, built AI personal engine, got patents for it, and also the results were phenomenal. It was 6x new assets. Ah, that was what the solution bought. So, extremely successful. And then I was like, okay, I'm done with these regulatory industries. Let me get on the other side. And now I want to get into tech. And that's how I got into Microsoft in, uh, July last year. So it's been seven months.
Speaker A: Fantastic. Well, um, I've certainly enjoyed your, uh, you know, the thought leadership that you've been providing and your, you know, 100 days of LLM, uh, that you posted on, on LinkedIn. Um, so let's, let's hop right into it. Uh, one of the big topics that always comes up that we haven't really tackled yet on this podcast, so I'm excited to do it with you today is how do you get leadership, Senior leadership, maybe even the C suite kind of bought in and also aligned and also just to kind of like, what, what do you need them to sponsor? Like, how do you, how do you get aligned with, with senior leadership? So maybe what are your, what are your recommendations? And also maybe some pitfalls that people should watch out for in that space.
Speaker B: Yes. So I have been on both the Sites. Now one where I was building solutions and really vouching uh, for myself, for the team I was working on to get the required buy in. And now I'm on the other side where I hold education sessions for the C suite and educate them on the art of possible. So one thing that I've observed is that the way we approach the problem makes all the difference. Whenever a new technology is launched, everyone is excited, everyone wants to work on it. You would also see all your managers coming in and talking to you about the new technology. And maybe as a C suite you yourself are very excited and you want to try the new technology. All of that is good. But I think the fundamental difference between a product that loses momentum over time and the one that doesn't is was it attached to a real business problem or not? So that is one thing that you need to differentiate as a data scientist, as a business user. Uh, tie the, I would say the technology with the problem. See how AI can enable you to solve the problem rather than the other way around, like trying to find a problem just so that I can use agents. That's not the right approach to. I uh, would say configure and go through a problem. So that would be my first step on deciding the use case that's impactful for you. Um, and I think second tip is for data scientists. And one thing that I have done in my career which has been, uh, I would say made a fundamental difference on how I got opportunities, on how I could vouch for my projects, is have an elevator pitch for your project. Once you receive the money for your project, once you receive the buy in, your journey doesn't stop there, right? You still need more money, more resources to get the product or uh, the project going. So have an elevator pitch every time you meet your C suite, they're like, how you doing? You should have at least one quick update about your project and how it is going towards the right direction. If you cannot convince your project in that one minute or two minutes, you are anyway not on the right path. You have no idea what you're doing. That's kind of my personal opinion.
Speaker A: I love it. It's so interesting. And this is true of just product management in general, or development of AI solutions or even just corporate innovation. If you can't show a path of quicker wins on the way to the bigger wins, uh, people lose faith, they lose interest, they don't know what's happening. They don't have any evidence that they should continue to fund what you're doing either with their time or their interest or even their dollars.
Speaker B: Yeah, exactly. And you know, the leadership is inherently very busy, right? They're swamped with a lot of things. So how you make these updates interesting for them makes all the difference. Sometimes in the first meeting we are also pumped up. We'll go with this, uh, you know, shiny glossy slides and demos and then we forget to update them. Right. Where are you using their money? So even if you cannot get them on call every month, I think it makes a fundamental difference if you just send them a quick email, a quick update, a side elevator pitch. All of those things help, you know, keep the momentum going so that your product is being discussed in the rooms where you can't be present. And that is very important.
Speaker A: I love it. It's amazing. Uh, so we've talked about, you know, attaching to a real business problem. Have an elevator, uh, pitch, uh, make sure you're, you're providing regular updates or proof points that you're actually investing the money wisely. What else?
Speaker B: So another thing um, definitely starts with is the right education, right? So obviously it depends on where you are in your journey. But if I take Gen AI, um, as a fundamental example, there are a lot of people who know about multiple concepts but they very few who can explain it to you in extremely simple terms. Right. The reason being that there is so much noise right now. People are being inundated with the resources, they are learning from different resources and they don't know what the credible resources. So I would say invest in a trainer or a person who is in the thick and thin of this Geni providers like Microsoft humble bragging here and uh, you know, and call those solutions accurate. Call those people and let them educate your people about this technology. So basically allow them to learn from credible sources. A lot of good resources available out there, right? But just give them a good path so they can extract the best and then do it. Uh, second thing is I think the path from a proof of concept to a production is often unclear, right? And when that is unclear, you cannot get the required funding to keep the project going. Um, and I see this a lot of times that in the first three or four months everyone is using that copilot or that product, uh, that they built and then you lose the momentum. So you have to be extremely clear as part of your AI strategy where your product is going to go and you need to be extremely clear on the scale of the product. You cannot prepare an architecture for 100 users and then have to 10,000 users using it. You're not prepared in terms of cost, you're not prepared in terms of the load, you are going to get latency issues, users are going to get frustrated, your project is going to get shut up, shut down sooner or later. Um, right. So you need to be very clear with all those things. And that is part of your overall AI strategy.
Speaker A: I love that. And I want to come back to AI strategy here in a minute. Uh, but let's talk then a little bit more. So, uh, you've already provided solid gold in the first few minutes here, uh, in terms of just some really crisp recommendations on getting aligned with senior leadership. What are some of the pitfalls? So maybe the things that seem like they're a good idea. But you, you tell your fellow corporate AI executives, don't do that.
Speaker B: Uh, I think there is a, uh, I would say a balance of information that you need to provide your senior leadership. Right. And it's all in the way you present. As data scientists and as someone who's been on the other side, we get so excited about the technology, about the project that we are working on, that we provide them too many details about the technology and completely miss out on the business metrics or how are we going to evaluate our product. Right. While the technology is important, you also need to get on their shoes that when they are talking to the board or when they are talking to their other fellow leaders, what is important for them? What are you selling? And just for an example, let's say if it is an internal copilot, it's very hard to measure something like productivity. But if you can do a back of the napkin kind of a calculation and show them that, uh, you know, a developer would save, let's say 15 minutes or 20 minutes of their time and how does it translate to ultimately the dollars or the roi? It's going to be meaningful, it's going to give them some food for thought. And you are basically projecting that your product is actually a dollar generating product rather than a cost center. Right. So it's a win and win situation. And I've been on the other side, I've done those calculations and I know how hard it is. Uh, but if you can invest in that, that's great. Second thing that I think we miss as a developer is we don't do our research in terms of the opportunity sizing. Like what is the opportunity out there? We focus again too much on technology. But it's important to provide your C suite a lay of the land. What does the overall ecosystem look like? Right. To make Them excited. And for giving an example, I would tell you that I was working on the small business project and we were trying to make an uh, AI prospecting strategy on how to get small business in our ecosystem. And the first thing that I uh, started with, you know, start my presentation with and said, you know what? This is a 33 trillion market. And they were like, what? This is a 33 trillion market. And the discussion went on and on just for that 33 trillion. Right. It got them so excited. So things like that are extremely important. So do your research, read the McKinsey Bain report and get those numbers on there.
Speaker A: Yeah, I like it, I like it a lot. One of the things that uh, we talked about in our, in our last conversation was setting the right expectations with leadership. Can you talk a little bit about that?
Speaker B: Yes. Uh, so this is again that new shiny object syndrome that happens a lot of times. You see a technology and even I am guilty of doing this. When I show the art of possible, I'm like, oh, this can do everything right. But there are things that I know that the technology feels like because you are a developer, you understand what it cannot do. So when you are setting the expectations, instead of saying, okay, I will land on the moon in 10 days, right, you can say that this is what it would look like. My phase one is going to look like this. This is what I can achieve, this is what I cannot achieve. Then my phase two is going to look like this. If all goes well, then the final product is going to look like this and this would be my metrics and I would be here. And that is why that designing a strategy where you almost have product thinking in mind and you are taking a face wise approach and you're educating your uh, leaders about where you are in the journey is extremely important because you are going to fail, right? That is certain. Your strategy is going to change. But how you're modifying it, that update is extremely important for them. So while the technology can solve a lot of things, there are things that it cannot solve. And it's important to be uh, very, I would say, yeah, transparent about it.
Speaker A: I like that. So built into the roadmap or the strategy is, hey, our plan is to go to the moon, but first we need to get off the ground for a couple seconds and if we can do that, then we'll get to 10,000ft. And if we can do that. And also, uh, that's the uh, it ties back to what you said earlier, which is the demonstration of quicker wins. So hey, we're on the path to the moon. Um, and here's how we know that as opposed to we're going to go to the moon, give me $10 million a year for the next 10 years and just, we'll, we'll let you know when we get there. And that, that just doesn't work.
Speaker B: Yeah. And I advise my customers all the time. Right. If you can give me a matrix of low risk, high reward use cases, let's start with that. And if you are someone who is just starting on a gen AI journey, what are those high reward use cases? And you cannot just design them, uh, just like that. You just cannot give me verbally. You need to do that whiteboarding session with your, uh, product managers, with your business stakeholders, with your data scientists and almost have a matrix. Right. Almost like a four quadrant. And then put those use cases in those four quadrants where, okay, low risk, low reward, high risk, low reward with all those permutations and decide what those top two or three use cases are. Start with that, get comfortable failure, learn from those, and then go to high risk, high reward.
Speaker A: These days I like that. Yeah. Get some training wheels first. Right?
Speaker B: Yeah, exactly.
Speaker C: Yeah.
Speaker A: How does that tie into AI strategy then? So I feel like what you just described is a component of kind of AI strategy, the risk and reward, uh, two by two or, uh, matrix. But what else would you advise in terms of high level, kind of how to set up a strategy that you can get buy in with senior leadership?
Speaker B: Yes. And, um, there's one thing that I'm observing and which I honestly am very proud to see. All the CXOs are now getting educated on. They need to resolve their data strategy before they go to their AI strategy. And I'm so glad that people are learning about that. And this was fundamentally missing when I started my career six or seven years back. So if you are someone who is on this Gen AI journey, I would highly, uh, recommend you to have a data strategy first. So start with that and then go to your AI strategy. Because AI is not just about gen AI. Right. That could be your machine learning products as well. That could be a recommendation. It could be anything that is impactful for you and your organization. So start with your data strategy, see where those gaps are. And when I say data strategy, I don't mean boil the ocean. Right. Get everything to cloud or clean the entire, uh, database. That's not what I mean. Um, that is why when you take the approach of starting with the use cases and then determining, okay, what are the right data assets for that, then Figure out how that data is available to you. Is it available in the right form? If the data quality is too poor, your use case might be gold, but your product is not going to be gold. It's not going to serve your purpose. Purpose, Right. So I would say figure out the use cases, map the data sets, talk to your data people, ensure the data is of, uh, is in the right format, the right quality. If you need to do the migration, this is the time. And then get onto your Genai, uh, bandwagon.
Speaker A: It's really interesting because the, you know, the kind of the overall way to think about innovation or product generally teams over index on feasibility too early and they spend so much time on feasibility when they're actually testing the feasibility of something that might not even be desirable. I think that actually one of the big differences between kind of that more traditional lean startup or product thinking mindset, uh, and lean AI is you actually do have to do some feasibility upfront. Like you just said, do we even have the data? Is the data clean? Do we have an AI engineer who actually understands what's possible and what's not? And so we found ourselves in our work at the lean startup company with our clients who are doing lean AI is actually bringing them back and saying, no, you actually need to do more feasibility analysis. Enough, right? Not, not six years of analysis paralysis, but enough to say, yeah, this is in the realm of the possible. And then we can start with. With desirability testing.
Speaker B: Exactly. Well put. And I think that was my second point. Right on the talent. That is also something that is often underpinned, especially when it comes to gen AI application. People think that AI Eng and data scientists are enough. But the reality is if you're trying to build an app, you also need app developers, you need. NET developers and people completely miss that. Uh, and later on when it's time to integrate with your legacy application, they realize, okay, who is going to do this integration? Where are my Java developers? Where are my. NET developers? And that's why realizing the right talent is also important. Uh, and that's part of your feasibility analysis.
Speaker A: Yeah, that's a great point. Yeah. Do we have the right people here? And if it's going to take us two years, what does that mean for our roadmap? You know, if it's going to take us two years to get the right people here, what does that mean for our roadmap tomorrow? One of the things in our, in our previous conversation that I thought was just great is you talked about the art of the possible. And the not possible. And I thought that was really good. What do you, can you maybe explain for our audience what that means?
Speaker B: Yes. So when I say the art of possible and they are not possible, specifically in cases of Gen AI, right. When you start working on a Gen AI product, uh, there is this productivity factor. The first low risk, high reward use case that usually people think about is let's build an internal copilot that could be to empower your business users or that could be just to empower general users on getting the right information at the right time, um, pretty quickly. Now the problem is once that is done, uh, most of the people think, okay, now all our problems are going to solve. Our employees have the right information now. They can do work in 30 seconds. Um, and you know, it's, we are going to be in our highly productive, uh, setting that we have been. But you have to realize that this is a journey. Uh, just because you gave them a copilot doesn't mean that all your problems are solved. First thing is, did you provide them all the data that was necessary? Second, is someone updating the data? Are they taking care of those updated Confluence pages? Do you already have that encompassed in your product or data strategy? Um, and third thing is, while that makes them productive and of course it's going to give you tangible benefits, it is possible that might take three, six or 12 months to see those changes, to see those productivity benefits. Um, it is not important that you're going to see it on day one. There is also an evaluation component to this. Sometimes even when we, with the right technology, with the right mindset, with the right talent, uh, the product might not do as well as we imagined. Right. There were some last minute changes like user preferences changed the data change the data got outdated, whatever it was, and suddenly uh, my model or my application is hallucinating more than I could imagine. Right. Because maybe there were no robust evaluations that were done right prior to launching the product in production. So because of all of those unexpected changes, your product might not give you the tangible benefits. And that's why it is important to invest in the evaluation. Have your SMEs, uh, invest. You are not taking their jobs. They are not losing their jobs. Rather we are using their expertise to build this golden product, uh, that, that you're working on. So, uh, yeah, I think I went on two or three different tangents there, but that was my. I uh, wanted to make sure that, you know, we get the end message of what is not possible.
Speaker C: Hi, this is Jonathan Burfield. Senior Director at the Lean Startup company. If you're a corporate executive looking to drive broad adoption of the AI centric products you're developing with far less wasted time and investment, we invite you to join us for a free 45 minute one on one consultation where we'll help you understand key tactics for validating use cases early in the development journey, to identify the optimal sequence for rapidly driving to scale and to navigate the potholes that have tripped up other leaders in similar roles. Head over to LeanStartup Co contact AI to reserve your spot. You'll find this link in the show notes, but don't wait. Spaces fill up fast and we don't want you to miss out again. That's LeanStartup Co contact AI. Uh, let's make successful incubation and scaling of AI centric products a reality for your team today.
Speaker A: Yeah, that's great. I mean, and I guess that's important not just for senior leadership, but also for just, you know, employees in general.
Speaker B: Exactly. Employees in general. You need to have those power testers, right, like power users before you launch the product. And that's why I say like when you are, even when you are in a competitive, ah, space where you're just trying to launch something to get yourself on a map, um, I still say slow down and maybe spend two or three good months to evaluate your product, see with your power users how the product is doing, ask the same questions 30 different times maybe and make sure that your model is ready to answer anything and everything and then launch it to a wider audience. Uh, right, And I am a big fan of face wise approach. I've said it before, I'll say it again. Uh, please take the phase wise approach when you're launching your product.
Speaker A: I love it. So let's, let's go back to AI strategy. So I would say, you know, you gave some really good advice on, you know, identify some use cases that you think might be interesting. Then go look at your data, make sure you have a data strategy that supports, uh, your ability to actually work on those use cases in the first place. And then you can think about AI strategy. How do you work with senior executives to identify use cases in the first place? Because one of the things that we've seen time and time again is that uh, there is no, uh, there are no constraints on the use cases. It's just let's use AI for everything. Which of course is not a strategy. A strategy is mostly about what you're not going to do. So how do you, how do you Recommend that our listeners work with the C Suite to identify where to, you know, which types of use cases to consider and which type of use cases to maybe put on the side for the, for the time being.
Speaker B: Yeah, uh, that's a great question. And there are two or three different approaches that I have taken in the past which have, uh, worked successfully for me. So the first thing is, when you're trying to identify the use case, you need to do your homework. First, you cannot go to the C Suite and say, okay, These are the 15 or 20 use cases that I want to work on. Uh, right. So now the tricky aspect is how to identify the most tangible use case that's going to give you the most reward, put you on a map. But it is also low risk so that you can fail. Right. And that is where, uh, some kind of, and analysis is important. And that framework has to be obviously very specific to the organization you are in. It is important for you to do some kind of business stakeholder interviews, talk to different teams wherever you are working with, understand their pain points. Uh, right. Like let's say if you are in the office of the cmo, their biggest pain point might be, okay, I want to get more users right in the ecosystem, I want to acquire new customers. How do I do that? So pick up that one business problem which, so that you can again tie it back to the business problem. So you need to talk with your business users, get that problem in. Second, do some research on whether in your, if you are a larger organization, whether something was done on that use case. Right. And that is the part which a lot of people miss is, uh, if the CMO said, okay, I need to get new customers, you immediately go cook up 10 use cases and go to your, um, C Suite. And the C Suite will question you. Oh yeah, you know, four months back this XYZ person came to me with the solution and then it failed because you didn't do your homework well. So it's important for you to do that homework if you want to get to the right contacts, of course you can ask your C Suite or maybe the senior leaders in the team get in touch with them. Um, and then what you are pitching to the C Suite is, okay, what are you going to do different that is going to work this time? That didn't work in the past. And how is AI going to augment and help you get to those results?
Speaker A: I love that. That is a simple and yet extremely powerful way of explaining, uh, how to, I mean it's just good product thinking, right? What problem are we trying to solve? Uh, what's been tried before so that we can learn from that rather than uh, reinventing the wheel. And then what's our proposal empowered by AI to do something different.
Speaker B: Exactly. And the third thing that I would like to highlight, right, and this is where you need that buy in from your senior leaders is there has to be some kind of change management and that you cannot do as a developer. Right. It has to come from them. Uh, there is resistance when change happens. And especially in case of a technology which is black box for 99% of the users, there is going to be resistance. So whatever you are working on, it is important that your C Suite is 100% on board because they are the ones who would have to do some kind of selling on your behalf. Your solution just can't do it for you.
Speaker A: Are you suggesting that developers are not the best at change management?
Speaker B: Um, in my experience, uh, developers are great at development and they are not the ones who should be responsible for change management. That is what I say. They shouldn't be the one, you know, doing this, leaning, uh, into all of the different dynamics of the organization that should come from senior leadership. And that's why if you are already in that AI first path and AI first thinking and you know, let's innovate, uh, what do you say? Innovate fast, you know, fail faster, kind of a mindset like a startup. You will innovate and you will do that. You know, you will experience that change management faster than ever. So that's why I say I love it.
Speaker A: Uh, and so the uh, the phase wise approach, maybe we could just kind of pick up on that because I think it's, that is actually part of the change management process. Right? Because it's not just a whiz bang. Hey, we've been working on this for five years and we're going to bestow it upon the enterprise. It's phase wise. Hey, I want everyone to know we just got, we were airborne for 10 seconds or hey, I want everybody to know we got to 10,000ft. And then eventually, and then people kind of get updates and they get brought along so that when the moon is reached, they don't say the moon's too weird. I'm not on board, I'm not going to, I'm not going to go there.
Speaker B: Yeah, yeah, that is true. And the biggest mistake I made when I was working on such products is uh, you get the buy in from the business stakeholders, you get them all excited and then what we do is we forget to update them on every step of the way. And once our final product is ready and how as a developer we think is okay, we are going to go to them when our final product is ready. Okay, CEO, this is for your, this is for testing. You know, start testing now. Um, but you know, you didn't make them excited during the entire journey. Journey is exciting. Not the final product. Right. Did you ask for their buying? Did you give them updates? Did you invite them to the C suite meetings? Did you tell them what was happening? Right. Take their recommendations? People love to give advice. That's just how the nature of human is. So invite your business stakeholders to meetings. Even if they cannot advise you on the technology. That is your job. Just ask them, right? What would that idle product look like? What would the idle world look like? Right? What is it that you wouldn't want to see here based on your experience? So those are the things that you could get them excited along the way. Um, and you know what that would help is it's going to develop an ecosystem for you where you are not the only one who's vouching for your product. Let's say there are cuts. The business stakeholders are the ones that are telling your cp, sweet, I want that product ready because I have already sold it to my uh, users. So you know, it's a double win.
Speaker A: I love that. And unfortunately, in today's world, uh, there are stock price events, there's leadership changes, there's reorgs, there are, you know, any number of events where it's in our benefit as leaders to be able to communicate what we're doing so that people see the value. And exactly like you said, say, uh, hey, we've got it. We've got to keep this team. Because they've been regularly updating me and I, I know they're not at the moon yet, but I've seen they've, they've hit the first four milestones and I have confidence and we're excited about it. So I, I think that's great advice. Um, um, let's, this, maybe this is a little bit more of a hardball question. So let's say that a senior leader goes to a conference and they come back and they say, I'm sold on agents. We gotta, we gotta start using agents. Go, hey, AI team, go start, develop, develop some agents and, and just roll them out to the whole company. How do you deal with that?
Speaker B: Um, unfortunately I don't think it's a, uh, one off event these days. I think this is happening There is so much hype around agents that people do want to work on it. The good part is even in agents as a topic we have different levels of complexity, right? Like we have single agents which are uh, which can basically automate your simple tasks and then you have your multi agents which are for your complicated workflows. So when such an event happens, and this is where if you have already done your pre work of identifying the use cases, things that you would like to do in the future, things that you are doing in the future, and maybe things that you've already accomplished with Genai, but you want to take one step further, this is a good segue to your agentic conversation. Uh, where can agents fit in that entire quadrant that I had just decided for my use cases? And once you have that clarity then you can go back to your C suite that okay, these are the use cases that we have identified for agents. Uh, we would start working on them and then you explore the right technology, the right uh, data sets, the right talent. And the problem with obviously building agents is that there is limited technology available right now. Even if it seems that there's a lot of technology that's available, there is very uh, there are very few companies that have developed the right technology for you to take it to production level. Until POC stays, it's all good, right? So you need to be upfront with whatever provider you are choosing. Okay, what is the level of support that you would provide me once I go into production? What can be my scale? What can be the scale of this agentic application? So that uh, exploration phase is also going to take a while for you. So you need to account that in your overall agentic strategy.
Speaker A: It's really interesting. I think implicit in what you just said is if you have the two by two, you know, for risk and reward and you have some uh, strategic criteria of, you know, here are things that should be on the two by two in the first place or not because it's tied to our, you know, certain things are tied to our corporate strategy. Certain things aren't. When somebody comes in and even a C suite, you know, executive comes in and says agents are the way forward, I think we should do agents. You can say maybe let's look at our two by two and let's, let's look at our strategy already. Does that fit? How does that fit? Is that more, would you agree or disagree? That, and, and that uh, and therefore you're not calling their uh, you're not calling their baby ugly or their idea bad. It's just. Okay, interesting. Let's, let's, you know the framework that we developed, um, that lens, let's use that, does that. Is that what we should be working on or not? And that way it makes it a little bit more objective and less subjective and maybe a little less personal.
Speaker B: Exactly. And I don't think any C suite, uh, would disagree to that. Right. Everyone at the end of the day wants the dollars attached to a product. So I'm sure they would honestly appreciate you for this honesty and for doing that kind of due diligence. Uh, um, you know, if you are in the right company and the right team, you would get that required support. So uh, don't be afraid to question, don't be afraid to cross, uh, question, have the discussion, have an honest discussion and understand the technology. Right. So that you can have that healthy and comfortable discussion with them.
Speaker A: Well, we've already covered a lot of ground and just really excellent uh, advice. Uh, is there anything else that you would recommend that you know, a corporate AI executive keep in mind as they're trying to just create value and drive adoption, whether it's for internal users or even external customers to the company?
Speaker B: I think one thing I would say is don't try to escape from this technology. I know there are uh, fears attached to it. There is also excitement attached to it. You um, basically choose that emotion whether you want to get uh, scared of it or you want to embrace it, uh, per se, I would say embrace this technology. There is an AI wave. We are in the middle of it. Uh, I don't think it's a hype anymore. It's been two, three years now that we have been um, in this ah storm and everyone's enjoying it, companies are adopting it, uh, so please embrace it. Take time to understand the technology, um, and just start using it. Don't get scared to do hands on work. Start using it. You would start appreciating it yourself and as if you are a senior leader, I would really appreciate and I would really advise you to have those, some kind of an incubation labs within your organization where people can play with this technology, they can explore um, some new ideas will definitely get generated. Hold hackathons, hold these training sessions and educate your workforce on this next wave of AI.
Speaker A: So Supreet, unfortunately we're almost out of time. This has gone super fast. Amazing, uh, amazing insight so far. If you had to summarize, maybe of of all the things we've talked about, the top three things that you would recommend to a corporate AI Executive to keep in mind to just deliver the most value possible, uh, without wasting time and money. What would those three things be?
Speaker B: Start building today. Build a proof of concept, a proof of value, uh, get educated on um, the technology. This is not going anywhere. Um, it's going to penetrate in your life somewhere or the other. Um, it's already, I think taken over mine, so it's going to take over yours too. Uh, and the thing is, don't be scared to fail. Uh, failure is part of the process. Just learn, embrace, uh, document all your failures, uh, um, and do a broadcast within the organization. And as senior leaders normalize that kind of a culture where if something doesn't work, everyone's comfortable sharing it with each other so that other teams can get excited. Um, and one thing I would also call out, which is very unpopular in organizations, um, but hold knowledge sharing sessions. Ah, sometimes there's so much overlap between the use cases you are working on, but if you hold, uh, knowledge sharing sessions, people can share the super shiny things that they are working on and that would inspire others, uh, to create something new, novel as well. And you, you might not know, you might have your next patent or a research paper, uh, from that development.
Speaker A: You know, you and I understand what we mean by don't be afraid to fail. But when you, when you talk to leaders about failing, you know, it gets, people get nervous and maybe they should, right?
Speaker B: Yeah.
Speaker A: And so, uh, one of the things in our work that we've seen is if you're failing for $10,000, you're really learning. It's not really a failure. But if you spend a hundred million dollars over seven years and that doesn't go well, that's a failure. Let's not, let's just, you know, let's not call that learning. And so, um, how do you think about, you know, uh, knowledge sharing when it comes to sharing learnings, or we tried this, or even maybe giving small amounts of money to people so they can try things out and then if it doesn't go well, it doesn't really matter because they didn't spend that much.
Speaker B: That's a great point. And that's why I said that starting with those low risk, high reward use cases is important because they are going to cost you less and they are going to give you learnings worth a million dollars. Um, and that happens, that has happened with me in the past. So start out with those use cases where there are less regulatory, uh, compliance needs and less people will get impacted in case something goes wrong. Uh, especially if you are a bigger organization and learn from those mistakes. Even if that product is a success, there are things that you would always wish. I wish I could have done this better. So there is always a, uh, you know, a brighter side and another side to the story. So that is what I mean when I say, uh, by failure. And if by failure. Okay. One of the most common failures I've seen is that the adoption slows down over time. Right? That for me is a failure. If after three months no one's using your product, what went wrong. So that when you're launching the product next time, you know, not what not to do, um, and you can improve and iterate and be better. And second is if you are taking a phase wise approach, um, the chances are less that you would be at $300,000 and $400,000 and your product is failing, um, because you learn from each phase and you adopt it and you were agile enough, uh, to build something that is worth, uh, for your customers, more than done. External.
Speaker A: I like it. And in the, in. You know, of course, in the lean startup world, we would call that metered funding. So that, that phase wise approach is don't fund the first phase where it's just, we need to get up in the air for a hundred million dollars, fund that for $10,000. Uh, and then if you can, if you can get into, into the air, then what's the next tranche and the next tranche. So I appreciate that advice. Thank you so much for your time today. It's been an absolute pleasure having you on the show.
Speaker B: Yeah, it was great chatting with you. Thank you.
Speaker A: The Lean AI Podcast is brought to you by the Lean Startup Company. To find out more about our Lean AI approach to generating more AI wins with far less wasted time and investment, including our training workshops, pilot programs and full implementation offerings, Visit us at leanstartup.co Search the Lean AI Podcasts in Apple Podcasts, Spotify or wherever you get your podcasts so you don't miss, miss a future episode. On behalf of our entire team here at the Lean Startup Company, thank you for listening and sharing with your colleagues and friends. If you found this episode insightful.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.