What Has to Be True Before You Just Add AI

Lightly edited for clarity. Speakers: Ysi Gonzalez (Vantelira) and Doneyli De Jesus (ClickHouse).

This episode is powered by Vantelira. We go inside a scaling operation, fix the process, and build the system that keeps it running.

Introduction

Ysi: Hello and welcome to The Forward Deployed Operator. I am Ysi, and I am here today with Doneyli De Jesus.

Doneyli is building the AI solutions practice at ClickHouse, with a focus on agents and evals. He'll explain a little bit more about that later. ClickHouse is the real-time database for AI, valued at around 15 billion as of the most recent round, with customers like Anthropic, Meta and Tesla.

Doneyli brings over 20 years of experience in software development and customer technical solutions. He is a keynote speaker with a tech talk under his belt and an active member of several data and AI communities, including the Toronto Machine Learning Society. He is also my husband and my own personal barista. Doneyli, welcome.

Doneyli: Thank you. Thank you for having me. It's a true honor. Honor is an understatement — I would say very, very excited. This was long overdue, and I hope people can feel and listen to the fun that we're having publicly having this conversation, because you're going to get a grip of what it's like: coffee mornings, Saturdays and Sundays at our house. This is it. It's all tech and all process and everything in between.

The competition in this family

Ysi: So I want to touch a little bit on the competitiveness that exists. We've never called it that, but there is a little bit of competition in this family. We've changed jobs at the same time a couple of times. We've had our tech talks actually happen on the same day. And last year we went in and did a hackathon together — which, I have to say, I won. Spoiler alert. And I'll let Doneyli tell the full story.

Doneyli: Yes, definitely. So I think it was one of those things that I truly believe we're going to look back on 10, 20 years from now as the moment when things changed for us in this whole AI revolution that everybody is going through. I think everybody's going to have their own personal moment when they feel like, oh, this is when it changed. And I think we know the exact date, the time and the moment.

This was about a year ago. All these AI models — ChatGPT, Claude, Replit, all this stuff that was coming out — it was not fully the way that it is today, but I was playing around with it a lot. I was spending up until like 1 and 2 in the morning just learning how to use them, burning tokens like a madman, trying to get my head around it: how to use it, how to properly harness it, how to properly take advantage of it.

But it was funny, because at the same time you were also doing the same, right? You were starting your own journey in AI with tools that are more no-code, specifically Replit in your case.

Taking laptops to date night

Doneyli: And then one day — I mean, we're trying to do this thing where we aim for once a week, but as you know: busy parents, young kids, life gets in the way. We try to do date nights on a weekly basis, and it's just a moment for us to get out of the routine of the day-to-day and connect, the two of us. And I proposed, how about we take our laptops to our date night?

Ysi: Yeah. Go ahead — because I remember I had been insisting for a while on your help with developing a solution for a customer I had. I had tried Replit before. I got to a stage where it asked me to pay to see the rest, and I was like, I don't want to pay if I don't understand this thing. So I just dropped it. That was probably back in April last year, or even earlier.

I remember asking you: I need help. I want to build this solution for this customer. They're stuck, and I know how to fix it, and I don't want to fix it with another Excel spreadsheet. And that's when you said, okay, let's use our date night to teach you something.

Doneyli: Yeah, exactly. And it was funny, because we went to a place nearby — we didn't even drive very far, it was like a five-minute drive, because the point was not the place. It was just to have a space where we could sit down with our laptops and build something.

But we actually had a proof of concept that we wanted to test it out on. You were developing this solution for your client. It was, I think, a SKU thing where you wanted to manage the inventory. That's outside my domain, my expertise — but that also was what made it fun. So we had a challenge. And you call it a hackathon. For me it was like a little challenge.

Ysi: It was a hackathon.

Doneyli: No, no, no. Definitely, if you look back, it definitely was a hackathon, because at the end we ended up with something, both of us, that was kind of usable.

The engineer and the domain expert

Doneyli: But I think the cool thing about it is that we both started from different places. We got, quote unquote, to the same place, but with very different results.

Obviously I have a software engineering background. I've been familiar with coding, software architecture, database architecture, all this stuff in the tech stack. But I know nothing about inventory management, logistics, supply chain. I don't know anything about that.

And then you are the opposite. You are the domain expert. You know that domain inside out — you've been there for 20 years. But you are, I would say, more technical than most, so I've got to give you credit on that. I'm not going to sit here and say, oh yeah, she went from nothing to a full-blown app in a night. No. You are very technical for someone with your background, and it's a testament to your smarts. You're an engineer as well. You like to solve problems and figure things out.

Replit vs. Claude Code: two starting points

Doneyli: But the funny thing was how you started in Replit, which is — well, it's not complete no-code, but it has a lot of things already taken care of for you. Whereas I started from Claude Code, which is: hey, here is the terminal, go crazy.

And then you started by actually describing the problem, the end state, what you wanted, the flows, all that stuff. Whereas me, I started with, oh, this is the database architecture that I need. I need to separate users to have their own space. I need the front end to be like that, to use Node.js, TypeScript or whatever — I don't remember. But I came from a very technical point of view.

And then at the end it was funny how both solutions were working. We both ended, I want to say, two and a half hours later — it was like almost three hours. So we both ended up with what I would call a little MVP, a minimum viable product. It worked. Mine was saving records into a database and you could see things in a UI. Perfect.

The domain expert takes apart the engineer's app

Doneyli: But then I showed it to you, and you, as the domain expert — you embody the person who will probably use this — you told me: what is this? This is not... you see, I'm clicking this button, it takes me here, that's unnecessary. I wanted to do this. All that stuff. So that kind of was a hit to my ego. I was like, oh, okay, this is interesting.

And then your solution, on the other hand, was like the perfect flow. It actually looked even better than mine, just visually, and it had the exact flows that you needed. The data was displayed the right way you were expecting it, and it was exactly what you were looking for. On the flip side, yours had, let's just call it, room for improvement in the back end.

Ysi: Right. For sure. Do you want to share what happened in yours at the beginning? Actually, mine was broken in the back end. It couldn't do the proper calculations, because it was not calling the data what it had to be called.

Where the forward deployed operator was born

Ysi: So I think this is the best example. I want people listening to see where the forward deployed operator term was born — how I understood in that moment: wait a second, now I have the power of using my domain expertise, as you said it yourself, and getting this product to a point where my forward deployed engineer can take it and say, oh, this is what you want, let me build the infrastructure and the architecture and everything that really is required in the back end. Because I'm not planning on doing that job. I want to make both our jobs easier and faster and more efficient.

Doneyli: Yeah. I remember one thing specifically on the technical side was that you had multi-tenancy all screwed up. Any user could see all the data and all that stuff. Whereas mine had row separations from the beginning.

But I think it's a good example of what happens when you go out and build a technical solution without speaking to the actual user or the stakeholder, and bridging that gap. It was funny how I fell victim to that, even though in my day-to-day work I tell my clients: no, you need to involve the users early and often, and the domain experts.

That just goes to show that it not only takes a technological challenge, but also human behavioural change, and the understanding of what is this for, who's going to use it. Who's going to sit in front of the computer and click on all the buttons every day.

Why the operator's app shipped and the engineer's didn't

Ysi: And one thing that I have to admit: I will forever call myself the winner of this hackathon, because my product actually went live a couple of months later, and yours stayed behind.

Doneyli: So yeah, that's right. You have proof. You have evidence in the world.

Ysi: That's right. You said it. It's now recorded for everybody to know.

No, seriously — on a serious note, I went ahead and kept iterating, of course with your advice and your help on all of this, and I was able to put that in the customer's hands. They've been using that tool for the past nine, ten months, and we're now phasing it out because we're evolving to a different tool that has a lot more features that they now need, because they have been able to grow their business to that level. And that's the beauty of what can happen with AI.

Twenty years in the back end

Ysi: I have questions for you. And one of them — I know the answers to these questions; this is for fun, and because I want to hear you talk about it. I want to take you on that memory lane of all of your accomplishments too.

You went from 20 years in software development, being in the back of the things happening with the customers, to AI engineering now at a 15-billion-dollar company, plus a TEDx and sharing AI communities in Montreal. What pulled you towards the client-facing side of engineering, instead of staying in the back end, heads down coding?

Doneyli: Yeah. I would say that's something that was an itch I had all my career, because of my personality. I like to talk to people. I'm also very curious. I like to understand people's problems and help them.

So I like to divide my career in two parts. The first part was, like you said, very much in the back end: just doing engineering work, solving problems, shipping things. And yeah, there were solutions out there, but I was never put in front to even talk about the solutions. It was someone else who was maybe explaining them.

But then it was evident to me, when I started talking with people who were ahead of me professionally, that they told me: okay, but why are you in the back end? Based on this conversation, you should be a little bit more in the forefront, talking to people, talking to customers, explaining yourself what you're building. So I would say that was one revelation that I had.

Discovering solutions engineering in 2014

Doneyli: And then I remember 2014, I believe, was the year when I first heard the term solutions engineering. Obviously I've always heard engineering — but solutions engineering was this role where you bring your engineering acumen, you don't leave it, you bring it with you, but then you have to be able to explain it to different kinds of people in a customer setting. All the way from a junior analyst who might be contributing to the solution, up to a senior vice president or maybe the CEO of a company, who only wants to understand the high-level details.

So having that ability to go up and down, having that range to explain things to different audiences, is something that has always been really intriguing to me. I'm very passionate about that.

And it also allowed me to develop other kinds of capabilities: better communication skills, how to ask better questions, how to better understand the motivations of people when they're trying to build things. And then over time I was also able to develop how to tell people, or advise people, on the things that they should and shouldn't build.

The ChatGPT moment

Doneyli: And then if you fast forward to now — we had the ChatGPT moment, that seminal moment around November, October 2022. I remember where I was, and: oh my god, this thing feels incredible. Then I immediately put myself right in front of that freight train, so to speak, of AI, and I just wanted to learn as much as I could about it.

And then my role naturally evolved from solutions engineering to, quote unquote, AI solutions engineering, because now the whole job is to try to help organizations, clients, people build solutions with all of this technology that is evolving very rapidly, where every week there's something changing.

So those are the things that truly drive me. I tell people I get bored very, very easily. I cannot sit still. My brain is always thinking about ideas, what things to do. So this actually pairs very nicely with my personality and some of the skills that I believe I have — because you have to keep up with this thing. Like I said, on a daily or weekly basis, things are coming, new changes and all that.

So what are evals?

Ysi: You're saying that things evolve and they're rapidly changing, the AI world. Just talking to you a couple of weeks ago, I heard the term evals. This is a new term that didn't exist probably a year ago — am I right on that? It's the first time I've heard it. Do you want to explain what that is?

Doneyli: Yeah. So that is an area where I've been specializing for the last year. Evals is just short for evaluations. And what that means in the context of AI and AI agents is that you want to be able to review the work that the AI agents are doing.

The challenge is that this is different from traditional software engineering, where you're writing code and the code, every single time you run it — I'm just going to give you a simple example. If you run a function with a formula, that's going to be the same result every single time. It doesn't matter what happens. For the same inputs, it's going to be the same result every single time. So that's what we would call a deterministic type of code.

Models with personalities

Doneyli: But then when you introduce LLMs into the equation, these things — and you've used them a lot — these things have even their own personality. So for the same question, the same input as we call them, they might give you an answer and give me a different answer. And it might be just slightly different.

But sometimes, in customer applications, that truly matters, because you want to be able to produce outputs that are aligned all the way from compliance to style. If you're building a marketing campaign, you want to make sure that things are aligned with your marketing copy and the standards that your company communicates to the outside world. All these things.

But then how do you evaluate that the thing the agents are doing is actually correct? That's where the term evals comes in.

Trust is the word

Ysi: Okay, got it. Thank you so much. And it seems like an important part of this whole thing, because customers are expecting the same output. They're used to deterministic workflows, automations. When somebody talks about an automation or a software that got implemented, they're expecting the same outcome all the time. And I believe this is the way to have them trust what they're getting out of their AI implementation.

Doneyli: Yeah, that's the key word. You nailed it. It's trust. That's the key word. Trust. That's exactly right.

What operators consistently get wrong

Ysi: What do you see operators consistently getting wrong about software and AI?

Doneyli: Interesting. I would say that right now we are in this interesting time where, especially for operators, it seems there are two camps.

The camp of people who think AI can just do anything and everything by giving it a few words, and then it will solve everything on its own without any specific instructions and whatnot. And then the other camp is where you have the more cynical operators, who say, oh no, this thing is not able to do it the way that I do it, or it's not able to replace 100% of the things that we can do.

So there's this dynamic where you have people eagerly adopting it without any sort of control, and then you have the other camp who are very sceptical of it, and then you have some people in the middle.

The operators in the middle are unicorns

Doneyli: But I would say the people in the middle who understand the nuances and can truly harness the existing capabilities of these AI agents, models, whatever you want to call them — those operators, I would say, are like true unicorns still.

The ones who know: yes, these things are not perfect. And yes, if you leave them unattended, or you don't give them enough instructions, they are going to give you a ton of, quote unquote, garbage. That's true. But then if you know exactly the instructions to give them, the context to give them, the information to give them, the systems that you need to connect them to, the workflow and how that workflow should look — I think those operators specifically in the middle are still very rare. But those are the ones I see truly taking advantage of this and becoming a hundred times more productive.

Ysi: And it's so interesting, because that's where I feel like I sit, and the people who call themselves forward deployed operators too. We know how the workflow should react, and we have given enough usage and hours and attention to the AI tools that are out there that we can really put it together.

So would you say that what operators are getting wrong is being at the extremes of this position — either no, that thing doesn't work, or yes, let's just let it do whatever it wants?

Doneyli: Exactly. I think those two extremes are not a good thing. If you are an operator who truly understands the nuances and understands how it works — and you've probably seen this — you can tell almost automatically, by the outputs it's giving you or the way it's behaving, that no, something feels off here. And you know how and when to interject and introduce either more instruction, or maybe stop it.

Knowing what not to build

Doneyli: And one thing that I always keep coming back to is also having this ability to know what not to build and what not to focus on. I think that is the hardest thing, because right now it's so easy to get these things to say, hey, build me this thing, do this for me, do that. And they will gladly go ahead and do it. They're not going to challenge you. They're not going to tell you, you know what, I don't think that's a good idea, I don't think that aligns with your business objectives. They're not going to tell you that.

So then you go into these rabbit holes. I've done it myself just for fun. I have a bunch of pet projects that I've started and they're half-baked, and then I'm like, what am I doing here? I don't need to spend time doing this.

But I think as an operator who has that knowledge of how the business operates, being able to sense: okay, no, no, no, this is not what the output of the agent or the LLM or the AI solution should be — or, no, this is how I want it to behave.

Who should define the evaluation criteria

Doneyli: And this actually ties back again to this whole evaluation framework, because those people are actually in the best position to define what the actual evaluation criteria are that need to be set.

Because me, as a technical person, I can help you set it up on the technical level and help you configure everything. Yeah, I do have some domain knowledge in some areas, and I can go a little bit beyond that. But I would say that people who sit in specific domains are in the best position to define: no, this is how we're going to grade these agents, and this is what a passing grade is going to look like.

And this is another hype word that you're probably going to hear. It's called failure mode, which just means: what are the different ways in which the agent can show errors that you might not be able to catch unless you have something to evaluate them on?

The operator and the engineer together

Ysi: So what I'm hearing is that this is the perfect marriage — the forward deployed operator and the forward deployed engineer. Because we do understand the business, and we can speak to the engineering team with the right terms, but set up the rules so you don't have to try to understand that portion, because that's not your domain.

Every system you fixed became someone else's win. The next one has your name on it. An eight-week live cohort. You solve a real problem inside a real company, ship a working AI system, and leave with the case study, the build and the title: Forward Deployed Operator. Join the waitlist at fdoschool.com. That is fdoschool.com.

LiliBloom makes personalized wooden and acrylic keepsakes out of Montreal. It is my choice for any keepsakes that I want to give to my friends, my family, my customers. First birthday photo boards, cake toppers, first day of school signs, anything in between and anything you need. Every piece is thoughtfully designed and crafted with love, care, and an eye for detail, making your celebrations and your gifts even more special. Find them on Etsy as LiliBloomShop. That's L-I-L-I-B-L-O-O-M-S-H-O-P. LiliBloomShop.

Why we've over-rotated to engineers

Doneyli: Yeah, exactly. And I think that right now, obviously, we've over-rotated to FDEs, because a lot of these AI solutions are coming from software companies, and software companies have engineers. So that's what they're going to put forth.

And in fairness, when you have an FDE, the FDE will typically try to work with the business domain expert on the client side to understand the rules, the workflow, the constraints and all this stuff.

The challenge is that sometimes — well, not sometimes, more often than not — the person on the client side doesn't know exactly what to tell the FDE, because they don't understand the nuances. Like I told you before, they don't understand the nuances of how the LLMs work, how AI is supposed to be harnessed, how you prompt it correctly, even the concept of skills. A bunch of stuff that only when you use it, and when you're deep in it, do you understand how these things operate.

And if you know that, then you are more effective at communicating the requirements to an FDE, instead of just letting the FDE try to figure things out and stitch things together — which would then be leaning towards more a technical-heavy solution, rather than a business-operations-focused solution.

What is ClickHouse?

Ysi: And I want to touch a little bit on the solution side, because I know you are working with ClickHouse, which recently acquired Langfuse — which I don't want to try to explain myself. I understand what both things do and I find them fascinating. Please tell us what ClickHouse is. What is it so good at that makes it valued at 15 billion dollars now?

Doneyli: Yeah, I would say the short answer is that it is the fastest database in the world for doing data processing.

And if you think about what the agents and AI need today, they need access to a lot of data. But before, the bottleneck used to be people. How fast can someone produce a report, or how fast can someone write this line of code? So we, the humans, were the bottleneck — not necessarily the systems underneath.

But now that you have unleashed all these AI agents that don't sleep, that can go on for hours and can do in minutes what used to take days or weeks, then you need a very performant and resilient system that is able to cater to those agents, which are going to come at the system with thousands of requests at any given moment, and the system needs to be able to respond. So I would say, at a high level, that's why ClickHouse is so powerful right now.

And we are squarely on what is being called AI and data infrastructure. So we are slowly becoming critical infrastructure for the AI era, in a way that a lot of the operations companies are going to start building that are agent-first or agent-native will need a system that can handle the speed and the scale of processing data at that level.

Langfuse and AI observability

Doneyli: And then the other solution, which is the one I've been focusing on lately, is called Langfuse, and that is more on what we would call AI observability.

The way that I like to say it to my customers is: you want to know and keep tabs on what your agents are doing. Because everybody's building agents. Everybody is having at least a chatbot, or maybe a bunch of things that are running automatically overnight doing a bunch of things. But when I ask people, do you really know what they're doing?

It feels like when you have kids and you give them free rein to do things. They're home, but you don't know what they're doing because everything is quiet. So it's one of those things where if there's silence, there's danger.

So it's one of those solutions where we monitor what the agents are doing and report that. And it can go from the simplest thing around cost control — to understand how much you're spending on your agents, the number of tokens — all the way down to all the things they're doing in very, very great detail.

Agents that don't sleep

Ysi: You said that the AI agents don't sleep. I have experienced in the past mine trying to send me to rest. And it ties back to their personalities — which, by the way, have you noticed I don't see Claude saying "doodling" or the funny words that it used to be saying all the time? I don't know what happened with that.

Doneyli: Yeah, I don't know. That's a good question. I've got to check the changelog to see when they changed that. But I think it happened after they had their code leaked or something, and everybody saw all the 200-whatever words that they were using. So yeah, it's kind of funny.

Ysi: It lit up my days when I saw it doing those things. So I miss it. I want it back.

"Let's just put AI on that"

Ysi: When you hear somebody saying, let's just put AI on that — what has to be true underneath for that to actually work? What would you say has to be true when an exec says, you know, just add AI into the mix? What has to be set up before?

Doneyli: Well, I would say it's a challenging question, to be honest. I'm not going to claim that I have a perfect answer, because there are a couple of dynamics at play.

The first one is that there's this big FOMO that is happening: if you are a leader of an organization and you are not telling your team to use AI, then it's like, what are you even doing? And then it becomes a question of, well, you're not maximizing all the things you can do to increase productivity, profitability, and all that stuff. So that's one dynamic.

The other dynamic is that I think we've also gotten a little bit more sober when it comes to just deploying AI willy-nilly across any team, any organization. So there needs to be this balance of: yes, we want to allocate a bucket — you can call it either hours or money or whatever that is, like a budget for experimentation — so as to let your teams figure it out. Because a big component of this is people getting enabled and understanding, and, if you remember what we were talking about at the beginning, understanding these nuances of how this thing actually works. And unfortunately, until you use it, it's very hard to even know what to expect.

Ysi: Well, you know, right? I know that you've spent many long nights trying to figure things out. You've run into walls, and then the next morning we are talking: hey, I ran into this wall, then I went into a Claude rabbit hole and this and that. So I know that all of us have experimented a lot to get to the point of getting knowledgeable on what it does.

You need a use case, plain and simple

Doneyli: But then once you pass a threshold — okay, I've experimented with it, I have a little bit of knowledge — I would say, going back to your original question, what needs to be there at the foundation is there needs to be a use case, plain and simple. There needs to be: okay, what is it that we're trying to build?

I think before, I want to say like last year, there was a lot of, no, let's just use AI for anything, just AI first, AI first, AI first. I think now organizations are going back and saying, no, we have these use cases, we have these business problems that we need to solve. Let's figure out how AI can actually help us either accelerate how fast we can build it, increase the opportunities that we have, or maybe explore new ideas or new streams of revenue that we hadn't thought about, because we were limited by human bandwidth, like I said before.

I would say at a base level that's what you need. You need a use case. And then you also need a stakeholder who is motivated to make this happen. And not only make it happen — the stakeholder in a way needs to understand what's going to be the benefit that I'm going to get out of this. So, not to just do AI for the sake of AI.

And I see it a lot. I see a lot of both things. I see a lot of just slapping AI on everything, and those projects typically take months. It just becomes like a science project. Versus the other ones, which are more like: okay, we understand AI is a very powerful tool, but that's what it is. Let's understand where we need to insert it.

But again, that takes nuance and understanding of the process, the workflow, the business. It's so cross-functional that it becomes very hard to control it. And typically you need to start with very small areas of the business to be able to not let it just go out of control.

So I would say at a minimum that's what you need. It's not even anything technical — because yes, I could say you need the data, you need the systems in place, this and that and the other. I think yes, you need that. But if you don't have the precursor I just told you, you can have all the technical components and you're not going to go anywhere.

What has to be true about the data

Ysi: And what would you say is true when there is a use case already, and the team is engaged, and everything is ready to go — we're ready to try to implement AI at whatever level in the company. What has to be true about the data and the processes for that use case to actually have people trust the solution after it's implemented?

Doneyli: Yeah, so the data needs to be definitely vetted and approved by the stakeholders who can say yes, this is the actual source of truth that we are using and that the business trusts.

One of the main problems whenever you're trying to build AI solutions is giving the AI enough context, or the right context. And what that context means is just the right data. So if you're building something that is a customer-facing solution, you need to give it access to your CRM to know who your customers are. You need to give it access maybe to some financial data, because you might want to understand how much every customer is paying, if they're interacting with it.

So sometimes you need data from different places, and if you don't have that data very well organized in a single place, it typically makes it very hard to even build a good, scalable solution.

When the same customer has two names

Ysi: And I want to tap into that example. The CRM, and then the customer spend on the financial side. I've seen it a lot. The customer is called Ysimer González on the CRM. On the financial side she's called G Aragon. How do you manage that?

Doneyli: Yeah. So that goes even beyond just AI. That's a data hygiene issue, and that's been there for decades at this point — especially when you have companies that might have acquired other companies and they inherit systems, and the systems don't necessarily have the same definition of what a customer is and stuff like that. So that's something very typical.

You can use AI to help you build a process that does an intermediate step that consolidates and aligns what those customers are. Like: okay, this is, in truth, Ysi, and this is her customer record in the CRM, and these are all of her records in the finance database, if they happen to be separate.

The main thing to know there is how are you going to define that relationship? You need to give the instructions and the guidance in very great detail to AI on how to achieve that and how to map them together. So if you do that, then yes, definitely it is an accelerant. But I would say that's an area where you need to have practices around how do you integrate that data, and how do you validate that they are the same records and all that.

Ysi: And you said it — we touched on it a little at the beginning. I think that's what a lot of operators get wrong: they don't have these definitions in place, or they don't give these instructions to the agents. That's the extreme of, oh, AI can do anything. Actually, you have to let it know exactly what you want, how you want it, what its name is, where it connects, and all of the things.

The question from the last guest

Ysi: We have a tradition on the show where a previous guest has left a question for you, and you will leave one for the next one. And this is the question that came — also from a guest in solutions, for customers. This was the question that was left for you: tell me about a real failure, an implementation that went sideways from the beginning.

Doneyli: Oh, wow. Okay. That's tough. Yeah, we try to forget our failures, to be honest.

The one thing that I see in common, at least in the failures I've had in terms of implementations, is that going in, you don't think they're going to fail necessarily. Going in, you go in with your plan and how things are going to go, and you try to be as prepared as you can, have all your docs in a row, all that stuff, and anticipate what could happen.

I would say that where it goes wrong — the ones that I've seen fail — is when there's no clear alignment at the beginning with the customer on: okay, when is it that you are going to say that yes, we passed the bar, so we are clear, or this is complete for you?

The ones that typically fail are the ones that are a little bit vague, where we don't have very clear exit criteria, or evaluation criteria as we like to call them. And we just keep adding things, adding things, adding things, and testing things, testing things, and then it becomes a big, big project, much bigger than we anticipated. And then it only takes one thing to go wrong for the client to feel, oh no, this solution is not for me, it's too complicated, this and that.

So the more that you can have that upfront, the more you can also anticipate the things in your product or in your solution that you might need to — I wouldn't call it massage — but present in a different way, so that they're presented in the best way possible to the client, aligning with what they would want to see. That's what I would say on that.

Ysi: Thank you. I really appreciate that answer. Knowing you personally, deeply, I know it takes a lot of vulnerability to talk about failures. So thank you so much for sharing that with us.

The question for the next guest

Ysi: This is the last time I want to talk about that. I'm going to let you think a little bit on the question for the next guest. The person who is going to come next to the seat has already deployed a massive change in the organization they used to be at, by creating a full-on agent that helps them out. What would that question be for them?

Doneyli: Interesting. Okay. I would love to know: what were one or two things that surprised you as you were building this solution, that you were not anticipating? What were those things that you couldn't even see coming, and after you saw them you were like, oh yes, this definitely totally makes sense? So that now, for the next one, you are kind of ready — but you were not anticipating it. So I would say that's my question.

Closing

Ysi: Thank you so much. Thank you for accepting and pushing me to do this. You are one of the most inspiring human beings that I know, and I have the pleasure to grow old with you. I really enjoy our coffees every morning, because, again, this is exactly what we do on Saturdays and Sundays when we go over coffee and talk about AI and processes. So Doneyli, thank you so much.

Doneyli: We could just have a podcast of us talking and that's it.

Ysi: That's it. You're definitely coming back. Get ready. You are in the plan for the next couple of episodes. So get ready.

Doneyli: Yeah. No, I appreciate the invitation. It's a true honor, and I feel like you have this thing where you make people feel comfortable talking. So I do truly appreciate that. Thank you.

Ysi: I mean, if I make you feel comfortable, that's — I won. That's it. Okay. Thank you. Awesome.

That's it for this one. Follow the show so the next episode finds you, and the newsletter goes out every Tuesday — the link is below. See you next time on The Forward Deployed Operator.