Gokul Rajaram on Product, Leadership, and Building Enduring Teams

Foreign.

So Gokul is currently at Doordash. He's on the executive team at Dodash, on the board. He leads coop dev and strategy at Doordash. Prior to Dodash was at Block where he led basically all a product. Prior to that, basically led ads at Facebook and then before that was at Google. So pretty much, you know, you can imagine like all these companies was on the board of Pinterest and is on the board of Coinbase and Trade Desk. The way we're going to do this is Gokul's going to go through, he's going to present some slides, we'll go.

Through it and then we'll open it.

Up for founder questions. Thank you for joining us.

Thanks Rajan and great to be here folks. One of the interesting things I reflected on when I was thinking about this is every company I was at, it's changed its name after I worked there. So I worked at Google, became Alphabet, worked at Facebook, became Meta, worked at Square, became Block, all after I left. And typically this happens when companies have multiple businesses. So it's hard for the primary product to be 90% of the business happened with Google, with YouTube, Meta, with other things, etc. So anyway, interesting anecdote as I was thinking through my career. So here's what I wanted to talk about. There are three stages of the company. Every company goes to ccages. Hopefully the best companies are lucky to go through all three. Many companies unfortunately fail in the first stage. Most of you are probably in stage number two, somewhere between one and two. Some of you might be in stage three startup, early growth and scale up startup. The three things that matter. Actually the first thing matters 90% getting to product market fit. As Mark Andreessen famously said, nothing matters unless you get to product market fit. Once you get there, you can think about other things. The second thing that matters in order to get to PMF is culture. You've got to and what I think about when I say culture is you've got to hire people. The first 10 employees of the company are going to driven the culture of the company for your lifetime. I'm sure you look back those of you who run companies with 100 people, you look back and see how the first 10 employees determine everything else the next 90 that come and how the ethos, the way you work, the execution, the operations, et cetera, very important. The third one is it's generally a generalist culture at companies. So you generally hire people who are generalists. When I look at the first 10 people at Google, Facebook, Square, all of them. And that's both good and bad. They were amazing and scrappy and could do all kinds of things. But many of them were challenged when the company became specialized over time. As happens when you start getting into the scale up phase, which is phase two, once you attain product market fit, this is phase three, scale up. At scaleup you have multiple businesses. So Google for example, having multiple businesses, et cetera, you have executives that you bring on. One of the biggest mistakes we'll talk about this companies make is bringing on executives too early. The third thing you have is you focus a lot on org structure. And the fourth thing you have is predictability. So when you get to these phases, you're in the scale up phase. In the middle between scale up and startup is early growth. And what do you think about in early growth? Two things. One, how do you scale the product prior to this phase? Most likely the founder or one of the founders is the product manager of the product and that's they're essentially owning the product in all aspects. This is when you start having to give control of the product to someone else. And a lot of founders falter here. A lot of them don't want to do that. But in order to scale the product you've got to give up control. And the second thing is scaling the organization. Like I said, the organization was made up of generalists till now. We've got to figure out how to transition to an organization at least partially of specialists and it's an interesting evolution. So let's talk about scaling the product. Sorry, I'm just whipping through these things that ultimately look, here's the reality. Every company is a special snowflake. And the reality is this is not a prescription that every one of you is going to follow. This is general things I've seen and observed across. I think I've invested in 500 companies and worked at associated with seven companies that have hit a billion in revenue. These are just some general patterns. However, the journey each of you are going to take is individual and unique and different and bespoke. So this is simply a set of guidelines and observations. Each of you are going to have slightly different experience with these. So the three things I think are important in scale my products is one, training the team of around how to work backwards from outcomes. Most product managers, most teams are used to the founder. Before this phase you are used to giving direction on what to build because you know what the outcome is and you're working backwards. Now you've got to give the outcome and the team has to tell you how they are going to achieve that outcome. The second one we'll talk about is habits. What habits inculcate, what are the process? And the third one is how do you break up optimization of the core product versus innovation or net new products or new features. So if you think about outcomes, the four things to consider here is how do you start setting goals in the form of customer outcomes? I'll give you a very simple example. I was talking to a company the other day and they said, I asked them what's on your roadmap? They sent me the list of okrs. It's a pretty. It's high up in the. They sent me their OKRs. They certainly said I hadn't heard from them in six months. They said, here's in Q4, they sent me their OKRs for their goals for 2024. And I was like, what the hell is this? They basically had written a bunch of things to launch. I basically forced them to completely scrap the OKRs and set outcomes. And I forced them to, for each outcome, figure out what are the different ways to achieve that outcome and then figure out what the best option is. And that doesn't need to be done as part of the planning process. But overall, companies before scale up, before this phase are used to have a massive focus on features versus thinking about what the customer goal is. I have a saying, if a feature doesn't move or change customer behavior, that feature shouldn't exist. Is it even a feature? And companies unfortunately tend to become feature factories as they grow. It's very easy. Any of us, given any product is probably able to take and give 20 different features for a product. But the reality is the best products probably have five features that matter. And the reality is how do you figure out what five things that matter? And that's really how to build simple products that drive most of the value towards customer outcomes. So the biggest challenge here is figuring out how to coach the teams on how to solve backwards from there. And this is the hardest thing. And I think founders are extremely frustrated because what happens is founders keep the outcome in their heads and, and they translate outcomes into features, give it to the teams, and when the team implements that feature, it doesn't hit the outcome and the founder gets frustrated. But the reality is the founder didn't do a good job articulating the outcome they're solving for and empowering the team to achieve the outcome. So think about when you tell your teams what to build. Even as simple a thing as build an Android app, that's not an outcome oriented goal, that's a feature oriented goal. Instead the goal should be improve daily engagement of my users from X to Y. And that one way could be to build an Android app. The second way could be to improve website mobile website and you need to give the team the allowance the opportunity to figure out how to do that. The second one is building muscle around validating hypotheses. So in general, a feature is simply all of us probably or most of us in science classes. You have this notion of experiment to validate a hypothesis. A feature is simply an experiment to validate a hypothesis that you have and launching a feature is not success. So really putting it in your mind that a feature launch is simply when the experiments have validated the hypothesis and the feature rolls out to 100% almost. This means that you've got to set up the muscle to build an experimental framework so that every feature, especially every major feature is launched only to a has a the question you need to ask is why are you launching this? If you can just train yourself before a product manager, product team comes to you and says we're going to do this, if you can just ask why? Why are you launching this? What is the hypothesis behind the customer behavior change that you have that governs this feature and push them to articulate how they know that this is going to happen? And this is what the point number three is. How can you validate hypothesis without writing code? The number one what's the scarcest resource in your companies? What is it? What's the scarcest resource in your companies? Developer time, engineering time. It's the most expensive, scarcest resource. Yet we persist in wasting their time in just saying let's build this feature without having any sense of whether this feature is going to move anything about any customer's behavior. And so one of the biggest muscles we need to build at a company is how to use no code tools, emails, operational things, how to use lower cost resources, less scarce resources to validate hypotheses. So think about what are proxies you can use to articulate to engineering and to convince yourself that this scarce resource should be used on validating hypothesis. We are all prone to, let's say let's build this and test it out. Can you test it out without building it in engineering terms? So those are the four things I think. How do you build a team that understands how to take outcomes? How do you train yourself? A lot of the problems with the founders themselves, they don't know how to articulate outcomes. They don't want to give up the outcome. It's in their head. They just want to say build this feature. You need to train yourself to give the outcome and negotiate outcomes versus negotiating features. Second, you need to ask why? Why are you building this? You need to hold them accountable to understanding the hypothesis behind. Every feature has a hypothesis, sometimes it's implicit. You need to get your teams to make it explicit. Why are you launching something? What do you expect to happen if you launch this? What's customer behavior? Do you need to change? And then finally you need to train them and push them to not use engineering time unless absolutely necessary to figure out how to validate hypothesis that are in code. Let me pause here. I think otherwise I'm worried that we might go quite a bit and then what questions do you all have around this specific piece? Yes.

So what we have generally seen is that while we create hypothesis and test it out in an OPS heavy way, sometimes the OPS heavy way of testing out the hypothesis is so biased towards bad customer experience that the hypothesis generally doesn't play true. But when the hypothesis is built using engineering bandwidth in a proper product oriented approach, the hypothesis moves the needle or the product that is built moves the needle. So you think in this there is a bias of implementing it quickly via ops heavy way or a product heavy way without using engineering bandwidth and getting bad results and missing on features which could actually have needle when done the proper way.

I think you're absolutely right. The question here was ops heavy and engineering heavy could result in dramatically different experiences. The thing is, you've got to really articulate what is it you're testing for. For example, I would posit that at younger stages of the company you need to go after things that are 2x that are not 5% optimizations. You need to go for 50x optimization because you're not Facebook scale. Facebook can do 1% change. So if you're going after 50x optimization or 10x optimization, even a bad ops experience result in a 2x difference, right? It's only when you're aiming for 10% change and ops is 1%, you're like it doesn't matter or not. But you should not be doing 10% changes. You should force your team. Maybe that's the other thing. We need to go after things that are because if you have 5, 10 million in revenue, who the hell cares about a 10% change? You've got to go after five exchanges. And at that point I would say even an OP experience that is half as good or 50% worse will still result in a 2x change. The second thing is we need to clearly articulate what is it about the experience that will change the customer behavior. And you're right. We need to figure out even with the awesome experience, can you put the most polish in that part of the experience? At Square we had the most horrible product for multi location chains. Multi location we had 100 location chain which had 100 accounts on square. Managing it, we didn't care because that was not our goal. Our goal was to be the best product for a certain segment and deliver amazing value for that segment. So I think you're absolutely right. But I would argue a that we need to go for massive hits and if they miss, that's okay. But if they hit, it should double the size of a company. And second, we need to really clearly articulate even within the hypothesis what part of the customer experience is most important and try to optimize for that and sacrifice some of the other ones because it's okay. No one can build that. We are not boiling the ocean. You've got to focus on what matters the most to our customer.

When you say customer outcomes metrics or is it workflows or journeys?

No, no, no. It's customer outcomes. Customer behavior changes, for example, Very clear customer outcome. Get my customer conversion rate from landing on the website to activation to 50% up from 25%. It's metrics only. It's metrics because every metric. So that's basically. Yeah, it's a metric that is a hypothesis around a customer journey. It measures a customer Fazer guys.

So yeah, just one more question that have you seen experimentation getting adopted by B2B companies because it is more difficult to do experiments by. You need to get some customers which are not too many.

Yeah, you have to do Pre post for B2B. That's small scale. You've got to do pre post. You can't do AB testing because you only might have 10 customers or 20 customers. But you still need to have some hypothesis. Again, if it's needle moving, the pre and post will change enough. If it's not needle moving you won't see a difference. And then of course it could be correlation or causality. But you can generally infer that if 90% of the 10 customers did something different, then something was it was due to something you launched. One more question. When you say that you solve backwards from outcomes, what are the guardrails that.

Get put where the team doesn't take shortcuts to be able to, let's say amplify that for example, if I were to say dau by MIU ratio for me has to move by 5% absolute. There are many paths to this. So can you double tap on the second line?

Well, first thing is, remember when you have an outcome, you also need to. You alluded to this. You also need a check metric, which means that you need to make sure that they are doing bad things. So you need to do that first. Second, you need to figure out how to train them on generating multiple alternatives, achieve the same goal, and then evaluating those alternatives in a very lightweight way. There are various frameworks like ice, which is impact, conference effort, Rise, which is reach all kinds of things, but those are the things that's basically the muscle you need to build. First, outcome. Second, what are the ways to achieve the outcome? Third, ranking those outcomes and fourth, getting data to rank them. Right. I mean I can rank them, but how do I know? And this is where building, validating them without writing code will come into picture the habits. Second thing is, we talked about outcomes. The second one is habits. Number one habit which all of us have gotten away from as the rise of the data driven product manager has come into work is customer discovery. I don't know how many of us, after a product takes off, how many of us actually talk to customers. Many of us basically just rely on data from our dashboards to basically give us a proxy for customer behavior. But the reality is you talk to a customer once a week, that just changes how you think about things. And so the number one thing I force teams to do is to make sure once a week they're talking to at least one customer. And what is interesting, it doesn't need to be the same kind of customer. There are many, many different segments of customers. There are churn customers, newly activated customers, customers who are continuing from last month to this month, customers who used you once, many years ago, didn't ever sign up. So every time you talk to a customer, you understand. And remember there's good ways to. The best way to interview customers is by asking them about their journey. Ask them the context in which they used your product or alternative products and ask them what you experience with the product. Do not just ask them directed, yes, no questions. That's not going to yield anything. Ask them for rich customer stories because those customers are what you can take back to your team and really have the qualitative overlay on top of the data you have. So I think customer discovery, really, especially your engineering teams, if they can even listen in a customer call that someone's Doing that will massively change how they think and build customer empathy. So get them to do customer discovery. Second, we talked about this experiment, mindset versus feature mindset. You've got to make sure that the habit here. You need some help from your engineering teams to build a data or experimentation framework. There's a lot of good tools like statsig. I'm an investor, that's why I mentioned that. But there's many other tools. LaunchDarkly, et cetera. Need some experimental framework that they can use to run experiments. The word feature itself I increasingly despise because I feel it really leads to feature factoring. Mindset, who the hell cares? Look at your okrs. Look at your goals you set. If your goals are on specific features, they are wrong. That should not be the case. The goal should all be in terms of customer behavior changes. Customer behavior changes, which then ladder up to business behavior changes which are revenue, profit, etc. Remember, business behavior doesn't change unless customer behavior changes. No one is going to give you revenue until someone becomes a customer. Right? A subscriber is when someone goes from a state of, nope, not being a customer to a state of becoming a customer. That's when you get a subscriber. Almost every revenue or product, business metric you have can be transformed, translated into a customer behavior change. And then find the analytics watch parties. There are really good tools now where you can again, this is tied to the customer discovery. Analytics is not just about looking at data, it's about looking at how the customer journey happened on your website or your app. And so there's a company called fullstory. Exactly. So I know companies that actually once a week have an analytic, have a watch party and they have a mobile. There's a mobile counterpart also. And then fullstory is someone else. You can actually just see how customers, as you know, are traversing a website and whether they rage clicking on something, thinking it's a button, but it's not a button, all kinds of things. So you can actually do this. And this is a different way of building customer empathy. Holy crap. They thought that this thing was a button or they tried to go here and they were trying to type this. And so you really build empathy when you see this customer journey. Because I think these data tools, these dashboards really separate us from our customers in a way that is somewhat pernicious because you, you don't realize it, but you no longer think of customers as customers. You start thinking of them as points of data. And I think that's really bad for A product centric company. I think we really need to understand our customers as individuals are trying to accomplish a goal. And I think the first and third things are one way to do it. Let me pause here, see if any questions.

We are actually building. We are building a product which takes several months, if not a couple of years to go from iteration to iteration because it needs to be manufactured. Basically we are building microcontrollers. How do you think the experiment mindset can play out over there?

Let me think about that. I think it's one of the hardest things because hardware products, once you send it to the fab, you kind of are. It's out of your control and then it comes back. I've not seen good ways to do this. It's purely a definitely influence and square. Also we have the same. I think you. At the very least what we would do was we would have these shells, we would have these mocks that we would give to merchants and we would get them to play around with it and use it. So at the least you want customers to handle it and play with it. But once it goes to the fab, it's out of your control. So let me. Let me chew on it a little bit more.

I have a question please. What do you think about the role of surveys to test hypothesis? I understand that's data points, but in.

Addition to customer interviews, I think surveys are good way. If you can control for the biases in surveys, that's a challenge, right? Remember, surveys are voluntary bias because people answer the survey instantly it changes the. So that's my worry about surveys. The people who answer are the people who have that problem or they can tend to bias you. So if you have a good holdout group or if you have a good way of controlling for that, I think they can be helpful. But I'm a little bit nervous around that. Surveys could be good as one. I always feel none of these by itself is good. But surveys plus individual customer interviews plus data together can paint the complete picture of what problems are worth solving. Third one is innovation outcomes, habits, innovation. I think there is something to be said every company that I've been at that has had a hack and hopefully most of you are thinking about this. Hackathons, hack weeks 20% because you want ideas to come from bottoms up. Especially new net, new ideas to increase customer satisfaction. Because turns out your engineers, your PMs, your ICs are the ones closest to the customer and you want them. There is just such a sense of freedom once a quarter or once a month if you're not just working on this one thing that you're working on, but you're free to explore. And that's what a hackathon gives permission to do. And some of the best products that companies I've worked at, Square Facebook doordash have emerged from hackathons where there was a clear problem that people saw, but they were forced to because they were part of this team. They couldn't work on this, but the hackathon gave them the opportunity to work on. One suggestion I would give for better hackathons is you could have themed hackathons where you could say a theme for this hackathon is how to improve our customer activation rate or how to improve loyalty of our customers. And so everyone is basically working on that specific customer behavior change. And so the theme framed in form of customer behavior could be a really interesting way of getting more ideation around it. The second one is I think innovation around how do you allocate resources to innovation? I think this is the time when you go beyond your first product and now you're starting to think about potentially second products. And it's very important I think at every company because product people are involved in founding companies there's a lot of excitement about shiny new products, forgetting that the first product is still not very mature. And it's very important to have some kind of framework to make sure we are guard railing most of our resources to work on the core product. It could be 80, 20 or something to make sure maybe 20%, probably likely more like 10% are working on net new products. There's also Horizons framework which is probably at the next stage where you have Horizon 1 products which are things that impact your bottom line or your top line in the next 12 to 18 months. Horizon Two things are things that impact your product or your business in the next 18 to 36 months. Horizon there are things that are three to five years and you do 70, 20, 10 or some framework. But make sure when new product ideas emerge that you are still keeping the main thing, the main thing and keeping most of your resources on the main product, the core product, because that still has a long ways to go. Remember, you're not at the scale up stage, you're not at 200 million revenue for your main product. You're still early. And finally, if you do have an innovation experience, if you do decide to fund a new innovation bet, almost certainly you need a single threaded leader for that team. What that means is this person needs to be working 100% on this new innovation, it can't be. They're doing 50% something else. It will fail, no doubt about it. Because it's hard to make innovation work. It's hard to make innovation work within a company and it's hard to make innovation work when most of the company is working on something else. So every single time I've seen innovation succeed is when there's an amazing entrepreneurial single threaded leader, someone who might already be starting to get unhappy with the current state of the company, who might have been one of the first 10 or 15 employees, but they were amazing at that stage. But they are starting to get frustrated with the bureaucracy you have today. And so think about who those people are and maybe that's the right person. It doesn't need to be an immediate report of yours or something else. You might need to pluck someone in from an IC role and make them the single third leader. And then they have to have a dedicated team that is completely full stack, which means they can go and change any part of the code base. They can do anything they want to versus reliant on other parts of the core team. This way the core team can keep doing their thing and the new innovation team can do their thing. Again, I think this is, again, I don't think you should even think about this until you get to maybe the middle of the early growth phase. The first part of the early growth phase is just to build the right habits to think about outcomes. Hopefully you get to the point where your product, your core product needs to be reasonably self sustaining first. If most of the if most of the org's time and bandage is going on figuring out how the heck to make it stand out to be a winner in the category, et cetera, you're not yet ready to start doing new initiatives. But this is where you start. This is the stage where you start having the glimpse. Because no company, I believe almost every very, very large company has to have multiple products. It is very hard to become a very, very large company with just one product. It's just very hard. I do think multiple products will be important, but when to start a second product is probably. You can't start it too early. There are some companies that are trying to do the very hard thing of starting what is called compound startups where they're building four products at the same time. But you need inordinate amount of capital, inordinate amount of talent and an incredible leader. I mean these are simply second or third time entrepreneurs who raised 100 million in their seed or something like that. To do that. Scaling the org. Five facets here, Org structure, planning, execution, people and communication. Okay. Org structures. This is the first time you're probably going to start hiring outside of engineering functional hires, true functional hires, who you're evaluating for function, things like marketing, sales. Because till now it's probably been founder led sales. For the most part it's been marketing through agencies. You're going to start thinking about it. You've got to be very, very, very intentional. I would almost strongly say do not hire any functional managers. And so I've met now several companies that have stopped that don't hire managers at all. They hire everyone, even candidates, even people they want to become managers. They will hire them as ICs for the first six to nine months and they need to be a good IC. And then they get the privilege of managing. Because managing is a privilege. It's not a right. It has to be earned. And so I think a lot of companies that I meet with, they instantly want to because a CEO doesn't know how to do the function. So they instantly feel hiring the head of X will solve that problem for them. It is going to create a new set of problems for you as soon as you hire ahead of X. So instead hire a specific, hire a good individual contributor or someone who can become a player coach over time. Instead of hiring the manager, hiring the head of sales or head of marketing. It might fly against advice, but the head of sales, there's lots of reasons why and we can discuss this, but that's my strong, strong recommendation. Do not have functional managers for as long as possible. Have functional ICs. I know they're going to be reporting to you and you've got to manage a functional IC. But that's. You got to. I've had CEOs who have had to do because they hired. One of my CEOs has fired his CFO, his head of sales, his head of engineering, his head of marketing. He's had to do every single one of those roles because he hired them too early, fired them and had to then take on their role because they had already built a team. So be very careful. Second one is the notion of cross functional pods. And I think this is really interesting because a lot of companies when they start to have functions, they start siloing those functions very quickly. So product and engineering work together. Sales works by itself. Marketing does its own thing. And one of the biggest frustrations you're going to have is that these functions not working well together. You basically become some kind of mini GM that is. So I met with a company two days ago. They're a fairly scaled company here in the US and the CEO basically was maintaining this massive spreadsheet of initiatives where they had tagged a bunch of people working on them. I was like, what the hell is this? And turns out that they were basically each function was busy doing their own thing and the CEO was basically trying to make the connections between the functions. And I think one of the easiest ways to solve this is to make sure your company is organized around initiatives. And each initiative has a cross function pod. A simple initiative could be new customer acquisition or increasing or retention or increasing loyalty, ideally phrased in form of customer outcomes. You'll hear the word again and again. And then you have a pod that consists of product engineering, marketing, sales ops, all of the people who are involved in executing on that initiative and they work together. Now they might report into whoever, but they work together and they present stuff together, they report on stuff together. And this is very important. They, you want them to feel that they own this outcome together. Number one problem I hear is the CEO feels that each of these functions or people working these functions is doing their own thing and there's no one uniting them. And the CEO is the one holding their mathematical formula in their head as to how what sales is doing. Okay, they did this product is doing this, how it all fits together. You can't have that. You've got to delegate one level down. And when you have these pods, you need to find the leader of the pod. So you need to anoint one of these people as someone. And leader simply doesn't mean a leader as in they're managing the people. It's simply someone who's reporting on the goal of this pod. And their only job is to figure out how the heck this pod hits the goal. These people many times are called biz ops or strategy and operations people and actually can be a very helpful function. They're reasonably much less expensive than product or engineering. They're typically ex consultants and ex bankers. And I would strongly encourage you to try using one of them. So almost certainly you can find a very good fresh MBA grad with good experience who wants, who's hungry to make an impact and has worked at a top consulting firm. I would say take one initiative that you as CEO have had challenges with and try it with that initiative. I promise you within two months you'll see results. Within a month you'll see result. It instantly will take the headache from you and then the outcomes, therefore. But it now links back to what I talked about. Outcomes. Outcomes should be set at the POD level. Outcomes should be set at the initiative level. And the holistic cross functional team that's working on that initiative should figure out how the heck to solve. Because a lot of CEOs default to giving the product manager the job to do this. But the PM is already, they're basically doing a lot of work with engineering and figuring stuff out. And now you're also trying to get them to figure out how the hell do I coordinate with the sales team to get the sales team to hit the quota. These are all very hard things on the marketing team to drive more leads. These are super hard things to do for someone who's already doing a full time job with engineering. So I would strongly suggest think about when you're not seeing success, the PM as owner of the business or owner of the pod. Try to think about having a separate person whose only job is to coordinate amongst people are like, why do I need this person? Well, I'll ask you this, why the hell do we need PMs at all? Why can't engineering do the job? There's a reason that PMs. The PM role was created so that the engineering team and the design team, which actually are doing all the work, are pointed in the right direction. Right? Think of this role as the PM for the initiative, for the overall holistic business initiative. They're making sure that the entire cross functional teams, product, engineering, marketing, sales, operations, all point in the same direction. And that's why you need this kind of person. Otherwise they all do their own thing. Just like without a pm. Think of it, without a pm, what would happen? Engineering and design, we just do their thing, but together. It would not be a holistic. It would not be a holistic well designed product planning. Hopefully at this stage, at the second stage, you're starting to create. You don't need very detailed plans, but you do need to have an annual plan with a budget and you really need to refresh it. Things change every year. So my recommendation is annual plan, but then refresh it half year in June, refresh it for July to December and then okrs. This way you're setting as part of your annual plan when you do it in November, December for the next year, you are already setting the goal for the first quarter. So you don't need to do a quarterly OKR at that point. So you do a quarterly OKR in Q2 and Q4 and you do a half yearly refresh at the beginning of Q3 and the beginning of Q1 and then many of you who are earlier on. I mean these quarterly okrs obviously need to be broken down into monthly goals. And again, they should be customer outcome focused and ideally by initiative. And again, again I have so many CEOs who are doing these OKRs and then the teams are executing. You've got to build the muscle in your org to take outcomes, you've got to give outcomes. And each outcome needs to have a cross functional pod working towards it. And they need to solve the initiatives, the krs that go towards the os. You should negotiate the OS and have the teams figure out what the krs are. And you'll see that it'll take a few iterations, but then they'll get better. And remember, these are teams that have to be evergreen or at least you can't treat them as chess pieces. Literally someone said, oh, I play chess with my team. How the hell are you playing chess? These are not pawns on a chessboard. These teams have to be enduring because domain expertise and problem expertise is built over time. You can't every three months make people move around from one team to the other. So at least a big chunk of the team should stay static from quarter to quarter. So they build the muscle to figure out how to take this customer outcome that they're owning. So don't think of these teams as well. I'm going to move people around every month, every quarter. That will not work. You will not have an engaged team that's good at solving that problem because each initiative is a complex problem that they're solving. This is what I call building the machine, which is what is the cadence of things, processes you need to do on a daily, weekly, monthly basis. Some things are weekly business reviews. Many companies, Amazon started this thing where once a week, typically in the middle of the week you meet the senior leadership team meets and finance actually runs this meeting. Once you have a finance function or someone in sagine operation at this meeting, the goal of this meeting is to figure out simply, are we going to hit the quarters numbers? That's it. It's nothing to do with long range planning. Are we going to hit the quarters numbers? Why the hell not? If not, what's the gap and what can we do right now to fix that? And many times fixing that means resource moving, right? Infinity dollars. So you've got to have a finance team that's very good at changing dollar allocation. I think Amazon does the same. You got to be able to move dollars because dollars move stuff fast and you've got to be really engaged as a leadership team, because really it's a company's goals. You got to be able to sacrifice some goal, some other smaller goal in order to meet the most important goal. So this weekly business review, it's a very intense meeting, one hour meeting once a week. And it takes a lot of muscle. It might be a little bit later in company's journeys that you set it up, but the goal is to. How do you never miss a quarter ever? Ever? The second one is initiative reviews. Remember we talked about teams should be. We should have initiatives and pods cross functional pods. So that's the level at which you should review these things. Right? You should not. I don't think CEOs should do product reviews. It should be part of the initiative because our initiative has product sales, all of those things. So you should do an hour long initiative review for the key initiatives in the company on a regular cadence. What should that cadence be? It depends on the urgency and importance. Some things where something is going to happen in the next two weeks. You want to do a daily thing. So it could be daily, weekly, fortnightly, monthly. That's probably the four choices. And then finally weekly weather reports. I call it weather reports, but basically it's a weekly report that your initiative team, typically that's one of the roles of the strategy and operations person for the initiative. They're sending you an email that outlines what the goal for the initiative was for this month and this quarter. How far away are from are we from the goal and what are the things you've done this week to catch up to the goal? And then what help do they need? Right. The key thing you need to really have from a cultural point of view, is asking for help. It's not a bad thing if they don't ask. This is the thing that comes to delegation. Delegation doesn't mean basically giving up complete. It means you're there to help them and you've got to. They need to know that this doesn't mean it's them all by themselves on an island with you just like sitting back and chilling. That's not it at all. They have to be trained to be able to raise their hand. You should reward them, recognize them for raising their hand. They need help. You've got to help them. And so many CEOs are like, oh, they weren't able to hit the goal. That's it, they're fired. No, that's not the case. That's not it at all. That's why you're here to help them. And so these weather reports and the business reviews teams come and ask for help. We are not able to hit our goal. This is what we need. Now if a team is continuously saying that at some point you question their competence, but if they're giving you clear reasons as to why there's a divergence or what hypothesis didn't pan out, et cetera, then you want to work with them, you want to help them, you want to figure out how to enable them. And so it's very, you've got to really be careful here, the tone you set in these things because everyone's watching you at these business reviews, at these initiative reviews. If you start setting a tone of blaming people and basically calling them incompetent, then you instantly people get scared, people are not going to come to you and then you're going to find out too late and the company culture is going to go down the drain and the company is going to go down the drain. So you've got to figure out how to empower, how to still hold them accountable and how to step in and help them. The easiest tactic I have for hiring is do not hire someone who's only worked at one company, especially a big company. Ideally I love hiring someone who's worked at a big company and then has been humbled by working at a smaller company because that humility is very important. Humility, scrappiness, agility, all of these you learn at small companies. At big companies you learn different things. Cross functional, how to work in cross functional teams, how to scale, how to be successful. The combination of the two can be really awesome. But people who only even simple thing engineers at Google don't know how to set up their own environment. You give them a box. Many of you probably worked at Google, they won't know how to do it. And working at a startup just changes your perspective. So I really think be careful hiring from a big company or people who only worked at big companies. Second, performance. Remember the word in performance is performance. A lot of companies and this is why the cross function initiatives come in but because if the engineer says you're doing a performance review, if the engineer says, well I wrote great code, it's not my fault that it didn't work. It's very hard to basically we set that culture. Yeah, that's not your job. I'm going to penalize or I'm going to give the product manager a poor grade on performance review. But the engineers get scot free. That's basically they all have to feel that they're in the same boat. And so that's why if you're part of an initiative, if the initiative hit its goal, and everyone in the initiative should basically get a certain performance score based on that. And then within that initiative, each team is graded. But a lot of companies focus especially in engineering and so on. They give too much weight to quality of engineering versus ability to hit goals. And I think engineering and product need to be gold on hitting goals versus just doing great engineering tech talks and basically writing amazing code and scalable code and mentoring people and so on. Those are great. But this is called performance review for a reason. It's not called culture review. Culture is 20% of the performance review score. And then what's the most important thing in performance review? Two things. Knowing who your stars are and knowing who your bottom 10% is. If you don't know those, you're failing at any point in time. I should be able to ask you, especially if you're a 50% company or less, who are your top five people and who are your bottom five people? If you don't know who your top five people are, you're screwed. Why? Because you need to incent them. These are the people. If you think these are top five people, you don't know, are they even going to stick around? What are their motivations? Are they going to leave? Are they interviewing somewhere else? Are they excited? Do you have growth opportunities for them? So those are the two most. Most of the company is going to be the middle 80%. But the top 5 to 10% and bottom 5 to 10%, you need to be pushing. I was one of the public companies on the board of. They basically had. The CEO was boasting to me, we have zero attrition. I'm like, that's really bad. Because they need to be a minimum of 5% involuntary attrition at any company. So he took that to heart. And the company has had 5%. Three years ago. This is during COVID 21. Three years. 5%. I think 5% in voluntary attrition over 100 people is almost important. Which means you're basically shedding the bottom 5%. Sad to say, but any group over 100 people, or maybe even 50 people, there's going to be two to five people who you have to let go. And you need to know who those are. Because. And I think everyone can improve. We have to give them a chance to improve. We're not firing them on the spot. But sometimes it's not a fit. It's not a fit. And you're A startup. Third thing is career ladders. I think people need to know how their career progresses. Engineering and sales are the fastest that come up because they are the most number of people. There's most. You look at a company, there's most number of people in engineering and the most people in sales. Everything else is onesies, twosies. So those are the ones where you got to create a simple ladder. A simple. At square we went through some unbelievable pain creating ladders. Something simple, an engineer like four or five levels so that they know what the next thing is to aspire to, where to get to. I think it comes slightly but hiring and performance most important. Okay, this final one is communication. One on ones, are you having one on ones? Ideally with every person in the company, especially if you're a 50% company or less, you should be having one on ones at least with your direct reports and your skip level reports. Direct reports once or once a week. If not and maybe once a fortnight. Skip levels once a month and maybe with everyone. And then small group meetings are away. If you're more than 100 people, you still want to have a pulse of what different teams in the company are thinking and so you just drop into one of the group meetings once a quarter and just have them and sometimes even kick the leader out and just ask them what's on their mind and be completely open, all hands important. And then CEO email. I strongly believe if you send an email once a week or once every fortnight out to the company articulating what's on your mind, what are the options you're thinking about and reaffirming your vision, mission, goals. It just helps the company understand what's on your mind. You'll be shocked at. You are like. People are like well I just said almost the same thing last week or this week, but I got so many responses. Everyone is trying to parse what you're thinking and this is a way for them to not to parse or guess you're telling them what's on your mind. So strongly encourage you say I know it takes an hour or so to put these things together CEOs but it's one hour well spent on a Sunday or a Friday whenever you do it. Typically Mondays are a good time to do this thing again. This is not a prescription. All of you will have your own different journeys. All of you are special snowflakes. But this is some of the things I've observed at this stage.

Hi Goku, I'm Raven, the CEO of Pixai. So thank you for the very insightful sharing. So I just want to ask a few more questions with regard to how to set up the initiative team and how to make it work. So apart from the option to hire a few new MBA grads, if we were to appoint someone from the team to serve as the leader of the, say, a new initiative, which function would you recommend to serve as the team leader?

Great question. The question is, who would serve as a team leader? I don't like calling it a team leader, but let's call it a team leader. In fact, people call them GMs, but whatever you call them, I think the best folks are generalists. Generalists who who work well, cross functionally and who are highly analytical and who have high agency. This is a role for massively high agency people who are extremely driven. When you get into the room with an SNO person, you know you're not going to get out of the room until you know what the next steps are. The only thing they care about is how the hell do we hit the goal. They're very goal oriented, very driven, very focused on what the next step is, almost to the exclusion of everything else. So you need someone who's extremely driven, who can get teams, who can navigate cross functionally, so who has either good relationships already, who has good communication skills and who can bring people together, and someone who's analytical. Because ultimately the people who work for these people are analysts, ultimately. But it's a unique kind of analyst. An analyst who communicates, who sets goals, who gets teams to follow them. Here's what they have to do. They have to go to the product team and say, because the product team is doing their thing right, they have to go to the product team and say why are you doing this? They have to question. They have to play your role, basically, which is asking the product, why are you building this? How does this contribute towards the initiative goal? The product team almost has to be forced to justify everything they're doing because ultimately they're part of the initiative. They should not be building anything that's not part of the initiative. And there's a huge culture change here. Why? Because at most companies like yours, product engineering rule the roost. They are not questioned by anyone. You're not questioning who can question them. Only CEO can question them. Here now you're putting into place this new entity, this new org where their job is to question product and engineering and sales and marketing. So they need to be extremely self confident and you need to imbue them with power. What that means is you need to tell the rest of the teams that this is the first of this. I shouldn't say they are equal in peers to you. It's the same thing. Think about a product manager going to engineers and asking them how did they manage to establish credibility. Because the engineers know that having a PM will help them do their jobs better. Similarly having an SNO person, That's what the PMs and engines recognize that having them as a partner. So they need to treat them as a partner and throughout the org they need to be there as a partner versus a second class citizen who PM in engineering kind of ignore. And that's very important through various. That's why it's so important to kind of have the right person who is already treated as and equal by the product ranging. Product ranging is where the biggest thing is. It takes a lot. When people join An Uber or DoorDash two companies that use this who are not used to the structure, they're like what we have this SNO person. We are not used to working with them. We just do our roadmaps. But then after six months they realize how important the SNO rules are and they're grateful because they now know that they're not just going to be blindly doing this or that they now have a very clear goal and the SNO person is going to keep them accountable and responsible towards a goal. So they embrace that. But it takes. It takes some learning. That's why don't do it across the company. Do it with one team first. Do it with one team first. The biggest, most painful initiative that you've not been able to untangle or get going. That's the one I would choose.

You recommended doing a lot of experiments to test out hypothesis rather than building. Do you time box these? Do you suggest a time box for these hypothesis? Because it sounds like some of them is just self evident. But if it's not, then what time.

Frame should it depends on the time frame of your product iteration itself. So it should be some sort of product. Your product. For an Internet product it's probably of the order of weeks. For the product which is a chip product, it's of the order of months. So I think it is scale of the overall product itself. So it should be because these hypotheses are I think generally weeks. For most software companies should be weeks and not months.

I'm curious how you'd recommend incentivizing teams in these cross functional orgs where they're incentivized to experiment Often as you said, that can take Months, sometimes to get it right. How would you recommend incentivizing that team? By the effort they're putting in, but also in the reward as well, because you obviously don't want them to get discouraged if they don't quite get there in the first go.

What you find, it's a great question. How do you incentivize these teams? What you find is. First, let's take a step back. These teams have OKRs which are in the form of customer outcomes. So they have OKRs, and these OKRs are quarterly, but they also have monthly. Right. Essentially, one thing you realize very quickly when you said monthly is if you miss the first month, it becomes really hard to catch up. If you miss month two, it's almost impossible to catch up in month three because the gap keeps widening. And so it's very. So what you find is the teams that start working together, they are tentative first because they don't fully understand the problem once you start understanding the problem. So the first few experiments are sometimes off the mark, have poor hypotheses. So your job for a newly formed team is to coach them and help them early on. And you'll see that by first, by the third month or the second quarter, they start working well together and the initiatives are much crisper because the hypotheses are much better. I think if you see that by end of second quarter, the team is not gelling well, is not able to do a good job. You probably need to mix, you probably need to replace some of the key people who are driving it. And I think for the first quarter of a team, I would really focus on how many experiments are you able to run. After that I would start goaling them on hypothesis and rewarding them based on. Sorry, on the outcome. And rewarding them based on the outcome. But especially when it's unknown, when you have an outcome like change, retention is one of the hardest things to change in any company. Hardest things. Right, hardest things. So it's like giving someone saying, well, I want you to move the retention curve by 5% or 5 points, that's damn hard in a quarter. So we've got to understand what realistic is and set realistic goals. And sometimes realistic goals, you only understand what they are after. We are in it and doing it for a while. Then we're like, okay, you know what? A one point a quarter is a better goal to have than five points a quarter. Even if you do a 50x thing, that's one point. We were at 0.5 and that's 1.5 that's 3x. That's great. So this is why it's so important not to treat teams like chess pieces, because you've got to give them the time to build trust, start working together, respect each other, understand the customer problem, understand the outcome, understand the choices, be able to work together.

Well, we're really trying to encourage our teams to be more solutions oriented, or in your case, custom outcome oriented.

Right.

But at some level, someone still needs to be in charge of kind of the detail or the feature. Right. Like how does that balance play out? Like who still owns.

That's a product team. That's a product team. Exactly. That's a product engineering team that basically has articulated that these are the five experiments you're going to run, not features, but experiments you're going to run to accomplish this outcome. And they go, and ideally they rank them by which is the fastest way to achieve this outcome. Right. Which has the most impact towards the outcome or so on. And so that's the experiment is the feature. Essentially the feature that they build in the product is the experiment they're running which they expose to some percentage of users. So it's a product engineering team. Absolutely. But the goal of the feature is not to launch the feature. No one cares. No one cares if you launch the feature. What you care is did the feature help you accomplish the outcome? Did the experiment, when it rolled out to 100%, accomplish the hypothesis that you articulated upfront?

Would you ever give a revenue oriented.

Goal to a product and engineering team? I would try to break it down into a customer goal as much as possible. A customer outcome. I feel, I believe very strongly that every revenue goal very quickly can be broken into revenue from new customers and revenue from existing customers. Right. Any revenue goal in the world, then you start breaking revenue from new customers into number of new customers times ACV per customer. Right. So instantly you have two different things. Then you have I need to acquire these new customers and you can have the check metric that the ACU for new customers should not dip below what the average was. Potentially that could be one way to do it, but I think it's much easier. It's very hard to revenue. Revenue just. But I think customer goals are easier to handle to grok. It's a number revenue. I would decompose it. I would decompose it to customer goals.

In the B2B world, what is the right framework to think about the features or the experiments specifically when let's say customers are asking for these five things, how do you rank them? What's the right framework.

Very simple. I think when customers ask for it. I don't care what customers ask for. I care about what pain point are we solving. Because this is a classic thing, right? I mean, customers ask for X. This is why customer interviews are so important. We need to understand why are they asking for this? What ultimately pain does it solve? There might be a better, faster way to solve this pain than what they're asking for. And it needs to be part of a certain problem that you're looking at the company. So I would keep this is called, you know, basically root causing or first principle thinking. You got to go deeper. There's a Japanese thing called asking five. The five whys thing. You ask five whys to understand what is the root cause here, what is the ultimate thing you're trying to solve and then solve the root cause and then what are the other ways to solve this? So go back, let's have that as a problem statement. Change the problem statement. Come up with five ways that you can do this. Compare them. Very simple, real life example. First principle is thinking.

All right, great. I think that's a great note to end with.

Thank you. Thank you. Am.