your-ceo-thinks-ai-working-your-team-doesnt-heres-why-annan-patel-launchpod-logrocket === [00:00:00] Annan, welcome to the show, man. Good to see you again. Yeah, you too. Excited to be here There is kind of a delta between where I think different parts of the organizations often feel like AI is at from a capabilities standpoint, and executives maybe think one thing, the people on the ground maybe think slightly differently and, and, uh, there's some reasons behind that, and, you know, your company did some good research on this, so wanna dive into that 'cause I think it's kinda something everyone is thinking about but hasn't been able to put their finger on. But first, before we do any of that, can you give us the TLDR background, how'd you get to where you are, all that kinda good stuff? Like a lot of product managers, I got in this profession from a different role, not a lot of people directly get into PM roles, but I've been doing this for about 15, 16 years now, I guess. It's always scary to say it out loud. But I've started off actually in ad tech, in a more consumer-oriented role. One of the things I tell pretty much everybody is that I, I very much consider myself a generalist. I've worked in a lot of different delivery models, a lot of different [00:01:00] industries, B2B, B2C, B2B2C. In the last several years, though, I really kinda settled into the enterprise B2B space. Um, was at a company called WP Engine working with really large enterprises on their managed WordPress sites. Did have a stint at a small startup, but over the last few years I've been at a company called Tricentis, which is the leader in enterprise testing, really working with some of the largest organizations in the world and ensuring that they ship quality software and achieve the kind of outcomes for their customers that we're all hoping to. Nice. I mean, so you've kinda been throughout everything from healthcare to, well, I think I heard WP Engine handles some ridiculous percent of the world's traffic at one point. Yeah, I think WP Engine alone is something like 6% of all internet traffic, 'cause WordPress is something like 45%. That's a lunatic percent of traffic. I think everyone knows Google sees a ton of traffic and all that, but there's these few companies that sit in the world that no one realizes quite how much traffic actually flows through them. I always like to point that out 'cause I think it's a really interesting fact. But the thing that you brought up when we first met, which I've seen just a ton of this, and I think we can all relate, is this kind [00:02:00] of idea that across teams and across layers of management, there seem to be different views on maybe how capable some of these AI models are or how advanced the use cases are, or maybe the reach of trust. I don't know, the trust radius, I don't know the term for it. But you talk to an engineer who's shipping code every day, and then you talk to the CEO of that company, I'd wager they have different views on how much the AI is actually doing autonomously. Is that an accurate summation to kinda kick it off? Yeah, I think that's absolutely right. You know, there's some nuance to it. I think, you know, look, we're all in software, I'd imagine most of your audience is in software and probably having the exact same thoughts and conversations we're about to have as it relates to their businesses, especially if they're in the SAS world like I am. A lot of the power of AI, and, and one of the interesting things about AI, right, is that we can use it as consumers, we can see the value of it in our day-to-day, and then we can think about how this works inside of our organizations. And a lot of the times when these, I think the model providers, AI companies are starting to talk to executives, they're pitching a vision. Mm-hmm. And that vision, I think, is based on a reality that they're building towards. [00:03:00] I think a lot of the times, though, as the practical application of sort of driving those outcomes inside of these organizations is not as straightforward as these executives might think. And I don't think it's because anyone has ill intent or, or is discounting what their people are saying or- doing. I think sometimes there's just a bit of a disconnect with understanding the way work is done in the organizations we're in. And I think a lot of the times what you see is the way that these AI companies are talking to executives, it's oriented around the same metrics that you and I probably talk to executives around. Mm-hmm. Like, what's the ROI that you're going to receive? How do we improve efficiency? How do we reduce costs? And there's some really compelling data, really compelling information, really compelling storytelling around metrics like that, that I think these companies are able to provide. The fundamental difference between what we're seeing with AI and traditional, let's say, SaaS software, or any really software product, is how much this is changing the work of the humans who do the work. The way we've oriented a lot of what we do here at Tricentis is saying the shift that we have to make is we built software historically that people bring their skills and expertise to. They [00:04:00] apply their trade to our software to achieve a business outcome. The shift that is happening is executives are expecting organizations like us to actually drive those business outcomes now instead, but that shift requires more than just plug and play, right? You can't just take what I do today, put AI on top of it and expect it to work. I think that's a lot of what you see, and that's why I think you have some of this disconnect is it's not as straightforward as just adopting a new tool. In some ways, and this is a term we've been using a lot, it's adopting a new operating system. It's a new way of working, and with that you have to really take stock of the way you work, 'cause I think we take for granted a lot of times that when we work with a team of people, people work together a certain way. People develop ceremonies, cultures, practices in the way they work that don't always easily translate to agentic or AI-driven systems. That doesn't mean there's not opportunities for that, but I think that that's a lot of the learnings that we've seen at least, is, is that idea of just this is a plug and play solution. Very rarely does that drive to the kind of business outcome that's promised or expected by those leaders, because the complexity of actually achieving it is a bit more [00:05:00] nuanced. Yeah. I think it's interesting because the theory is document your process, give it to the AI- And let it go. And it seems like more times than not, if you just do that, the outcome has been not quite what we expect. But one of the interesting results of this, I think, has been realizing at a very, very basic level, there was a lot of things we kind of glossed over in what was important in process, or maybe we didn't understand as leaders always how much nuance went into every single thing or process or, or there's a lot of obfuscated detail that is nuanced that's really important. And the higher up you get in the hierarchy, like you said, I don't think there's any malintent here, but it's very easy to... You're operating at a, you know, 10,000, 100,000 foot level. You're not going to see all the little quarter-inch corrections being made on the day-to-day doing any of these things, but they're really important to good outcomes. Absolutely. And, and again, I- I'll go back to what I said earlier, which is I think in some ways I think we take it for granted. When you work with a team for a long time, there's shorthand you develop. We trust that, you know, Sarah knows this about the process, or [00:06:00] Bob just understands that this is how their part plays into this. Oh, remember two years ago when this thing happened? We know to be on the lookout for it next time. And imagine, again, most of your audience who's going through this same challenge or, or seeing a lot of these same things, they're probably in the same place we are, which is recognizing that context has become this incredibly important part of making really robust and strong AI systems. And I don't think it's as straightforward as, yeah, connect it to a repo or, you know, set your SharePoint or whatever it is to be able to have the AI be able to read that. There's a lot of the way that we work that's not well documented, that's not really instrumentalized in a way that can be easily consumed by AI. And so a lot of what these systems have to do is learn from the people who do have that knowledge, who do have that context. Mm-hmm. And so that's really the shift we're seeing, I think, as we see organizations start to move up that maturity curve and try to, to adopt more agentic technologies. I saw an interesting thing. There was-- Someone wrote, basically, "You can never communicate the full breadth of your knowledge." And that seems like a good analog for kind of often what goes on here, is, is you can write a process down, [00:07:00] but in reality, you can probably keep going, and you can write five bullets. Each of those five bullets can probably have five sub-bullets, and you can just keep going. Like, you can just keep explaining and being more detailed. Right. Conversely, though, I think the problem that goes the other way is maybe it's not always fully communicated. Like, why is this transition so important, or why is this the push to kinda move to these AI-based systems, or why is it the push to agentify maybe a process that the executives are pushing? If that's not fully communicated, that kinda causes some of that confusion, too, where people don't maybe realize, like, why are we going this way? And it just feels like a little bit of this isn't working, and it, it's just in vogue, when in reality there's a lot of very strong reasons why- This is important to move forward on. Yeah, you know, it's funny. I think for the longest time, right, there was that old adage, uh, cheap, faster, good, pick two. Right. And I think what AI has shown is that there's potentially a world where you can achieve all three. Let, let we'll find out about cheapness given, given the model costs these days. It seems to vary depending on what model is de rigueur at the time. Right. So that one, I think jury's out on that one, but at the [00:08:00] very least, no, look, I think it comes back to what every leader in every organization is looking for. It's how do I achieve more? How do I drive to higher quality outcomes? And how do I do it as efficiently as possible? I'm gonna use the term jaded, but I don't mean that negatively, but I think jaded is the word I use because it's the first, I would say, real mental model we've all aligned around is with coding assistance. It has been very easy to see the ROI of coding assistance. Someone who's very non-technical, my brother is not a technical person, built a very basic website very quickly because of what he could do with ChatGPT. I think when we can easily grok, well, wait a minute, something that used to maybe take days, even hours, let's say, is now done in minutes, well, it's very easy to realize that ROI. It's really easy to understand, well, this is done much more fast, much cheaper, and it's of a decent enough quality that I'm happy with it. I think as you try to scale that inside of organizations, that's where you really run into these context problems. You know, if you're starting from greenfield, you certainly have a lot more leeway, right? Where we don't have that historical, let's say, business context or needs that need to be [00:09:00] considered. And you know, in the world that I'm in, working with some of the largest enterprises in the world, it's not usually that way, right? They're building on top of or inside of systems that are decades old in some cases. They are beholden to regulatory and, and compliance related concerns, and I think that that mental model we still have though is, well, but this could be done a certain way. We see that in some practices, but when we try to apply it to others, that's where these problems start to run in. And I think what we've all sort of internalized, and I'm of this opinion too, is that these are challenges we need to overcome. They're not necessarily blockers, and so I think that's why you're still seeing the push towards this. You're still seeing people trying to make this work. And I do think there are plenty of examples of organizations that are finding some success here. I think what we've really recognized is- There's sort of a path that we see customers on, and I would say maybe a year or two ago it was a lot of that, well, let me take the coding assistant or the, the AI tool and give it to my people to kind of use in their day to day. And I think that there was some level of value that came with that, but recognizing that there were limitations. [00:10:00] That next stage that I kind of think a lot of organizations are in right now is they're starting to adopt agent to agent protocols where maybe a human and an agent or a series of agents work together to do something. But that kind of grand ambition is the unattended workflow, right? That idea that, hey, I as the human am potentially just setting the goal, I'm setting the outcome I want to achieve. Maybe I'm providing the guardrails or the, the requirements to an extent, and the system is just going to do it. I think we've seen enough to understand that that world is possible, and that's what's driving us to continue down this path, even though, again, the path to get there is not straightforward because of the messy complexities of organizations and frankly, again, the way that people work. I don't know if you read like LinkedIn or a lot of Sub Stack content or any of that. There's almost like theater of AI that goes on where supposedly everyone has replaced their 40 person development team and their 35 person product team and their entire marketing department with agents, and they just got GroqBots or Dots or whatever the new agent tech is running their whole business. But then if you really talk to most of those folks, it's [00:11:00] nowhere close to that. But the converse happens where at LogRocket we've built Session Replay that has agent technology on top that watches all the sessions for you and tells you what's important, and it works with a couple other of your systems to kind of understand that context better. And more recently, one of the things we've done is built it so that it does have the MCP and through the agent system can go and work with your code agent. And to date, we do have several customers that have built out things where a significant portion of their errors are being auto fixed because of this kind of context it's able to add, and their code agents that they've built and all this. But I will tell you, when you talk to them, it's really interesting because across the board what I hear from when they're showing this to us is, "Oh, we're probably actually behind the curve on this. This is not that interesting. You probably see this a lot." And we have to tell them, like, "You guys are advanced. You know, there's only a few companies we see in the market as far as you were doing, ignore LinkedIn." The other piece is it's still only so much of a percent. Like there's a lot of stuff humans still have to do here. So I do wonder if like some of this kind of what people are writing and bragging about and not [00:12:00] lining up with reality causes some of this, you know, almost FOMO I will say, and, and you know, we've talked to a lot of organizations, and I'll, I'll go back to, we work with a lot of really large enterprises, but when we did a lot of the discovery around our agentic QE platform that we're, we're developing- Yeah we also spoke to some of our non-target organizations. And, and typically for us, that is smaller technology companies or smaller organizations, and we are finding a lot of them have moved to these truly unattended or let's say limited human in the loop workflows. Yeah. But I think this comes back to something you said earlier, which is what is the business value of what I'm building on, or what is the business value I'm touching? Probably the most famous example, right, is the Amazon outage that happened a few months ago. Mm-hmm. I never actually saw the figures, but I'd imagine that was tens if not hundreds of millions of dollars in revenue that was lost because of something that happened. It all comes back to that how much risk are you willing to take, and if you're in a position where the opportunity cost of that risk is relatively low, then of course, go for it. You should do all the experimentation. You should treat it as greenfield as you can. That's just not the reality of most major enterprises, right? You sort of touched to this, and I think it's a [00:13:00] pretty interesting point when in some of the organizations that you work with, I think where we see organizations be successful is if they treat this as a greenfield project internally. Maybe they augment one existing process or one way of working. I think where organizations get a bit frustrated is when they try to do too much at once, in my view- Mm-hmm ... because that's when you start to identify, to an extent, the skeletons in the closet. Yeah. And that might be the hidden context, the information that is not as easily documented or easily accessible that is contained within the teams that do the work today. Where we have seen a lot of success is the, let's take one call to jobs to be done or a, a task or whatever it might be. Mm-hmm. Let's think about how an agent augments that, maybe accelerates something that humans would normally do, and then you reallocate that human time to other tasks. And, and I think that that's a pattern we're definitely seeing a lot of success with. Now, I think there's a tremendous amount of value there. At the same time, the reality of that is not always matching the crazy ROI metrics that the executives are getting pitched, right? Yeah. Or these higher level numbers that can't really be achieved unless you really [00:14:00] touch those core critical business processes, which are going to take a bit more investment, a bit more time, and need a bit more care. Yeah. I'm curious if this kinda matches with where you've kinda talked to customers about this too, where we see really a lot of those kind of more advanced capabilities maybe happening and really being implemented. It is not the result of trying to just swing in, maybe giving it access to one SharePoint doc and be like, "Oh, it has context." It's a concerted effort of process change and understanding and really understanding the breadth of what they're changing and looking at it and going, "This is the area this is going to work in. This is the area we're gonna have to still pass to humans." And it's a pretty heavy- investment these companies have taken to make a third of issues they find maybe on their site to be auto-remediated. They put a lot of investment in getting there. I know it's not GAAP standard, CapEx OpEx, but it's almost like you can look at it as a CapEx investment because they know it's going to pay out in efficiency over time. You guys over at Transendus did this whole survey of companies and put out some really interesting [00:15:00] info, and one of them was 80% of companies say they can trust agents with release decisions, but at the same time, like 60% were saying they're definitely releasing untested code, and there seemed to be, you know, back to this kind of lack of alignment and trust on how these decisions are made between maybe executive level and ground level folks. You know, some of that seems to line up pretty well where a lot of times, as we kind of started from, to go full circle, a lot of people don't realize all the nuance that goes into doing these things really, really well. Yeah, and I think that's where you see some of that tension too that can happen inside of organizations, right? Is you're, you're getting a lot of push from your executive leadership team to move faster. They've spent all this money on these AI tools, and they expect to see value. I think we as humans sometimes can be guilty of trying to, what's the word I wanna say here? We're not always measuring the right thing, right? And I do think this is getting better across the industry, but what you saw a lot of, certainly a year ago, was the token maxing, the, "Hey, how many lines of code am I shipping that are okay," right? Yeah. That's the metric to optimize against, and I think that's what you saw a lot of because that was the easiest way to justify the ROI. And I know we've done some [00:16:00] studies on this, and I apologize, I can't recall the metrics offhand, but there's a material percentage of that code that was either rolled back or was untested code that was rolled back or could not actually be shipped to production. And that's, I think, the cost of this, right? Is that moving fast is certainly one metric, but you wanna move fast in the right direction. And I feel like I'm using a lot of cliches here, and I'll use one more. Sometimes you have to slow down to move faster. Yeah. I think what you described is exactly that. If you take a more program-driven approach to implementing these things, you treat it like an investment, like CapEx, you will get that ROI over time. Now, you're not gonna get that ROI year one probably, but the bet is, is that over time you will become more efficient. You will be able to drive to better quality outcomes. But, you know, I think right now what we're seeing is just that lot of, "Hey, we're trying to move fast because we've been told to move fast." And I think we have to acknowledge the reality too, and in our space especially, the number of jobs for testers is going down. The amount of code that's being shipped is higher than ever. That's also something that at least our customers are having to contend with, that I have fewer resources to test the code that's now maybe even in some [00:17:00] cases 10X what my teams were delivering before. There are starting to be tools or AI solutions for quality teams, like the ones we're building, but I would say it's lagging behind where the coding assistants are, and that's also contributing to some of this divergence that you see. To pivot a little bit, we've talked a lot about where we see the diversions on other teams. I'm curious to get back to kind of product teams and, and teams that kind of operate more on, on that sphere. Like, what does adoption look like there and, and how is that kind of playing out internally? So, um, I can answer this a few ways. I'll sort of talk a little bit about what we're doing internally to drive to better outcomes by having our teams adopt AI, and then I can certainly talk more about some of the products that we're building that leverage AI. You know, internally, we are very much moving towards an ADLC model, and we've taken the approach of let's focus on specific use cases. Uh, a very common one is, like, security remediation, right? We know security bugs and defects and security vulnerabilities happen. We know our ability to remediate those quickly is more critical than ever because these models are great at exploiting those things, so we've certainly focused on that as a major area, and that's been a way that we've been able to move fast in one facet [00:18:00] without disrupting our entire development process as we're continuing to improve the overall process. Even within our product organization, you know, we talked about this I think in our first meeting. One of the things I really hate, to be honest, is how AI has led to product management is just vibe coding the thing that I want to build, and I think that can be a neat, nice tool, but that is certainly in my opinion not the best use or the only use of AI. I think AI has been a, a great tool for our product managers to become more efficient in their day-to-day, whether that is helping distill and break down work that's more actionable for teams, whether that's creating documentation and materials to help with things like go to market and really supporting what we do, and so that's a lot of where we're trying to adopt it. I know everybody kind of hates that quote, "The PM is the CEO of the product." I don't believe that That way. But I do believe that that's a mindset, and that kind of mindset to me is what I'm trying to drive within my team of you're not the CEO of the product, but the more you can think like a CEO, I think the more successful we'll be. And we use the cloud, but it's really helped facilitate a lot of the different activities across the [00:19:00] organization that I think are usually would be constrained by what a human can do. That's where we've seen a lot of value. Within our products, we've taken a bit of a different approach, and it kind of builds on what we've talked about earlier. When we launched our first AI products, I think we made the same mistake a lot of companies did, which is we released a tool that uses AI that was supposed to effectively replace what a person did, or a person would use it, and it would replace part of their job. And, you know, we released some tools like that, and we saw some good success at first, and then we didn't really see a lot of long-term adoption. And when we really dug into that, there were two primary areas that, that really stood out. And again, probably won't be a surprise based on the conversation we had earlier, but one was context- Mm-hmm ... and one was augmentation of workflow. And really what it comes down to is, well, okay, what the AI is doing is good, but it maybe solves for sixty percent of what I need. Mm-hmm. Because that remaining forty percent, thirty percent, whatever you wanna call it, comes from information about my business, my team, my industry, the way that we work, the history we've built up over time. And then the other piece is, well, [00:20:00] hey, yeah, this is a good tool, but there's actually just too much friction using it because this is the way our process works. This is the way we operate. That one to me is a bit more interesting because I think what we acknowledge is, is that the context problem is one that needs to be solved and, and there's software solutions certainly in the market. We did a recent acquisition of a context company to help really improve our overall AI products, but the workflow problem's an interesting one. You know, I said earlier that in a lot of ways, the adoption of these new tools, it's like adopting a new operating system, and really what you can't do is just say, "Well, here's a new way of working. Good luck. You know, go do it." You've got to win the hearts and minds of the people that are actually using the tools that are actually responsible for the outcomes. There's a very famous IBM quote, right, from the '70s that is so relevant still today that a computer should not make a management decision because a computer cannot be held accountable. Well, has that ever been more true? The AI is not gonna be held accountable for doing a poor job. It is gonna be the person who's using the AI. And if I am responsible for the outcome and the AI does not fit within the overall [00:21:00] workflow that has the same guardrails and context and let's say compliance related needs that I might have, I'm not gonna inherently trust it. And so what we've seen a lot of and what we're building towards now is we wanna tell that story about this is a new operating system, it's a new way of working, it's a new way of achieving the outcomes that you want. And that story really resonates with executives because again, it hits on the main topics that they're interested in when they're making these types of purchasing decisions. But the way we've gone about building products is how do we make the humans who are using these tools effectively more productive and really what we call expert reviewers, expert users of these products? So rather than just, hey, it's gonna do the work for you, it's gonna do the work and it's gonna give you recommendations. It's gonna rely on you, a human, to help understand, is this right or how can this be made better? And then where we start seeing our ability to drive our customers to this new operating system is by the more we learn about the way that our users are using our agents, for example, how can we recommend that next agentic solution or that next [00:22:00] activity, or let's build the next agent based on what we know our customers are doing next. And what we've been able to do is really start to help our customers automate some pretty complex workflows in a very natural way. So rather than coming in and telling them, "You have to change all these things," it's more of an adjustment that happens over time. And I'm not saying this is the right way to do it, you know, we're still pretty early in this journey. We're seeing some success, but we recognized pretty quickly that we have to take this bottoms-up approach, and we're gonna have to win over the people who are responsible for the work that gets done, and help put them in a position to drive to the outcome that their executives are looking for. Because at the end of the day, executives don't care how much AI was used. They care, did I get to the outcome that I needed? Did we get the quality that we're looking for? How much market cap was added? How much revenue growth was happening? Like, were we able to ship faster? Were we able to do more? Exactly. To, to go way back in our conversation for a second, the, think of like a CEO line, or you're the CEO of the product line. You make a joke that it's not that popular of a line. Everyone hates it. I think everyone hates it kinda like everyone hated Nickelback, but yet they still sold out stadiums everywhere. Someone was buying those [00:23:00] tickets, and I hear that phrase a lot, but I really appreciate your bent to it, which is like, that's probably not true, but the more you think about it as if you were, I do think is really important. If you think about in the product role, how are you solving customer problems? And part of that has to be adoption. That drives velocity, right? That's what we're talking about when we say velocity, is you can move very fast and in the right direction, and that's where To your point of, like, all three, right? You can get fast, good, or cheaper, right? But you need both those el- you need a good vision for where you're going to get there. Yeah. I really like the way you phrased it, 'cause the shift that we've had to drive within our product organization is, I think the impetus for product teams is normally, yep, ship things quickly, validate, and then pivot if needed, right? And the nature of who we work with, again, these large enterprises that, yes, are slow to adopt new technologies, and I'll give them grace because, again, they are defending, in some cases, tens of billions of dollars- ... in revenue, right? And so- Yeah ... that, that cost is very high. And when I think about that CEO mindset, I think a lot of product managers are technologists, right? They wanna build cool things. They wanna build the really cutting-edge product, [00:24:00] and that's certainly something we wanna be doing, too. But I think the reason I really like the CEO analogy personally is because you gotta work with the market you're in. Mm-hmm. And in our case, it is, look, we know if we don't move at the pace our customers move, and I don't mean move at our pace as in slowly, but just more if we're not managing to the pace at which they're willing to adopt, we're gonna get too far ahead, and we're not gonna be the right solution for them, or we're not going to build the right solution for the problem space that they're in. Mm-hmm. And so I do think this is some first principles when it comes to product, right? It comes back to customer empathy, and that's really, I think, more important than ever in the age of AI. Because when you can build very quickly, yes, you can test and validate very quickly, but I don't think it changes product market fit necessarily, right? Like, I think that's still incumbent on strong product people and people in general, again, really understanding their customer, their user, what good looks like, what their incentives are. I think something else we talked about last time we spoke about is I think we often take for granted in software that what we work on is not our customer's universe. It's our universe 'cause we spend so much time. [00:25:00] It's their, like, very small part of one day a week maybe. It's the thing they do after they get their cup of coffee, or it's, like, step eight of 36 in the different tools they might use or, or systems they might touch. And look, this is very self-serving. I'm in product management, but I think this is why it's made product thinking and product skills even more important. You can build the wrong thing really fast, and you can build fast in a way that doesn't work for the market you're trying to serve. What you have to be able to do is understand who are you building for- Mm-hmm ... what are they willing to accept, how are they willing to accept it, even if it's not as fast as you might want. And now we have the power of being able to iterate quickly and update quickly, and that is incredibly valuable, but it doesn't change that hard work that you have to do to understand that you're building the right thing, and then to your point, that they're adopting it in the way that is healthy and sustainable and will, will lead to the business outcomes you're trying to drive. I'm curious to get your take on this 'cause I wonder how much kinda conflict here comes from if you look at what leads to maybe that shipping things that faster than people can absorb it or kinda moving in a way that isn't, to your point- How would you think about it as if you actually [00:26:00] were the CEO? You would want to think about what is going to drive the real business outcome, and that has to involve how are people adopting it? How are people using it? Does it fit in their workflow? Like, all these things that are going to lead to a positive net business outcome. But what often a lot of people hear in line is, think like a CEO, ship faster, do more, more features, features faster, and are we just communicating the wrong incentives? It's the same way if we one day have some super AI and, and we tell it like, "Hey, reduce pollution." There's always the joke about, well, the answer is just get rid of all the humans, and then there's no pollution. If we tell people, "Just move faster and move faster and you can do more with less," are we giving the right incentive to think about... Also, though, think about, like, people need to use this, and enterprises may adopt this slower than maybe small SMBs are moving quickly or, or more agile just 'cause there's less people. And like, that might be some of the conflict here we're running into is on one level People on the ground are seeing, like, you can't do the things you think we can. On the other hand, we're going move fast or else get left behind kind of thing, and those are conflicting. I think you're right. I've been in tech for a while now and, and, you know, I think the, what, late 2000s, early [00:27:00] 2010s in some ways were kind of the golden age of tech, right? Of move fast and break things, uh, done is better than perfect, like all those old quips and adages. And I think we often kinda still hold onto those. And look, I, I think what you said is also a very important caveat. I think the market you're serving, this can make a tremendous impact on. If, if I'm in a consumer business, I actually think velocity is really important, and the reason that it's important is because consumer tastes are very different, consumer needs change much more quickly. You also have a much larger base of people typically to test and validate your ideas against. Even in the SMB space, I agree with you. I think there's an element of velocity that does matter. You're typically working with a lot of organizations. You know, your deal size probably isn't that large, and so your ability to add new features, add new innovations, do things really well, but maybe do a lot of things is how you actually win because there's just not as much share of wallet to go after. But when you're working with enterprises and you're working with really large businesses, there is an element of quality that is incredibly important. You know, look, I'm sure a lot of your listeners work inside of, you know, Fortune 500 companies, Global [00:28:00] 2000 companies, and I guarantee that most of us work with software that is not the most consumer grade software, right? Look, I worked at Microsoft, so I, I say this with love, Outlook is not my favorite email client. Excel and Word are not my favorite tools for word processing and spreadsheets, but there's a tremendous amount of business value that's been built into those tools over time just by the nature of being in these organizations for as long as they've been in them. And while the UXs might not be what I consider the most ideal, I can understand and appreciate the value that these tools have because of their focus and because they are oriented towards a specific type of use case, and that might not lend itself to just deliver a bunch of features as quickly as possible. It might mean deliver things that are just really resilient, work really well, and solve for a specific use case because that's actually where there's more value when you get to a certain level. So you know, I think it just really depends, right, on, on your market, who you're working with, and what your customers are looking for. Yeah, even in the consumer market, right, if you look at Apple, still one of the biggest market cap companies ever, they didn't get there by making 2,500 products [00:29:00] or, or even 100. It was, like, a very tight number of a few things, and as soon as they started diversifying more and more, every CEO who has kind of led a widening in the product has gotten nothing but criticism. Sometimes it's better to do a few things really well. Yeah, I think depends on what you're doing. One thing I will say is I'm, I'm not a one-size-fits-all person at all. I'm not really a framework person either for the same reason, is- No ... if there was a framework, everybody would do it. Well, Annan, I appreciate you coming on and talking about this because I think it really kind of helped spark some interesting questions, and I think people listening are gonna hopefully have a couple things to really think about as they come away. Look, it's an exciting time in software, right? It's a scary time- Yeah ... but it's also a very exciting time. Yeah. It's like a rollercoaster, right? Like, legitimately in that it's thrilling, but also sometimes you're like, "Why did I do this?" right before the dip. But it, it's a blast. So Annan Patel on LinkedIn, Tricentis. Appreciate you coming on, man. Let's stay in touch. I'd love to talk more and see kinda how it all evolves. Thanks for coming on, and hopefully talk again soon. Yeah. Thanks, Jeff. [00:30:00] Absolutely.