← Think AI Podcast
Think AI Podcast
There Is No Magic Wand: What AI Can (And Cannot) Actually Do | Ep. 15 with Dilip Bagrecha (Wishtree)
00:45:56
Loading summary
Transcript44 lines
- [00:00]
A
It's not a magic wand. It will only actually aggravate some of the problems if you don't fix it in the right way. If you don't design it the right way, you are actually creating a lot of technical debt which someone else, after two years, three years, will have to kind of solve it.
- [00:13]
B
Welcome to the Think AI Podcast. Each week we talk about the most exciting AI research tools, case studies and more. I'm your host, Dev Goyer and I've been working behind the scene in data and AI for over 30 years. Whether you are an AI expert, skeptic or something in between, this podcast is for you. Welcome back to the Think AI Podcast. I'm Dev Goyal and my guest today is Dilip Bagrecha, Founder and CEO of Fishtree Technologies. Dilip's career started where a lot of great engineers start at Infosys and then went somewhere that changes how you think forever. He built large scale mission critical financial systems at RBS and at ubs. When you write backend platforms that move real money, you learn very quickly that it usually works is not an acceptable answer. That discipline shows up in everything he has built since. For the last 15 years he has been running Wishtree, a product engineering firm he founded to democratize top tier digital services. Today he is 300 engineers. More than 750 solutions delivered clients in over 40 countries. Wow. And Vishtree's positioning is one of the boldest I have ever seen. AI native by design, agentic by default. And they're not bolting AI into software, they are building autonomous systems that real business workflows in supply chain and in fintech and in healthcare and in distribution works. Here's the line that has made me want to have this conversation. He said by 2026 we will stop talking about AI tools and managing AI teams. This is either the most important sentence in enterprise software right now or it is the most dangerous one. We'll find out soon. Dilip, welcome to the show.
- [02:12]
A
Thank you. Thank you so much, Dave. It's a pleasure being here.
- [02:15]
B
Great. So let's get on with it. I want to pick back right back onto what you said. You built mission critical systems at RBS and ubs. As we said. What did that teach you that most people building AI today has never learned?
- [02:34]
A
Well, it was a different times. We're talking about 2006, 7, 8 period where there was not so much of hype around AI and automation and any system, be it banking or healthcare was expected to work always 100%. Now we see a huge debate good enough. 99.9% is fine. The acceptance criteria has kind of lowered down. Non deterministic behavior of software is accepted as a. This is how AI works. But back in days that was never good enough. I mean, so I work for RBS Royal bank of Scotland into international payments. I was the Swift architect there. And then you cannot expect the Swift system to, you know, work for 99.9% but not work for one or two payments. It is not acceptable. There will be huge escalations, there will be some regulatory penalties and you cannot live in that kind of world. So you have to design systems by default in a way that those Corner cases, those 0.01% use cases are also covered. And I understand why this is the case with AI at the moment. But I also see that this is going to improve. We are not building those kind of use cases yet in enterprise AI. And that is possibly the only reason why you see only 5% of enterprises have adopted AI because you cannot take risks with those kind of use cases. There's anyway there is a room for even 0.01% of error. There will be huge reputational laws. There could be potential lawsuits, regulatory penalties and obviously the businesses at stake. So good enough is not good even in this so called AI fluff or I know a lot of AI world and modern systems have to be deterministic if they want to have an enterprise adoption.
- [04:41]
B
Now that makes total sense. And there's some similarity I have with you. I studied on finance, international finance and then did cfa. I actually worked as a portfolio manager with ABN Amro bank in Bombay.
- [04:58]
A
So I was actually the part of the project where we kind of merged the ABNM. So RBS had acquired ABN Amrobank in 2016.
- [05:08]
B
I remember that.
- [05:09]
A
One of the largest banking deal in history.
- [05:13]
B
Correct. I was there in 95, 96 and then later on it got merged. Yeah, long back. So there was a famous thing about you. You must have seen like Orange Sweet. I know going off track on the script, but I'm just geeking out here. You know, we had this orange suit thing because they only like orange. So you are drinking Capicola, not Coca Cola. A lot of funny things that are happening coming back to this. I think building that discipline now, you know, whether in it in finance, as you mentioned is getting somewhat difficult. AI is not to blame, by the way. So I feel a little bit differently. AI is not to blame, but it's really people getting lazy due to they think AI can do everything. But AI is Merely an improvised tool, just like a calculator, to put a simple analogy there.
- [06:04]
A
So a lot of this legacy issues, challenges, people try to solve it as if AI is a magic wand which will, you know, do some magic and undo a lot of this lazy work done for many, many years. So that's kind of mindset people have. It's not a magic wand. It will only actually aggravate some of the problems if you don't fix it in the right way. If you don't design it the right way, you are actually creating a lot of technical debt which someone else, after two years, three years, will have to kind of solve it. So, so think of it in a way that you design it from day one for all your use cases. Not every again, use case is meant to be solved by AI. You can use it for simple use cases like coding and stuff like that. Why not? But then don't think of it as a magic wand which will, you know, solve all your problems, especially in enterprise. It's a very risky proposition to have.
- [06:50]
B
No, I agree 100% with what you just said. And that leads me to the next question, which is more about managing AI teams, not tools, what we just mentioned. So you said by 2026 we stopped talking about AI tools and start managing AI teams. Unpack that for me. And what actually changes for a leader?
- [07:12]
A
Right, so we are already seeing team compositions where AI agents are being called out as a separate line item or, you know, as a team member. Like suppose I want to deploy a team of 10 people. I put three engineers, humans, two DevOps guys, one UX designer, and three Java agent or AI coding agent. So we are already adding that element of, you know, kind of an entity to an agent now, which means you have to manage AI agents as, in some sense human, as someone whom you need to manage as a leader, as a manager. And for that, I think it's very, very important to understand the pros and cons of an agent or, you know, that entity, the benefits of using them, as well as the limitations of using them. Now, in a pod where you have seven, eight humans and then three, four agents, you have to, you know, play to their potential. For example, some of the tasks that, you know can be definitely be better done by agents because they work. They can work 24, seven, they don't get tired. They can do a lot of this repetitive, monotonous task. You humans will get tired and that will reflect into their quality. But at the same time, you cannot just rely on them for the final output, especially when you're building health care systems or banking systems. And that's where human by design, keeping them in the loop makes sense. Example, the standard use case we all give is coding. Now software development by nature is now most of in most of the companies done by agents. But then most of the companies have also realized that having a human review the code is extremely, extremely important. I mean, we cannot ignore that fact. So you have to design your workflow in a way that you use agents to the truest of their potential by doing a lot of these tasks which are easy to do by an agent, but at the same time have humans in the loop who does. And you work to that potential, towards that potential so that the team, as a complete pod, as a complete team, we are maximizing their output. And as a leader, you have to, in your mindset you have to think like it's an entity. I mean you cannot say, oh, it's a software, you know, it's not a software, it's an agent. It's a real thing now. And you have to stop thinking like it is software or some delta addition to the productivity. No, you'd have to think of it like an entity. And trust me, companies are doing that. I have met few CTOs who, if you see their budgets, they have a separate line item for agents, right? So they put humans, engineer and then AI agents a separate line item to take care of their cost, the token cost and their management cost. So we have already started doing that and I think you have to have that mindset as well to ensure that you use them to the fullest of the capacity, but also knowing the limitation.
- [10:04]
B
So Dilip, I like what you just said. One of the thing in our business also, which is think AI, we created the whole C suite while we do have a human just to see and you know, when we consult our customers, how do we see and what works and what doesn't work and anything more mathematical formulated works great. Like I create a fractional CFO or virtual CFO as an agent I have a full C suite and that works just perfect. So there is an advice, obviously you have to take it or not take it. So advice is okay, it's not that harmful at all. The second is it's balancing the balance sheets, cash flow and other things. We are not giving access to our systems by the way. We are just giving local models access to the statements and things like that. And it matches picture perfect way because it's all mathematical. There is not much to hallucinate with. So there are exam and then we have done some research. I have a patent in AI, so certain things in innovation in research labs is amazing. In AI there are some good use cases. What could be few good use cases in finance which people can start quickly in AI without worrying so much on other things.
- [11:15]
A
I think the best use case is any job which needs analysis like you want to analyze few companies. Example, I do my competitive analysis a lot. Any analysis, analytical job, anything which needs to fetch data from different sources. Example, if you are a public listed company or you are competing with a public listed company, you have a lot of balance sheets available, you can do some market research. Also example, you're competing with a competitor and some of the information is publicly available or through balance sheets. If it's a public listed company, you can use that to also read through a long balance sheet and understand, say, hey, I want to go to, for example, Japanese market. Now what is the revenue mix of this particular company, which is my competitor in some sense, what is the mix of that company in Japanese revenue? Or you know, so this kind of research. A lot of this analysis job can be done from a financial perspective, which I use a lot these days. I'm not a finance guy, I come from computer engineering background. So a lot of times a lot of people ask me certain financial questions and I use AI for my personal usage as well to unclutter things and okay, tell me like a 10 year old kid, what does this term mean? You know, like roce and all those things. So yeah, it helps a lot at the level of the company as well as at the level of personal usage.
- [12:33]
B
Now that makes total sense and I want to pig back on it. Any workflow that you've seen successfully implemented in your side of the world, in your businesses that AI can handle very well, may not be 100%, maybe like 90% successful.
- [12:50]
A
So I can share an example for each. One for our internal usage internally at my company and one for my client. So for internally, we are at the end of a day an AI native technology services company. So we give our services to our clients and for that, the coding is something that we use a lot. We used to have a huge pool of developers, a huge army of developers, but I don't need so many developers. So what we have done is we have implemented a lot of coding agents internally at wishtree and we have workflows where a human is in the loop. There's a technical architect who will review the code, who will see the design, who will see the the system design is in place, or Stuff like that. So I think coding software development as such is an amazing use case. It works really well. It is kind of becoming better and better and better. And trust me, in just a matter of a year, you will see 99% of the code being done by agent. That is actually happening in a lot of companies where you have to write software, ground up, but it will start happening again in companies where you also want to move some legacy code to modern design and modern systems. So yeah, that's an internal use case for clients. Again, I give this as example to most of my clients to try with. The best example is voice agents or chat agents is the easiest, low cost, low entry barrier and you can deploy it in real time. So you have an agent to whom you can use for multiple reasons. Calling collections, ap, AR processes you can use for customer support, customer success, order information. A lot of use cases can be built. And then there's always a human in the loop. So there's a workflow you define where there's a human in the loop. It takes over if the agent is not able to understand or get some context and if the client is not happy or you can understand from the sound and the tonality of the conversation. And then human takes over. And then some use cases where it's not able to get an answer, it just passes on the call to the human. And needless to say, it actually fits into your existing telephony system. For example, if you're using RingCentral or any system, having those AI agents will not change anything for you for your customer. It actually fits into your existing telephony system. So it works really well. And I think that's the best use case for every company, big or small, to start using AI asap.
- [15:23]
B
Now that's a beautiful example. And you know what you were mentioning before, I've talked to executives from large database organizations, one of the top three to companies such as ours, and there's this term now called agentic engineering. And that is just floating very beautifully because you want to have more thinkers who can nurture it and use agentic tools such as cloud code or Codex or anything out there and get a lot of results. And results are we have monitored in our own organization too. It's like 10x. It's not like simple thing, you know, you can. Yeah, my son, you know, he's now 10th grader, 9th grader, he learned agentic code, he built websites for some of the local businesses that do not have websites. So he did it on his own. He went to Yelp he said okay, do they have a website? He went to Lovable initially and then build the site. It's like a two hour thing he made. I don't know how much money he make, I don't ask, but he made good. He doesn't want to share it because he wants to buy his game or anything, which is fine, his money now he made the money. But that gave him a lot of confidence for three things, right? One, finding customers, which you and I struggle. We have come from that background, finding customers, understanding their needs and delivering the solution. So nowhere in this conversation he's mentioning AI, right? And it's not about AI and AI as a tool. What we were talking before and you know the agentic engineering is helping. So you can, let's say subcontract the task to agents, see what the results are. Like you said, see through a human eye if the site is correct, if their things are laying out correctly, if the content is correct, whatever the case may be. And that's beautiful, what you just mentioned those two examples. So I want to pig back on agentic AI and why most agentic AI never ships. You said brilliant. Agent Aki is useless, stuck in the lab. Why does so much of it stays there?
- [17:39]
A
So I, I think so. I'm a computer engineer and I have a very practical and hands on a feel of a lot of things that's happening. A lot of agentic solutions are built because of a FOMO thing rather than having a genuinely good use case. I mean as we say, Bay Area always suffers from fomo, right? Investors, developers, founders, all of us. So we are part of that problem anyway. But a lot of these use cases are actually can be solved through normal software rather than agentic. So you don't need an AI hammer for every nail. That's unfortunately happens to every problem. Now a lot of these problems are solved through Agent Dick, but then these problems cannot live with a non deterministic output. So you will see a lot of demos and prototypes being built. But then when it comes to actually deploying it in production, neither the CTO, nor the CISO nor the tech team will be confident to put it into production. So there's a huge anxiety about the non deterministic behavior. But that's by design, right? That's how AI in some sense at the moment works. So then that's the point of you know, who is going to belt the cat and no one is able to belt the cat. So you see a lot of production, a lot of this, prototypes and demos, not guaranteed to production. And that's why I feel it's a huge waste of time for a lot of people. People are doing it for the sake of FOMO or you know, just trying out, I want to see what's happening in the market and stuff like that. But then when you start looking at solutions with the right design mindset, having the right evaluation tools, the right use case, having human in the loop for important workflows where there are humans which, you know, unlock the deadlock, then it makes sense and then it became, it adds a lot of value, otherwise it becomes a lot of futile exercise for a lot of people.
- [19:34]
B
Yeah, no, you beautifully said that. And a lot of times any new technology, if you remember the days of blockchain and then back then some of the other technologies, it's always goes through the hype. So if you talk to any executive today, the agentic word without them knowing what it really does and the difference between an agent and an agentic which is a process than the, the actual person or actual thing. There's a noun and adjective difference, I mean to say the least. But in any case they are just thinking, oh I do need, like you said, fomo, right? You, I do need it and I use this term called pilot purgatory, right where people just want to keep doing pilots and you know, they don't pay attention to a few things. First, do you have the right data to put AI on? Now some cases you don't need data, but most cases you do need data. Especially in corporate world, enterprise mid sized companies. Do you have the data is your workflow or the process really mapped out, it is done properly. And then third, do you really have the gaps from human where the consistency is an issue because a person changes hand and then your process falls apart and nobody is monitoring it, right? In those particular cases you get the result but then the last leg everyone forgets to look at which is what would you spend on it, what's your token usage, what model you would use, how you would use it. And there's a statistics from MIT, I'm forgetting about 90 or 95% actually projects are failing right at the pilot level and this is the reason why. And there's a lot of educational thing needs to happen on what is AI, why is needed and why it is not needed. So we teach our team, do not embed AI like gen AI in everything. Use AI to build it, but just don't throw AI for the sake of it. If it really has a need like on research, right? Finding things like this Podcasting. When I need to do research, AI is beautiful. It will give me a lot of information. Obviously I'm a writer, I write music too, so I want to write on my own. But AI helps me tremendously. My process is at least three to four times faster now, you know, so, so those kind of good examples that you need to find and then apply towards it, what do you think?
- [21:54]
A
No, absolutely. And as you rightly say, I think the first point, so what I have seen is a lot of these so called AI projects on day one become data projects on actually day two. You don't have the right data in the right form and in the right structure in the right place is in silos. And then suddenly the whole narrative of oh, we need data and then where's the data? And then you start, you know, making data bricks kind of a project for them. So we recently became databricks partner and that's the reason, I mean we were very bullish on some partnerships that we did for a few agentic AI companies. But then you start looking and you know, talking to enterprise clients, you realize there's a lot of historical legacy debt and you know, there's still a lot of structural problems. So then you start solving those plumb problems and then you can build a beautiful castle on top of it. But then before that you need to first do your homework. And that's I think is very, very important.
- [22:49]
B
Your example is perfect. I always say data before AI. 30 years I've been doing data and AI, both AI in 1997, 96, 97 in data for a long time, being Microsoft partner. Couple of my companies, you know, think AI is advanced specialized partner with Microsoft. And the value of data. You just mentioned right plumbing. Getting water before plumbing is not going to happen. You do need to have the right plumbing to get the right pressure in your bucket. So that's the analogy. It's a beautiful analogy. And data has even far more importance today than ever. Because if you want to analyze something, it's still garbage in, garbage out. So if you don't have right data in right shape and right format, AI is not going to do anything.
- [23:35]
A
It's all gibberish and it will hallucinate and it will give more stupid answers. And then the problem is, even if it's a top down approach, CEOs and CTOs want the team to use, if they're not confident on the answers and the output, the team will not have adoption, there will be no adoption in the team. So it's a riskier problem to have right. The team is not using AI, the senior management wants everyone to use AI. And then there's a huge problem and gap between the two.
- [24:06]
B
Very true.
- [24:07]
A
It's extremely important that we do it in the right way.
- [24:10]
B
Absolutely true. So I want to go back to our initial discussion on where to use AI. So software engineering excellence, that's the word been floating around for a long time. And we thrive for it. You know, being the implementers for our clients, that has to happen. That's the reason why they hire us now. In this era where AI writes a lot of code, what's the bar now? And the reason why I'm asking, you already mentioned you are using testing or QA on a human loop and AI to do the coding. And then AI follow the best practices. I think testing and security. I can clearly see the two human side angles that needs to happen. But then there is another aspect, because when we are hiring, there are juniors. Like my son is still so junior. But you know, the ones coming out of college and they are into this AI hype in this AI era, and they're not no longer learning because the mindset is, whatever I need to learn, I'll learn it on the job. I'll go into an AI chat model and start talking to it, and they'll start learning through it. So how do you keep your organization consistent where learning still has a lot more importance? And what do you refuse to let an AI do? Other than what I just mentioned?
- [25:28]
A
I want everyone to understand what they want to do from AI. So the thinking cannot be outsourced to AI. First of all, thinking cannot be given to AI. You have to know what input I am giving, what is the process and what output I'm expecting from AI. But then you just let AI dictate everything. No, it will not work. Now, you're right that a lot of developers, especially freshmen who are coming from colleges, they are struggling. And as a part of our interview process, to be honest, we actually give them a paper and a pen and actually ask them to write algorithms and data structures and all that. So I want to see their thinking, their system design, their technical architecture design and all that before actually giving them an AI tool to, you know, code and stuff like that. So the basics have to be very, very clear in terms of your programming skills, your design thinking, your system design and all. And then we definitely give them all the tools because you cannot let them live in a world where you're not giving them tools. But then you also give them tools with the proper training and that training has to continuously evolve, right? Every three months, every six months. Not even three months. Actually, every month, right. There's a new thing or one thing or the other coming. So there's a separate team in my company that does the research, that keeps an eye on the latest models, on latest tools, technologies. If there's a new inference engine or something new coming up, they keep a tab on what's happening in the market and then they kind of propagate that inside the engineering team. That's how we have a continuous training sessions. We have a group called Technical focus Group that does it, and then they bring those lessons back in the company in terms of educating all our engineers. So it's a continuous learning. Trust me, things are moving so fast that you cannot have a monthly or, you know, quarterly thing. It's like a daily. There's something or the other coming. So we also created a board, we call it TechBytes. And we continuously put stuff because not everyone follows LinkedIn or, you know, what's happening in the market. Developers are working on client projects. They are, I mean, chasing a deadline. I understand all that. Someone will definitely continuously put something on the TechBytes platform. And we kind of keep everyone updated about the latest what's happening in the, in the world of technology in general.
- [27:45]
B
That's really amazing. And, you know, it just brought a memory back. So when I started, as I mentioned, I did finance and CFA and was not a programmer, but a company hired me to set up their operation. I got excited to learn programming. Back in the days it was Biotech Solutions and they come from Palo Alto, from Bay Area, and I belong to a city called Indore. So initially I said, I want to do this. I like what all the other developers are doing, which I help them hire. And they said, you know what, Everyone went through this process, so you need to. And the process was I need to go through the C books and things very short amount of time. Second, I started to write code on paper. Everything written on paper, like all those hives and pointers and everything written on paper. And I need to score 80 out of 100 to get to it. And that was, you know, the computer was sitting right in front and I set up the first power Mac for them and I was itching to go onto it. And they said, no, you have to do this. So they taught me two things. One is the coding. Second is the biotech. I, you know, I'm an engineer, so biology. We come from India, we hated biology. We hated anything related to that science. And I had to learn that and they scored me on that also. And we went through the business side, we went through the technology side, we married that up and then I became a programmer. And I talk about that story a whole lot because these days people say it's not needed and but, but it's needed more than ever because AI is taking over your job. Especially a lot of Indian engineers are from India itself are losing these jobs. So if they are not an SME, they don't understand the subject area well, they're going to lose their job constantly. And like you said 90 or 95% jobs will be outsourced to AI. So then what would you do? You will apply the logic on the business and improve upon that. What's your experience looks like there.
- [29:47]
A
I say this to my team all the time that so we have heard of this term called shift left where a developer is expected to do testing. We heard about shift right where developer is also expected to do DevOps observability and infrastructure. And then I said shift north which means you have to start also learning the domain. Start understanding the context of the project, the domain of the project, the industry of the project, the business model of your client. Because when services company we sometimes do not pay attention to say example business model, what is my client's business model, how is he making money and stuff like that. But then only if the developer understands all of that and have a complete holistic 360 review then we become more and more valuable and then we genuinely become a problem solver or as they call it in modern world now with a lot of hype, forward deployed engineer. Otherwise you just are a developer or you know, are playing a role of a tech team, a technical member team. But then once you get a holistic view and can appreciate other aspects of the whole cycle then you actually become a real forward deployed engineer. And that is where I think the industry is also moving towards because coding is cheap, software is a commodity and that's where you know, problem solving skills of an engineer becomes important.
- [31:09]
B
Now that's, that's amazing. And bringing that culture is absolutely the need of the hour. And that brings me to another point. So you know three pillars of my life I would, I'm a disabled entrepreneur, done multiple things, nine businesses, five miserable failure. So learned a lot. And I don't want to change that process what happened at all because that gave me a lot of learning three things that I pay attention to. So I'm passionate about technology. So tech innovation for sure leadership and motivation which Is like mindset game. Now you're just talking about the leadership thing. So this is kind of an honesty question. When you build vishtri on openness, ambition and honesty. Tell me a time or an example or a use case or story about honesty. Cost you a deal and you did it anyway, meaning you lost the deal but you wanted to do it because of your values.
- [32:05]
A
Well, I think that comes naturally to us. To me, someone who has worked at Infosys and we all carried that feeling very, very with a lot of, you know, it's like, oh, we've worried on our sleeves. Like if you remember, Infosys was the darling of the stock market and everywhere and that tagline was powered by intellect, driven by values. So in that sense, I think values have been something which has been inculcated for a lot of us who are proud ex. Infosys is inculcated and is part of our DNN culture. So when we started working with large enterprises, you are, you know, you are supposed to claim a lot of things, say a lot of things as part of the vendor onboarding. So we have one client, it's a very large financial institution that we work with, based out of Washington D.C. i'll not name the client, but yeah, it's one of the world's largest nonprofit international development agency out of Washington D.C. and then we were supposed to do, I mean, there's a huge vendor onboarding form and we were a small company back in days, it was like around seven, eight years back. And then we were not such a big company. And we were supposed to enter certain information about all those, you know, nice to have things like environment safeguards or certain vendor policies and all. And we were advised by our advisors to kind of bluff or, you know, our way out and put some incorrect information. But then I said no, whatever it is, let's put it very clearly in black and white. Let's not even put it in, you know, a gray area. And then if they want to select us based, they knew that we are a small company. So let's be honest about it and let's not bluff anything just for any one particular team. And initially there was a lot of, I mean, it was not a rejection. But then the vendor team was not too keen to onboard us as a vendor because it was a large institution. But the client, the champion inside the company, the large bank, they appreciated us more, they were honest and we didn't cut corners to just become a vendor, which a lot of companies do. And they convinced the procurement team and created an Exception for a few requirements and then we became a vendor. But then we were very clear that we will not use a shortcut or, you know, bluff our way to become a vendor to such a big institution. We will, we will share whatever is the truth and, and then let's see what happens. And then that also built a solid reputation and a deep relationship with the client. And then we have been working with them for many, many years and that was our biggest breakthrough in the enterprise business. So we were not qualified in the strictest sense, but we were honest. It, the process took longer than expected, but at the end of it, I think it pays off really well and I'm proud that we stood our ground and did the right thing.
- [35:02]
B
No, that's amazing. And you know, that just builds your character, your identity and soul. We have a few examples, but one of the example is where we were working in an environment, client knows us for a long time and they wanted to do something on SAP. We don't do it. So we hired an SAP team and obviously our PMs could not understand the nitty gritty and the depth while we had checks and balances and one thing led to another, the value was not delivered. And he was like, you know, it wasn't delivered, no questions asked. We talked to the team, they said, yeah, this is what has happened. We refunded all the money. Not only we refunded all the money, we found another team. That's a lot of loss at us. We found another team and got it done by them. Absolutely how he wanted it and we didn't do it so that we get more work from him or whatever the case. Maybe he was well connected but then he appreciated. We laid it out transparently. This is what has happened. And since then he is like our biggest referral and a lot of work comes through him. So for good reasons. Yeah, yeah, yeah. So yeah, that, that always gives a lot of value. One of the question I have is if I'm a mid market CEO with no AI team and also a nervous board, what is the very first thing I should do on Monday or what would you advise him if he just sits one on one with you?
- [36:35]
A
First of all, he should look at AI as not just an incremental technology, but look at it as a big transforming disruptive technology. And now I don't think anyone in this world, even the board, will kind of discount it. So it will be easy to convince a lot of people. So he has to think of it as a transformative and disruptive technology and more Importantly, think of building some use cases which he or his team has not built in the past. So when I double click this, a lot of times you have different teams like hr, finance, sales, marketing, ops and you have some use cases that you want to build, you want to automate certain things and you know you have every, every department, every function will have their own list or bank of use cases. But then we all, we all have thought because we always had some restriction, restriction of building software, restriction of restriction of not having an amazing coworker called AI. So I will as a CEO, give all my teams a free hand to be very bold, very expansive and think of amazing use cases which they have never. And it can be crazy sometimes and it will, maybe it is not possible to build them all today or tomorrow, but then think of it as to get bold as much as possible and think of all amazing good to have, nice to have use cases, North Star use cases and note down. So you create your bank. So example, your finance team will have a bank of use cases that you want to build every department. So you have 100, 200 good use cases which then you can prioritize, you can plan, you can plan short term, midterm, long term. Maybe the technology is not ready today, but I can guarantee the technology will be ready tomorrow because everything is happening at such a high speed, at such a fast paced speed. So that's my advice that hey, think of scenarios, think of use cases that you have never thought of in the past that you could not take big bets on. Start thinking that's those use cases and that's where we'll add a lot of value. You will add a lot of business value to it. You can increase your top line, you can reduce your expenses, you can increase your bottom line from all those use cases. Building those, you know, use cases in your company.
- [39:00]
B
Beautifully said. And that has a follow up question. So what is the question you wish clients would ask you, but they never do.
- [39:13]
A
That's a tricky one, I think, I think, I think that I still see, I still see some, in some, in some conversations say they know the limitation. But then because I run a services company, sometimes it's hard to kind of ring fence it in a, in a proper way. Example, a lot of these clients, if you work for large institutions, they always look for a fixed cost quotation from you guys, which is hard to give in an AI context. You don't have, you cannot give a fixed price quotation to a client.
- [39:45]
B
But we are in the same boat. So I feel the pain so that's hard.
- [39:49]
A
Second is you can see a lot of times this hype of outcome based pricing. I am seeing this a lot, that the client expects an outcome based pricing which is okay, okay, if you know the outcome. A lot of times the client doesn't know the outcome. There is no system, there's a big data problem. Data is in silo. And then how can you give them an outcome based pricing when the client themselves do not know what is the outcome expected? So a lot of times, yeah, I mean this life I'll not complain. But yeah, I wish we all had a better sense of what AI can do and not go by what's happening or just a fluff or just feeling of FOMO that someone X has done it and I need to do it. Because the context is very different in every company. The legacy is very different. There's a lot of debt in some companies in terms of tech debt or knowledge debt, which is not anywhere else. So you have to be more realistic of the context that you're working in. And that sometimes is, I feel the science is missing in some cases, in some conversations and we have to kind of explain, educate our client. And it's not that they don't understand because I think they know it, but then they just want to, you know, hope and assume that there's a magic wand. But unfortunately there's no magic wand. And yeah, you have to be very pragmatic about what IT can solve for you and what AI cannot solve for you.
- [41:05]
B
Yeah, you said it. And this is one culture I've seen because we end up working with a lot of mid sized customers. Some of them have the right IT tech leadership so they can ask the right questions. But most cfo, especially when the organizations are run by CFO on the IT part, it becomes scary because the mindset is I think like cfo. So I understand their mindset. But mindset is more about saving money than getting value. Right. So more than outcome, it should be a value driven proposition. And how do you really determine that? And so when I ask my team, and I do that too, what is the definition of done for the client? And it has to be very specific. You can say, oh yeah, the project is completed or this is deployed or whatever, it's pretty generic and abstract. How do you really measure if this is done? Because if they know, then you know and if you know then your team knows and then you are delivering incrementally to get to that level and then it's easier for client to sign off on it. Like AI is such an abstract term because you can, it's like an electricity, you can put it anywhere. Right. So I generally tell my client, do not think about AI. We are the company who think AI, so we think about AI. You don't think about AI. You really think about what value you want to get. Now we can use AI to bring the cost down, but we still need to define the value. And what is the value to you? If this is done through AI, are you ready to take those kind of risks? Because technology is not there yet, it will hallucinate, there are guardrails. We need to think about what are the risks you are willing to take and what are the options if you don't want to take that risk. So most of the times they are only looking at fixed cost and hybrid team engineers who are knowledgeable. This is all good. But are you getting the value? If you are hiring a contractor, can he build a beautiful room? Can you see his work, what kind of work he can deliver at cost and per your liking. If you are not looking into those things, you're gonna get doomed sooner or later.
- [43:13]
A
I think that's a fair point. And a lot of times we feel the client is also on the not the same page. Right. The finance is saying something and the engineering is in a different direction. So you're right. Sometimes you have to put your foot down and tell the truth. And then as I said, there's no magic wand, unfortunately.
- [43:32]
B
Awesome, awesome. That brings me closer to end the show. But I want to give you an opportunity to talk about wishtree, what you do, how you do it and if your potential clients are watching, what do they need to listen about? Wishtree.
- [43:47]
A
Sure. So I run an AI native technology consulting firm focused on mid markets. So we work with the likes of Coupa. Exactly. Blue Ridge, Integral Lab Science. These are all portfolio backed companies, large private equity backed companies and essentially in the SaaS space. So we help them build software products, digital products, we help them with DevOps, cloud data and AI. And we are AWS partners. So we help them with cloud optimization, DevOps infra monitoring, observability and we are also databricks partner which is becoming very, very important as I said for a lot of this AI implementation. And we are backed by a solid engineering team with a solid engineering culture. And that's possibly our secret sauce that has so much of focus on the overall engineering, overall problem solving in the company. And that is possibly the reason why we are able to work with these amazing brands and these amazing logos.
- [44:44]
B
This is Great. So, Dilip, this is the exact conversation I wanted to have with you. This is beautiful. You are one of the few, you're one of the few people building this stuff who will say out loud that most of it never leaves the lab and that autonomy control is a liability, not a feature. And honesty is rare in this market. We just talked about it. It is the reason people should listen to you and for everyone listening, Dilip. He's the founder and CEO of Vishtree Technologies. Found him on LinkedIn and find vishtree@wishtreetech.com if this episode was useful, subscribe to me @thinkai podcast wherever you're listening and send it to the leader in your life who's about to buy an AI or who is an AI skeptic or curious and they want to build an AI agent to fix their data. You will find the answers differently. Please send it over. I will. Thank you, Dave Goyal, and see you on the next one.
- [45:42]
A
Thank you so much, Dave, for having me. It was a pleasure.
- [45:46]
B
Thank you. Dilip, you have been listening to Think AI podcast with Dev. Take one idea from this episode and turn it into action.