In this New Builders conversation, RedMonk’s Kate Holterhoff speaks with Jessie VanderVeen, Global Head of Product Marketing, Agentic AI, Developer Experience and Ali Maaz, Head of WW GTM, Agentic AI and Developer Experience about how AWS is approaching the crowded agentic IDE market. They discuss the importance of customer obsession, AWS’s unique launch strategy for their agentic IDE Kiro, and the lessons learned from integrating AI into developer workflows. Their conversation touches on the balance between speed and reliability in AI development, the evolving definition of developers, and the future of developer workflows with AI, emphasizing the need for authenticity in marketing AI tools to developers.
This is a RedMonk video, sponsored by Amazon.
Links
Transcript
Kate Holterhoff (00:04)
Hello and welcome to this RedMonk New Builders conversation. My name is Kate Holterhoff. I’m a senior analyst at RedMonk and with me today, I have two luminaries from AWS’s agentic AI team. First is Jessie VanderVeen, Global Head of Product Marketing, Agentic AI, Developer Experience. And the second is Ali Maaz, who is the head of WW GTM Agentic AI and Developer Experience. So Jessie and Ali, thanks so much for joining me on this New Builders conversation.
Jessie VanderVeen (00:34)
Thanks for having us.
Ali Maaz (00:34)
Thanks for having us.
Kate Holterhoff (00:35)
so let’s start at a high level. The agentic IDE market is extremely crowded right now. So I’m interested in how that pressure to innovate is looking behind the scenes at AWS.
Ali Maaz (00:45)
I’ll take a first stab at it. Look, the pressure to innovate is always there at Amazon, right? And how we manage this is by staying true to our leadership principle of customer obsession. In this case, our customer is the developer. So day in, day out, Jessie, me, engineering teams, our teams, we try to channel our inner developer, and we ensure that developers are able to harness the crazy momentum of this technology.
That journey starts from our own internal developer teams, by the way. But we have come to realize that in our domain, it’s not just about technology. The pressures are not just about innovation of technology. It brings in secondary and tertiary pressures as well. And that often manifests in changes in processes and cultures that organizations need to go through along with this change.
Therefore, our GTM product engineering and product marketing teams sort of, you know, it has forced us to come very close together. Previously, it was departmental sort of functions, but right now with this pace of innovation, what it has necessitated is that we work very closely together as one team. But, and so as the story has evolved with us, right, our perspective of innovation is more about solving real world problems.
As an example, in 2023, multiple teams internally were looking to upgrade their existing Java applications. And that is a job that everybody has to do, but nobody wants to do. And so that is where sort of AI, because it was early days, was an internal consideration of why not let’s try AI to solve that problem for us. And that’s how Java Transformations was born inside Q Developer.
And so our pressure to innovate comes from internal desire to make things better around us. And ever so often, something as simple as upgrading starts making a lot of sense if it was powered by AI. Jessie, what’s your take?
Jessie VanderVeen (02:38)
Yeah. I mean, I would just echo what you said about customer obsession. think like in this space in particular, developer experience is always paramount. So we’re working backwards from developers, thinking about their needs, listening to developers and getting community feedback, actively engaging in communities to get that feedback. And then translating that into a great product experience. I think right now, I there’s so many tools to choose from out there. And so we obviously need to be really relentless in thinking about
how we think about the developer experience and how do we speak to developers and cater to developers’ needs. I would say one of the biggest things that’s shifted in the last couple years at AWS is we’ve become extremely agile in the way that we ship and market new features. I think Ali just kind of noted this, but we’ve been more in lockstep and integrated in a way that we’ve never been before.
You know working at such a large company with you know Matrix teams and things like that We basically have like a V team that has been stood up to help support this agility and to help us ship faster and market faster as well
Kate Holterhoff (03:44)
wow. I love that word relentless as well. I think that that helps me to I guess, get teed up for my next question here, which is about this tremendous amount of excitement that I’m hearing from the developer community about Kiro in particular. So I suspect many in our audience would be extremely interested in taking a peek.
behind the veil to hear the backstory of Kiro. So can you speak about how the launch and the go-to-market strategy sort of differed from traditional launches at AWS? And by that, mean, why did you decide to move off name, domain, and sort of stand up these new channels for this exciting new product?
Jessie VanderVeen (04:24)
Yeah, I mean the project was really meaningful on a number of levels, I would say. Just having worked in DevTools for a while, it always starts with the developer. You need to win the hearts and minds of developers before you can expand across teams and organizations. Ali, can probably speak more to this, but even in an enterprise sales motion, developers are highly influential in any kind of purchasing decision. So typically a company will run a pilot before making any other long-term commitments, and they’re gonna wanna get feedback from teams.
and developers are going to be using the tools and they’ll be very vocal about it. So I think one of the first things we were thinking about was how do we work backwards from that developer experience. After, know, Kiro’s product was scoped, we were thinking a lot about naming and positioning and, you know, at AWS, when we add AWS or Amazon, that name to a developer tool, it often suggests that it’s for building on AWS.
With an IDE with Kiro, that’s obviously different. You can use Kiro for building on AWS or any other platform. So we wanted to go with a new name and position Kiro’s for building on AWS or for building anywhere. And so that was kind of the mental mode behind the meme and not using AWS or Amazon as the name. We’re just not leading with it, but we obviously, you can use Kiro if you’re building on AWS.
And from there, we wanted to build a special unique developer focused brand, which is totally net new. So that included, you know, a new look and feel. built a new visual brand, style guide, editorial guide. The way we speak to developers on our website, kiro.dev, it’s just different. We lead with a developer first voice. You can kind of see, we’re kind of trying to lead with like a fun and quirky brand. We’re not taking ourselves too seriously.
And we build out a totally different website with that brand. My team and the product team kind of jointly own that now as part of the product and the product led growth engine, which is very different. When we went to market, we took kind of the traditional AWS launch approaches and just turned them upside down. So typically you use specific AWS channels for the launch and many of those are kind of B2B, TDM focused, kind of purchaser focused.
But because we were off AWS channels, we needed to completely like build and operationalize new channels, social channels, community channels, Twitch, Discord, all of that. And basically kind of operating like a startup and building that all and scaling it in a few months. And then when we were thinking about the actual launch motions and the launch activities, we needed to think about, you know, we’re leading with a developer first experience. So what does that mean? Initially, meant,
leading with an authentic organic approach versus kind of broad digital campaigns and media tactics, or positioning Kiro as for building on AWS or not on AWS. So we need to kind of access this very broad developer audience, which included the AWS community. The AWS community was really integral in shaping what Kiro is today and giving feedback. So we obviously wanted to continue to tap into that AWS developer audience.
but we also wanted to tap into a broader audience. so a big part of that was just boots on the ground efforts. you know, had built this product, we had the messaging, we had technical content, but we needed to think about, you know, how do we get in front of key developers in, you know, in different communities and kind of show up. And so part of that was just talking to developers, kind of getting them excited before the launch about what was coming and, you know, hopefully they would.
try out Kiro and talk about it or write about their experiences. And so part of that was once we started to do that and get that initial feedback, we could really see that Kiro was offering something really unique and special. With both vibe coding and spec-driven development, it’s kind of like striking a chord in something that developers were seeing with vibe coding tools. They were seeing some of the challenges. And so we kind of got that excitement and we kind of built.
Based on that feedback, we really felt like we had something special and unique and kind of like took that early feedback and went bigger. So that was kind of like the thinking behind the whole initial launch.
Kate Holterhoff (08:37)
that’s super cool and I appreciate the insider view there because those are the sort of stories that I find so interesting and I feel like we don’t get to hear enough of them. Ali, did you want to say anything about that?
Ali Maaz (08:49)
Plus one to Jessie, right? Like one thing that people sort of don’t grok in this is innovation is not just happening with the technology. Innovation is also happening on how you market a product or how you go to market with the product. So based out of the experiences with Q Developer, we, Jessie and I, and our teams, we realized that this is not about companies and enterprises alone, right? It is really about the end user. And so…
It was a very altruistic sort of desire to make a difference in the day-to-day life of a developer and their development teams. And that persona empathy sort of changes how traditional companies and tech companies like us, we think about going to market. The best go-to market is that our developers love our product. You actually don’t need a go-to market if developers love your product. And so hence a new brand, a new fresh trick, a new UI.
new capabilities, we sort of unleashed our creativity into this product and put our heart and soul into it. So all of that said, it doesn’t mean that traditional go-to-market approaches won’t work or will not do them. It is more a yes and kind of mentality, right? Drive up. Build a product that people love. Make sure that people are aware of that product. And then use your traditional GTM approaches with buyer personas, as Jessie mentioned. So it has been a journey, Kate.
Kate Holterhoff (10:15)
I love that we are able to bring the language of improv to this conversation. Okay, yeah, that makes a lot of sense. And I think it adds to the fun quality of Kiro that I get when I use it personally. I mean, I like the cute ghost. I like the fact that it’s got this sort of playful feel to it. And yeah, so “yes, and…”, awesome.
Jessie VanderVeen (10:38)
I think that’s also just to that point too, is really connecting the dots across the developer journey. So to your point about bringing the ghost into the IDE, like bringing some of the brand elements all the way through and just thinking when you think about developer experience, what does that mean? It’s all of the touch points. So it’s not just marketing is here and the product is here, but how do we kind of connect the dots across that journey? And that was what was, I think, one of the things that we were really looking to kind of relentlessly focus on.
Kate Holterhoff (11:04)
Fantastic. So AWS has been in the AI and agentic dev tool space from early on in the boom, particularly with Q Developer. So I want to talk about some lessons that your early entrance into that market presented, because it’s tough. I get it. So what would you say would be the biggest, like, hell yes, the biggest, oh no, moments that you had when Q hit the real practitioner workflows?
And where your assumptions about how developers would use AI, you know, from code completion to agents, maybe were incorrect. Did you ever have this experience where you were forced to pivot?
Ali Maaz (11:42)
many. So I’ll start, and then Jessie will have her own aha moments. there a lot of battle scars in there, Kate. So let me start, right? Like, everyone started, if you go back to 2023, everyone started from what we today call the smart autocomplete, right? It is a piece of code. You start writing, and it will complete for you, unlike traditional complete. It was more AI-powered autocomplete.
And very early on, if you remember 2023, every company and everybody talked about developer productivity. So from a GTM point of view, we realized, you know, that it’s all about the software development life cycle end to end. And if you were to sort of think about software development life cycle from the paradigm of a supply chain practitioner, right, it is held by the same sort of principles of bottlenecks and, you know, cycle time and the metrics are broadly speed, quality or cost.
Now you can translate that into developer speak and the metrics looks different, but principles don’t change. And so we realized that it is not about developer productivity because if you have somebody code faster, all you’re doing is you’re shifting the bottleneck somewhere else. And so one of the earliest aha moments for all of us was it’s not about developer productivity. Yes, and it’s about development productivity, right?
How can teams and organizations increase their throughput in the most efficient way with a highly reliable and high quality code? And so if you think about the journey of QDeveloper to where Kiro today is, our focus is not just about writing and shipping code faster, it’s about POC planning right from planning and thinking about it to production. And you will see that reflected in our thinking and our message on Kiro as well. The second aha moment sort of
came about was that, know, remember it all started from typing code faster. Very quickly we realized with AI chat interfaces inside the IDE became very popular as developers started to engage. So think about it, right? Like people were typing code and then suddenly back then chat modality was a thing which was not the primary thing and suddenly it became the primary thing to a point where today Q CLI or vibe coding, that is how you code now.
That change, right? Like we forget, it looks like it has been decades. It’s just 24 months. And so there is a massive transformation journey. And so for me, the aha moment was fundamentally the industry has changed how they code and they have done it at a pace that we have never seen before. Jessie, what’s your take on it?
Jessie VanderVeen (14:27)
Yeah, I mean, just in terms of like the Q developer CLI really took off quickly and showed what was possible. we could see we had a lot of internal and external momentum. We had a lot of internal champions that still are using it. And we could see a lot of the impact it had where teams were able to finish really complex projects in a really short period of time. And I think…
Some of the aha moments just kind of building off of, or echoing some of what Ali was saying was that you can’t just apply agents to one aspect of the SDLC, which is like the coding aspect, which is where Q kind of started. You need to apply it to every aspect of software delivery. And, you know, as teams get more familiar with how to work with AI, now they’re trying to figure out how to apply it to their workflows better. So this is something like we’re continuing to see today where like,
I’d say one of the key lessons is like maximizing the potential of AI requires more than just adding it to existing processes. We have to kind of rethink how development work is done. And so I think this is kind of why we see, for example, why some developers or teams are seeing, you know, maybe 10 % productivity gains while others are seeing like three to five X or 10 X improvements because they’re thinking about how development processes.
should evolve as we apply, we learn from how we can apply AI. And I think that the SDLC gates are kind of blurring now with AI, which kind of really requires us to think about that and like what does development mean today and how it’s done. So I think that’s kind of like one of the biggest takeaways we’re seeing is because Q was really applying agents across the entire development lifecycle. And so you could kind of see across the board how AI could kind of transition and kind of help us rethink how development works now. I think we’ll continue to see that as well.
Kate Holterhoff (16:23)
All right, so I am guessing that there is a fair bit of internal tension between the sort of move fast and ship AI features camp and the developers need reliability camp at AWS. So I would be interested in hearing you talk about how you’re addressing this tension. Particularly, I want to hear more about specific feature debates maybe and how those philosophies have clashed.
Ali Maaz (16:49)
That’s a good one. absolutely, your guesses spot on. This is the struggle and dogma of today, practitioners like us, and how we deal with high value judgments. A good example of this conversation is this recent explosion of what we heard or hear called vibe coding. It was very exciting. Developers and even near developers, product managers, people like us, went on the CLI and started doing stuff, and it worked.
But with this early excitement came a lot of tension from the DevOps or release management teams that this is going to cause more or faster chaos downstream. So the tension is not only internal, but we started seeing it with our customers as well. Different personas within customers, the voices echoed and echoed large and huge and high volume. But think about it. That is where we looked at spec-driven development.
This is where Kiro and the ability to provide structure to AI-based coding with speculative and development essentially forcing AI to go through traditional software development processes like requirements, user stories, design patterns, while contextualizing enterprise best practices. It’s the middle ground, right? There is this one echo of, you know, vibe coding is cool. And then there is this other aspect of control, governance, some semblance of what the hell is an LLM doing, right?
That’s the middle ground we sort of came up with spec-driven coding. And if you think about it, it’s the best of both worlds. So the paradoxes or the debates internally almost always, in our view, seed more innovation. It’s not about trade-offs per se all the times. Yes, it is. But sometimes these are opportunities to innovate. And that is the genesis of spec-driven development. That was the problem we were trying to solve. So that’s my take on it, Kate.
Jessie VanderVeen (18:43)
Yeah, and guess just like in terms of how that’s reflected in the way that we’re shipping, think there’s definitely an inherent tension in this space right now. We want to be able to ship things quickly, but we also want to be able to ensure there’s like a remarkable and differentiating developer experience that we’re shipping. And with developers in particular, I you often have one chance to make that first impression. I’d say one example is with Kiro was when we shipped the preview, we kind of…
really held off until we had that remarkable experience and had that developer feedback before we shipped. And we weren’t attached to an event or any sort of traditional AWS launch processes. And so that kind of really, I think, helped us. That kind of paid off. We saw a lot of momentum in the first week. We had over 100,000 developers using Kiro within five days, and there was a lot of organic momentum. We had to implement a wait list at a certain point just because of the demand that we were seeing. And I think one of the
challenges that we’re continuing to deal with, think is just how do we market every single thing that we’re shipping versus telling a story about a few of the things because it’s so hard to break through in the space. So that’s one of the kind of trade-offs that we’re continuing to think about quite often now.
Kate Holterhoff (19:58)
Yeah, I can echo that from RedMonk’s perspective. It is a very frothy market, and it is very loud, my goodness. So trying to cut through, especially in the IDE market, is extremely challenging. And I remember, yeah, when Kiro came out, I felt like there was kind of a news desert for a while. And then when it came out, it was like an explosion. It was very exciting. So yes, I think that your unusual timing, the sort of non-conventional way that you launched it,
Jessie VanderVeen (20:06)
Yes.
Kate Holterhoff (20:27)
At least made a huge impression amongst the developers that I speak to. frankly, in the news cycle, I saw it pretty much everywhere. so it had some good payoff there. OK, so I now want to direct some specific questions at you both. So I’m going to begin with you, Ali. From a go-to-market perspective, what’s the most surprising truth about developer adoption of agentic tools that you have had to confront?
Ali Maaz (20:51)
So is, so let’s start with the premise of the question, developer adoption, right? The fun part of this question is we have started questioning the definition of developer itself. There is an increasing interest from other personas like product managers, UI, UX designers, business analysts, who wouldn’t traditionally develop code, but now have started to do it.
And unlike developers by trade and education, they need a pathway to learn and become builders, right? So there is this education aspect to what we traditionally did not call developer personas. Here we see a lot of interest, but they often need hand-holding and features like spec-driven development for them in a very educational experience. So spec-driven development in a professional environment means something very different for teams, right? But for my son, it means a very different thing because now it’s educational.
and they get to see all the workflows and processes and thinking. And it’s eye opening for a lot of people, including my own team who some of them have not written code, right? But on a more serious part, right? Like while developers have innovated, surprisingly developer tooling space, if you think about it, hasn’t seen the same amount of innovation in the last two decades. Those tools, more or less, other than the visual sort of thing,
There’s not a tectonic shift in technology. And so with this change, what we realized is that developers needed change management too. And so we realized that unlike any other technology where we have seen in the last decade where we are faced with a tech that warranted a tectonic shift in processes and culture. So normally you would have a technology that you introduce, right? And it fits in magically to your existing workflows. And so there’s not much change management required.
But with this one, it was not just about technology and ease of use of technology, but it warranted changes in processes and culture. And we had to think about it from a go-to-market perspective.
In terms of our GTM strategy, we had to shift thinking and we had to build specific programs to help customer drive end user customer success. Now, the notion of customer success, right, in large organizations is typically very different than what this required. And so we sort of toyed with this idea or experimented with this idea of end user adoption. And how can companies like AWS go inside a company environment and drive and help those people drive change management?
And so think about evangelism, but in the context of end user inside a company. And so for us, that surprising truth about developer adoption is that you can’t just ship a piece of technology and forget about it and expect everybody to adapt it and then change its processes, change the processes and change the culture. No, that became part of the GTM strategy. So we had to actively do it and we continue to do it today and customers love it.
Kate Holterhoff (23:46)
Awesome.
Okay, Jessie, what would you say is the number one complaint from developers about AI coding assistants that you’re desperately trying to solve?
Jessie VanderVeen (23:54)
I think one of the challenges, well, I’d say there’s two. One of the challenges is there’s a lot of options out there in terms of tooling. Switching costs are low. So how to think about why they should use one tool over another, that’s kind of thinking about how to differentiate and how to show how, for example, we’re different, we offer something different. And it ties into the second, which is I think so much this year has been about vibe coding.
which is really allow developers to kind of freeform with agents through prompting. But with kind of traditional Vibe coding, gets challenging to sometimes generate production grade code after a certain point your code can just break. And so with Kiro, we’re kind of trying to rethink something. You can start in Vibe code, but you can also use spec driven development with a spec. Kiro will break down a spec down to a design.
tasks and then it’ll just execute on that task. So the spec really helps you to focus on what matters instead of kind of wasting your time with having a backtrack or course correct, which is often one of the challenges with some of the other tools. And I think here will help with complex projects through the spec driven approach versus just kind of prompting along the way. So it helps guide and do some of the complex reasoning upfront.
And you can kind of go on different side quests and have Kiro implement things while you’re doing something else. So think overall, really trying to bring more structure to AI coding workflows, that’s kind of one of the key challenges we’re trying to solve with Kiro’s spec-driven approach and as something like responding to some of the feedback that we’ve seen previously with some of the tools out there.
Kate Holterhoff (25:37)
And I’m going to come at you with another question, Ali. so I want to hear a little bit more about developer workflows as you anticipate they will be in 2027, say. So, you know, maybe even more importantly, what fundamental assumptions about coding are you betting on in the future?
Ali Maaz (25:57)
It started with 2027 and I had a chuckle right? Because nobody knows where 2027 will take us. In our industry, we don’t talk about 2027. We talk about near term, right? But we’re already seeing some patterns, right? Like, and one thing is for sure, right? As Jessie sort of alluded to earlier, today what AI is, is what we call Bolt-on AI. So you have an idea, you have a plugin, right? And you bolt AI into that and it starts to work.
But fundamentally, if you sort of think of AI as the central collaborator of your work, rather than just a bolt on, it necessitates a change in UX. So if you play around with Kiro, you will realize it’s a completely different UX, which optimizes AI to work for the human. And so I see a pattern where all management tools, developer tools, literally the human machine interface.
that UX needs to be redesigned en masse. And you will start seeing that happen. The other thing is, and this is something we internally joke about, is you will start seeing the emergence of new modalities. As technology matures, as agents get more powerful, you will start seeing that people will start using the phrase, best IDE is no IDE at all.
And so we’ve already seen agent proliferation and some interesting use cases in there. And you will start seeing increasingly a lot of agents will start to play a role in software development without an interface. And so by definition, they’ll be asynchronous, they’ll be autonomous, and they’ll be able to do a few tasks. Stay tuned because there might be something interesting around in the next two to three months. We’re also seeing another interesting aspect play out in the
human or culture side of the aisle, right? And what we call or I call workflow convergence, right? Role of product managers, principal engineers, UX designers, front end, back end, full stack developers, data scientists, they’ve all started to converge. By the way, that doesn’t mean that any of those roles is going away. What it means is teams will have to interact and interface very closely in a very collaborative.
AI-powered, AI-managed, native environment, This whole culture that we have in Amazon, we call two pizza teams, right? Like where we sort of work as a startup. A lot of that will start happening. And industry, at a large sort of extent, is not ready for that change because that will necessitate changes in how organizations organize around technology. And so I anticipate that to start happening.
Another thing which I think is already fate-accomplished by now is AI will get pervasive. Dev onboarding, right? Like today, like already there are a few companies who expect when they’re interviewing developers that they’re AI savvy. And the use of AI tooling is actually encouraged. And so we anticipate that the role of developers and their onboarding pathways will continue to change. And there is this weird place where the students of today
will become AI power developers versus a lot of people in the industry are going through that change. right now you see the spectrum and noise and different signals in two to three years that will start to harmonize. And you’ll not see that kind of friction or noise in the system. So it’ll stabilize and mature. But one thing that sort of we often joke about it, Jessie and I, but most importantly, judgment, context, and taste.
They remain human domains, right? AI will write the code, but humans will still decide what’s worth building and whether it’s built right. That is not going away.
Kate Holterhoff (29:53)
fantastic. I like that optimistic view of the future. And you said you didn’t have a crystal ball, and yet here you have these remarkable, prescient thoughts about what is coming down the road Okay, so I am on my final question here. I am going to pick on you both for this one. And let’s get Jessie to weigh in first since she had a little break there. So let’s
assume that we could go back 18 months and you could give yourself one warning about marketing, agentic tools to developers based on all the scar tissue you’ve accumulated, based on everything that you’ve seen, based on your experience launching Kiro, things like that. What would that warning be?
Jessie VanderVeen (30:34)
Yeah, I’d say I think the biggest warning I’d give myself is not to oversell AI as like a magical solution that replaces developer expertise. I don’t think we’ve necessarily done that in our marketing, but you always want to map agents to reality and what they can actually do. So I think that’s a P zero requirement. think we’ve really adapted to make sure that we always incorporate developer feedback in all of our messaging and
And that’s been super helpful also just to kind of make sure that the way we talk about things is really mapping to developer perception and what our tools can actually do. Also, I would say developers don’t want to hear about how AI will make them more productive. don’t think most of us are sitting around thinking about how we can be more productive. I think we just in our days to grow like a little bit better, to feel a little bit more meaningful where we can like focus on deep work and solving problems. So I think…
Kate Holterhoff (31:23)
Yeah.
Jessie VanderVeen (31:32)
You know, just focusing on how tools can help you do that has been the most important. Showing, not telling how AI can work alongside you to amplify your work. It’s not replacing it. And I think developers don’t want to hear about how AI will revolutionize everything. They just want to understand exactly how it fits into their workflow. They want to understand how it handles edge cases. And I think most importantly, they want to know how they can maintain control over the development process. And I think…
One of the key points is just to talk about tools as like sophisticated assistance or tools that enhance developer capabilities, but they’re keeping developers firmly in the driver seat. I think that’s really important. And so I think just doing those things and doing it authentically through a great product and developer experience, those are the kind of key takeaways that we’ve had over the last couple of years.
Kate Holterhoff (32:23)
All right, you cheated a little bit. Let me just point out that’s more than one, but I’ll let it pass. Yeah, no, all good. Okay, Ali, what do you think?
Jessie VanderVeen (32:26)
Sorry.
Ali Maaz (32:30)
I’ll bring us home, right? Like at the end of the day, that one thing is, let’s just be authentic. Let’s not feature sell, right? Let’s just be authentic. And I think Jessie alluded to that. It’s authentic about what technology is and how it is transforming lives. And just be authentic about it. And not get into this rut of competitive, hey, my tool can sort of generate 40 % acceptance rate and mine can generate 45%.
doesn’t help anybody. In fact, we all lose trust. We have lost as an industry in the last 18 months, we have all lost trust. But thankfully, like we have taken the stance that we’ll not get into this. We’ll talk about innovations. We are on a journey as builders. We’re a company of builders for the builders and we should remain true to our
Kate Holterhoff (33:16)
such a great place for us to end on. It has been an absolute pleasure speaking with Jessie, Ali, both of you. This has been extremely insightful and I don’t know, I feel kind of hopeful at the end of this. This is great. So again, my name is Kate Holterhoff. I’m a senior analyst at RedMonk. If you enjoyed this conversation, please like, subscribe, and review this episode on your podcast platform of choice. If you’re watching us on RedMonk’s YouTube channel, please like, subscribe, and engage with us in the comments.
