#FirstPrinciples with Gokul Rajaram

A quick Introduction About Me I'm Ayush. I'm part of cogect's marketing team. Thank you so much for joining us today even though it's just over 9pm in India right now. I know it's late for so many of us in this part of Asia, but also it's super early for Google. Okay, first things for all the first timers here. First Principles is a product webinar series run by Gojek to host subject matter experts like Gokul. We encourage our host to share their ideas, mistakes and learnings with us. The idea is to learn from folks who have been there, done that and we have a community on meetup. I'll share the link in the Zoom Chat window. I'll just quickly go ahead and share my screen. We will. Yeah, okay. Yeah, okay. Another quick thing I talk about Lightning Talks which is a subset of First Principles. The idea behind Lightning Talks is to Give platform for junior PMs who have interesting things to talk about, learnings to share, but need help in structuring and presenting it. So think of these as 5 minute quick talks before a main talk. So we'll assign you a mentor, we'll help you put the talk together, we'll work with you, we'll do a dry run and we'll basically assist you with it all. This is especially helpful for folks who want to showcase the work they've done. Our idea is to help the community find more interesting like minded people. I'll share the link to apply for Lightning Talks in the Zoom Chat window as well some pointers for the session today. We'll start with the questions we received along with the registrations and we'll take more on the go. If you have any questions around those topics, please feel free to share those through Q and A and we'll pick them from there. Also, at the end of the session you'll receive a feedback form. Please take out 2 minutes to fill that in so we know how did we do and what can we do better. Okay okay. Without any further delay, today we have Gokul Rajaram with us. Thanks so much for taking out the time and joining us. Gokul Kokul is based out of San Francisco. He is currently on the executive team at Doordash, before which he has led teams at Square, Facebook, Google. He also advises a bunch of companies like Pinterest, Coinbase, Spine Labs, just to name a few. While I was reading up on the work that Gokul has done, I came across several articles on TechCrunch ET Business Insider, which also refer to him as Gokul Godfather Raja Ram. He helped launch Gokul, he helped launch Google AdSense and grew it into a big part of Google's business. And with all that he does the thing that's super interesting here, he's super quick with his responses, which is simply amazing. That's a thing which I really found amusing at 7:30am in San Francisco. It's the beginning of the week and this makes me want to ask an obvious question at Google. How do you manage your time? What apps help you? People are bullish on notion these days. Some use the GTD framework. So give us some advice, give us some hacks on what makes you this superhuman over to you.

I think the actual tactics don't matter, you just need to be intentional about your time. First of all, thank you for having me here. Ayush. I was, you know, with Zoom, it's actually great that we can do these conferences essentially at a time that anyone in the world hopefully can attend or join without much difficulty. And if the recording is there, hopefully you can make it available later also.

Yes, we do have excited for today.

On the productivity front, my eyes were opened by something called GTD or Getting Things Done and seminar I attended 15 or 17 years ago. But it doesn't matter what the principles are. There are two or three things which suck up most of our time as productive or information workers. One of them is email. So you need to have or messaging an email, you need to have some method to deal with it. For me the method is simple. It is that for anything that takes less than five minutes to process an answer, I just do it instantly when I open my inbox I just answer it right of my inbox. So anything that takes more than five minutes where I write a more detailed response or I have to get some data from somewhere or maybe create a document in response that I don't put in my keep in my email inbox, I keep it somewhere else. I have a list of action items which I added to so this way I'm able to process every email at the same time I open my inbox. And this kind of removes a source of psychic tension because because email is no longer lingering around. So I think everyone needs some method to process their email in a way that's efficient. Now you've got to also limit the number of times you open your email inbox. It can't be a rush every time you get an inbox notification and then you open it. It's true for WhatsApp, Facebook, et cetera also. So I would suggest three or four times a day, spend half an hour and using some process to just clean out your inbox. Don't use your inbox as your to do list. The second thing is just having a to do list. And that's what Ayush mentioned about notion. I just use Apple Notes, which is basically on my phone and essentially that serves as my to do list. And that's where I keep both ideas that come up. I basically try to. My goal is to try to keep my mind free because I feel creativity comes when your mind is free and not constantly worrying or burdened about what's next. What am I missing? And so if you have a device, whether it's a Notion app or your. I used to actually, when I was working before COVID I would keep a notepad and carry it around and I would basically write it on a physical notepad. But during COVID I stopped wearing shirts with pockets. So I didn't carry note, I just carry my phone around. And so I use. I just take notes on my phone. I have a. So I just take. And then that's what I review. Actually when I think of what's to be done, I feel confident that I've recorded it all on this, on this note. And, and I just constantly refer to it.

Okay.

And then check it off. And I think the thing I miss about paper is that it's viscerally very satisfying to be able to check off something or cross off something. And so I have a check, I have an underline or something I use here to denote the same. It's not the same. But at least you see that here are all things you've accomplished. And I think that's, that's a good reinforcement that you're making your way through it. And the third one is the. They call it eat the frog, which is do the hardest thing first. Especially in the mornings or whenever your day starts, do the hardest thing first because that makes you much more productive. So it's very, very painful to do it because you want to procrastinate. But if you can just do the hardest thing first out of your task list, whether it's many of the times or people actually turns out, because all of us are probably really good at just getting stuff done that we have.

To deal with ourselves.

But when you have to hire somebody, convince someone to join fire, someone, you know, give someone a tough performance review, write a performance review, all of those things, especially at the leadership level, those are the hardest things and most, they require the most pain and thought. And so that's, that's what you do first or try to scour LinkedIn or something for profiles and try to get people to come join your team.

Correct? Yeah, yeah, yeah. That sets the ball rolling if you deal with that first and yeah. Builds the momentum for the rest of the day. That's right. Okay, thanks Gokul. That was really helpful. Let's take the first question again for those watching, if you have any questions around this, around whatever questions we are discussing, please shoot the questions through Q and A and we'll pick them from there. Okay. So Gokul, here's the first question. What are some of the biggest challenges you faced while scaling products in teams? Any particular anecdotes, learnings that you like to share? And another interesting question which was on similar line looking back, which are the biggest mistakes which you have made and how would you go about them?

Now?

I think if I were to think about the biggest challenge is all about people, I think you get. I have gotten into cases where my, I was so focused on hiring for a role and filling a role by a certain time that I ignored some red flags in the evaluation of a candidate and didn't, didn't really push myself to say is this candidate someone who will bring up our overall level? But I just, I essentially said I'm just going to be fine with hiring this even even though there are some red flags here, I'll figure out how to paper over them. And there's always, always red flags. You just need to make sure that for your specific role, your specific company, those red flags are not fatal, especially at a startup. I think at my startup, I think the first six engineers we hired, three of them we had to fire, let go, which is kind of very painful. And the reason is because they were all hired from amazing firms. Google back then, Yahoo 15 years ago actually was a very good firm to hire from. Even now there's a lot of good people, very strong firms. But we didn't. And we quiz them on technical chops and basically problem solving and Olympiad questions and so on. These are engineers. But what we didn't really spend time on was the culture and their work style. Like basically they would disappear at like 5pm on Friday and would be unreachable or very hard to reach during the weekend. And with our work at the startup it would be spiky and up and down and we would have to come in on weekends and so on. It was just very hard to get them to commit and they didn't want to commit either. We didn't set basically, also it's our fault. We didn't set expectations because we were scared of losing that person. So I think the more clearly you can state your values and principles, it's okay if you lose people, but you'll make sure it's a filter to attract the kinds of people you want. So we never exactly said, hey, you might need to work out of four weekends, you might need to work two weekends. So make sure you're comfortable with that. Because we didn't want to scare them off because we were a startup. We were trying to get people to like us and choose us rather over the comfortable jobs. So that's. Those are the lessons I've learned. It's all about people. I tweeted this out at some point a couple weeks ago. 99% of the challenges you face almost in any role is people oriented. Is either dealing with people, convincing people, hiring the wrong people, not having the right people, etc.

Etc.

Got it. Okay. Yeah. Since you mentioned Twitter people, Gokul is at Gokulr on Twitter. Please follow him. Some really interesting learnings from there as well. Okay, moving on. You've worked across a bunch of very impressive products. What motivates you to do what you have been doing? Also, I was, when I was reading about you, I came across a lot of testimonials on Angel List which says you're always on. You are a great problem solver. Yeah. So another question around that. So can high agency be developed and any tips around those?

So the products themselves, I think I'm motivated by certain kinds of products and companies. I'm motivated by products that impact lives of people which in a tangible way and where I can actually see the product and use the product. At least working on a product, it's hard for me to be motivated by, for example, enterprise products where I'm not the user directly because it's a little bit too abstract and it might make you more productive or solve a certain workflow in a company. But it's not something that my kids can use or my parents can use or I can walk around and say, look, this is a business that was helped by it. So most of the companies I've worked at have all been either consumer or small business companies. In the case of DoorDash, it has both consumers and small businesses. In the case of Square, it was the same and both Google and Facebook. So I think that's at least from a work point of view and I think it's true for everyone. If you had to wake up in the morning for several years and come into work at some point, you can't fake it. It has to be real, genuine enthusiasm for the mission, for the product and for the company. And I think the second thing is the leader. I think the same company with two different leaders can be very different places. So you want a leader who you can learn from, who you feel excited about leading this company and who you feel has a greater purpose in mind than just making money. I think I personally am not, and I think different people are motivated by different things than leaders, but I personally am motivated by leaders who want to win, want to build a product that is used by hundreds of millions of billions of people that think very big, but never mention the word revenue or money. They just want to serve the customer really well, better than everyone else. They're fiercely competitive, but not about making money. Money will come, revenue will come, all those things if you build the best product, if you compete fiercely for the best processes, etc. I think high agency is a hard one. I think it's a good concept. I feel there is a lot of intrinsic stuff there. I've seen that the agency development comes when people are motivated intrinsically by three things, essentially. One is a sense of purpose, where they feel that what they're doing matters. I think this is why a sense.

Of purpose.

It basically is something that you can get from both your job as well as your, you know, as well as the actual company you work at. The second thing is potential. I think high agency comes when the work that you do gives you skills that you can use later on in life. So people feel that what they're doing is not this drudgery or mindless work, but it's building up some skill set or some ability that they're building. It's almost superb. That would be helpful later on in life. And that's why you see a lot of people who maybe were not computer science undergrads, but basically were, say, literature undergrads and then go to do a computer science class. They're extremely motivated. They're high agency because they know that the literature undergrad maybe didn't give them the type of role or job they wanted to work on building products. But the CS degree now can help them. So they are much more motivated than the CS undergrad who's just in college doing cs. But now in one year, you have to find a job. You want to find a software engineering job and so you go through a CS boot. Camp and you're extremely motivated and you're very. You become very proactive about things because you know more. And the third one is play. When I say play, what I mean is you are allowed to be creative and inventive in your role and not micromanaged by people. The more micromanaged you are, the less agency you will have, paradoxically. In other words, if you're told what to do precisely and you can't deviate from it at all, you're just going to overtime not have any agency of your own and you'll just. Just try to follow the letter of the law and even cheat the letter of the law in a way that will be bad for yourself and the company. There was a classic story of the. When the British were in India, they asked people to bring cobras and they would pay money for. In India there was a big cobra infestation, I think in north India somewhere. And they asked the locals, Indians to bring cobras and they would pay for the cobras to get rid of cobras. But it led to people basically started gaming the system where they started growing cobras or basically hatching cobras at home and they brought more cobras and they would cut off just the tail of the cobra and bring it and the cobra would survive in order to bring the tail. So they were essentially the behavior that you wanted to avoid. You are now by very specifically telling them what to do. So that's why I think external incentives. So this is actually a story that shows that it has to be through these three things, purpose, play and potential. It cannot be through rewards. I think don't work like this, reward for cobra because it leads to people basically gaming the system, get the reward. They actually do the work that you think.

So.

Those are the three things I would say.

Yeah, yeah. Okay. We have a question on culture and people which you talked about earlier. We later have a question on hiring. I think we can take it then. Moving on. This is another question which we come across quite frequently. If you don't have enough data to develop a feature, what things do you rely on? And as a new pm, what are the early wins that are necessary to build a strong intuition? So when it comes to data versus intuition, how do you balance those? And in the absence of data, what is it that you look for so you can talk a bit about that?

Very simple. I think there are three things like you mentioned. There is data, intuition and the third one is customers customer insights. I think every good product development team should every week be talking to at Least one or two customers. And it's not just a product manager, but it's the engineers and the designers. If you do that every week over, you know, talk to two customers, it's only half an hour interviews. Take one hour of your week to do that. That's a hundred customer interviews. And I bet that with those hundred interviews you will never be short of customer first party customer insights around anything.

You want to do.

And even if you are, guess what, right around the corner, there's two interviews this week and two interviews next week. And so I think that's something that is very, very important. The second thing is I think you as a PM especially you need to realize that engineering time is the most valuable time in the company. It is literally the most valuable time, most expensive times because engineers are the highest paid function at most companies. And what that means is that you need to try to test things in a very scrappy way before you get engineers are building features. So building features is something that is only done once you have some kind of hypothesis that is supported by either customer insights, data or ideally scrappy experiments you can run. You also have to I think build some scrappiness. There's a lot of tools out there. There's a lot of no code tools out there. There's a lot of things you can do without writing a single line of code. You can do mockups, you can show customers that data. You can send emails out to existing customers and get them to click on it email that simulate what the app would have done. For example, if you're building consumer app or you can even have a landing page which is basically built directly in a website building tool, a wix, a weebly or a squarespace or something like that and get them to check something. Or you can get someone to check a box but then show them something saying oh, sorry, we haven't yet built it. Thank you adding us to the waitlist in the app itself. So there's many, many ways to build even if you don't have either customer insights or data to scrappily get data around whether customers will engage with this feature. And this feature is valuable. But I would strongly suggest think as if you had zero engineers while trying to validate something. Do not use your engineers to try to validate intuition, but customer insights and getting them getting engineers and designers on customer calls on a regular basis. I think not the whole engineering team doesn't need to be on every customer calls, but rotating them so that at leave once every two weeks every engineer listen to one customer call is I think a very good best practice. And especially their laptops down list actually listening and you're asking the right kinds of questions and drawing out the customer. What they like, what do they use this for? How they discovered it is always a good thing. How did you find out about it? Because that tells you about acquisition and then what else do you use? Tells you about in the same scene, what were you using before? Tells you what other competition you have, what else have you tried? There are all these questions that are open ended. You want the customer to talk, but there's a lot of good insights you can get. And use a recording tool like an otter AI which you ask customer for permission, records them and then transcribes them. So you're not taking notes, you're then just synthesizing them later on. So just come up with a good process. Do these since you're going to be.

Doing these twice a week, right?

Yeah. Interesting. So instead of engineers working in silos, it's really important that they are also involved in the comments or listening to the conversations with the customers.

Exactly. Got it.

Thanks Gokul, that was really helpful. And auto AI to help you transcribe and go through the calls later. Okay, moving on. Your advice on defining and deciding the North Star metric. How do you go about it?

The North Star metric? I think there are two things about the North Star metric before we define it. Actually. No, let's define it. First, you need to understand what kind of value are you delivering to your customers. So if you can define a metric that is not about value to the company, but about value delivered to the customer, I think that's something that provides value to the customer but also provides value to the company. If you deliver that value, that's probably the best way to do it. And value the customer expressed as an output metric. I would say so. Therefore, daus for a consumer company or for a media company is a good number because DAUs means that consumers are coming back to use the app or service on a daily basis. It also is valuable to the company because obviously if you have DAUs, then you can monetize them at some future point. Similarly, GMV is a good example for Marketplace because GMV means that customers or consumers are buying whatever product or service you have and then that's valuable to them because they're buying, they're making the action. But it's not directly revenue. So revenue is never a North Star metric. I think you always want to use something that is one degree removed away from revenue, which is ideally an action based on consumer behavior. The one caution I would have is never use a single North Star metric. Always have what I call a check metric along with the North Star metric. North Star metric by itself can lead to really challenging behaviors. And so you need to have a check metric that essentially is a check or make sure that you're not doing crazy stuff. So in the marketplace example, easy way to improve your GMV is to make all the fees zero. But if you make all the fees zero, you don't make any money yourself. But your GMV will skyrocket and you basically have a very, very unprofitable business that will die. And similarly in the DAU, you can actually increase DAUs by just having a bottom, you know, or some, you know, some kind of browser plugin that just pings your website when someone uses it or some other way to do it without someone engaging with your content. And so there's no engagement mechanism. So I think you need to make sure this, the quality of the North Star metric is high and that's why you have a check metric. So you never have a North Star metric at the company level or the team level without having a corresponding check metric that make sure this is a high quality North Star metric. The quality is good.

Got it. Okay. Okay, moving on. What's the biggest opportunity and the biggest challenge you see in the food industry right now? So with your experience with caviar, I.

Didn'T deal properly because of doordash being public. I can't speak on food delivery industry or doordash related questions because.

Okay, cool. I think we have a couple more doordash questions. You see they can be answered otherwise. Yeah, can skip those.

This also I won't give you the.

Answer.

But in general I would say all acquisition. All the acquisition. Not this specific one but I've done a 10. But people issues are the hardest. Not even people. Integration is always the biggest thing you have to think about because acquisition not about acquisition of company. That's kind of a one time event. But the ongoing event is integrating the teams, processes, all of those things. So I think you need to have a very strong. That's why M and A teams very quickly realized that most important person on the M and A team is not the cop dev person who does the deal but the integration leader who integrates the companies and brings them together.

Got it. Okay. Okay. Again, a doordash related question of learnings insight from doordash about food delivery that you think can be applied. Is this something that you can take.

This I, you know, this also I probably shouldn't because of Doordash. I wouldn't be able to answer this one also.

Sorry about that.

Okay, no worries.

This next one is interesting. How do companies get the acquisition going without dependency on Facebook? The reality is that there's always going to be some dependence because if you don't have that, then you're missing out on a big channel. So you've got to test those out. But every D2C company has to build their own channel. I think virality is one way where I think one of the hardest but most defensible basis if your product is truly a multiplayer product. There's a company, there are two companies in the US called one is called Venmo and the other is called Cash App or square cash versus. Both of them are P2Pmoney sending companies. They are literally. They won't work unless you have someone on the other end. And WhatsApp is the same way and so is messenger, obviously, Facebook Messenger. All of these products require people to be on the platform to communicate or send money. So anything, if you can somehow make a product be a better experience when other people are on the product, I think it becomes naturally viral. So that's one. The second one is I think something that what clubhouse is following now or Twitter did back in the day, getting celebrities or influencers to use the product and being known as like a place where influencers are using it. And I think there are companies, like, there are other commerce companies that are using influencers to do videos and so on on YouTube or sponsored videos or tweets and so on where influencers actually are using the product and promoting it. So I think those are two of the examples. But I think look, looking around, I mean there is, as I say, you need only one golden channel for acquisition. But I think the biggest challenge is acquisition is actually you can spend money left and right and get acquisition. The challenge becomes retention. Because, you know, an easy way, for example, for almost any company to quickly acquire is to give away your product, right? To reduce the price on your product. But the challenge is when you reduce the price on your product, you'll see that. I think it was Burger King one day in the US they made the burger free or something, or they made the burger like $1. They became the top app in the App Store for like two days. But I'm not sure if that promotion actually led to high quality users. So one of the things I would advise on acquisition is hold your acquisition.

Team.

Hold them accountable for not just Acquisition. But for companies which have E commerce is defined as placing one order but hold them accountable for what percent of those first order customers also place a second order. Because you probably have a metric like that for your general new customers you acquire where like say 20, 30, whatever percent of customers end up placing a second order within the first 30 days, which is important. And you need to hold every channel to the same metric because if they just place one order but they don't pay the second order within the first 30 days, that's a useless channel. Right. Because that customer is basically useless. You've paid a lot for that customer or done a lot of work with the customer. So that channel needs to be scored not just on CPA but on the percentage of, but on CP off the number of second custom second time ordering customers within the first 30 days.

Got it. That was super helpful. Yeah. A question on scale. How do you approach experimentation at scale? What are the learnings you've had implementing an experimentation mindset in your team?

So this is a good one. It's a very good. My approach to experimentation is this goes in part to the, to the product feature question is that every product feature is a hypothesis. It is a hypothesis about consumer behavior. Because regardless of what data you have, what customer insights you have, you can't know in advance what consumers or customers are going to react to it. You can, you can hypothesize. And so you think of a feature as an experiment you're running to validate the hypothesis. If you think of it that way, then every feature is an experiment. Every feature is an experiment. And so what that means is that every feature so that then it removes the, I think the artificial boundary or distinction between growth teams, product teams, because then every product team should treat every feature as an experiment, have a hypothesis about the customer behavior that this experiment or feature is going to change, and then launch this feature as an experiment only going out to x percent of customers. See the behavior change in that test bucket and only iterate and see how it diverges from the hypothesis you had. And, and if it diverges, then iterate and understand why does the behavior feature diversify. The hypothesis should be tangible. It should be something like we expect a second order change by 5% as a result of this feature and basically then launch it to 10% of all new customers and see the second order placing rate changes by 5%. If it only changes by 1% or it changes by 20%, those are both divergences. You need to understand why. And if it's especially if it's lower than 5%, you need to push the product team cannot just oh yeah, well, it's lower. I'm just going to launch it still to everyone. They need to be held accountable to iterating and getting it closer to 5% or understanding the root cause of why it's not 5%. But that basically forces discipline around A, understanding the impact of every feature and B, iteration till you can prove the hypothesis and not giving up on a feature too early. So every email should with an experimentation mindset. So launch is not success. Launch is just an experiment.

Launch.

Yeah. Yeah. Okay, this is another interesting question. What are the most important pieces to put in place for a domestically strong startup to succeed with international expansion? Is there some advice which you can share about this?

Well, I guess the question is, when you say domestic, we are here on this webinar from so many countries that.

It'S mostly Asia, Southeast Asia.

But an Indonesian startup to go to Malaysia is a very different beast than for a US startup to come to Asia.

Right.

I think there's a few different pieces. One, a playbook. I think a Playbook, as hopefully many of you know from Uber or gojek or other places, is a repeatable process that you can put into place and execute on that given certain conditions, can lead to success. You've got to make sure this Playbook actually works in different conditions because a new market might have very different conditions.

Than your current market.

So therefore, the second piece is operator who you're sending out who actually understands your company culture and actually has seen this playbook in a few different places. So then when they go there and they find almost inevitably that it's not exactly the same as what it was in your first country, they don't just say, oh my gosh, I have a playbook. They kind of have seen a few different cases, they try a few different things and they're confident to try a few different things and adapt the Playbook as needed. And I think patience is the third thing. I think a new market, international expansion always takes longer. It's almost like, you know, it takes one year instead of three months for the playbook to click and. But so you need someone who's very flexible on the ground, has a lot of, like I said, they have, you're not micromanaging them so they are able to be creative and innovate there. You don't know what the situation on the ground is. So you need to send one of your most trusted operators there because ground is very different. Even in a Neighboring country situation can be very different because of competition, how customers think about this brand, who knows what. And so you need to trust them, you need to give them a longer leeway and you need to give dedicated resources to them. Especially in product engineering if there are things that need to be done. Just a pure operator LED team can starve because they might need to build a new form of payment. For example, as many of you may know India needed cash for example when they were Uber cash payment. And you know, I think it was good that Uber was able to allocate resources to do that, but some other company might not have been able to. Well, we'll build it, figure out how to win without cash and we'll get to it on a global roadmap. So I think every company, the more different the company is from your original company, the more important it is for there to be dedicated team. So for example, if a US company were to go to like you know, a non English speaking country or you know, country which is not UK or Australia from the US you better have a dedicated team of engineers and product managers because you're going to make have to make localization changes, a bunch of changes which are cultural in nature, you don't even know what they are. But completely nimble and ideally the same time zone so they can behave like a startup. And their goal should be to get this country successful, not to worry about.

The U.S. country or U.S. market.

Yeah. Yeah. Okay. Yeah. This is the last question from the registrations which we have received. After this we'll move to the Q and A tab on Zoom and we'll take questions from there. Yeah. Coming back to this Google, what makes a great PM for you? Some things you look for while hiring. So you mentioned that culture fit is of utmost importance. So how do you go about that?

Let's see. I think this, this is actually I have refined this over the years because I've hired and so many. I would say there are three things. One, being a problem solver, product manager at its core about problem solving. It is about solving customer problems in a way that in a remarkable way that's different from what others are doing or a unique way ideally that adds value to the company. As you are junior in your career or earlier in your career, you basically solve very focused problems. Where someone gives you a very specific problem, you solve it and then as you get more seasoned, the problems become more and more open ended. At the chief product officer level you're solving the company level problem. What does my company, what does my company do, how does it solve, what problems should my company solve for customers? How does it do so in a way that's different from others? What others are doing in a unique way? How does it do so in a way that's building value for shareholders and the company? And so I think you've got to, when you're hiring a pm, you've got to test their ability to solve problems. And so the second thing then what makes a great PM is when confronted with a problem, they are able to decompose into a. They're able to decompose it into, I would say, a structured technique. They're able to decompose it using a structured technique of experimentation and hypothesis. I think I like product managers who really, we talked about features being hypotheses, who are very intentional about how they tackle a problem by working from first principles. So when, you know, I think this first principles concept is really powerful because first principles, again based on earlier question, come from either data about customer behavior or actual insights from customers by talking to them. They don't come from, well, competitor a competitor X is doing Y, so we should do X. I really dislike that kind of answer to any question. I like original thinkers who think from first principles. And this is true whether you're solving a problem, whether you're almost any answer. If I ask them, what do you think of Z or what do you think of this thing? They should never say, well, it's because these guys did it. They are smart, so it should be good. No, what I meant is what value does it add to the customer? What do we know from our customer behavior? Is this something that customers need? Is this a top pain point, why do you think that, etc. So always try to go back to first principles and keep asking the why and never ever settle for the lazy answer, which is someone else did it, so we should also do this. The third thing is, I think someone who works collaboratively, final thing, someone who can work extremely collaboratively with design and engineering and ideally with all functions. Because product management no longer is just an isolated product design, engineering, it's increasingly, it impacts every function of the company. And what that means is they don't have a CEO mentality. A lot of PMs, young PMs are attracted by this false notion that the product manager is the CEO of the product. No, you're not the CEO of the product. There's nothing. You're not managing these people. You're not telling them what to do. Your job is to be very clear about the problems we are solving about the problems we are solving and about really helping the team brainstorm. Putting the structure in place of the team can brainstorm alternatives to solving the problem and identify the best alternative, the best way based on data, based on insights and then run a structured process around proving this hypothesis and then having a way that okay, the hypothesis is not proven after iteration. Then let's go to our second best way of solving the problem. But always keep the team focused on the problem we are trying to solve. What are the customer problem we are trying to solve? What is the customer problem you're trying to solve? Teams many times will be like, well, it didn't work well, let's go back. Always bring the team back. What are we trying to do here? Right? Is the person in the room, what are we trying to do here? What are we trying to accomplish? We're trying to solve the customer problem. We're not trying to just launch a feature for feature's sake. And those are unfortunately the behaviors that PMs need to cure themselves of becoming feature junkies. So when you have a pm, when you ask them what have you done? And they rattle off a list of features, that's like I think one of the unfortunately bad behaviors because you get rewarded for just launching features XYZ versus saying here's the impact. Forget the feature. You in fact, good PM answers don't even talk about the actual feature. They talk about the customer problem. I got customer retention to go up by 30%. I got new customer activation to increase by 20%. I got daily active users to increase by 3%. That's the kind of things that you want them to be proud of. Not launching an Android app. Who the hell cares if an Android app was launched or launching a certain screen?

No one cares.

Customers don't care. Customers want to solve problems and Android app is a tool to solve a problem. So instead of saying I launched an Android app, tell me what the Android app did for how many customers started signing up or how many of them started using it on a daily basis or how many of them became more engaged or active or retained. Only them started buying stuff from your app.

Correct? Yeah, that was super helpful. PM aspirants on the call on the webinar. I hope you took note of that. Okay, let's pick some questions. I'll stop sharing the screen and we'll pick some questions from the Q and A tab now. Okay, there's a question around culture. Isn't culture something you learn once you join the company? What is it that you can do individually to make sure that you are a good culture fit wherever you go. So some comment rates there which could.

Be developed because culture like you pointed out, is not something you can put on a, on a list and just publish it. It truly is something that after you have 20 or 30 people you in more ways than not, almost certainly because.

Founders end up hiring. The first few people they hire are people that they are similar to in many ways.

So they reinforce the culture. Google, for example, had a very, very technical and productive innovation focused culture because that's the kind of people that Facebook had a very growth focused culture, not as an innovation focused culture because the goal was to grow at all costs.

And and so that was the culture. DoorDash had a culture or still has.

Again, I won't speak to DoorDash, which.

Is very, very, I think Uber, I.

Would say has a culture. Forget about DoorDash.

Uber has a culture which is very.

Operational because that's what the company is about. It's about operating and making sure things get done square has a culture that's again similar to Google, very innovation focused. So I think you get to understand the culture by talking to the leaders of the company and observing their behaviors and how they answer questions like how do you set goals?

How do you get stuff done?

How do you make decisions, you know, and just asking them. And instead of how, talk to me about how you set goals for the year.

If they talk, if they say, well the goals are all set bottoms up, you know, that's probably a different kind.

Of culture that I set goals top down and plans to set bottom down. We met somewhere in the middle or.

How did you launch your last product?

Tell me about the last product launch.

You know, well, I was talking to.

The CEO of X company and we.

Came up with this idea and then.

I emailed my PM and I launched this product that's a different one where we talked to a bunch of customers and customers. We basically surfaced this pain point that customers had and we basically did a lot of work to understand that we could do a better job of satisfying these customers needs in a more remarkable way than anyone else can. And so we said let's test this hypothesis. And we went and tested the hypothesis.

So I think there's, you know, I.

Think it's very hard. Many people sometimes don't give you the full truth.

So but the best you actually, if.

You can somehow spend a week at the company almost as a, almost as a.

And companies would like you too, you know, three hours a day after you have gotten the offer, if you say.

Hey, can I spend afternoons at the company just hanging around and especially if you're not in a competitive space, the company will be fine with that.

And the company also likes it because.

They get to also see what kind of culture fit you are. But just seeing how people work with.

Each other, how they interact with each.

Other, sitting in on a few meetings, that would be a great way to understand the culture. Because culture is behaviors that are expressed.

By people's actions, is the agglomeration of all of them.

Not words, like I said, not words that are written on a piece of paper or said at an all hands. It's behaviors of people.

When you see behaviors and how they treat each other, how they make decisions, how decision making is one of the.

Best ways this culture is expressed.

Who makes a decision when there's a meeting, do people just automatically defer to.

The highest paid person in the room? Or is there mutual respect and trust and actually everyone's voice is heard. There's a clear decision maker who's not. The highest paid person is the person who is basically owning the decision. It can be anyone. And highest paid person is also just an input to that person.

So I think those are the things that are very hard to suss out. But asking some questions on decision making and really not just general questions, tell me about the last decision that was made at the company or about your product, who made the decision? How was it made? And so asking questions on decision making, what do you look for while hiring? I mean, obviously you're being hired, but once you get the offer is when you can really dig deep. But you should be asking those questions throughout your interview process to get a better sense of what they value, what they look for. Tell me about successful. Tell me about a successful product manager or leader at this company. What is their background? What did they accomplish? So it also tells you what the company. Because successful people at companies many times embody the company's culture. And so if you can understand, if you can ask each interviewer, tell me what the most successful person in your function, what did they accomplish? What did they do? You know what? And so you can actually probably then join the dots around, okay, there are these five successful people. Each of them mentioned a different person. What is common about all of them. And those behaviors are probably something that is embodying the company's culture because you don't get success at a company. I can tell you this without. Without being a good culture fit.

That's right. Yeah, yeah. Okay. Kelvin asked this question, how do you build product prioritization process that ensures the most impactful initiatives are selected and executed periodically? So how do you prioritize features? How do you prioritize in general?

So again, I think it's like I've said a few times, you have to first figure out what problem you're solving. And so each product team should have a problem. And I think you, you, once you understand what problem you're solving and have a clear goal around the customer behavior you want to change. For example, like I said, there could be product team goal is around acquisition and activation and the goal there is to increase, increase your activations or acquisitions from 10,000 to 50,000 in a quarter. I think one of the ways to do that is to throughout the previous quarter have a strong analytics team who's constantly exploring the relationship between inputs and outputs. What I mean by that is input metrics are metrics that are under your control, completely under control. For example, changing the price of a product, if you know what the relationship is between changing the price and conversion, for example, to running a bunch of tests during the quarter, then you can actually see whether changing a price in a more full blown way is a way to improve conversion rate for new customers. Just for new customer, changing the price. And then it's something that you can actually launch as a feature. And it's a way, it's one of the, one of the tactics to then solve the broader problem was how do I increase number of newly acquired customers? Because if you decompose a number of newly acquired customers, you can break it down into two or three things. One, you can say, well, I want to increase the number of customers who just come to my website or download the app. And second, I can improve the conversion rate from the visit to the new customer, the conversion rate. So, so then you can see which of those two problems is the more important problem, which is the easier problem. So those are the things that you need to, you know, you've solved one. Hopefully the same team is owning this problem for at least three or four quarters. And that's why it's interesting because then you build muscle around, okay, we tried these things, we tried these six things to improve the people who come to our website. It's not as hard, especially not as easy anymore. Let's now go and tackle this other thing which is improving conversion rate. And we know from analytics team that improving increasing price or changing the messaging or we know from our customer conversation that they don't understand. We've interviewed 10 customers who got stuck between, you know, that's why when you do customer interviews, you should actually interview different segments of customers. Customers landed on your web, you can even come up with different segments. Customer landed on your website but didn't convert. You can put up a little thing for them to enter the email. You can then interview them. Why did they get stuck? Why did they not go? So I think out of the hundred customers you interview, you know, a year, 20 of them should be customers who've never heard of you. 20 of them should be customers who've heard of you but not visited your site. 20 of them should be customers who visited your site but not actually gone on to purchase. 20 of them should be customers who've gone on to purchase but not made a second purchase. And 20 of them should be customers who are loyalists who are constantly purchasing from you. So you can have different segments like that, and you're basically mixing and matching the customers you interview so you understand again what customers care about. And based on what part of the customer journey you're tackling, you can then have a hypothesis around it, but always go back to what problem you're solving. It centers you, it. That's why I don't care about how you prioritize features. To be honest, I've stopped caring about that. What I care about is I negotiate with my product teams, the customer behavior change and numerical value for that. I want to see what you're committing to. And it always is going to be a little bit off the first time around as a team. But the second time around, I want you to, you know, basically understand what, what this, what this customer behavior is about, what drives it, what insights do you have? And I want a pace of experimentation. That's one experiment every two weeks, one hypothesis, one test every two weeks or something like that.

Got it? Yeah. There's a similar question by Dennis which says, how do we do customer interview at scale? How do we pick the right customer to talk to? Which I think you answered based on segments.

I think categorize the same type of customer again and again. They could also be, obviously this is consumer customers, but if you have different verticals you're targeting, you come with different Personas and they could be at square. Their restaurant owner is a very different customer than a single, single restaurant is different customer than someone who owns 10 restaurants or someone who owns a retail store or someone runs a spa or salon. So you have different archetypes. But make sure you're, you're, you're, you're, you know and then I think different stages of the funnel but you ask them open ended questions, I think ask them what, how they, how they learned about you, why they chose you or didn't choose you. You really want to get two or three levels deep. Okay, you didn't. But what, what made you choose this competitor? So just keep digging deeper and deeper and ask the five whys question. There's a five whys W H Y S technique developed in Japan which allows you to get to the root cause of something. Okay, why didn't you, why didn't you, you know, why haven't you heard of this thing? Well, it's because I don't, I'm not in tv but you know, why are you not on tv? Because I don't like. So I think you basically get to the root cause. That's typically something that you can address through a process change or some other mechanism. But really try to get ask a smaller number of open ended questions that lead to deep customer insight. You try to want to aim to at least one interesting customer insight from every two interviews every week. Ideally you should then say my goodness, we learned this thing about this segment of customers. Ideally for that week you should interview both customers from the same kind of segment so that you basically have one fresh and the second one you can build and you can see what the similarity differences are from this segment of customers.

Perfect. Yeah, yeah. There's a question from Kalol which says if we don't use engineering bandwidth, then how do we do it? A B test, Is there a way around it?

I think this is harder when you're a young company, but when you're a slightly more mature company, you can actually build tooling.

So optimizely. For example, there's a lot of AB.

Testing things that you can do without engineering. Marketing can do a B test. Now there's a lot of good A B testing tools without needing engineering. Engineers need to set up the framework and then PMs and marketers and others can do a B testing without doing stuff.

Also, you don't need to do AB testing in the product.

I think what you're trying to say here is that every AB test has to be in the product. Like I said. For example, if you're testing a product feature to existing customers, you can just email those existing customers and have them click through on and land on a separate page or website that you've designed and see what they do there. Doesn't need to be fancy because you just want, you just want directional indication. Are they going to subscribe. If you want to test, assume you have a transaction that you want to test. Subscription feature, right? You just create an email saying you're testing out a subscription, you know, and.

You can manually, you can manually run.

The subscription in some way. You can get them to sign up to a webpage that you create and.

You can just build the credit cards.

Manually if you want. You can even say it's free because you want to see if they.

And then you can build the credit.

Cards a month later. But I've seen a lot of things done by some combination of PMs and operators who are basically business people that.

That they see because operators actually I.

Would say are even PM sometimes unfortunately have been made too dependent on engineers.

So they basically are unable to run tests without engineers.

Operators have never had engineers, so they are much scrappier than pm. So I would say find an operator at your company who's not had any engineers and brainstorm with them. I want to test this. I bet you your operations people will be able to smart operations come up with great ideas on how to test things without even touching the product or.

Smart marketing people because even marketers and.

Operators don't get many engineers. They've had to do themselves using third party tools.

Yeah, yeah.

Third party tools now to do stuff. No code and other tools. Lots of them.

Yeah, yeah. There's an, There's a question by. There's an anonymous question I think from an engineer that says, which I think you've already answered. I understand we should see the impact from a product point of view. Any advice for engineering devs please. From a PM point of view, I think you mentioned that an engineer should also be talking to the customers or listening to the calls. Is there any other advice you have for engineers as a pm this is.

Advice I think be customer centric is definitely one. I think you got to really if you are the kind of. I think a lot of companies love engineers who are, you know, not just very good at engineering but, but very good at understanding and taking it back to what the customer need is and pain point is and what you're trying to solve. I would say the other thing I would say is that if you're an engineering manager, you should also hold the engineering team working on a project accountable to the same level of. Same level of. I would say same, same performance metric that you hold your PM accountable for. One of the hardest things to do is basically one of the. Sorry, one of the things I don't like at all is that you Might have a product ranging team working on a product, the product didn't do well or do well, but turns out that the product manager working on that product gets evaluated in their performance review completely differently than the engineering manager, then the engineering lead on the product. The reason I think is because engineering orgs don't really reward business metric performance or performance against customer goals. They seem to reward a lot of good engineering behaviors like writing high quality code, building scalable systems, et cetera, et cetera, hiring good engineers, all of that stuff. So I would say, you know, remember performance review has the word performance in it, which means people need to be evaluated on performance. And so everyone on the team should be evaluated and get the same grade for performance. Now there are 30, 70% of your grade and performance review should be based on performance against your customer problem you're solving. But 30% is based on behaviors. For example, if you are a good colleague or if you are helping with hiring. I mean every function has their own set of behaviors that they value from a functional perspective. But 70% has to be the same. And I think as soon as you start telling engineers that, guess what, it matters whether you meet this goal or not. Engineers also become equally customer centric because they realize that just because I write great code, I can't just say, well, it's a PM's job. They basically said that, you know, this is what we need to build. And we built this or tested this, it didn't work. We didn't hit our goal. No, no, no, that's no excuse. All of you are in it together. All of you are in it together. And that's the thing. I think that mentality needs to be built and you need to build a mentality as an engineer. It's not the PM's job, it's to get our job to figure out how to solve this customer behavior. As soon as it becomes us versus them, you're done.

You're done as a company.

So you have to. That's why I think, I think you ideally don't even want funk. You don't even want marketing to have different goals. You want your whole company divided into three or four pillars or initiatives. And that pillar is completely cross functional. And its goals are owned by a product lead, marketing lead, engineering lead, maybe a sales lead, operations lead. But all of them are evaluated on that goal and they don't have a different product goal. But not all of so product will then sacrifice. Ultimately everyone's sacrificing to make sure they're hitting this common goal. Then whatever. That's the goal that matters. So what if product didn't fully do exactly this? They changed things around to hit that goal to help operations operations. Turned out they had an insight but all of them are together focused on this goal.

Yeah, yeah, that was really helpful. We have had our time. Let's just push it by five more minutes. We'll take a couple more questions and then this. Okay, you have spoken about learnings already Google, but there's a question specific to what was the key learning in the initial stages of building ads network for go for Google at Google. So any specific learning from that you can share.

I think the biggest one is that you need to build multiplicative products and not additive products. What I mean by that is that the best products are those that leverage the existing assets that your company have in a very seamless way. Google, the Google Ad network succeeded because both the things it had as a differentiation were things that Google already had. One targeting Google already knew how to map keywords to web pages or phrases to web pages. So it is easy for us to do the reverse which is take the Google index and take a web page and figure out what phrases it responds to. So we were able to figure out target instantly leveraging the react and it became better and better automatically built into what Google was doing. And the second thing is an inventory of ads because if you want to you need ads for a given publisher and Google already had ads to adwords which had launched. So we were just able to create a new channel using the same technology as Google had built and the same inventory. And so that's what you need to I think new products that are completely additive which don't leverage any of the technology resources that the company has already built are very, very hard to get off the ground. I think the best new products are those where you just say you just add a new thing and a percentage of customers will use it automatically because it's so seamless and it's just part of their behavior. And so for example, if I'm a company that moves money something to some easy new product would be instead of building a completely new like lending product in that money moving phase that customers go to, I would just put a checkbox in, do you want a loan? Or something like that? And that itself like that's a multiplicative product because 100% of people are going through their flow, 5% of people start using the product and guess what, that's a big product right there. So you want to find these multiplicative products as much as possible versus having a new tab and emailing customers and so on. So I think you want to do things that are seamless as much as possible within existing flows. And new products are simply offshoots of existing products or use fundamental technologies is the other thing I think the fundamental things you build. So beware of things that make you conglomerate because the General Electric side conglomerate is no longer going to work or even a Berkshire Hathaway style unless you're not part. Berkshire Hathaway is different because they just own holding stakes in a bunch of companies that are all independent companies. But General Electric was a good example where they had a bunch of underrated businesses under one company and there were no synergies within the companies. So synergy is not a bad word. It's actually a good word. It means that there is something you're sharing and some asset or some competence that you're bringing from one business to the other. Why us? When you start a company, when you start a new product, why does. Why do we. Why do we deserve to start this product?

Right?

What is it about us that makes this product more like you, successful under our umbrella versus standalone startup? What do we bring to the table? Got to ask ourselves this, honestly.

Yeah. Yeah. Okay, quick question. Okay.