#88: How to accelerate your company's AI adoption with a 5-day hackathon | Gaurav Hardikar (VP Product & Growth @ HomeLight)

Hello, hello, Gaurav, Ben, great to see you both. Likewise. Hello. This is the first time we're having Gaurav on just on his own. Last time he was on a panel and I'm excited to go deeper just with three people instead of four. I think it's a better conversation. I agree. And we get a hundred percent Gaurav and yeah, I'm super excited for this conversation in some context. So I was catching up with Gaurav and it was like three or four weeks ago. And of course, AI made its way into the conversation and I was pretty mind blown what some of the stuff that Gaurav was sharing with me. I was like, okay, I think you should come into the pod and share some of this stuff you're doing for Homelite. And I think there's a lot of companies out there that, you know, they talk about AI using, you know, changing their processes, but very few of them are actually, you know, taking action and really just taking action at all different levels of the organization, right? Like when I caught up with Gaurav, he shared how they're changing their product development process, right? And for all the PMs that he manages. And I also, when I was catching up with him, it was like right after he had organized an ELT hackathon for a week where everyone in the exec team was hacking together. ELT being an executive leadership team, I think is for those who don't know that. So yeah. So it seems like you guys are doing a lot of things and you found a lot of success. So I think a good place to start is like kind of maybe walk me through like kind of that evolution from being a company that like, you know, you keep hearing, you know, there's something in AI to the point of like you actually started incorporating it into the way you do work. Yeah. Yeah. I mean, so I guess I'll start first with like the journey Homelite went through with AI. So I think whenever GPT first came out, it started first with like, how do we apply it into our chat experience? Because Homelite, for everyone who doesn't know, is a company that matches sellers with agents, investors, and lenders. And so we have different products throughout your real estate transaction. And so the first place it started was this chat experience. I'm going to need some context. I need some context too. So I don't know what your official title is now. I know like it's like your responsibility is just I feel like every time we talk, they keep growing and growing. But I feel like are you, you're basically the GM for one of this, the business or like VP? Yeah. What is it? Yes. I was. Yeah, I was. I was doing that. I'm more now VP of product and growth. So I lead product across the entire company and a lot of the growth initiatives. And so there's three different business units. So there's the consumer business, which basically matches clients to agents and investors. And then there's Biba Free Sale, which is our home equity line of business. And then there's Title and Escrow. So the full real estate transaction. So like, you know, when I first, when we've been talking, I've been primarily talking about the consumer side over the last year, it's been actually all three business units and how we can abuse AI across everything. So like, while we started from a very small footprint, what became very clear over time as everyone has is like, hey, how do we reimagine this business and this team from the ground up with AI? And so the hackathon you're talking about was actually more of a, it was primarily an EPD hackathon across all of our engineers, product and designers. We brought them over there all over the Americas. So South America, Central America, and we brought them in San Francisco. And the objective was, if you're rebuilding Helmlight from the ground up today, how do we actually make our systems work 10x faster? That was the purpose. And I think it's important to note that because, I mean, what do you mean by systems? Is it like the processes of how you work together? Is it the tools? Anything? Just think about all of the above. If you want to move 10x faster with shipping product, how do you do it? It wasn't about customer outcomes or anything. It was about how you work. Yes, that was the focus of the hackathon. Because ultimately, customer hackathon, customer outcomes, I think we've always been good about. It's just more like, hey, how do we get to those customer outcomes faster? Which I think if you figure out how to ship faster as well as validate faster, then I think that's going to make everything happen. And I think the second part is, every time we talk about AI, it's always talked about in a greenfield environment, very not so much in a brownfield environment. Helmlight's been around for like 12 plus years. The systems are super old. And so how do we make them work for this new environment? Got it. Okay. And then the other clarification is, given that the focus of this hackathon, this exercise was how can we work and move 10 times faster or 10x the way that we work in our systems? Should I make the assumption that you guys had kind of gotten to a point where you're generally comfortable with the way that you've integrated AI into the actual product experience already? Like the main wins with integrating AI into the user interfaces that your customers use, you guys have felt better about that, which is why the attention shifted to how we work? So yes and no. I think it's adoption always is different by different business units. So I think on the consumer side, yes. I think we were very, very integrated with AI across all of our funnel. Meaning we have voice AI qualifying customers. We're talking hundreds of thousands a month. We have AI analyzing recordings from between real estate agents and clients, providing coaching to the real estate agents as well. These are real product experiences that are live today. So we're very far ahead on one side, but I think not on all the different business units because they just have different use cases. Some of them might be more about automation in the back end or operational excellence from AI rather than end user customer experience. So it's mixed. But I think what was clear to your question, Ben, is that, hey, we have seen enough out of AI that we need to now look at how we move faster in general. So that I think is the realization we have. Yeah, I'm calling that out because it seems, I mean, it makes total sense that this is the progression that's gone for you guys because it sounds like you had a few maybe clear opportunities in the product where when you guys saw this technology come out, your team knew this is going to supercharge this part of the customer experience, this part of the customer experience, etc. And it wasn't until you kind of got to a point where I'm not saying you're done, you're going to keep obviously improving your customer experience. But it wasn't until you got to a point where it felt good enough on that front that your attention started to shift internally to like how you become more AI powered and how you work. And I'm calling that out because I think some teams might have a bit of an inverse take on that. You're totally right. And I think it's because, like I was saying before, we did like tests, right? We validated and we put it into experiences, like you mentioned, that saw real ROI. And then you go back and you start to work the old way. And you're like, what am I doing? I think that's ultimately what happened is that, you know, we're moving so fast on certain initiatives and just shipping features, seeing things real time happen. And then you are like, oh, I got to make a PRD. Wait, what? Like, why? Exactly. And then so you end up challenging every single assumption you've had before. And so that applies to like the product side, design side and engineering side. And so then that's why you're right. That's kind of why it led to that specific realization. Yeah. I mean, I'm super curious to like get into the specifics of how you run the hackathon, you know, like different problems, what came out of it. But maybe before we do that, like what were your expectations? Right. Like, you know, like what do you think was going to be like the before and after? You're going to run this and maybe like to do a little like sneak peek, like kind of what ended up happening. But yeah, I'm super curious to see, like, what goals do you have in mind when you were organizing? Also, it's expensive. It was an expensive event. Right. You had to fly all those people. So I'm sure you had to build a pretty good case for like your budget and stuff. Yeah. I think the so the expectation was, I mean, it's this multifold. One is cultural. Right. So I think that and it's probably the most important here. And I'll say I'll say why. It's like you have an engineering team and design team, product team, whatever that has done all their work pre-AI. And you want to make sure they can actually work in this new new world. So you're not trying like obviously you want all of them to be with you in this transformation. So that takes actual cultural change. It takes like in my opinion, an in-person change. Right. So because you you're trying to sometimes you're trying to teach these concepts or share these concepts and you're doing it individually over like a remote workspace. It's hard, man. It's like you're you're telling an engineer, wait, I can build. Maybe it's not great code, but I can build something similar like this. And they're like, well, no. Right. And then you have to kind of like figure out what works between you guys. What doesn't what do you what are you missing? How do you split the work like all those questions to answer? So cultural is one a big one. I think the second thing is like, yeah, we obviously wanted some things to be actually stripped out of this. Right. And so we did we pre pre work was like, OK, here is like 10 or so projects. Here are like the groups we're going to assign. We picked, you know, CTO and I picked the different groups. And then we said, here's the outcomes we expect. And then after the hackathon ends, how are we going to ship them all? So how did you land on both the projects and the groups like what were like some of the heuristics that that guided the selection process there? Yeah, I think projects we pick the parts of the code or app that have been the most challenging to change. So like the most tech debt? I'd say product debt or tech debt, meaning like if a product ever asks something, then yes, maybe tech debt causes it or the ones that are just like haven't had no love whatsoever for a long time. Like the tech side is fine, but like the UI has gotten cornered to a point where it's like really complicated to evolve it. Yeah. And then and go. Yeah. And so it sounds like a lot of those projects were more around basically like improving surface areas. So then whenever you want to make a change, it's a lot faster, right? Like like a PM can just go in and add a feature, like almost like almost rebuilding the foundation in a way. So you can like very easily start to build. Maybe. Yeah. Let me say it. Let me say it a different way. If there was a large change I ever wanted to make and I ever paused because I thought it's too hard. That's that is a place. And then everyone, every PM has experienced this. This thought was like, oh, I'm like, oh, why is it so hard? Why is it? Oh, it's a blocker. It's just I don't want to touch it right now. I'll touch it in three months. If I've ever thought that that was on the list, OK, because I don't think that should be excuse ever again with AI at all. So that was on the list. You and the CTO together kind of sitting down and looking back on probably some recency bias factoring in here. But what the last six to 12 months of maybe frustrating moments where it's like this should be easier. Yes. So that was that was a very key one. And then the second part was probably key experiences where we felt like we were not seeing like the business outcomes we wanted. So like if we saw, for example, slowness on the homepage or something, we're like, well, why don't we just like rebuild it and see what it looks like? Like why not? Right. So things like that. Yeah. Yeah. Was there also like things that were like, like, you know, quote unquote, like, you know, you said you had like 10 projects where some of those projects do like the way work gets done. Yeah. For example, like, yes. Yeah. Why? Yeah. There's three of them. One was, but they're all they're always related to kind of what I described before. Like, why is it so hard? One of them was like the design design components. How do we make sure we simplify the design system across every app we ever build? Because we have so many different repositories and apps out there. The second one was around how do we like spec or scope projects? So that was more product development that was more what I led. And then the third one is around analytics and BI, meaning like, how do we have an automated analyst in Slack that is basically feeding us reports, rather than having to request that? And how do how do we make that really a tool that people can just like create on their own? Yeah. So what's super interesting here is like, I can almost imagine, like at the end, you basically like have three new tools that you can use in parallel, right? Like you have this new scoping solution that you just created. Then you can use that in this new service area that it was like historically notorious for being super hard to work on. Exactly. And all of a sudden you can ramp up an analyst agent that can help you like, you know, get insights as quickly as you ship. So in a way, it's like really cool that a lot of these projects, you know, could work in tandem. Totally. And I think going back to something, Ben, you're kind of pointing is like, okay, well, we, you know, free, all of these are pain points that we kind of called out, right? There's like pain points around tech debt, product debt, just pain points around process and so on. Right. But ultimately, what we came to is like, okay, well, when we have at the end of the hackathon, what is actually shippable? And I think this is probably something we can, you know, go deeper on is when you're at that end point, what is actually, well, how long does it take to go from there to actual ship with an AI product? And that is also very interesting because they're not all, you'll find limitations on every single one. And you have to make choices and trade offs on like what is worth shipping now and what needs more and more thought. So like, yes, you can build a prototype and you can build a experience really fast, which is great. But then when you start getting into the finesse, the taste, everything of it, and you're like, okay, is this like actually good enough to implement across the board, then you make different choices. Yeah. Yeah. Let's work our way towards that because I'm going to have a bunch of questions and kind of like what the, what the, what the output of the hackathon was like and what that last mile for a lot of these ideas ends up shaping up to be. But before we get there, just to cover our bases with the second half of my question, how did you choose how to structure the groups that were tasked with kind of tackling each project? Was the idea that each of them has to have at least like one main subject matter expert on that part of things? And then... No, I think sometimes we mix it up on purpose. We mixed up teams on purpose to get them, you know, working together. Like fresh eyes on a space that they just don't know that much about. Exactly. There was not, besides putting like front end, back end type things, it wasn't really anything more than that. And we tried to not have PMs on everything. So we basically put out PMs only on like things where like they had to offer guidance. So like even on like, for example, homepage, you know, refresh, or there was one about the buy before you sell application flow. No, I, I basically was not involved on them on purpose. How many total PMs do you have on the team? We have four. Four PMs. How many, just to get a sense of like the EPD headcounts, like how many designers, how many engineers? Two designers, four PMs, and engineers as well. Engineers about 30. 30. Okay. And did anyone outside of product design engineering participate in the hackathon? No. Okay. So you have 10 teams. So I guess like the typical team was something like three to five people? Yeah, exactly. Okay. Yeah. Makes sense. Yeah. I think the only one where I'm like curious of like, that I feel like maybe you would have to be more involved and is the one where you're almost like redefining the way you scope work for your company. Cause like that one. That one, that one I led. Yeah. That one I led. Okay. Yeah. Where my head is going is like, one, you have to know what's possible with this tool. So you have to be very familiar. You have to have played with them. You need to know where the limitations are. And then the other one, you need to have a little bit of like a deep understanding of like the bottlenecks of the current process and what great looks like, which some PMs may have. But I feel like it takes like that bird's eye view that maybe just the BPO product. Totally. Totally. Makes sense. How do you even approach that? That development one? Yeah. Like if someone wants to like crack that can of beer open and like, yeah, I'm gonna, I'm gonna dive into how we think about scoping work. Like what's the, what's the thread you start pulling on? Like, or at least for you, what was it? For me, I had like in a very, so I haven't fully like shipped that one. I've gone into like a initial flow and then had to pause for basically feature work. But the way I thought about it is like, what are all the places in the process that that current process that didn't work for me. And that basically, I just like, I just hate myself documenting I'd like hate, I hate it. But I want AI to do it for me. And I realized, good, yeah. What are I mean, just like in the spirit of, you know, product therapy, almost, what are some of the most frustrating parts for you about just like, the scoping work over the last six to 12 months? I think it's you, you talk a lot, like with people over multiple channels, but this never in one place. And then you end up having to document it yourself and consolidate it in one place, which is totally fine. But then you have to follow a specific structure and you have to like, make sure you know, you have checkpoints or reviews and so on when you go from spec scope to spec to technical approach. And then at some point, you're like, okay, now it's got to kick off all these different tasks. And you know, you can definitely when you're when you're doing that yourself, like as an IC, it's like totally fine if you you know, if that's what you like doing. But then when you start managing people, and you're trying to make sure a team is following a process, it's really hard. And I think if different people have different leans, and I don't think it I don't think it's natural, I guess is what I'm trying to say. I don't think it's a natural thing. I think we've had to, you know, different companies find different ways of coping with it. And sometimes that's like different roles that are created. Sometimes it's a very structured tool that they're using, which I've always felt like tools don't actually solve the problem. I think it's more about, like, how are you actually changing? How are you adapting the experience to what the person naturally does? I think that's kind of what like, so like, yeah, I'm going to build, you know, I build software to kind of like, try to solve it. But it's, it's actually a very simple process. So basically, all I all I kind of thought about is like, I like I am okay talking to something and then documenting for me. So I was like, why don't I say, just like how we have on all the different AI apps, if I say, what do I want to build? I start off talking to a voice agent. It's a real time, real time agent, it has a pre prompt that says, here are the questions that need to be there for anything I want to scope. I have a dialogue with that with that agent, it may be when you say real time agent, does that mean that like, like, it's conversational, it's conversational, using, okay, using, you know, open AI, real time, or Gemini, real time, whatever, whatever flavor you want. But the problem is, like, you guys got all this exposure, actually implementing AI, like voice AI technology into your actual customer facing products. So by so by the time you maybe got to the hackathon, you're, you had a good amount of familiarity with maybe how to use that for familiarity and trust. I feel like biggest thing, biggest challenge with AI, a lot of times is trust with teams. And so that was talking about you talking to Chad GPT. This is you, like you coding something using the API, the open AI, like API. Yeah, exactly. Yeah. You're trying to build an app that basically integrated with the real time API. And it would, you would talk to it. And then as you talk to it, what ends up happening is it takes down all of your different scope, it asks you questions to kind of clarify things you it's basically like, you're trying to baseline everything that you've done so far. And once you baseline that, then you take it. And you say, Okay, cool. Who else are you collaborating with on this project? So then I might say, you know, what spends my engineering lead, Mark is my, you know, my designer, I'm going to send it just as add your email, okay, well, it sends Ben and Mark a similar link and says, here's what Gaurav wrote. Here's what he put down for scope. What do you think about this? What does the existing experience look like? What is the what do you do disagree with any points he made? Do you have any artifacts you want to add? And so then you talk to it back, and then you add whatever artifacts, and then then the tool or system will then say, Okay, great, right, combine everything together. I'm gonna point out the differences. I'm gonna put it on doc. And that's your initial spec. That's your initial spec. And so at that point, you have a then you didn't have a kickoff meeting, which says, All right, cool. You guys have a spec that you want to use. Let's talk about the scope and spec. Here's all the details around it. And then you discuss, there's a recorder somewhere that I haven't obviously built this part. There's a recorder somewhere here that is like, you know, no noting down everything you talk about, outputs, transcript, and then it says, Great, now, engineering is responsible for the approach. And so it spits out initial approach, then you kind of edit, basically, you can just ask whichever, whichever LLM you want to construct an initial technical approach based on your format. And then it'll have that doc in Google Docs. And that's your first tab of like your draft, and then everything from there. So you basically have shortened down the scoping process from like a week or more to like, hours or days, really, right, depending on how fast you do this. And then at that point, you're now able to go from tech initial tech approach to start development like really fast. And in between, like, you know, different people might be like, hey, here's a prototype I made, here's this I made, but like, it's forcing discussion and iteration way faster. So I think this is kind of this is how I work. I work way better with this level of iteration rather than thinking of everything up front. Because guess what, like, every time you think of everything up front, you get challenged the minute you show something. So let's just show something as fast as possible. And it sounds like this process is mainly for kind of like the ICPM that's working with their designer and their engineer. I mean, I'm sure if you're doing some IC work, you also would do something like that. But as someone who is sitting at the leadership level, and you're eventually accountable for whatever comes out of your team, like, at what point are you inserting yourself in the process? Is it like after that initial spec is created with the, like, you know, I'd probably be there at the discussion. I probably want to be there in the discussion, actually. Yeah, I think you want to be there for the discussion, not the initial. So, OK, so if I'm not mistaken, the workflow that I heard is PM talks to agent and does a brain dump. Agent knows all of the questions that need to be answered in that initial brain dump. And only once all those questions have been answered will the agent then ask who else is involved. Then you say who else is involved and maybe like their role in the team. Agent then goes and shares what you've given it, the dump you've given it with each of those people, ask each of them to basically chime in and ask them some additional questions like, do you agree, disagree, any gaps, anything missing, anything you'd add, etc. And if there's any like domain specific context about like, you know, what is the current state of this part? What is the current state of this part? It might ask those things. And then it takes the synthesis of what it gathers from those people and it creates almost this like super summary of of like the spec. And then you have a conversation about it. That conversation is recorded. The transcript of that conversation is then factored in to that super artifact. And then that gives you almost like the final thing that engineering can go and like start working on. Yes. OK. And so if that process is happening across four PM's plus you, right. So technically, like sometimes you're the fifth PM. Sure. OK. Then, Mark, is your question for the ones that Gaurav is not the ICPM for, where does he insert himself in that process? Exactly. I think. Yeah. Yeah, I think. Go for it. I think I would be there at whether I am cc'd on email or I am in the conversation, I would likely be there at the scope conversation part. Is there a reason you don't want to be one of the people that they list and like that one of the people that the agent goes to to get reactions to in that very first round before the larger group conversation? Yeah, I think I want my I do not want my opinions at the very beginning. Why is that? That's so interesting. I think it's better to have like very fresh thought on every project first. And then, you know, then I can if there needs to be a correction because there's something that's not heard, then I can be there in the conversation. So it might even, you know, just as an adaptation to this, if there's there's probably a step at that conversation level where I can basically opt in or opt out and I can decide whether I want to do like a async feedback or I want to just be in the conversation, it's probably something there. But that's probably how I do it, because like for I would say, like, once I feel and I have that level of trust with my team, I'm like, I don't need to be there on everything. I just want to be there for certain things and have like a lot of maybe a lot of impact. And I'm like, no, I have an opinion here. Maybe I don't have an opinion. That's fine. Yeah, I think that's a critical piece of like if we apply a product design lens to this entire workflow, which we are right like you're you know, this is very much a product. The idea is that is almost like if this then that kind of logic, like a conditional logic that could apply to like who to include in that first round. If it's a brand new PM joining the team, probably loop in their manager, just to be like, I got context you don't have, right? Like, correct, correct. I know, I know things you just don't know. So let me just like add that context. Right. But as but if someone's been, you know, owning a certain part of the product for a year, you really trust them. They're crushing it. You're like, one less thing. Like, I trust them. Like I'm probably not going to have that much time. Yeah. I mean, I could almost imagine too, like, I mean, I don't know how true is this at Homelite, but at Asana, for example, depending on the experience that you're working on, you also would want to include like cross-functional people as well. That's also true. If it's a very like, and cross-functional, there's almost like two definitions. There's like other product teams, for example, hey, if it's a core feature, you might want to involve the mobile team. Or if you're adding a feature that might be premium, you actually might want to include their packaging and pricing PM, right? Or if it's something that is going to be like very heavy on performance, you might actually want to include like an infra PM, right? To make sure that, sorry, infra PM, or if you're a small company, probably like an engineering lead. Totally. So I could almost imagine like, as you're asking questions, right? Like the, this app could eventually, basically, I mean, actually, I think, you know, in addition to the designer and the engineering leader, you actually should include these two people. And here's why, basically. I mean, and the other point I want to make, Ben, too, is that this, in a way, this process already starts with Gaurav. Like, this process already starts with Gaurav, right? Because Gaurav is the one that kind of programmed the agent to ask questions. And he's probably, that agent is asking the questions that Gaurav would probably ask. Yeah, exactly. Like, hey, like, have you thought about this? Or have you thought about that? So in a way, he's already inserting his train of thought in the beginning, as opposed to like kind of more in the middle. Yeah, I mean, I think as long as the failure state that I'm just like thinking about designing to avoid is like that group conversation happens, and there's some context or input that Gaurav has, that would have meaningfully changed the direction of the initial conversation ahead of ahead of it. But because if you show it, and all you got is a little bit of context, a little bit of extra perspective, but you know, it's like 90% of what you're seeing is directionally right, then yeah, like, you don't need to, it would have been a waste of your time to probably share your thoughts ahead of that meeting. But if you come to the meeting, and they're going left, and you really think they should have been going right, hopefully, that would have as long as that gets caught earlier, there's there's two two aspects of this, which are like much, much more long term that ideal state it would be there. One of them is like, you probably want some maybe some level of checkpoint, as you said, that is like, hey, scope approval, some level of that. And that's just like a checkmark for whoever the approver is. And that shouldn't block any of the conversations, but it probably blocks some level of development work. Like if it's taking more than two days, like you got to like, get that. So that's probably one. And the second thing is, these baselines, as they start coming in, and as products get built, need to be starting need to start getting stored back into GitHub, or a different repo to be like, this is the, the central place for all of product thought. And every time you release a feature, it needs to go back and re, re update that. So like, we always like you guys have both experiences, I'm sure you launch something you're like, I don't know exactly where what I launched is. It's in the app. Yes. But it probably changed a bit from the purity by change a bit from the tech approach, it probably changed a bit from the figma. Where do I put all that? Right? Like, I think that needs to be happening. But it's not it. It's really annoying when you do it manually, right? But if like, if AI can figure that out, yes, that is that would be ideal. If you're enjoying this conversation, please check out the links in the show notes to support the podcast. Mark and I do this out of love, but to keep it going, we also need your support. Thanks. Now back to the episode. Well, I think the hardest thing I mean, I think honestly, that's like, one of the biggest challenges of working with AI, and I'm moving super quickly is that you have all these different almost data sources, right? You have a notion maybe, right, where you're writing your PRD, you have linear, then you have your code base, right? And like, they're all out of sync. And this has always been a problem, right? Like, I've worked in the collaboration space for a while, and that was like, kind of the vein of our existence. But I feel like now it's like almost like multiply times 10, because we're moving so much faster. The volume and the speed is going up by a lot. Yeah, but I feel whoever cracks this in a way that's meaningful and useful and easy to use, I think it's going to be magical. The other thing I was thinking of is when it comes to like setting up that group conversation up for success, does I guess there should be a pre-read that gets generated by the AI for everyone attending so that everyone's like, here's what's been thought about. Here's where it's at. Here's the open questions or the things we don't know. Here's versioning the spec, right? So you start off with like, here's what I got. Here's the differences. It's the pre-read. And then like, each time you make an update, it's a new tab in the doc. Man, imagine going to like the third design review for like a really important flow and having an automatic AI generated summary ahead of that as a pre-read. That's like, here's the key things that have evolved. Here's how this has evolved across the key dimensions of the discussion between the first, and now upcoming discussion, third version. It's like when you watch like Game of Thrones and they do like a quick recap for you of like storylines that will happen to come up in that episode, right? Absolutely. At Asana, we had to do that like before every product review. And like we basically had to do like a recap. Be like, here's what, and it was after the PMs, because to bring it up, be like, hey, this is actually what happened last time we were here. Here are the open questions. Here's where we landed on them. And based on that, here's what we're going to present today. And here's kind of the topics that we want to cover and the open questions that we hope to answer. And that was really helpful. It's kind of grounded everyone on like, hey, we already discussed this. We don't have to go over again. So I think like having, I think what's really cool about this approach is like flagging the conflicts early on and be like, hey, like here's where maybe there's like fundamental differences or where based on what the designers said and engineering said, like, I don't think you guys are talking about the same thing or that, you know, you're not really thinking about solving the problem the same way. So maybe let's spend some time here so we can all get aligned. Like that's super, super valuable. Totally. One question I also have, because I do want to come back to like the rest of the projects too, but I know we're doing a little bit of a tangent specifically about the one that you led, because I do think it's kind of interesting. Did you, you know, there's like the saying, like, don't skate to where the puck is, skate to where the puck is heading. So when you think about designing the way that you work, you know, how did you think about trying to, I want to say like fully future proof it because things are changing faster than any of us really knows, but like how far ahead were you trying to kind of like think when it came to like designing the way you want to work? I just wanted to focus on the scope, like the scope definition part. That was the part of the flow that I thought had the most back and forth and most slowest. And so if I could solve, if I could reduce the time there, that is all I need to get done now, which is why even when we're talking, I'm like, yeah, here's like my ideas for the future. But I haven't built that. Right. Because it's like, yeah, this is the only part that really matters to me right now. Clearly. And I think that's, that's so important. Like I want to, I think the mistake that I see a lot of people is, for example, like trying to address entire product development cycle and find like a solution end to end. Right. And then I think you end up with like suboptimal like experiences for every step along the way versus when you pick a very specific job to be the problem. I think you end up in a place where you actually want to have like a, you can spend a lot more time thinking about like the problem, right. And what's wrong with it. And actually like build something that that's much better. So I think like being very specific about the exact problem they want to solve for. I think it's, to me, it feels like the right way to approach it. And the one thing I'll say about that though, is that there, I just want to make sure we're clear, like that approach does still require the presupposition that specs matter. Yes. And I think that some of the teams we're talking to are like moving past the specs. That's kind of why I'm asking like how far, you don't necessarily want to design the best way to get specs done with it in an AI native way if you're planning to just like throw away the spec altogether. That's great. It's a great point. I think specs don't matter. Scope matters. So and it's a very big difference because I think like in the flow I design, yes, you get a spec, but I think about like, I think about like there's scope and then there's technical approach. That's really all I'm considering. I do think having a clear definition of what you're trying to address is still important. And you'll notice that because when you are, I feel like I'm past vibe coding, I'm just like coding now, but like if I, if I'm vibe coding, if you have a clear scope definition, your product's way better, like hands down is way better. If you are really hand wavy about your prompts, then you're like kind of end up in a really weird state and then your context is all messed up, right? So I think, I think at its most simplified form, historically, the teams I've been on would think of scope in terms of like amount of effort or, or like the amount of surfaces that need to be impacted by like a certain update or a change. Like what's the definition of scope that you and the team landed on that you, you agree like is the thing that's being defined as part of this process? Yeah, I'd say what is in and what is out and why are we doing it? That is essentially all it boils down to. So the debate in that conversation should be primarily what is in, what is out? Why is it in? Why is it out? And then that's kind of it, because everything from there can be put into a prompt. Got it. And so it sounds like, because, because like the danger, right? The danger right now is the danger right now is you go into this, whatever tool you use, and you spend, I don't know, however much time building everything. And you're like, and then at the end of the day, you're like, why did I do that? Like, there's, I've seen that so many times, people just build every feature, and then they get no feature working well. So I'm like, no, like, you got to decide, like, maybe I'm not gonna approach this feature at all on purpose. And so that's the conversation I really want to have. Okay, I'm, I want to make sure I have the definition of scope correctly. So yeah, I understand what's the difference in like a scope and a spec. So yeah, the way I'm understanding what a scope is in your world is kind of like a quick context on the problem that we're trying to solve. And then almost like, it can be a table, it can be like, you know, document with rows, but you know, here are the user stories that are in the MVP, here are the user stories that we thought about, but we don't think are valuable enough or necessary. We could call this a one, we call this a one pager, if you want, like, whatever, whatever we want to call this, it's like, to me, scope is a one pager, it says, here are the things in here, the things out, here's context, that's it. And I want to put X. Yeah, good. No, no. Sorry. No, I'm actually curious to see what, what are you gonna say about spike? What's the spec? For me, a spec or a PRD is way more detailed, you get into like, functional requirements. You go into schemas, you got to go to market stuff, like, it's just becomes super broad. And then you get stuck in like, documentation hell, rather than to me, this one pager doc, which you would typically create, usually was used for like, I guess, like executive approvals. A lot of times, I'm saying like, that's just that's all you can eat. And I don't think you even need to document it. So big, a key part, key difference here is, you should not feel like you're doing work. And I guess that's something that we should make very clear. You should not feel like you're doing like, a bunch of work to get this document created. It is like overhead. Yes, there's like no mental, there's very little mental overhead. There is no you actual writing, it is you talking to a mic. That's it. Right? Think about like, all you're doing is talking to a mic. That's how easy this thing should feel. My generation should be that easy. Yeah, I, so the push I wanted to make of like, I'm trying to channel my inner like, LinkedIn bro who's like, who's like, specs are dead, prototypes, prototypes are here. Like, you know, like, specs were like, so 2024. Mark, don't lie. It's just like what you're thinking, right? Yeah. I'm that guy. Yeah. Yeah. And hence, here's my question. So yeah. I'm like, okay, that sounds great. But, you know, why did you spend all this time scoping? And then all of a sudden, you, you build a prototype like, oh, actually, now that I'm playing with it, that like, to those two stories that I have there no longer make sense, because like, now I'm like playing with it, and I can get the feel for it. And I actually think that we don't need it or that actually, it's like have a clunky or so it's almost like, and I'm glad you Yeah, I'm glad you brought that up. There are there's two roles, or there's another role I didn't mention that we have called AI product builder. And those those roles are meant for specifically that is like, if you just want to prototype build new initiatives, that is kind of how we will do it. What I'm what I'm talking about, and I guess here's my split in my head, okay. So if we're talking about existing product, that we're going to be, you know, existing thing we're working on, and we're going to be like, basically brownfield items, I do really believe this is important. If it's a net new greenfield one, you're right, I don't know if there's needed, I think you probably should just do exactly what you're doing what you're saying. And I think that's what actually the approach we've taken. So the PMs that I mentioned before, as I mentioned, they're on like, existing products, right? The AI product builders that I have, they are focused on completely net new ideas. And they just do what you're saying, they just build. And then they switch back into go to market work, or sales, and they get built again. And that's how they work. But these are PMs. They're not PMs, they're product builders. But what's, what's, what would they be called a year ago, or two years ago? They wouldn't be I don't think I don't think they exist. I don't think they exist. Two years ago, they're they're code, they're like, they're building the full. One of them came from ops. The other one was I just hires came from analytics. You created a new type of role with people that are not PMs, not designers, and not engineers. Yes. But have some amount of subject matter expertise about correct, the company and different parts of the customer experience. And then they've demonstrated some that they spike in some element of like tinkering or AI fluency that impressed you? Yes. Okay, and then you and then you created a job for them. Yeah, that they were excited to accept, hence, they're doing the job. And that job has no tie to core product dependencies, for the most part, or core product surfaces. It's entirely about building greenfield product, prototyping that is disconnected from the mainland. Yes. And internal tools as well, or just product work? Internal tools are kind of like open space, right? There's no opinion. I don't have an opinion on that right now. I just like I touched internal tools myself. Sometimes I'm putting PRs on internal tools, any PM can, I don't have like a big process for that. Yeah. It's whatever we want to do. Yeah. I think the line of questioning that you were doing is like, I'm sure that was exactly what happened like 25 years ago when you're like, when people were talking about PMs for the first time. It's like, wait, wait, wait, you're telling me that you're putting a person that's not an engineer, that's not a designer, that's not even go to market, and they're telling everyone what to build? Whoa. Well, yeah. Well, they're building. They're actually building. Yeah. Exactly. That's the difference. Yeah. I think that's what's so interesting. And they don't call themselves the CEOs of the product. Well, no, they probably don't. But like what they're doing is they're, it's just because I've done so much of this like new product experimentation, zero to one stuff inside of teams. And the reason I'm so fascinated by this is that because there's always this tension organizationally and incentive wise for people working on brand new bets to quantify the impact and justify the investment in the same exact way that you think about justifying the ROI on core product bets that you're making. And what's really elegant to me about the way that you've chosen to structure this is that because it's not stealing resources from the main EPD org in any way, and it's taking people that have the existing subject matter expertise they need about different parts of the product and people who are like presumably coachable and just like really smart and curious and can move really fast, you've basically de-risked the cost of zero to one of funding zero to one exploration in a way that doesn't jeopardize the core. And I think that's really impressive, actually. I don't think I've ever seen anyone do that in that way. Yeah, it's it's been really, it's been really fascinating to see because like taking someone from a different, totally different like, job focus and then kind of bringing them into this world and then them learning how to code, you know, use codecs, cursor, Figma, whatever it is, and then put it together and like build, obviously, they'll partner with Anjali to guide them, then get up to speed. But like, they, you know, would build like, at least 50 60% of everything, and especially all the UI and UX would be them. And that's cool. That's really, really cool to do that. And you don't need to involve other subject matter experts, unless it's like, you know, key things like, oh, like, what's the best way to do this onboarding flow? What's the best way to make, you know, what are changes we make on a landing page, that's where I would be involved, or like the design leads would be involved. And then other than that, you know, it's up to them. So if someone's like listening, and they are sorry, Marcus, I have one more question here. And then I just curious about this. So if someone's listening, and they want, they're like inspired by what you've done here, and they want to test this, and they, what are things to look out for, like, what should they be looking for as attributes or behaviors or characteristics and people outside of EPD to figure out whether they might be good candidates for this kind of role? I think like, number one is scrappiness. Like can they and what I mean by scrapping is like can have they demonstrated zero to one in whatever field that they're in. So like, you know, if this, this person was able to, like, take a new business, like zero to one very fast, with very little assistance. So that's like self sufficiency, being able to be scrappy, just get to the goal, right, get to the business outcome. That's, I think, very important. And then the second thing is like, taste, meaning like, also subjective, but it's more subjective. And like, hey, are they creative? And are they able to actually make opinionated decisions on how an experience should be for the users? And, you know, do you align with that? So I think those are probably the two that I care most about. The rest you can, you can teach, like, that's kind of the rest is very teachable, as long as, as long as they're coachable, of course, I guess that's the third. Yeah. And I guess that the reason why these people spike in taste is because they've, in their previous role, they spent so much time with customers that they can, they also kind of like, have developed this intuition of like, hey, here's what this person, how this customer would react to it or not. So it sounds like that's part of it, right? Of like being able to channel. Or internal ops, because I think one of them came from ops, right? So it's like, yeah, for internal tooling, that might be the background there. Yeah. So, so that's one. And then I think the, I think what, what I'm gathering here of what you mean by taste is like, you know, out of like 10 decisions that they make, do they make the right one? Maybe nine times out of 10, right? And by right decision, it's like maybe something like the decision that you would have made or that you're like, okay, I can rally behind and I can understand. You can understand. From point A to point B, I know how you got there and I agree with the way you thought about it, basically. Exactly. Yeah. And then, so, okay, so like the taste is one of these, by the way, I'm like really jealous about them, about these people. That's a great, what an early, great early career, like in my twenties, that's like a dream role. Yeah. Yeah. That sounds so sick. Yeah. Especially if I get to spend time with Gaurav too. Yeah. That's a bonus. But how do you, so like, let's say, okay, like this person just like crushes it in their first, you know, like they take one zero to one, makes, you know, it makes a lot of sense and you know, that you, you deploy it, you have a couple of users like in the beta. What happens when you have to graduate that? I mean, I'm sure probably you're not, you're not there yet, but I'm curious, like, how are you thinking about that kind of graduation from kind of zero to one kind of prototype speed versus, you know, something that becomes more stable and integrated into the code base? Yeah. I mean, we haven't gone there yet, but I think what would happen is you would, that person would have to choose on like what they want to do is whether they want to end up becoming like the actual PM for it or GM, whatever you want to, whatever that business ends up looking like and, or do they want to move on to something else? And I think that's a question, like, do they want to just keep doing new growth initiatives or do they want to pick a specific discipline and like, can I go into that? And I, I'm grouping PM and GM together because I think like if they created the new, a business, a new business or something, a new model, then they should have the option to like, can I lead this to the next phase as well. And then, then you might have a new pod created for them, not like a huge team or something, but like maybe like a engineer or two and then like some design help and then they can then direct how it should go. So there's a world in which, because Mark, I think what I was hearing your question is not just what happens to the person, like what kind of growth is available to the person leading that zero to one exploration, but what happens to the work itself? Exactly. Yeah. So, yeah. It sounds like there's a world in which the work itself, what kind of, yeah, I guess like what is that? The connective fabric between the greenfield bets in the mainland, regardless of the career advancement of the person that leads it. I, maybe I'm not understanding the question fully, but like to me, I'm like, well, it's a new app. It might have integrations with like the backend and so on. But other than that, it can stay how it is. And we can have linkages as it becomes a bigger part of the business. But ultimately how the thing gets resourced or how it ends up being integrated with the rest of it is purely a monetary thing, meaning like how much is it bringing back to HomeLock? Makes sense. So like, you know, that's just five different levels for each thing. And then we say, okay, cool. Now I'm ready to integrate into the rest of it. And that's the next phase. And so we would, if it does not, then we'd probably collapse it. So, so your code base is like made up of a mixture of these like very old legacy systems and brand new, kind of like recently manifested in an AI first way systems. And over time, the code base should theoretically, like the green will cannibalize the brown. Maybe it just depends. Some things may not, right. Some things it's like, it's fine. Right. I think it's just purely dependent on like what needs to be, what the opportunity is at. And so it's all right. For me, it's all revenue oriented. Makes sense. And okay. I feel like we could spend like an hour in this rabbit hole. I wish we had that time. But there's two things that I would love to do, like before we land the plane that I want to make sure we cover, because I think they're, they're actually really, really important. One is let's talk about the last mile delivery, right? Like I think that's something that maybe we don't get as much into specifics, but I think just like any learning that you've had here will be extremely valuable for people to get a perspective on. And then the second one too, like maybe we have time to, that I would love to do later is any, like, what have you learned about, like, you know, what are the actual leverages for all the different like areas that you touched on the hackathon? Like, and because I think that's also like, will help basically the audience refined their intuition of like, you know, here's where, where the gold is. But anyways, let's start with the, the last spot, right. And maybe we can use the, since we'd be using these like, nice scoping app as an example, maybe let's talk about like, you know, where you're at with it. It sounds like you still haven't fully deployed it and kind of what had been some of the challenges that you've had to maybe get it like fully rolled out among your team. Yeah. I mean, I think ultimately like any feature last mile is about prioritization and where it fits compared to everything else. So given I was the lead on this, it's became lower on my list because of everything else going on. And so that's why it has not been deployed fully, but I can tell you what has been, and I can tell you how I prioritize it. So there were, like I said, 10 different, different projects. We identified leads for each one to bring them to the finish line at the end. We identified like, basically there was like a last day was presentations and demos. And then we were like, okay, here's the next steps. And so we put that for each one. We deployed, you know, the new homepage one within the next few weeks, we are deployed a new application flow. We had the reporting agent that I was talking about before. And then the design components are now at the point where they just need to be packaged. And then they can be put into every single app. So that's kind of where we are. But the way we got there, and the way we prioritize it was basically like, who's leading it? And what is the actual like real, like what can be realized within it? So I'd say of the 10, like probably five are like, either fully deployed or very like at the finish line right now. And then the remaining five. That's a lot. That's more than I'd expect. It's good. It's how long has it been since since since like the hackathon ended just about a month and a half. Wow. Yeah, that is impressive, man. It's fast. Yeah, it's been good. I mean, we've had to put obviously top down pressure on it for sure. But it's, we want to make sure that we actually come out and actually have like real impact. So it's been really cool to see that. I think the trouble has been when you see the limitations as it's in the wild. So like, okay, so like reporting agent, we are used to people posting like specific visuals of these charts and so on. And we're now trying to make the AI produce this and submit this in Slack UI. And it's like really hard, right? Because Slack UI is not great for any of this stuff. So like the Slack blocks and so on just don't work. So we have to like now be like, okay, how do I show these charts and reports, probably gonna have to be image capture. But like, that's another feature that we have to like kind of build. And so that's kind of like, okay, we can implement this for certain channels, but not everything. So that's where it's like pause there. Now if we talk about some of the other ones, it's been who is going to be able to select sometimes it was led fully by an engineering pod for a project. And then you're like, okay, now we actually need to have the rigor is replacing a core piece of tech, the rigor to test into this and like, you know, QA this and so on. And that's where things get stuck. Because we, we built without scoping. We built just we just built right. And now we're like, wait, now I need to compare with what was built currently, I need to have a QA list, I need to test into that. And now man, that's tough, man. That is really tough. We've been kind of stuck on a few projects at that last QA step, because we, it took a long time to kind of get all of the edge cases like kind of ironed out. A lot of things spiked, like we spiked really well on experience. But then we did not spike well on these edge cases. And so that's been that's been taking a bit of time because their core experiences. Yeah. So I think one thing that's really cool of how you run this that I'm speculating that was probably key to the success here is that you, you know, you just not, you didn't stop at the hackathon, right? It sounds like you gave teams budget to continue working on it after the hackathon, to make sure that you got it through the finish line. Which is great. And it sounds like there are some projects where maybe the level of ambiguity was lower. And then those were probably the ones where you were able to get it through the finish line or you had less hiccups, but then the other ones were maybe they were more complex or maybe the flow was a little bit more critical. And that's where you kind of like the details mattered more and that slowed you down. So in hindsight, given kind of knowing what you know now, is there anything that you would have done differently in either the way you structure the hackathon or even the way you give people instructions for scoping what happens after the hackathon? Like, how would you? Yeah, I would have limited scope on certain projects and probably pushed the QA sheet or whatever QA test cases part very early. I think that's actually very important now with the AI piece, making sure what you're going to test as a release process thing. It's probably the biggest thing I'd say. If I change that, I think three or four projects would have gone. I think three or four projects would have gone way smoother. Yeah it's interesting. So the other thing I'm just I'm just thinking about is this hackathon happened in the context of like the broader company and I'm just curious if like the leadership team itself you know like the executive team has done anything like this to kind of get the rest of the company to start to think in AI native ways or if the change has mostly been kind of he PD first so far. So the entire company has been like our CEO has been pushing AI from the beginning and you know it's been like encouraged every every step of the way. So a lot of different teams have adopted it but in very different ways. Right. So it's like operationally they might have used any of the available agent tools to kind of automate that. There's a bunch of that going on in different teams. The reason we kept this one purely PD is because we felt like the way that engineering has changed has changed so dramatically that like I think product and engineering just have to like design have to like mind meld together. That's the reason why we kept it that way. But every every team is experiencing their own their own version of this maybe not hackathons but it's like in their daily work. Yes if a CEO is listening to this and they're like man I wish I had a product leader like Gaurav and a CTO like your CTO is so on top of this stuff and thinking about embracing it and even creating new roles for people that make sense to them outside of the current structure what would the advice to that CEO be like what would you what would you say you could maybe generalize or share with based on what you've observed in your CEO that they're doing well to kind of empower the team. I think like like one thing I think we had the ability to do was there was not any restrictions if that makes sense like we were given the ability to try what we wanted. If we put restrictions around how you use AI tools and so on it's like really hard to like experiment like everything here was an experiment like to your point this could have gone a very different way it could have gone away where like none of the projects did anything but that's not how it happened. So it was like live iteration even during that week and like what to do differently how to how to guide the teams to like implement differently. So I guess that's one don't limit you know these kind of experimentation exercises. I think that it's really important to evaluate whether your team is thinking from the ground up or just thinking of AI as like oh it's like this new fad. I think it's a very important thing to distinguish and I think the last part is like there's a difference between vibe coding and like actually using AI and I think that if if that's not fully realized then like if you just stick to vibe coding if you stop there you're not going to get there. Is the key difference to you that the kind of thing that you're doing that some people call vibe coding but you think is not is that you're starting at the current production code base and then you're building on it and then merging back to production is that the key difference? Yeah yeah I would say like the way I think of like I think like v0 if you're if you're like oh I am prototyping I'm using v0 I'm like cool. Like if you're like I use Google Docs it's really impressive. Yeah but that's cute son. Let me call you you know give me a call when you use anything that started with a C like Crusher, Konix, Client. Exactly. Exactly. I think that that's exactly how I think about difference is that if you're like I feel like if you you should everyone should feel comfortable now getting into Git should I mean I like I can create a repo create an app in like 30 minutes right like a real app that is hosted on something and that that's just magical man. I feel like I just like don't I don't know how and when you know when you realize that you're like wow why am I limiting myself. So there's so much of this going on I know two founders that I've met in the last let's say two months who have still are still operating like from a place of thinking they don't have the chops to figure out the UI patterns and the product that they want to build. And I've pushed both of them I'm like is that still true. Like do you still really need someone that can help you figure out the UX of the thing that you're thinking about like and both were like yeah that's probably a good push like I probably should be like I probably don't I don't need the kind of help I used to need because the tools can do so much more. Like if I these days I'm genuinely not sure what I can and can't do anymore like I have to start by talking to Chad GPT and I'm like here's a there's a thing I'm trying to achieve my preconceived preconceived notion is like it would require these kind of skills or this kind of knowledge or this kind of access. Is that true or is there a way to do what I'm trying to do in ways that like don't you know have to require that. And just like having that conversation up front I think has really expanded what I'm what I think I'm capable of with the tools which is great. It's almost like the skill that matters now is less about like can you actually do the raw like skill set right like can I design the website that's more like hey do I have an understanding of what's the best tool out there possible to do that thing. And then do I understand where are the limitations of that tool and where I'm going to hit the block and then when it might make sense for me to bring an expert to help me get it to the finish line. Like I think that's kind of how I think about it like and there's unfortunately there's some scenarios where like for example like getting like a security expert or a performance expert like unfortunately there's no tools out there that are really good at that right. And you still probably got a really good senior engineer but over time I think that's going to change and you know and they really specialize and there's going to be only a very small number of roles where that is true and there's not a tool that is really good at. And I want to totally totally agree. Yeah. And maybe maybe one one final question for you Gaurav is like out of all the things that you did and you know like kind of improving the website kind of adding new processes for your team in the way you build product and kind of cleaning up areas that were maybe there was a lot of cruft and friction. What has you know now it's has been a month and a half. What yielded the biggest results and what what else was surprising from that experience. Yeah it's a good question. To me it's it's still at the point where the results are being like measured. So it's a it's a really good question. Right now I'm like basically a lot of things got to the finish line in the last few weeks. So it's deranged to be seen. I have my bets on what I think will have the biggest results which I think like are actually more of the process oriented changes that I want to make. I think the other ones are more like they were tests like I can't like you know yes they went out but they may have taken longer than I would imagine. So then I always come back to being like oh man if I had done it this way it would have just been like you know half the time. So that's always kind of like clouding my my my experience there. So to answer your question it's like yes we got a lot of things launched and I think that is an accomplishment in itself. Now yielding results by next few months we'll see. And not getting pulled back into like the old way of working right or like yes because there's like a gravitational pull to like the yeah there is yeah there is. I think you just score yourself another invite because we will have to reflect in a few months to see how things are going. Also just like a meta note Mark is just like how freaking awesome it is that we get to do like we should be having more of these kind of conversations I think with people that are literally on the ground like implementing and learning because this is just it's fascinating and it's evolving. So it's still good to keep other people like us I guess who are not in the in the seat day to day you know on just to see what they're hearing too. But yeah hearing there's nothing that beats I think hearing directly from someone like you Gaurav and what you're seeing. Yeah and I think that the kudos that I have to give you Gaurav is that you know you're not only just consuming content and playing with it yourself you're also taking bets right like you're spending a lot of time of your resources to go deep on this right. Like what you just did is cool but it's also extremely expensive. But you made that choice and instead of building feature for your customers you decided hey we need to learn this. You also created this like random role that didn't exist a year ago and you're trying it out. So you're taking action and I think that's actually how you learn and how you kind of push forward and so kudos to you for doing it. I think more people should be doing what you're doing and of course I think you need the right environment you need leadership that you know trusts what you have to do that you need someone who's open minded. But yeah huge kudos to you man. And two final questions for you. Where can people learn more about what you're doing? And then the second one is how can the audience be useful to you? I think I have two things for where can people learn more on my LinkedIn. I'm going to be posting more about this and I'll probably like you know launch this app separately anyways. And then second is where I do have a growth and product newsletter so that you can subscribe to that would kind of share a lot more about this as well. And then the second question was how can people be helpful? How can people be helpful? I think I just want like you know like we said at the beginning I just want to learn more about what people are doing. Like you said Ben it's like I just want to know how are people implementing AI in their natural workflow and reducing just moving faster because ultimately all I care about is get to the goal faster. Well luckily we have a platform that allows us to take that as marching orders to figure out which guests to bring on. And yeah I'm definitely committed on a personal learning perspective and I know Mark's in the same boat to have exactly what you're asking for. So stay tuned. Amazing. These are up. Thank you both. Thanks Gaurav. Thanks. Bye bye. If you enjoy this conversation please share it with someone who you think would benefit from it as well. We really appreciate it. We'd also love a follow or a rating on Substack, Spotify or YouTube. That's going to let other people find us. And if you have any topic recommendations for a future episode please send myself or Mark a DM on LinkedIn. We'd love to hear from you. Thanks.