Lenny's Podcast: Product | Career | Growth
00:26:28 · Lenny Rachitsky, Roman Ugarte
[00:26:28] S1: Wow, that is such a cool example. First of all, someone's about to take the transcript of what you just said, put it into a bot and create their version of this, which is great. On the other hand, I think you guys could sell a template of this bot for a billion dollars. I think could basically use Adam's team strategy for finding the best people and just turn it into a bot, holy moly, democratizing hiring. I want to come back to a few things. Okay. So one is you made this point about unshipping, such a important point I think that people can overlook because AI is not good at telling you what to take out. It's very good at, okay, here's more ideas, here's more stuff. And something that's come up a number of times in the podcast is that's a big space for humans to continue to be very important and valuable is knowing what not to ship and what to cut and what not to do. And so it's so interesting to hear that that's been a big part of the internal evolution from prototype to launches deciding, okay, we need to cut a bunch of stuff. Anything more there? [00:27:34] S0: Yeah. So one thing we talk about internally is for anything that we're working on for Grok Bot, what is the launch post? What is the thing that we would actually tell users? And if it's not- [00:27:47] S1: A launch tweet, I imagine.
00:27:48 · Roman Ugarte
[00:27:48] S0: Launch tweet. And if it's not compelling, maybe we shouldn't be working on it if it's not something that users will directly feel in the product. And to take that even one step further, I think there's this old school software tendency to say things like Grok Bot now has, and when you think of completing that sentence, it would be like a new button to press or it'd be a new dropdown or it'd be a new integration that you can press plus and add. And instead to reframe it as Grok Bot can now, which is I think a much more human way of describing these capabilities. And I think it's forced us to think more in the frame of what are tools and what are capabilities that we can give Grok Bot, not what are new things we can add to the product? Adding things to the product is not the goal, that's not the thing that's going to push this product forward and make it more useful to more people. Making your bots reliably do really impactful work for you behind the scenes in a way that just works and giving them the capabilities to do that, that's what users actually care about. And so I think in the context of unshipping, there have been a lot of Grok Bot now has things that we've realized are actually just capabilities that don't need pixels. Let's kill as many pixels as we can. Those can just be things that your bot manipulates behind the scenes for you and you don't need to directly control. And I think one example of this is the way that many of our competitors, you set up automations or routines is you go into a sidebar, you press plus, you select what the trigger event is, you then select what action it should take after that, and you might describe it in natural language and it's just really clunky. And it means that people don't set up many automations for many things. We certainly have seen this in the coding realm. And so I think what Grok Bot did in response to that was actually you should just define automations in natural language and you should tell your bot, "Remind me that at 8:00 AM every day, please." And then it should just do it and you should never ever have to see that interface of creating an automation. And so that's kind of the decision that we've made and now that's how 99% of automations on the platform built. And I think there are a bunch of other places where we can do things like that.
00:30:03 · Lenny Rachitsky
[00:30:03] S1: So I tweeted about how much I love Grok Bot when it launched and a lot of people replied, they're like, "Wait, can't you just do all this with Codex and Cowork?" And you can. Technically everything, as far as I know, you can do with Grok Bot you can do with the other foundational models, the coding assistants. So let me just ask you this big question. What is it that you think you did that is so different, that made Grok Bot so successful?
00:30:28 · Roman Ugarte
[00:30:28] S0: I think it was two early decisions that at the time definitely did not feel obvious, but in hindsight, I think are critical to what makes Grok Bot work for people. And the first is you should never have to think about local and cloud and where are these workflows running? Does my computer have to be awake? If I kick it off from my phone, does it need to be tethered to my computer back at home? There's so much jank happening right now when people are trying to conceptualize where this runtime lives. And we made a really early decision that this should just all be in the cloud. And if it's in the cloud and it's this persistent colleague that has its own computer, it can do its own work, it has the same state everywhere you interact with it opens up a lot of really amazing opportunities to text your bot, kick it off from your phone. In the future, you should be able to call your bot from anywhere and it should be able to do real work.This is its own entity and it lives separately from your device. And I think that was a very important decision that current products I think haven't made that same decision. And I think it has a bunch of paper cuts as a result of it that users feel every day. I think the second decision was to take that one step further of not only should this be an agent loop that kind of runs in the cloud and you can interact with in various ways, it's actually really important that these bots have their own computer. And part of it is what I described earlier of there are a bunch of tasks that don't have well-supported MCPs and APIs. We as humans don't do our jobs via MCPs and APIs. We use a computer and we click on pixels and we kind of type things and input boxes and it's very important that your bot has those baseline capabilities as well. But even to go one step further, I think we're in a really weird moment right now that I think we're going to look back on and be like, I'm surprised that this is the way that a lot of people worked with AI, where you're onboarding these super intelligent new colleagues, these AI bots, and you're asking them to share the same computer that you have. It's crazy. If you were onboarding someone to your team and you said, "It's your first day, I'm going to onboard you.
00:32:41 · Roman Ugarte, Lenny Rachitsky
You don't have your own laptop, you're going to sit next to me, we're going to share this laptop forever and constantly trip over each other. You're going to have access to my credentials, I'm going to have access to your credentials." There's a good reason why that's not the way people operate. And I think bots and these kind of AI colleagues of the future will also need a way to onboard them that's somewhat similar and we've tried to push the product in that direction. [00:33:10] S1: That is so funny. Why do you think the other companies didn't do this? My guess is they were building off of their existing coding assistant platform and approach, and this was a pretty big shift.
00:33:24 · Roman Ugarte
[00:33:24] S0: I think a lot of it comes down to starting from scratch and how freeing that is. And we felt that ourselves where a lot of the primitives in Grok Bot we had attempted or we had built in other ways, cloud infrastructure we built for coding agents. The way that you could maybe name agents and talk to them as discrete entities, it's a pattern that we're also seeing for developers bringing specific named agents into Slack. But instead of trying to retrofit those concepts into some new surface or into an existing surface, which I think would've been the strong default I think for many companies, we decided to start from scratch and we decided to just try to get these things really right for general knowledge work, which is a new audience. And then second, for the point in time that we're at now where the models are very capable and if you give them the right tools and the right infrastructure, they can do a lot. But a lot of these ideas, these aren't strokes of genius on our part and I think for good reason. I think these are primitives that had already been getting attention and product market fit by other products, the open claws of the world. And I think we took a lot of inspiration from that and tried to productize it into a bit of a tighter surface, something that required a little bit less setup and I think it was more accessible to more people. And so I think our competitors and other tools that have been trying to solve these types of problems, I think we're all seeing the same opportunity. I think we're seeing a lot of the feedback from the market, but I think it's just been hard to act on if you're stuck in the existing paradigm. And if you have a lot of sunk cost in that existing paradigm, it's very painful to create a new thing from scratch. And I think a lot of that is what allowed the product to just work and click for so many people.