Sequoia

Gokul Rajaram on Product, Leadership, and Building Enduring Teams

In this insightful talk, investor and company helper Gokul Rajaram dives into a wide variety of subjects, including critical factors to achieve product-market fit, and when to opt for generalists and specialists in your startup journey. This session was recorded during our Surge 09 US immersion in February 2024. Gokul has a stellar history of helping build several generational technology companies, including Alphabet, Block, Coinbase, Meta, and Pinterest. He also invests in early-stage technology startups and partners with founders to help them build enduring companies. In this video, he talks about why it's important for founders to delegate control and the need to adopt an outcome-based approach while making decisions. He also advocates for an experiment-based mindset over a feature-driven approach, discouraging a “feature factory” mentality. Gokul expands on leadership and talks about how managing people is a privilege that must be earned, not a right.

SHOW NOTES:

TRANSCRIPT:

Rajan Anandan: So  Gokul [Rajaram]  is  currently  at  DoorDash.  He’s  on  the  executive  team  at  DoorDash,  on  the  board,  he  leads corp dev and  strategy  at  DoorDash.  Prior  to  DoorDash  he was  at  Block,  where  he  led  basically  all  the  products.  Prior  to  that,  he basically  led  ads  at  Facebook.  And  then  before  that  was  at  Google.  So  pretty  much,  you  know,  you  can  imagine  like  all  these  companies…[He] was  on  the  board  of  Pinterest  and  is  on  the  board  of  Coinbase  and  The Trade  Desk.

The  way  we’re  going  to  do  this…Gokul  is  going  to  present  some  slides.  We’ll  go  through  it.  And  then  we’ll  open  it  up  and  find  the  questions.  Thank  you  for  joining  us.  

Gokul Rajaram: Thanks,  Rajan.  And  great  to  be  here,  folks.  One  of  the  interesting  things  I  reflected  on  when  I  was  thinking  about is this: Every  company  I  was  at,  it changed  its  name  after  I  worked  there.  So  I  worked  at  Google, [it] became  Alphabet; worked  at  Facebook,  and [that 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.  I  happened  to  Google  with  YouTube,  Meta  with  other  things,  et  cetera.  So  anyway,  an 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 through three stages. 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. 

The elements for a startup essentials pack [01:26]

At startup, the three things that matter, actually, the first thing matters 90%, getting to product-market fit (PMF). As Marc 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 determine the culture of the company for your lifetime. I’m sure if 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, etc., are 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 overtime, 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 scale up, you have multiple businesses. So Google, for example, having multiple businesses, etc. You have executives that you bring on. One of the biggest mistakes companies make, [and] we’ll talk about this, 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 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 are essentially owning the product on 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. 

Scaling up: Changing the generalist to specialist ratio [03:29]

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. These are general things I’ve seen and observed across, I think I’ve invested in 500 companies and worked at and 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 is going to have a slightly different experience with these. 

So the three things I think are important in scaling the product is one training the team around how to work backwards from outcomes. Most product managers, most teams are used to the founder, before this phase you’re 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 to inculcate? What are the processes? And the third one is, how do you break up optimization of the core product versus innovation or net new products or net new features? 

Aim for outcome-oriented goals [04:35] 

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 I asked them, “What’s on your road map?” They sent me their list of OKRs (objectives and key results). It’s a pretty…it’s high up in the…I hadn’t heard from them in six months [and]  in Q4 they sent me the 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 the 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, 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 [are the] five things that matter?And that’s really how to build simple products that drive most of the value right 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 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 of 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 the daily engagement of my users from X to Y.” And one way could be to build an Android app. The second way could be to improve the 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 and validating the hypotheses. 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 a 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… The question you need to ask is, why are you launching this? If you can just train yourself before a product manager, a product team comes to you and says, “We are going to do this,” if you can just ask, “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 a 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 company? Developer’s time, engineer’s time, that’s the most expensive, most 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 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 proxies you can use to articulate to engineering and to convince yourself that this scarce resource should be used to validate hypotheses. We are all prone to, “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 problem is 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 are you building this?” You need to hold them accountable to understanding the hypothesis. Behind every feature there is 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 is the customer behavior you need to change?” And then finally you need to train them and push them to not use engineering time unless absolutely necessary, and to figure out how valid the hypotheses are that are in code.

Let me pause here. I think otherwise I’m worried that we might go quite a bit into [all this] and not… What questions do you all have around this specific piece? 

Audience: So what we have generally seen is that while we create hypotheses and test it out in the 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 [do] 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 would actually have needle when done the proper way. 

Gokul: I think you are 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 the younger stage of a 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 one percent change. So if you’re going after 50x optimization or 10x optimization, even a bad ops experience results in a 2x difference. It’s only when you’re aiming for 10% change and ops is 1%, you’re like, “Does it matter or not? But you should not be doing 10% changes. You should force your team. And, maybe that’s the other thing. We need to go after things that are…because if you have $5 million, $10 million in revenue, who the hell cares about a 10% change? You’ve got to go after 5x changes. 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 it is about the experience that will change the customer behavior. And you’re right, we need to figure out even with the op experience, can we put the polish in that part of the experience. 

At Square, we had the most horrible product for multi-location chains. Multi location, we had a 100-location chain, which had 100 accounts in 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 customers. 

Audience: So when you say customer outcome, is it metrics or is it workflow or journeys? 

Gokul: No. It’s customer outcomes, customer behavior changes. For example, a very clear customer outcome, “Get my customer conversion rate from landing on the website to activation to 50%, up from 25%.” It’s a metric basically that is a hypothesis around a customer journey. So it’s a metric. It measures the customer journey for us.

Audience: So just one more question: 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. 

Gokul: Yeah, you have to do pre pre-post. For B2B, that’s a small scale, you’ve got to do a 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. 

Solving backwards to an outcome [13:02]

Audience: When you say, “You’ve to solve backwards to outcome,” what are the guardrails one can put where the team doesn’t take shortcuts to be able to say, amplify that number. For example, if I were to say, DAU (daily active user) by MAU (monthly active user) ratio for me has to move by 5%  absolutely. There are many paths to this. So can you double tap on the second line [on the slide]? 

Gokul: Well, first thing is, remember when you have an outcome, you also need a check-metric, which means that you need to make sure that they’re not doing bad things. So you need to do that first. Second, you need to figure out how to train them on generating multiple alternatives, to achieve the same goal and then evaluating those alternatives in a very lightweight way. There are various frameworks like ICE, which is impact, confidence, and effort. RISE, which is reach, impact, confidence, and effort…But 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. I mean, I can rank them, but how do I know? And this is where validating them without writing code will come into picture.

Effective customer dialogue: Go beyond yes/no questions [14:04]

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 is, it doesn’t need to be the same kind of customer. Remember, there are many different segments of customers. There are churned customers, newly activated customers, customers who are continuing from last month to this month, customers who used you once many years ago and didn’t ever sign up. Every time you talk to a customer, you understand. And remember there are 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 about their experience with the product. Do not, just ask them direct 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 on a customer call that someone is doing, that will massively change how they think and build customer empathy. So get them to do customer discovery. 

Experiment mindset versus feature mindset [15:32]

Second, we talked about this experiment mindset versus feature mindset. You’ve got to make sure that the habit they [build]…Here you need some help from your engineering teams to build a data or experimentation framework. There are a lot of good tools like Statsig, I’m an investor [in Statsig], that’s why I mentioned it. But there are many other tools, such as LaunchDarkly, etc. You 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 a feature factory mindset. Who the hell cares? That’s why I’m saying, look at your OKRs. Look at the goals you’ve set. If your goals are on specific features, they’re wrong. That should not be the case. The goal should all be in terms of 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. So I know companies that, that actually once a week, have an analytic, have a watch party, and they have a mobile, there’s a mobile counterpart also. I don’t know if it is Fullstory or it is someone else. You can actually just see how customers are traversing a website, and where they are 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 it’s somewhat pernicious because you don’t realize it, you no longer think of customers as customers, you really think 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 trying to accomplish a goal. And I think the first and third things are one way to do it. So let me pause here, and see if [there are] any questions.

Audience: So, we are actually 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? 

Gokul: Let me think about that. I think it’s one of the hardest things, because hardware products, once you send it to the fab (fabricators), it’s out of your control, and then it comes back. I’ve not seen good ways to do this. It’s purely, definitely… at the Square also, we have seen the same thing. 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. 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. Let me chew on it a little bit more. 

Surveys: Helping pinpoint worthwhile problems [18:37] 

Audience: What do you think about the role of surveys to test hypotheses? I understand that’s data points, but in addition to customer interviews?

Gokul: I think surveys are a good way if you can control for the biases in surveys. That’s a challenge, right? Remember, surveys have voluntary bias because people who 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 that, I think they can be helpful. But I am, I’m a little bit nervous around that, about 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. 

Innovation is vital, but don’t forget your core product [19:20]

Third one is innovation. Outcomes, habits, innovation. I think there is something to be said [about innovation]. Every company that I’ve been at has had a hack, and hopefully most of you are having, 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 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 the companies I have worked at Square, Facebook, DoorDash have emerged from hackathons where there was a clear problem that people saw, but they were forced because they were as they were part of this team too, but they couldn’t work on this, but the hackathon gave them the option 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 on 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 the 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 trying 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 guardrailing most of our resources to work on the core product. It could be 80-20 or something, maybe 20% or probably 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 2, things are things that impact your product or your business in the next 18 to 36 months. Horizon 3, 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, and keeping most of the resources on the main product, the core product, because that still has a long way to go. Remember you’re not at the scale of state. You’re not at $200 million revenue for your main product. You’re still early. 

The must-have for innovation [21:51] 

And finally, 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 that 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 companies are working on something else. So every single time I’ve seen an 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 getting starting to get frustrated with the bureaucracy that 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 reportee of yours or something else. You might need to pluck someone in from an IC role and make them the single threaded 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 core base. They can do anything they want to, versus [being] 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. 

And 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 org’s time and bandwidth is going on figuring out how the heck to make it stand out, to be a winner in the category, etc, 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 glue, because no company, I believe almost every very large company has to have multiple products. It is very hard to become a very large company with just one product. It’s just very hard. 

When to start building your second product [23:42]

I do think multiple products will be important, but when to start a second product, [the answer] 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 an inordinate amount of capital, an inordinate amount of talent, and an incredible leader. These are simply second or third time entrepreneurs who raised a $100 million in their seed round or something like that. 

Managing teams: privilege, not a right [24:05]

Scaling the org, five facets here: Org structure, planning, execution, people, and communication. 

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 intentional. I would almost strongly say, do not hire any functional managers. And I’ve now met several companies 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 (individual contributor) 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 a head of X). So instead, hire a specific, good individual contributor or someone who can become a player or 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 recommendation.

Do not hire 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 [something] you’ve got to do. I’ve had CEOs who have had to do [this], 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 the role because they had already built a team. So be very careful. 

Organize around initiatives, not functions [25:56]

Second one is the notion of cross-functional pods (product-oriented delivery). 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 are not working well together. You basically become some kind of mini GM (general manager) that is … 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 it turns out that they were basically, each function was busy doing their own thing, and the CEO was basically trying to make the connection 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-functional part. A simple initiative could be new customer acquisition or increasing retention or increasing loyalty. Ideally phrased in the form of customer outcomes. You’ll hear the word 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 to whoever, but they work together and they present stuff together. They report on stuff together and this is very important, you want them to feel that they own this outcome together. 

The need for goal-specific leadership [27:22]

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 what sales is doing, “Okay, they did this, product is doing this, how [does] 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 a 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 [talent]. They’re typically ex-consultants and ex-bankers. And I would strongly encourage you. To try using one of them. So almost suddenly you can find a very good fresh MBA graduate with good experience, who’s hungry to make an impact and has worked at a top consulting firm. 

And 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 the results. It instantly will take the headache from you. And then the outcomes, therefore, 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 has 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 their 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 thinking about when you’re not seeing success as 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 … Now people are like, why do I need this person? 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 is actually 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 about without a PM, what would happen? Engineering and Design would just do their thing, but together it would not be a holistic, it would not be a holistic, well-designed product.

Build enduring teams and review initiatives [30:00]

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 an annual plan, but then refresh it in half a 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’re doing November, December for the next year, you’re already setting the goal for the first quarter. 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 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, 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. So, you should negotiate the Os and have the teams figure out what the KRs are. 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, right? 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 and try. So don’t think of these teams as, “Oh, I’m going to move people around every month.” 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 the senior leadership team meets, and finance actually runs this meeting once you have a finance function or someone in strategy and operation at this meeting. The goal of this meeting is to figure out, simply, are we going to hit the quarter numbers? It’s nothing to do with longer spelling. Are we going to hit the quarter numbers? Why the hell not? If not, what’s a gap and what can we do right now to fix that? And many times fixing that means resource moving. 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 thing. You’ve 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 goal. You’ve 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 the company’s journeys that you set it up. But the goal is to, how do you never miss a quarter 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. 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 might want to do a daily thing during COVID. So, it could be daily, weekly, fortnightly, monthly. That’s probably the four choices. 

Institute ‘weather reports’ to help achieve goals [33:48]

And then finally, weekly weather reports. I call it weather reports, but basically it’s a weekly report for 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 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 in, 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 with delegation. Delegation doesn’t mean, basically giving up completely. It means you’re there to help them. And 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, and 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 other 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, what hypothesis didn’t pan out, etc., then you want to work with them, you want to help them, you want to figure out how to enable them. And so you’ve got to really be careful here. You still tone, you set the tone in these things because everyone’s watching you at these business reviews at this initiative reviews. If you start setting a tone of blaming people and basically calling them incompetent, then 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. 

But the easiest tactic I have for hiring is not to 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 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 things, engineers at Google don’t know how to set up their own environments, 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’ve only worked at big companies. 

Rethink performance metrics & identify top performers [36:15]

Second, performance. Remember, the word in performance is performance. A lot of companies, and this is why the cross functional initiatives come in, but because if the engineer says, you’re doing a performance review, the engineer says, “I wrote great code. It’s not my fault that it didn’t work!” It’s very hard to, basically [make them accountable] if you’ve set the culture that, “Yeah, that’s not your job. I’m going to give the product manager a poor grade on performance review, but the engineers get [away] scot-free.” So, 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 hits a goal, 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 [teams] 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 grilled 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 for a reason. It’s not called culture review. Culture is 20% of the performance of your 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% are, 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 your top five people are, you’re screwed. Why? Because you need to incentivise them. If you think these are the 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? Most of the companies are going to be in the middle, 80%, but the top 5%-10%, and bottom 5%-10%, you need to be pushing. 

I was … one of the public companies I am on the board of, we basically had the CEO boasting to me, “We have zero attrition.” I’m like, “That’s really bad because there needs to be a minimum of 5% involuntary attrition in any company.” So he took that to heart and the company has had 5% [involuntary attrition], three years ago, this is during COVID in 2021, in three years, 5% [involuntary attrition]. I think 5% involuntary attrition over 500 people is almost important, which means you’re basically shedding the bottom 5%. Hard, sad to say, but in any group of 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, and I think everyone can improve, we have to give them a chance to improve, you’re not fighting them on the spot, but sometimes it’s not a fit, it’s not a fit, and you’re a startup.

Build a ladder: Simplify career progression at scale [38:43]

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. If you look at a company, there are the most number of people in engineering and the most number of people in sales. Everything else is onesies, twosies. So those are the ones where you’ve got to create a simple ladder. At Square, we went through some unbelievable pain creating ladders. Something simple, like for an engineer, four or five levels so that they know what the next thing is to aspire to, where to get. I think it comes slightly later, but hiring and performance, most important. 

Strategize your communication [39:16]

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 reportees and your skip level reportees. Direct reports 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 a way, if you have more than a hundred 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 you can kick the leader out and just ask them what’s on their mind and be completely open. All-hands are 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 opportunities you’re thinking about, and reaffirming your vision, mission, goals, it just helps the company understand what’s on your mind. People are like, “I just said almost the same thing last week and 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. Strongly encourage you to say, I know it takes an hour or so to put these things together, 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 one of the things I’ve observed at this stage.

Generalists make good team leaders [40:39]

Raven Gao: Hi, Gokul. I’m Raven, the CEO of PixAI. Thank you for the very insightful sharing. 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. Apart from the option to hire a few new MBA graduates, if we were to appoint someone from the team to serve as the leader of, say, a new initiative, which function would you recommend to serve as the team leader? 

Gokul: 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. Let’s, we in fact, people call them GMs, but I, whatever you call them, I think the best folks are generalists. Generalists, who work 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 (specialist network operations) person, 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, 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, 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 team, “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 rules the roost. They’re not questioned by anyone. They’re not questioned. Who can question them? Only the 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 a first step.” You shouldn’t say, “They are equal and peers to you.” It is the same thing …. Think of what a product manager going to engineers and asking them [means]. How do 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 engineers recognize, that having them as a partner … So they need to treat them as a partner. And throughout the org, they need to be treated as a partner versus a second class citizen, who PM and engineering ignore. 

And that’s very important for various reasons. That’s why it’s so important to have the right person who is already treated as an equal by the product and engineering [teams]. Product and engineering is where the biggest thing is. It takes a lot when people join an Uber or a 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. 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 the goal. So they embrace that. But 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.

Audience: You recommended doing a lot of experiments to test out hypotheses rather than building. Do you suggest a timebox for these hypotheses? Because it sounds like some of them are just self evident, but if it’s not, then what timeframe should it be? 

Gokul: It depends on the timeframe of your product iteration itself.

So for an internet product, it’s probably of the order of weeks. For a product, which is a chip product, it’s of the order of months. So I think it is the scale of the overall product itself because these hypotheses are… I think generally for most software companies, it should be weeks and not months.

The secret to incentivizing teams [44:48]

Audience: 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. 

Gokul: 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, right? So they have OKRs. And these OKRs are quarterly, but they also have monthly; essentially, the one thing you realize very quickly when you say 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, and 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 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 the end of the second quarter, the team is not gelling well, it’s not able to do a good job, 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 based on the outcome and rewarding them based on the outcome. 

But, especially when it’s unknown, when you have an outcome like, retention is one of the hardest things to change in any company. Hardest things. It’s like saying, “I want you to move the retention curve by 5%, or five points.” That’s damn hard in a quarter. So you also have 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. And we’re like, “Okay, you know what? 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 five, and that’s 1.3x, that’s great!” 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, and be able to work together well.

How to define & take ownership of goals [47:08]

Audience: We’re really trying to encourage our teams to be more solutions oriented or in your case custom outcome oriented. But at some level, someone still needs to be in charge of the detail or the feature, right? Like, how does that balance play out? Who still owns…

Gokul: 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 and 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 lose 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’s rolled out to a 100%, accomplish the hypothesis that you articulated up front?

Audience: Hey, would you ever give a revenue oriented goal to a product and engineering team? 

Gokul: 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 the number of new customers, times ACV (annual customer value) by 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 ACV by 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 [do it through] revenue, 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. 

Harness first principles to shape frameworks [48:57]

Audience: 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? 

Gokul: Very simple. I think when customers ask for it, I don’t care what customers ask for. I care about what pain point we are solving? Because this is a classic thing, right? Customers ask for X. This is why customer interviews are so important. We need to understand why are they asking for this? What is the pain that it ultimately solves? There might be a better, faster way to solve this pain and what they’re asking for. And it needs to be part of a certain problem that you’re looking at the company. 

This is called, you know, root causing or first principle thinking, you’ve 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 principles thinking. 

Rajan: All right, great! I think that’s a great note to end. Thank you, Gokul. 

Gokul: Thank you all.  

This transcript has been edited for clarity.