Gokul Rajaram on Defensibility, Scaling Companies & Hiring for “Spikiness"

This is one of my favorite times of the year to meet with this great group of founders. I'm looking to this group and the group of talented AI engineers and engineers broadly in Asia, India and beyond to hopefully lead the way and take what Deepseek has done and bring it to the, to the next level. I think one thing that a lot of questions, I speak at a lot of events and talk to a lot of founders. What is the number one implication of Deep seq? The number one implication of Deep SEQ is that AI is now democratized in a way that we didn't really imagine even three months or one month ago. And so every lab, I think a few weeks after Deep Seq, we saw here in the US somebody replicated deep seq for $50. So you're going to see a massive cost lowering of API access or building AI models. And capital is no longer a moat in AI. What is a moat then? The challenge is for all of us who are investing in and building companies, what is a moat in AI? The only enduring moat is to invest in R and D and product development and keep building product. Because the reality is the foundation model companies are realizing that API layer is no longer going to be a viable business model. They're all coming up the stack. You might have seen that there was a leaked slide screenshot from OpenAI's presentation which showed a sales agent that OpenAI is building. So for all of us who are building agents of different kinds, anthropic, OpenAI and others are going up the stack. There are no definitely going to come after agents. So the best modes are probably data that is not crawlable publicly, not available publicly, and is private so that the foundation models cannot crawl it. Second, workflows that are complex and interconnected, where you need not just one agent, but six agents working in tandem to make something happen. And then third domain of vertical expertise, maybe even systems integrator implementation expertise to make it work for an enterprise. So the more complex interconnected the workflows are and harder to implement they are. And the more data that is private that they are trained on, the bigger mode we can get. But again, these are just temporary. I think every mode in software is going to be broken down, is going to be crossed. The only real mote is innovate. I actually feel that you've got to innovate six times and have six fundamental innovations for you to be an enduring company. I've done this math a few times using Google, Amazon, et cetera. If they just stopped at one, they would not have succeeded. You need six different things. So I think even in the AI models, companies have stopped after model one. If OpenAI had stopped after GPT version two, they would be dead at this point. They had to go to 4 or 5 to be one of the top two companies left. And even then obviously they're going to be one of the survivors. But they had to do five or six foundational things in order to survive. And so each of you, you've got to make six foundational product things in order to actually build an enduring company. One is not going to be enough. That's very clear. Anyway, let's get to scaling companies and we'll discuss some of these through the presentation. So this I wanted to also talk about how quickly technology is moving. A month ago I got a note that company I'd invested in that had reached 35 million in revenue was shutting down basically and it was zero to everybody at the company. And I had made the intro to DoorDash and they DoorDash was a $2 million account for them. I was like DoorDash is paying 2 million 35 million. They're not going to die, are they? And they're truly asset sale essentially and won't name the company. But the reality is if you're not innovating, if you basically have a single product which is ultimately going to be commoditized, you're not going to build an enduring business. So just because you have 10 million revenue, 30 I have a company at 125 million revenue that I've written off at this point. So I think every moat, every revenue scale is susceptible to cannibalization. And the good news is you're all small so you can all cannibalize the big guys. No moat is safe, no castle is safe at this point. That's the point I wanted to make. Quick recap. Some of you might have been here last year, but there are three stages of company. I think there's a startup stage, there is the early growth which is the stage you're going to talk about. And then there's a scale up stage, startup, the three things that matter. Actually the one thing that matters the most is finding product market fit, figuring out how to get, figuring out who your customer is and how to serve them better with a remarkable product and in a way that gets them to retain. So retention I think is the number one metric to focus on getting a small group of loyal customers that retain and use your product and love your product usage, love and retention. And then culture is the second thing, the first 10 people you hire are are going to most likely set the template for the rest of the company. So it's very important that you handpick the 10 people. In fact, I think Max Levchin said this, that it's actually okay to have it be a monoculture. In other words, it's actually important maybe for the first 10 people to be very, very, very similar in their backgrounds, worldview, et cetera. So you're all aligned on what to build and don't get into tiffs around other things that are not around the customer and the product. So it's actually good to have maybe from the same school or same background, whatever the case may be, but you want them to be as unified, uniform as possible. And then finally, a startup is characterized by generalists, especially even engineers. Engineers are generalists, definitely. The non engineers are generalists almost. The First Neeraj at WhatsApp is probably the best example who basically is the ultimate generalist. He was I think one of the one or two business people at WhatsApp till the time of acquisition. And he did everything from signing the leases to making offers to engineers, to negotiating the corp dev with meta everything. And so generalists, that's what startups are scale up, which is the third stage is when you have executives, you have real executives who come bearing big titles and managing managers and two or three levels. You actually think about org structure much more. And there the org structure there are some important decisions to be made. A lot of companies think about should we go to a GM like model, a bu like model where you have product design, engineering and other function reporting to a person, you have multi product come into play and then much more predictability. Of course as you go towards an IPO two or three years before the ipo, you've got to start operating like a public company. You've got to start having internal quarterly forecasts and really understand if you missed it, why did you miss it. If you beat it, why did you meet it? And then keep revising the forecast. So a lot of predictability in cadence and so on. The middle is where I think many of you are and hopefully many of you will get to. So that's what we'll spend our time on here. So there are three pieces. Scaling the product, scaling the GTM and scaling the Org. I won't belabor scaling the gtm. We'll focus a lot more on scaling the product and scaling the org. Scaling the product. Three things to think about. Outcomes, habits and optimization. Focus on outcomes versus output. What are the right habits to build as a product team and then how do you think about optimizing versus innovating? Most importantly, a lot of companies get into after you have product, get to product market fit. A lot of companies get into the trap of building up, becoming a feature factory, where you're just launching feature after feature after feature. And you ask the PM or the founder what the product roadmap is. It's simply a list of features. And if you ask the question why, nobody can truly understand why this feature exists, what it adds, what value it adds to customers, et cetera, et cetera. So one of the most important things I try to encourage companies to do is to stop orienting around features and start orienting around outcomes and train our teams to orient around outcomes. What that means is every feature you launch should be directly tied to changing a customer behavior. In fact, I would argue that a feature shouldn't exist in a product unless it changes a customer behavior. And customer behaviors, or customer states as I call them, can be anything from not a customer state to becoming a customer, becoming an initial customer to become a loyal customer, going from a churned customer to a reactivated customer, et cetera, et cetera, all these states of customers. And we want to make sure customers move from one state to the other. And if we can't articulate why a feature changes a customer behavior, we should not be thinking about the feature. And in order to get to even customer behaviors, we have to map what happens is a lot of founders live in the world of revenue and output outcome metrics at the company level. And then the engineers and product teams sit at the feature level. There's no connective tissue between revenue and profit. And features and customer behaviors are actually the glue between business metrics and features. Customer behaviors are essentially things I outlined. One of the most important customer behaviors is new customers. And so how, how does a customer, how does an entity go from becoming not a customer to becoming a new customer for the first time? And then how does a new customer go to becoming an active customer after that? Right. There's a new customer when they sign up, register and maybe place their first order or make their first transaction. And then an active customer is somebody who actually is engaged and loyal. There's multiple states here. And what happens is a lot of the burden for this is put on the sales and marketing team. The product team doesn't really engage the with this very, very, very important flow of the customer, maybe the founder engages, but really it's not a so one of the things I Try to advise companies very early on is can we put a product squad which is product engineering, design, analytics to work on this very very important thing not just delegated to marketing. And you'll see your marketers, your sales teams will immediately embrace and they'll be so much more productive if we just put some product brain power and horsepower behind this very important state transition. But because companies cannot grow unless they get new customers, obviously retention is super important at pmf. Improved retention. But we've got to as demand gen it's extremely challenging today especially it's extremely hard from just SDRs to cut through the noise. You need a lot of product led demand gen a lot of inbound marketing techniques and product can turbocharge that. So coaching teams on how to solve backwards from outcomes. The two things I look for for any role at any company, problem solving and agency. Can they solve a problem given a problem and the more senior they are, the more open ended I expect the problems to be. If you're the CEO or CXO at a company, I expect you to solve company level problems. If you're mid level, I expect you to solve product level problems. Given a customer outcome. Tell me six different ways that you can accomplish it. Compare and stack rank why you will use one versus the other. But we've got to coach people to solve problems. And second is agency. Agency as you know is basically a better way of saying being proactive, not being reactive, not being told what to do but taking initiative seeing that something is busted or broken. And I think we've got to. It's very hard because many of us have grown up. I grew up being told what to do. My first software engineering job, I thought I'd done a great job. I got to meet the expectations of my manager. It's like why? He said well you didn't take agency, you didn't take ownership. What does that mean? He said, well I expect you to basically tell me what is to be done and do it versus me telling you what is to be done. And I think that's what we want. Our people, our people should be telling us what's not working and then fix it versus pointing out things. So it's a good lesson for me around agency and then the third bullet is around validating hypotheses. Just like I said, a feature doesn't exist in my brain until it moves a customer needle. I think a feature is actually an experiment to validate a hypothesis. A feature is an experiment. What that means is you should never celebrate launching a feature. Never Ever. So many companies think about the last celebratory email you sent around the product. It is very likely it was sent around launching a product or launching a feature. Who the hell cares? Who cares if a feature was launched? What we care about is did the customer behavior change? What does it do for the customer? A feature is very company centric. It's about me instead, I want to see what it did for my customer. Think about the okrs and goals you've set. How many of them are about launch feature X. I want all of you to look at every single okr and change every OKR to be from the angle of the customer. Be from the angle of the customer. Change it to be customer centric, not use centric. And I think when you say, one of the questions I always ask PM candidates is tell me about a situation. If I gave you zero engineers, zero engineers and you have to test this hypothesis, how would you build this product? And in today's day, there is no excuse for, for a PM to be able to build a product, to be able to not build a product without engineers. Why? Because there is so many prototyping tools now. And so I would challenge you and urge you that if you're hiring product managers, make sure that they're capable not just of creating great presentation, but of creating prototypes. Give them an AI prototyping question, make sure that they can validate hypotheses and get something on the web that you can then send a few people to maybe with paid marketing and see with zero engineering resources to see if they validated the hypothesis and only launch a product. DoorDash, I think is the perfect epitome of that. At DoorDash, the feature only launches when it validates a hypothesis. It launched to 3% or 5% and then when it launches to 100%, the team will say, well, it launched to 100%. That's a launch. That's it. And more importantly, this is what it did, this is what it accomplished. It changed dashpass retention from X to and yeah, there are some features, but no one really cares what the features were. What matters more is what it did for the customer. So that's outcomes. Training the company around outcomes, making your goals around outcomes, praising and celebrating outcomes and figuring out how to go from business outcomes to features, which is the intermediate glue of customer outcomes habits. Continuous discovery is very important. What it means is you cannot have only salespeople and customer success people interfacing with the customer. If your product teams are not engaged with the customers on a weekly basis, you're going to fail, they're not going to live in that shoes the customer. So you've got to have discipline around. Each product team, in my opinion, should meet with at least one or two customers a week. And they don't need to necessarily in many cases meet with them in person. You can do a zoom, you can do whatever the case may be, but they should listen to a customer call, they should shadow cs, they should shadow sales, they should figure out how to engage and hear from customers in their own words. I think sitting with customer support people and seeing how they answer tickets is one of the most clarifying experiences for a product manager engineer because you realize how broken your product really is and how much people are struggling to use it. It really gives you empathy for customers when you sit. So we forced every PM at Google, every company I've been, to basically sit with customer success for one hour a month, just one hour a month go in and you've got to schedule the time and show you've done it. And you just come out of it saying, I didn't realize my product was that broken, that bad. And then experiment versus feature mindset. I talked about it. So every feature you should have, you have to think of a feature as an experiment. It is not a feature. Who cares? It is an experiment to prove a hypothesis. And then the other thing I think the important thing about customer discovery, so there is observing customer. How do you interview customers? I think a lot of PMs over the last 10 years, I was not an analytics trained PM. I was a very customer story trained PM. But over the last 10 years, because analytics tools have become so good, a lot of PMs have become data jockeys. They basically know how to run the spreadsheet and they've become data scientists. But if you put them in front of a customer, they don't know how to extract insights. We're talking to customers. So it's very important to figure out how the hell to train our product and engineering teams to extract insights from our customers. Because customers can't tell you the solution, but you can damn well get the problem out of them. You can get the problem out of them and you got to observe how they're using the product to get problems. So one of the good examples I use is Square Capital. Where Square Capital was a product, Square was a payments company for a long time, for three or four years after we started seeing that. One of the reasons in the customer success tickets, a lot of things, people wanted the money faster to be sent to them. And we built the faster money feature. But the reason they wanted the money fast and is they wanted to invest in working capital. They wanted to invest in working capital. And we said, okay, that's really the problem they're trying to solve by getting money faster. Because these people are living literally on each payment cycle they would pay essentially their landlord and other things. So we said, is there a way that we can build a working capital product for them that we already have a bunch of signals, which is the payment data we have there, we actually collect their payments, we have their bank account. Can we use that to underwrite them better than anyone else can? It turns out we could. We launched Square Capital and. And the same happened with almost every product I've been involved in after the first one that the company launched has been by observing something about the customer behavior, understanding the root cause, and then building a product to address the root cause. And that's how you build a series of interconnected products. That's how you build defensibility. Your defensibility is not going to come from product one alone. That's remarkability. Defensibility is going to come from product 2, 3, 4, 5 that are going to surround the first product and make it really hard for a competitor. I think Service Titan, which a lot of people criticize when they went public because their revenues, etc. Forget all that. It's a great example. If you look at the Service Titan S1, the public document is a great document because they have built, I think, every single product needed by the field service agents that are the target customer and they've grouped them into buckets, but they have truly served every single need where they have made sure their customers are using them top to bottom for every single need. And that happened over 10 years. But that's the kind of thing that's going to be very hard. Even now I see some services company trying to displace service side and it's very hard because you try to displace one product, but the company, the customers are using seven different products and you can't displace one product. So building an ecosystem of products is going to be one very important thing that you need to do as you grow. And this is Exactly, I think two years ago or one year ago, I would say, oh, you get to $10 million, ARR, et cetera, then you launch a second core product. Now I think you probably need to launch it as soon as you get PMF for the first one. You need to start planning your second one because that's your defensibility. That's your core R and D you've got to do. And what is the second core product? Be honest with yourself. It's not a feature. It is second core product which unlocks meaningful distinct budget than the first product. Meaningful distinct budget than the first product. Or meaningful differentiated value in case it's not a paid product. It doesn't matter even if it's a paid or a free product, because again, companies get very confused. If you have six products, which one should I charge for? Which one you shouldn't. The reality is it's okay to not charge for some of them. Some of them can purely be retention products. Capital, for example, doesn't make that much money for Square. But it's okay because turns out once you use capital, you're hooked. You're not going to leave the company, you're not going to leave Square. It's okay to not make profit. So be careful about figuring out which products are your profit pools versus which are retention drivers. You'll have a suite of products, some will be retained. Gmail is a great example. Why the hell does Google have Gmail? It makes some money through ads. Minimal. But reality is a retention driver. It gives them a lot of data for training purposes. Once you use Gmail, you have a Google account and they have a lot of things they do with that. But it's not a profit pool. So it's okay to have profit pools and retention drivers. Not every product, you need to suck all the money out of it. But regardless of that need to launch a second core product sooner than ever before, that is going to be your moat. That really is the moat. The ability for a company to launch products. Waves of innovation over time, and then innovation. How do you actually generate ideas? Every company I've been at, hackathons have resulted in at least two or three core product ideas. I think engineers, product everyone, even non product engineering functions, love the opportunity to get out of the silo they are in and come together as a company for a week, a day or something like that, once a quarter to hack on products. And you could even have thematic hackathons which I've seen work really well. For example, you could say we want to solve problem X for our customer. Let's come up with ideas and let's build products. By constraining the time, you make sure that people are just building very, very rapidly, basically prototypes. And then you can see people vote on it. You see which are the top three products. Some of the things I've seen as Prizes for the top performers they just present to the board or they get $100 gift certificate. More than that, they just love being recognized and love the opportunity to work together. And this also allows you to identify talents because if you find that there is somebody, an engineer, a PM or even a salesperson, who grabs together six people and they build a prototype for a really compelling thing, guess what? That might be the seed team for your next product. And you could basically pull them from what they were doing earlier and get them to work on this product instead. So, hackathons. And then again, you are at this point where your core product is important to scale, but you do need to have some resource allocation framework and you can use. There's multiple frameworks. Google had 70, 20, 10, there's another framework called Horizons. You need some way to allocate resources between your core product and your new product. And so the core product still needs to be the main thing, but your new products need to get to, say, 20% over time. And at some point the new products will graduate to becoming a core product, at which point you fill the 20% bucket with another new product, et cetera. And then, most importantly for the new products, it needs a single threaded leader. You'll see that the core, once the core is starting to move, the core always resists any attempts for other products to take resources away from it. So you as the CEO or the founder, have to be really, really strong and make sure you're giving space for innovation. Otherwise the core always threatens to choke off all innovation. At square, more than 50% of gross profit in revenue comes from a product called Cash App, which is the largest fintech app in the us. But for several years, the Square part of the company tried to kill Cash App because it wasn't making any money, it was burning money. It had some of the best people at the company working on it. So people were like, and we were going to go public, this was about eight, nine years ago. People were like, why the hell are we funding this thing? We have to go public. We have these numbers to hit for the street. Why the hell are we putting 100 people on something that's not making any money? Actually burning a ton of money through a referral program. And Jack, our CEO, stood in front of the company, defended it every week at all hands. And thank God he did, because otherwise the company would be half the size it is today. So these things take a while to get going. And you've got to defend it. Obviously that doesn't mean you defend it illogically you've got to treat them like startups. You've got to just like your VCs treated like startups and give you metrics. You've got to constrain them from a funding point of view. Don't over invest in them, give them a small team, get them to hit a certain metric again, PMF scale, et cetera and then you fund them. Do not over fund these things that constraints beat creativity. So that's basically the scaling the product piece outcomes habits and then innovation optimization you'll do. But really innovation is the more important thing and then scaling the GTM number one thing Demand gen Demand gen is going to be something you have to think about every day and there are many many different ways to do demand gen and you're going to find your own thing based on many many different Here are four different examples. Many of the legal AI companies are using events as demand gen. If you I don't know if you're involved with legal AI. So turns out there's hundreds or thousands of at least in the U.S. regional events that lawyers go to. So it's become a good way to generate demand. Zapier famous for using SEO Slack use product LED growth where you get one person, they shared across the company. Replit uses social and brand and promotions a lot. So different folks, different kinds of companies use different it has to be consistent with your customer base, how they use the product, how they find it, how they make decisions, et cetera. But you've got to pay attention to figuring out how to scale and ideally you have one golden channel. You have one golden channel, you obviously be testing smaller channels. But if someone asks you how you do generate demand, if you give five answers that means you really don't have one. You really don't have one. You need one that's like your core bread and butter that's doing 80% of your demand and then the remaining 20% are testing things out. But you need 1000 thing, that's 80%. You need one thing that's 80%. If you don't have one thing that's 80% you need to keep working on making that one thing 80% the second thing. The number one difference between fast growing and slow growing companies is sales cycle. Simple, that's it. Sales cycle. And sales cycle doesn't mean you're selling, it's mean how quickly from the time your customer sees the product do they become customers. That's why self serve companies grow so fast because there's no one to touch. Customer lands on Website signs up and grows, becomes a customer and pays you. So from the time of salesperson touching your customer to the first payment, what the time is, the faster you can cut that time down, the faster you will grow. And so many companies get stuck in that fourth and fifth bullet. 300k for six months. I have a 500k client, it's going to take six months. There's a POC, then there's some other thing, then infosec, et cetera. They are dead. That's over definitely the 1 million, 1 year they're dead if that's their first customer. So I really suggest as a scale up or startup, you stay in the first three rows, first three rows. Cut your acv. Cut your ACV of making a simpler product. So many times when I see startups with the 500k product I'm like, I don't want to see this crap. Make it a 50k product. Cut 90% of the functionality out. Make a lightweight product. Make a lightweight product that instantly goes in and takes three weeks to sell instead of six months to sell. If you sell six months to sell at a startup, you're dead because you don't get any feedback. You have no idea what's going to happen. Six months is a lifetime. You have no idea what's going to happen. The number of companies I have lost personally that had six nine month sales cycles and just somewhere along the way something happened. Decision maker went away, some POC died. They just died. They just died. So please try to see if you can cut your. Simplify your product and you can upsell. You can upsell. Of course you can upsell. You can upsell. But start with a small lightweight product. I would much rather see you hit 200k with 10 20k customers than 1 million with 2 500k customers. I don't care about the 1 million 200k customers. I would rather see you 10 customers with 200k because I can see that you have some muscle you've built. You've been able to get to 10 customers using it with 20k. Hopefully there's some retention. I can see that with two. What do I know? It might be your brother's friend or your buddy from college who's using it. I have no idea. It could be completely random. I have no data points. 2 is zero data points. To me, 10 is more. I'm okay with low ACV. In fact I want to see low ACV because then your NRR will also look really good. That's the beautiful thing about low acv. Your NRR looks really good when you upsell. If you have high ACV then you can't upsell. Strange. And then I think the foremost important metric to track as CEO, I think it's for new customers. What percent of reps are hitting quota and what's your pipeline coverage? Pipeline coverage as you know is okay. If you want to hit a million dollars in new ACV or new ARR this quarter. How much pipeline do you have entering the quarter? You better have 4 million to 5 million. 3x no longer cuts it. You better have 4 to 5 million of pipeline entering the quarter and then you better have at least 70% of reps in quota, if not 80%. If it's less than 70% I would say you don't have product market fit or you've not trained your sales team well, you're not hired well. And then existing customers. I'm looking at both gross revenue retention and net revenue retention. I think NRR is not enough by itself because NRR can be influenced. With one or two customers. You might have massive churn across the base. But then two customers are driving up NRR and 150% turns out GRR is like 50% or something. So I want to see GRR pretty high because it shows me the product is actually valid and valuable to customers. And then some of them are expanding. So both of them are important. Here are the four things I think you should use when you think about the GTM in particular. Sales team. Again, I understand some of you might not have a sales led approach. They should have sold at a price point in their earlier jobs. They don't need to be in your domain but they should have sold at your price point. They should have hit or exceeded quota in your earlier those. One of the biggest things is people don't look at their prior. You've got to understand did they exceed quota or not. You've got to get their commission sheet, you've got to get their comp sheet and see did they exceed quota or not. Maybe you can ask if they don't want to share it with you. They can share with the recruiter but they need to show you got to know that they were not an underperformer in the prior role. Can they generate their own leads? Can they generate their own leads? A lot of folks at mid sized companies come in expecting, oh, a demand gen operation is fully set up. You're going to feed me leads, I'm going to close them. Turns out when you're silly young, you don't have enough leads to feed all mouths. So you need salespeople to generate their own leads at least a little bit. You need them to be able to generate their own leads and then you can't train them for six months and say I'm going to put up points on the board six months from now. They've got to start putting up points on the board within a couple of months. Ideally even in month one. I want to start seeing them close deals. And then your sales leader at this stage should not be a VP, they should be a player coach. At least 20% of them, if not more should be showing, modeling, closing deals and going on deals and closing it themselves. So you got to hire them. This is one of the most challenging things to get right. Forget the VP of sales. I mean most people get your hiring and firing A's till you get the right fit. It's so, so challenging. And then scaling the org org structure right now, I would say we are still in the generalist mode. Remember in the startup phase we are in generalist mode and in scale up we are in specialist. We are slowly starting to make the transition of being generalists to starting to hire our first specialists in some areas. Do not hire managers. One of the most interesting things that has happened over the last year is that companies, even the largest companies like Meta, have started saying you're either a manager, manager is a full time role, which means that you can manage 20 people or you're an IC. Okay, if you're managing three people, that's not a full time manager role. So they're basically cutting. That's called span of control, which is how many people you're directly managing. So if you have roles which are managing three or four people, they better be also doing like 50% IC work. And so I think that's what you should demand. Either people are managing 20 people or their ICs or if they're managing four people or five people or six people, they better be doing IC work. In addition, unless their org is going to grow to 15 people, unless they're going to manage 15 people in the next few months. So that's, I think increasingly I don't think managing six people is a full time job is what people are saying. And it's right, I've managed eight, 10 people, probably could have taken easily another 10 people. And so I do think there is some push towards having flatter orgs and having basically people with large spans of control and having more ICs. I should have made it even stronger. I Should say flatten your org more. Flatten your org more. Try to avoid fewer middle managers, few middle managers who are managing three people and then each of their reports is managing five people. That's 15. Hang on, why do you need three people managing three people? You should just flatten the org. Remove the expensive middle managers, make them ICs or make each of them two ICs each and then have 15 people reporting to your head of function X. And then the other one is create initiative focused cross functional pods. I gave the example of new customer acquisition. I think the new customer acquisition works only if there's a group of people who are dedicated to it, from product design, engineering, analytics, marketing, maybe sales, et cetera. They all work together and they all think of themselves as part of the new customer acquisition pod. I think every company can benefit from removing these silos and having people work in pods that include not just product engine design, but other go to market functions also. Because then they're all united. They work together in one goal. One of the biggest challenges that CEOs face is they feel that go to market and their product functions are working at odds with each other. They have no idea what the other is doing. And the CEO is the one who's doing coordination between them. And the way to avoid that is to blow it all up and make sure the pods are created and they all feel they're part of this pod or this group or this team, whatever you call it, xfn, whatever you call it. But you need to create cost functional pods for the most important initiatives at the company, company for the most important issue of the company planning. Hopefully this is the time when you're starting to do plans, which really means setting goals and then figuring out each team. Each pod figures out their way to hit the goal. So if you're very young, I would say weekly when you start out, hopefully you did weekly goals. You're probably at a point where you're doing monthly. You're probably somewhere between monthly and quarterly. And I would say quarterly. Maybe it's too hard for companies because things change too fast in a quarter. Things change too much in a quarter. So monthly might be the right cadence till you get to 30, 40 people. And then maybe you move to quarterly. At public companies, obviously there's annual, quarterly, half annual, and various things, but I think monthly or quarterly, and then you need to have an annual plan to start with. I'm sure your investor is already telling you you need to have a forecast, a plan, but you need to be able to edit It So hopefully you have a good finance and strategy person can be worth their weight in gold here. So again, as a founder, if that's not your strength, hire a person who can be a finance and strategy person. Not just an accounting person, but somebody who can help you manage your capital allocation, manage a bunch of things around creating plans and whether you're hitting plans or not. So make sure you have the right help there. And then you need to have a set of. This is. What is your cadence of execution? What is your cadence of execution around which your teams execute, do you hold them accountable, et cetera. So there are three things I think that three kind of processes you could think of instituting. One is weekly business reviews. I talked about initiatives. Every company, I think is essentially a collection of initiatives. In general, when you think of your company execution, you'll probably in your mind think of initiatives. And each initiative has a cross functional team with one person being the DRI or the directly responsible individual for that team. So what you want to do is you want, for some of those initiatives, you want weekly business. Actually, no. Weekly business reviews is, is done once at the company level. So the weekly business review, the only goal of the WBR which is started at Amazon, is to figure out am I hitting the quarter or not? Am I going to hit the month or the quarter? Am I hitting the quarter? If not, what can I do right now to hit the quarter? And so finance is a very important part of this. What resources can I move to hit the quarter? Many times it's budget, it's people, it's, it's something else. So literally it's a decision making meeting on figuring out how to bridge the gap from where we are to hitting the quarter. And so if you run it seriously, then the CEO and every exec who can drive execution shows up at this meeting with a small group of people who figure out what does the company need to do to hit the month or hit the quarter and what is the gap? What do we need to move, why are we not hitting it? And then more importantly brings force to bear on the most impactful thing we can do to hit the quarter. Initiative reviews are the reviews that you'll conduct at the initiative level. And the frequency of them depends on how urgent and important it is. Some two by two metrics of urgency is important. Obviously with some things you could do a daily initiative review, which some you do weekly, some you'll do fortnightly and some you'll do monthly. So it depends. And then you have to demand that every Initiative sends you a weather report. I call it weather report. That's a doordash terminology. It needs to send you a weekly status report and you should figure out what the right format is. And everyone needs to follow it on a certain day of the week, probably on a Friday or a Monday, they should talk about. And it always needs to start with goals. What is their goal for the time period, say month or quarter? Where are they in that goal? How far are they? And then what's the gap? What's the gap and what are they doing to fix the gap and what's working well? What have they done so far? And then most importantly, what help do they need from you, from the execs to help bridge the gap or to make sure they're working well? So this is a very important thing because by email it keeps everyone apprised as to what is going on in addition to the initiative. Because especially if the distribution in general, these weather reports can actually, and I think should actually go out to the whole company, even if possible. Because turns out many times when you send it, a lot of ideas and sparks emerge. If something is not doing well, then someone else at the company might have an idea, oh, I didn't know it was not doing well. Why don't have you tried this? Or have we tried that? And ideas can come across the company. So you want to make sure that this is a way to get transparency across the company as to what things are working and how they're working. And then I think people. I talked about what I look for in hiring, problem solving, an agency. The other thing I say is hire for spikiness. What I mean by that is typically you'll have a panel of people who interview somebody and they'll give scores between say one and five. If somebody gets all threes and all fours, don't hire that person. Don't hire that person. I would much rather hire somebody who has two ones and two fives than somebody who has all threes and all fours. If they have two fives, I know they're excellent at something and maybe they have two ones. If it was something else, I would rather lean into their strengths and make sure that obviously it depends on what the fives are for, but if the five is something that's a strength we could use, I would rather hire them and really lean into their strength and versus trying to cover up their weakness. 3 and 4 means people are good, but no one's truly pounding the table. No one says they're going to raise a bar in A certain area, but a five means they're excellent and they're bar raisers. If they're two fives, that's very rare in theory. And I would hire somebody with two fives all day over someone who's four fours. And then titles I always have to put in my obligatory picture on avoiding director and VP title for as long as possible. I am proud to say that Indian company what fix? Actually it's a global company, it's not an Indian company because most of the employees are. They've switched to descriptive titles last year. There are more than 500 people and they're the largest ever company that rolled back their svp, evp, vp Director, Senior Director titles completely and they have no titles anymore at the company. Again, it was founder driven. I was like, I told them when they came to me two years ago, they were like, we read your post, we want to implement this thing. I was like, you're too late, you shouldn't try this because you, you're going to have to. There's massive discontent that's going to happen because there are hundreds of people that they're taking titles away from. It's easier to not have something that would take away something as loss aversion and all that. But they were like, no, you're going to do it. And it took them a year but they did it. And they have zero titles. Especially India is a very, very title centric society and the fact that they already have titles pulling away, absolutely incredible. Absolutely incredible. So just give it as long as possible. I'm telling you, I know it seems, oh, this person is going to join. They just want the director title. Once you do the director title to this person, guess what? Every other person in your company is like, ok, got it, that's fair game. Now they're going to all come and ask for director. The first VP title you give. Everyone else in the company is going to ask for VP title. I'm telling you, it just opens a Pandora's box that you don't want to open. Now obviously maybe once you're at the scale up stage, you give it but avoid it till you are 200 people or something or hundreds of people if possible. And then performance, you need to have your people need to have some idea of how they're doing. They need to have some idea. So yes, you don't need to do crazy performance reviews. But at least if a manager is managing someone, part of their management responsibility is to give them feedback, is to have conversations with them on a regular basis and to let them know how they're doing. A lot of people just suddenly fire somebody without ever giving them notice. You're like, I'm packing my bags. I didn't even know I was doing poorly. And then you need to have, especially for engineering and sales, you need to start having ladders. Those are the two functions which have the most number of people. So people need to know am I growing in my, how am I getting promoted? So you need to have some internal levels where you get them promoted. Because again, if you have 20 or 30 people in a certain function, you need to start thinking about ladders, which is the internal promotion thing, and then one on one. So fully people are doing small group meetings. Your job, once you get to 40, 50 people, it's going to be hard for you to meet everybody one on one. You should try to at least once a quarter go into your direct reports meetings and sit in on them and see and invite a conversation and questions and just see how they are being run. I think it'll be tremendously helpful. Hopefully you're all doing all hands on a regular basis, fortnightly, if not weekly. And then I recommend that every CEO if possible, sends an email out to their company once a week or once every two weeks. I think it's very, very important. Number one question in employees mind is what is my CEO thinking? What's on their mind? Because they all want to help you, but if you don't tell them what's on your mind, they don't know what's on your mind. So if you just tell them again, just search for weekly CEO email with my name and you'll see some examples. A lot of companies again have started this over the last few years and have seen tremendous engagement. It's a great employee engagement tool. And that's basically it. That's basically it.