Lenny's Podcast: Product | Career | Growth
00:24:01 · Roman Ugarte
[00:24:01] S0: Yes. The recruiting team gave us a lot of great feedback. Anytime the product, especially in the early days, if there was a little bug, we'd get a ping from some folks on the recruiting team. Yeah, I think the main use cases for recruiting that were particularly interesting was first, it was incredibly valuable as a sourcing tool. And I think one thing Adam talked about on the podcast with you, and it's a big part of our hiring philosophy internally, is looking for a job, being on the market is not a precondition for us trying to hire you. And in a lot of ways, the best way to hire is really just look at the biggest problems at the company that need someone to own it or take it to the next level, find out of the total universe of people in the world who would be best and then ruthlessly go after them and try to convince them to join. And this is a lot of the philosophy from the very beginning of the company. And so if that's your mindset, really the best recruiting work stream or workflows to automate are not here are a bunch of resumes, read through them, help sort them. The most useful thing is here's an entire universe of potential people, help match that to this very concrete business problem or this very concrete role that we're recruiting for and help me get in touch with them, help me get coffee with them. Let's just throw everything at it. And so there have been some cases of really kind of unexpected ways of finding top talent that is beyond even just looking on LinkedIn and trying to find interesting people. But who are the co-authors of this paper and the PDF doesn't exist on Google Scholar. It just exists on this conference website. I want you every morning to go to the conference website, download the PDFs. If there are any new ones, you should find every new name that we've not yet tracked. You should add that name to a spreadsheet, you should do research, you should look at everybody at SpaceXAI, see if there's anyone directly connected. If so, you should send them a Slack message asking for an introduction. It's those types of always on sourcing use cases that I think in the past were incredibly manual and now it's the type of thing AI is superhuman at and our team can focus on closing great candidates and getting conversations with great candidates and not pulling these huge lists.
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.