Kaushik Subramanian - Learnings from building products at Meta and Stripe, Extreme focus on the user problem, User first mentality, Choosing your design partners

During those four years, I was like, shit, I am average and this sucks. And I'm average because I didn't work hard. You had the opportunity, but you didn't work hard enough. So now you're in the averages and that sucks. So at that point I was like, I'm never going to let myself not win because I didn't work hard enough.

Hey guys. Welcome to a new episode of the Venture Europe podcast. Our guest today is Kaushik Subramanian, partner at EQT Ventures. Investing primarily in product led technology businesses through from offices in Stockholm, London, Berlin, Paris and New York, EQT invests in and supports entrepreneurs building the next generation of global winners from a 1.1 billion euro fund. Prior to joining EQT, Kaushyk was at Stripe and Meta, where he built and scaled several products to global reach and generating billions. During this episode we discuss how to choose your design partners when building the early version of the product, why he decided to join EQT Ventures, and how he assesses founders if they have a product first mindset.

Enjoy. How is your sleep going?

There isn't much of it at the moment. It's a bit full on. I think. One year into a new job, one month into a promotion as a father and you know, everything just changes around you. As I described to a friend the other day, it's a firmware update. So just trying to make sense of everything around me at the moment. Yeah. So not much sleep. Sadly, that's not the priority at this point, so it's a bit full on.

We were actually introduced by a common friend, Henrik, and he told me that this very cool guy, he led product teams at Stripe and prior to that it's Meta, arguably two of the most impactful companies of this decade. So I was actually very, very excited to get to talk to you because also have a lot of friends building products. So for them maybe it's easier to see iterations and to build products for not such a big volume, but probably you saw how it is to build products both for a smaller user base, but then also how to think about scaling that product. So super excited to touch on that.

Thanks. Yes, very happy to share more about that. I think there are pros and cons of that and very, very happy to dig deep into that.

Let's start with philosophy. Like do you think building products, you need to have a sort of philosophy?

I think as long as your philosophy is user first, I think it's a good philosophy. But I think that's probably the, the one Hill I'm willing to die on in the sense, I think, respect to whether you're a startup founder or whether you're a PM at Stripe, you put your users first and you try to build a product that solves a user problem. I know it sounds very simplistic, but amidst all, it becomes a pretty hard thing to do because there's obviously so many frameworks and tools and productivity stack and this and that, all of which is cool. But I think at the core of it, it's user has a problem. I solve that problem using technology, and that is a great product. And obviously then you know, you have to find the right kind of users and all of those kinds of things. But that is the philosophy, I think. So every time I've found myself, you know, not like my product not taking off, it has primarily been because I wasn't really solving the user problem. I thought I was solving one, but either I hadn't done enough work to understand the user or the problem, or both.

What is the work that you would do initially to understand the user problem? So I guess if you already have a product that has multiple type of features, maybe you can get an insight into the data what a user problem might be. But if you don't have a product with a lot of features, how do you go about, how do you go into the market and test the user problem? Because not all the founders actually will tell you, or not all the users will tell you what their problem is. And maybe they will tell you one thing, but actually the problem is something else.

Yes. Actually, here's something I learned. So I have a pretty strange background in the sense I started my career in consumer goods and it was very unconventional to go from consumer to like hardcore tech in that sense. Like, you know, my last role at Stripe, I was doing money movement, which is, you know, pretty different from consumer goods, specifically Shampoo. But I think the one thing that I learned about, you know, when you're doing consumer goods products or when you're trying to create a new consumer goods product, is you go out and the market and you meet users. You meet, you know, shopkeepers or stores that are storing the product. You at least meet 2, 3 users of the product every month. Similarly, there's something called as like observation. So you just look at how the user is using your product. And all of this, like training happened in like very formative career years for me when I was at l' Oreal and, you know, so we would actually go and like look at like, how are people squeezing the shampoo out of the bottle, how much shampoo are they taking, how much of that are they actually using on their hair? And do they do it twice or just once? And does it change by, you know, gender or does it change, you know, length of hair or whatever, things like that? Honestly, like, I kind of started using the same principles and I think a lot of the best PMs as well do, which is just pick up the phone and, like, talk to users as much as possible, like, know what they're saying, but also know how they're using the product. For example, you know, there have been times when I've just tried to observe what users are doing. Kind of like it's a bit creepy, but just like sitting behind them and seeing how they're using the product. But that kind of usability and that kind of depth that it gives you, I mean, you know, it's taught me a bunch of things like, for example, users rarely use the product in the way you intended them to use it. So I'm like, you know, what user will go from here, there to there, and this is what they use it for. And then you actually go and see where you find product market fit. It's probably somewhere else or in a completely different use case related to it, of course, but not being used in the way as intended. And you're like, okay, that's the use case I need to build for, not what I wrote in my PRD seven months ago after reading, you know, a lot about the user problem. So I think it comes down to what I said initially, right? Which is, are you really deep in the user problem? How well do you know your user? How well can you describe them? How much time are you spending with them? Are you observing them? Or are you just doing half an hour of intake interviews every month and saying, oh, yeah, I did one user interview. It's brilliant, everything's going well. Because I think in half an hour it's impossible to tell if that's an actual user pain point or, you know, if it's just something the user's like, trying to tell you just to validate your assumption. So, yeah, that's my philosophy.

I would say absolutely agree. I remember I just talked, like, with the CEO of Curry Pod, and they're building this software for education and he told me, never listen to the users. If we would have listened to the users, we would have built something completely different. But to your point, just go there, sit behind them and see what they do. Because sometimes the actions that they do, they're not even Conscious. So then when you ask them, how do you use a product, they will tell you how they think they use the product, but not necessarily exactly how they use the product. What's the intentionality, what to do with the software? So I think that's just like very, very valuable because, I mean, it's a cliche how you know when they say it, but if you would ask users if they wanted a car, they would just say like a faster, you know, like a faster horse. Yeah. So you have like multiple processes. Like the way that I see it, one, like you have a process from, let's say zero to a couple of user to test if you're actually building something the users want. But then you have the process of, after you have a couple of users, to actually reaching out to millions of users and to have, I don't know, potentially, as you had at Meta and at Stripe, billions of euros. How do you scale from zero to one and then from one to two? Yeah.

And there was actually a really nice internal note at Stripe, I remember that Patrick Collins had written, I wish it was public. I actually don't know if it's public or not, but I'll try and find it for you. But which is what he knows about building great SaaS products. Right. And I 100% agree with that. It's kind of mandatory reading when you join part of the onboarding. And basically what he talks about is trying to find a single customer problem, trying to find a design partner who's willing to work with you, and then going really deep and trying to make sure you actually solve the pain point of that design partner and getting them to pay for it before you actually figure out if you know that's something that you want to then replicate. Obviously there's tons of considerations. Very simplistic. What I'm explaining, it's a beautifully written note. I'm not doing justice to it, but I think there's a number of considerations there. So one is like, which design partner do you pick? A lot of times I see, you know, founders picking, like, not the ideal design partner. So you pick something for a design partner. The product works well, design partner pays you for it. But the design partner is one of three in the world. It's not a design partner who is actually representative of a large chunk of the market. So that becomes a bit of an issue because then you actually not built for the chunk that you want to serve for you built for, you know, a small section subsection of the market. I think that's number one. Number Two is I see a lot of people, like, I would say, jumping the gun on taking the product to market and saying, yeah, yeah, I have one design partner, I shipped a couple of things and they're using it. It's amazing. Now I want scale, so that's what I want to do. I think patience there generally pays off dividends over time. It's a very hard thing to do because obviously, you know, you're excited you've got your first product out of their design partner, they seem to be using it. They're giving you very good customer feedback. They're like, hey, it solves a pain point of mine. Amazing. But like, have they used it for a month or three months or six months? Are they using one module? More than one module? Who is using it? Is it the person who intended you built it for, or is it just some other person altogether? Are they using it, but will they pay for it? And that's the other thing. Like, you know, a lot of times I've fallen trap to this myself. You go interview a user and you're like, hey, is this a pain point? And they're like, yeah, this is a pain point. I'm like, amazing. I go to three users like that, they're like, this is a pain point. And I go back and I'm like, this is what we have to build. You go build that product, you ship that product, and one year later they've not used it. And then you're like, okay, why are you not using this product? And they're like, oh, that's because this doesn't exist. You build that and then the cycle repeats until the point where, you know, they never actually end up using the product or never actually end up paying for it. And the reason why that happens is because you didn't actually go deep in the user problem. Coming back to where I started, which is in this case, I actually didn't spend time, as much time as I would have needed or as much time as I should have with the design partner to actually validate the user pain point. And I think that's how I think of approaching a problem and building a product that scales. That said, I think one of the things I always tell everyone is that, like, for me or I think anyone in big tech, you should take the scale that they say and divide it by 100. It's a distribution multiple. It's a lot of people say, oh, it's not hard to build products at a place like Stripe because you have a lot of distribution. It is hard, but it's not the same challenge as someone who's just trying to get off the ground because there you have momentum, there you have distribution. You don't have that much worry of acquisition because you have a pretty large customer base already. So the problems there are different. The problems there are more around. How do you actually get this shipped? You know, like the kind of navigation channel challenges that you have. How do you think about dependencies with other parts of the big platform? How do you actually validate a user problem here without going against your business model? So there are problems that exist. I would think it's hard, but I would say definitely discount it. If someone from big tech is saying, this is the scale that I got divided by 100, I think is a decent rule to think about.

Got it. And going to the design partners. What are some good terms to agree with your design partner? Because on one hand, you as a startup, you're very happy that they want to be the design partner, but also you want them to pay. Is it like three months? Is like, look, this is a trial, and if we solve this pain point, then after three months as a trial, you go into a monthly or yearly contract with a discount because you were out. Design partner.

It's always easy if you know the design partner personally. So, like, you know, if I'm building a startup, ideally, if the CEO of the design partner was my friend, that's always an easier thing. And a lot of times that's how it ends up becoming. But I think in terms of terms like, at least for the first six months, I would say what you need to optimize for is not whether they'll convert to a paid contract or not, but what you need to optimize is how much time and how much access are they willing to give you in terms of data, usability and feedback. You can have a design partner where you meet once a month, they give you some feedback. It's kind of secondhand feedback and not really useful. And you ended up wasting six months. At the end of it, you just end up with something that actually doesn't work that well, or you end up with a design partner who's like, actually come camp out at my office and work from here for a few months and you know, you have unlimited access to everything that you possibly need. That's obviously the dream situation. It's very hard to achieve that. But I think the goal of a design partner is to help you design the product, is not to help you prove traction, right? So you, as a design partner, to help you Design the product, not to help you build traction.

Yeah, no, actually I made this mistake and it was a great founder for a business that I'm building, backed by Sequoia. And he's like, oh my God, I really resonate with the value proposition that you have presented. And I was like, okay, this is the cost. And we're like, oh, so I already tried to close the client. Whereas, like, I got a little bit ahead of myself. Instead of say, hey, let's work together for three to six months, give me the feedback. And also this. I would have built a nice relationship with him. So lesson learned. What do you think is a good product velocity? Iteration Velocity. I've talked with multiple founders and also investors, also with James from nfx. So he's like, look, it's super important to have product velocity. So how fast do you ship, learn, ship, learn, ship, learn. Like, what do you think is a good product velocity?

I think it depends on the kind of business that you're running. Like when I was at Meta, for example, I would see an incredible velocity of products getting shipped and that was the first tech company I'd worked at. So I was like, okay, this is how it happens. And then I went to Stripe and one of the engineering managers I used to work with also used to work at Meta, and he'd come to Stripe after and one day I was talking to him and I was like, why are we not moving faster? And he was like, and this was in my first 20 days. And he's like, man, this is like people's money. And I know it feels like it's annoying, but you know, you have to be really careful. And you know, it sounds very commonsensical in hindsight, but I was like, super motivated. Just got into Stripe and I was like, you know, got a ship, like, got a ship, got a ship and you know, move fast, break things like fully indoctrinated with, you know, that and you know, so coming, coming back to like, what my learnings are now is that I think it really depends on the kind of business that you're building. If you're building an infrastructure business and you ship, ship, ship and you know, things break and it's a key process, like, you know, like payments, for example, for, you know, mid market enterprise customer, that customer is going to be pissed and that customer is going to be like, never going to come back to you, likely. So you don't want to do that. The other thing is also like, infrastructure takes time, so it's just very hard to build and it Takes time. Like there's a reason why people pay for, you know, infrastructure products. So I think in those cases it's harder to like ship something every, you know, at a, at a very fast cycle. You better like ship and get it right. If you're building a consumer product and you're not not shipping like your house on fire, then I think there's a real problem. So I think it really depends on like which kind of business you're building in general. I would say ship more. I'm still biased towards that. Like, I think there are two kinds of like product people. I think you'll find in this world people who are more like ship one ship, right, and ship fast and make mistakes and it's okay. I'm more the latter for sure. But I have to keep reminding myself saying, you know, it's like there's an infrastructure business. This is not a consumer social business.

So yeah, you've been exposed to building products both in the US and in Europe. What do you see the differences there?

I've worked in American companies here. So like I think both in Meta and Stripe, we used to, we had like a global remedy at Meta, Stripe, also similar, more emea, but yet some global stuff. And I've seen a lot of European startups, there used to be a very big difference. So I think around 2018, 2019, when I started engaging with the startup community, I think I noticed a few differences, right? So I think first one is product or engineering being at the center of the company versus business being at the center of the company. So in a lot of companies you had these MBA type business people who would make decisions. So let's assume, you know, we have to build travel, for example, and then they would go and tell the product team saying we have to build travel. And then the product team would write a user story about what kind of travel product you want to build, then give it to the engineering team and then the engineering team would build it. What I saw at, you know, the companies I worked at was that you would have product and engineering at the center of decision making and engineers and product team being empowered to take those decisions and build on those decisions. So saying that users have a problem of discovering trips and so either. And I'm just making this up as I go, right? So let's assume you have a problem of discovering trips. How can we solve this problem? It's a discovery problem. So you say we can solve this problem multiple ways. We can either show them an aggregation of all trips from different platforms, we can make our own trips. Or we could also just be a booking agent. We could do that too. But going deep into the user problem, what we realize is that users don't have a problem of discovery. Users actually have a problem of having too many trips. So ultimately then users want trips personalized to them. So we should not build anything to do with travel, but we should build a personalization engine that works for travel. Like that's like the. I just made that up literally right now. But that's like a product driven approach to I would say solving that user problem and then building a personalization engine that maybe then helps people discover trips. In the other approach, which is the more business led approach, I would have said travel is a big opportunity. Users are saying they don't discover trips. Make a nice presentation about how travel is a big opportunity. $10 billion TAM, something like that. And then I just say we need to build travel and we should build booking because that's where the highest margins are. And then there's a fundamental problem. Right, because one is a tech business, the other is a business that's enabled by tech, in my view. But you know, that's something I'm willing to back that's changed significantly over time. So when I meet founders now, I say I would meet more of the American product style founders than the earlier type. And that's I think a really, really good thing for the ecosystem because yeah, I mean that's just the way it should be because that helps you operate with a large engineering team maybe or you know, mainly engineers, some product people and then you know, maybe some salespeople. But you don't actually need the MBA types.

Yeah, it almost seems like the top, bottom, bottom up approach from building a business. Whereas like bottom up would be what's the user problem? And just build the business around the user problem. Yes. Or like top down. I found a gap in the market that is so big and I'm just going to purs.

Consultant approach. Right. Which I think, yeah, I mean maybe it works. I don't know, I'm just not a fan.

I remember I was reading this report how many ex McKinsey and BCG consultants have built unicorns. And there are quite a bit. So I think there is something to their way of thinking and analyzing a problem. But I think you just to assess the opportunity, it works. But then you need the products team, you know, to really understand the user and the problem and to build the product. There's just no way around it.

I mean, I think, look, I worked at McKinsey for a while, I think it's an amazing place, teaches you what they call the toolkit. There's also a selection bias because McKinsey's like line of recruiting is insecure overachievers, if I remember correctly. There's a massive selection. So yeah, I mean they teach you a really good toolkit. They hire like a specific kind of person and then they, you know, go on to do other things. But there were a lot of ex consultants at, you know, Facebook as well, at Stripe as well and just then becomes easier to add on those skills. So I think the question that I would really ask in that study is how many people went on from consulting straight to build a unicorn without doing anything in the middle?

Oh, interesting. Yeah. Actually like David Friedberg just came on the pod and then he said that that's the hardest part when you know what to do. You have all these reports, you have all this yeses, you have all this knowledge, but in the startup land you have very little. You just have to go and try and you have to fail so many times that any person that worked in any type of job will feel very uncomfortable.

Comfortable, yes. But also like there is a fundamental like length difference. Right? I mean, even when you're in vc. And like I've, I've been in VC for a year now and I've seen like similar stuff. Right. I try not try to fight that, but you look at something outside in and you're like, hey, this is a great opportunity because, you know, the TAM is large and it looks like there's not many players and it, you know, white space and all that kind of stuff. And that's what you do in consulting as well. But I think the big difference is when you move to move to like a product role in tech is you end up looking at things from a user point of view. So it's no longer like, is there a white space? It's more like, is there a user problem that you need to solve? I realize I'm sounding like a broken record with this whole user problem thing, but I genuinely believe in it. Like, I think that is the key to unlock.

Tell me about your journey into venture capital. You mentioned that you kind of started working with founders maybe 2018 also. I know that recently you also joined Equity Ventures. Maybe you want to tell us a little bit about that.

I've had a pretty, I would say unconventional journey in that sense. Like I mentioned, I started in consumer goods, spent some time with McKinsey. I joined Facebook around 2018 and that's when it was called Facebook at the time. And you know, a friend told me that they're hiring. Like, he called and he's like, hey, like, you know, we're building global teams out of London. Do you want to come interview? And he was looking out for me because he knew I wanted to move to tech. So I said, sure, why not? And it was like this catch all. I was supposed to do like a lot of inbound user research, you know, some positioning, that kind of work. And then I ended up doing everything for that product during this time. Well, Covid happened. And I think when Covid happened, a lot of people were like, what is happening at Facebook? We need to know. We ended up doing some interesting work. We ended up, you know, building a new way to serve ads on apps, helping app developers make money. That product ended up scaling quite well. And I started getting acquainted with a lot of VCs and startup founders. And one of the things I realized is that I'm getting pigeonholed. I felt like I was getting pigeonholed and I was really enjoying, you know, the kind of conversation that we're having right now, right? And then with founders, they would ask you, saying, hey, like, what should I do? What should I do now? And then you end up trying to help Sometimes, you know, send them a format saying this is what best in class looks like, things like that. And you know, they come back to you and they're like, hey, that was really helpful. And that would give me like a dopamine boost. But also like, I started learning about new sectors, right, Which I'd never, never had any exposure to. So I was just really hungry. And I think over the next, like, I would say three, five years, I ended up forming a really good network between like VCs and startup founders. And I was doing calls pretty much every evening, every weekend. You know how this ecosystem is. There's always like drinks and like quick chat intro. There's like tools for intros, right? So I literally ended up at this point where, yeah, I was just meeting founders all the time and it felt like I was doing two jobs. I was doing one job, which was my job at Stripe, and then another job over the weekends and evenings where I was meeting founders and trying to help. Some of these founders were like, hey, do you want to be an engineer angel? And given my background, I didn't really have a lot of cash to invest because I had a number of like, you know, education loans and things like that. And then somewhere around like Covid time is when I was, okay, I can maybe experiment with this, if nothing else, literally just to be part of that journey, right? So I started cutting really like small tickets. I felt almost embarrassed at the time, but then I was like, why not? Because I feel comfortable with this founder. And then slowly started doing more and more of that. And then a couple of things kind of struck me. The first thing that struck me was that that there are very few operator VCs in Europe specifically. That's number one. The second thing I realized was that the kind of like exposure I've had, I actually enjoy, like I actually enjoy the context switch. And I started enjoying that more than my day job still. The plan was not to move to vc. I was like, I'll continue doing what I'm doing and then maybe move at some point to VC sometime in the future. And that's when I kind of met eqt and it ticked a number of the boxes that I was looking for, except I was looking for that in a tech company rather than looking for it in vc. So I was looking for a place where I could build, you know, a long term career and a legacy in the sense, you know, I think it's a lot of fun to kind of like be part of a journey and say I was part of that and I've always wanted to do that. So I think that's one, one thing. We're, we're a large fund. We have early product market fit, I think touchwood with some good investments. But we're still a very young fund. We're like a seven, eight, year old fund and we have a long way, you know, we call ourselves a series B startup. So long way to ipo, right? So I think it's good to do that. Second, it's an operator or founder only fund. So all the dealmakers are ex founders and ex operators. So it felt like, you know, more familiar environment I would say, rather than a more finance background LED vc. And I think the third is just the ambition and the culture in the place. Like when I met all the partners, it was one the culture was emphasized on, which is great, like super collaborative, very open, which is something I value a lot and it's core to who I am, but also extremely, I would say ambitious and hungry and gave me very Silicon Valley vibes. Although it's Swedish, so it's a more cinnamon bun than Phil's coffee. But, but, but same price, right? So I really enjoyed all of those and I was like, okay, like, you know, this is a great opportunity. They were like, hey, Would this make sense for you? I thought, you know, maybe now is a really good time and frankly, like. Well, for one, my wife is very happy because I'm only doing one job now because before I was doing two jobs and now I have some of my weekends back. But I think on a, on a more serious note, it's really enjoyable, right? It's just doing what I was enjoying doing.

I'm very happy for you. And I mean, also given the recommendation that I got from another founder. I think you can tell when you talk with someone that has been an operator, that has been in the shoes of building, they know what you're going through. Whereas, like when you're maybe talking someone that it's a little bit more from a market finance perspective. You know, they have their checklist and kind of they grill you. So it's really great to see more operators being also in the VC role and supporting and investing in founders. How do you assess founders for having a product first mindset?

I'm really happy to hear that it was a founder recommendation because I think, honestly, I think that's the highest compliment that we seek in response. Like, if I was to think of like VC as a product, I think a founder recommendation is the equivalent of a customer referral, right? That's, it's like you can't, it doesn't really beat that in terms of just becoming better or saying that you're a good product, I guess in that sense.

How do you assess founders for having a product first mindset?

So I don't think I've quite nailed this yet, but I will try to answer it. One is when I see the founding team come in for what is purely a tech company. So, you know, not food delivery, not something like that, like literally like enterprise software, something like that. And the CTO is not in the room or the CPO is not in the room. So that is honestly like, that's first yellow flag for me, which is why is the, like, you're a tech company and. But your tech person is not involved in you taking key decisions such as who's going to be on your board for the next 10 years. That's a yellow flag. A good reason for that sometimes to happen is they're out fundraising. It's, you know, it's. The deal is live and CTO is meeting some other vc. That's a fair reason, but it's something I make sure I notice and I understand ask. The CTO is not there. The second is I try to see how the founder is framing the problem if they're framing it as, you know, a problem being solved using technology or being solved using their product and why their product is solving that problem versus being extremely execution or sales driven. There's nothing bad about that. By the way, like I have a colleague who loves sales driven teams and invests in them heavily. But then I just send them to her. I'm like, you should meet them. I think you will enjoy them. But yeah, I think for me it's that like is a CTO in the room, how are you framing the problem?

Problem?

And then I talk, talk more about like, you know, what is our shipping velocity? A good hack I have with infrastructure products is. And this is something actually I've done one deal since I've joined and this deal I first went, when we were looking at it from the outside, I first went into the API doc and then read through the API docs and the founder. When we met for the first time I was like, yeah, let's write API docs. Like here are a couple of mistakes I found. And the founder was like oh wow, okay. I don't like, no one's done that before. So I was like okay, cool. Like if I'm investing in a company and I don't understand the product or I don't use the product, I don't see how I can actually provide you with any insight. So that's like a good way for me as well, like a good hack is go into the API docs and actually see if like there is care and attention that is given to the product over there. That's a good way as well.

How much did you guys invest? So just for clarity, maybe you can tell us also like what type of ticket size do you guys invest? If it's merely if it's pre series he, series A or if it's multi stage.

So as a fund we are currently investing out of a 1.1 billion euro fund. 3 We try to be early partners to founders. Our aim is to be early. Realistically our sweet spot is series A. We also do some seed. Sometimes we make mistakes at series A assessment or sometimes we miss around. At that point we do the series B. But I think we will end up doing mostly series A and seed and very very little series B out of this fund. Ticket size can go from 2 million US to 50 million US obviously 50 being for the more capex intensive series.

Got it. And that's across Europe, Europe or US as well.

So we have historically invested in Europe and west coast and now we've kind of slightly pivoted to do Europe and East coast, reason being just a stronger fit. We have an office in New York, we have, we have colleagues there and you know, it's just focus. So we'll do a lot of Europe and East coast across the four sectors that we invest are fintech, which is what I spend a lot of time on. B2B, SaaS, consumer and deep tech and climate. Those are the four sectors in which we invest.

Maybe we can change gears a bit and we can get personal. You've led teams making billions at Stripe and Meta and now you're a partner at a premier VC fund. What do you attribute your success to?

Well, a few things I think. One, I would say growing up in a very resource starved or opportunity starved environment I think definitely has a part to play in that. Two, I would say good parenting, I still take advice from my parents. And I think three, I would say not. Like, I really enjoy proving people to wrong. Like, I really enjoy it. Like it gives me satisfaction to no end. Like, you know, a lot of people I spoke to when I was at McKinsey were like, oh, like, you know, it's going to be really hard for you to break into tech. A lot of people, you know, was like, hey, it's going to be really hard for you to break into McKinsey. So you know, I really enjoy proving people wrong, I think. So Those three things, I think I appreciate they're not at the same level of abstraction, but I would say those are the three things I would attribute it to. Although I, I still think that like in the grand scheme of things, I think there's still a very long way to go. Like I don't by any means think that I'm successful. Successful.

How did your definition of success change now that you became a dad?

My definition of success has always been actually the same. It's not changed. When I was younger, I grew up in India and you have to give this exam when you're trying to study for engineering. A few million people give it and a few thousand people get in and they get into like these top engineering schools. So the acceptance ratio is quite poor. And if you don't bust your ass for a couple of years, you don't make it like very similar. Simply if you get into these schools, you get out and you get a job at Microsoft in Seattle and your name is in the paper and it's all amazing. If you don't get into these schools, your future is basically making about £3,000 a year sitting in a bus and going one hour away to an IT park and then coming back one hour in traffic and pollution. That's kind of severe relegation to the averages, right? I didn't bust my ass and I didn't get into these schools. I got into a good school, but not into these schools. And the precipice of that drop is so high that, you know, during those four years I was like, I am average and this sucks. And I'm average because I didn't work hard, right? Like this one is like, you are average because, you know, you're just not intelligent enough. Like I don't think I'm like above average intelligence. So that's one. But there's also like, you're average because you didn't work hard enough. You had the opportunity but you didn't work hard enough. So now you're in the averages and that sucks. So at that point I was like, I'm never going to let myself not win because I didn't work hard, right? Or I didn't work hard enough. And so my success since then has been winning. So like to the top in whatever it is that I do and busting my ass for it. There might be different ways to get there and I will do all of those ways, but one of the ways I will definitely do is work hard for it.

I like the story. What do you think most people get wrong about India?

About India? Lots of things. I read a tweet the other day which is India makes both the optimist and pessimists sad because it's. Well, because, you know, it has this amazing promise. So it's been emerging for a while, right? Like as a country. I would say right now it's probably economically at least in one of the best positions it has ever been to actually emerge and become a proper middle income country. But the reality is like there's many countries in one, right. There's a report that comes out that publishes like the different segments of India. So there's, there's a UK of India which has a top 70 million people and their spending habits and you know, their consumption will be similar. The Mexico of India, sorry, first top hundred. Then there's a Brazil of India which is going to be exactly analogous to Brazil. And then there's a sub Saharan Africa, which. India. Right. I feel like when people look at India, especially in Europe, I feel like in the US somehow there's a more nuanced view of India. US investors invest in India. I think Indians ignore Europe and Europeans ignore India. And I think it's actually a pretty lost opportunity because there's a lot of good Indian founders that are coming out of India, like a lot of companies, you know, like postman, chargeby, etc. Etc. And there's a lot of good European investors who don't invest there. So I think there's a bridge there. And most people get this thing wrong is that they look at it as a single entity and they're like, yeah, emerging markets. We have this emerging markets bucket in that we're going to put India, Indonesia, Vietnam, half of world's humanity and not look at nuance. Which kind of makes sense because it's hard to kind of do the work when it's not your focus. But I think that's the thing that people get wrong. I think if you're serious about it, I think you can actually find a lot of really good opportunity there. And there's actually a lot of opportunities for exchange, I think, which are still untapped. It's, I think, a pretty big opportunity.

What is the worst advice you have received?

Huh? Good question. So I can think, actually, I would say any advice I've gotten in the wrong context is terrible advice. Like, for example, if you get a seat on a rocket ship, don't ask which seat. A lot of people in tech will give you this advice, right? Like, pretty popular saying, it's great advice in a particular context. Like, for example, if you're early on in your career, if you get a seat on a rocket ship, take the seat, don't ask which seat. It's not great advice if you're pretty advanced in your career, right? Because then you want to be quite, like, sure about where you want to go and what you want to do, in my view, at least. Similarly, you know, the, the regret minimization framework, which is a tech favorite, which is, you know, if you feel like you'll regret it in the future, then do it again. Terrible advice out of context. Like, what are you optimizing for? You know, what context are you in? I think those are pretty important things. So I think I've got advice out of context, which is very bad. And I think it's important to contextualize advice. The second I would say, is people encouraging me not to take more risk. I remember when I was leaving McKinsey and I was going to Facebook, it was 2018 and Cambridge Analytica had just happened. Election interference had just happened. Cambridge Analytica was about to happen. So, you know, the atmosphere wasn't good. And I went in, I spoke to someone, you know, pretty Senior up at McKinsey, and they were like, oh, why are you going to Facebook? Go to Amazon? And in my head I was like, what I didn't realize is that like, you know, that person had no idea of tech. So for them, Facebook and Amazon were kind of the same. And I was like, why will I go to Amazon? Like, which is like e commerce, you know, do that work when I have this amazing, like actual tech opportunity in front of me? Yeah, that was also pretty bad advice, I think. So I would say, I always say, like advice, you should be really careful of what advice you take and from whom. If it's the right context, if it's the right person, non contextual advice is the worst, I think.

Always contextualize the advice. And if Kaushik from 10 years ago leaving L' Oreal and joining McKinsey, would listen to this episode, what would you tell him?

A lot of things. Number one, I would say take more risks and don't stress so much about that. Number two, I would say don't try to optimize every aspect of your life, just optimize the things that count. And more importantly, understand what counts as well before you start optimizing. Third and last, I would say if you can, try and enjoy some moments, some more moments instead of just like thinking about, you know, how do I get from here to there? Which is again, all of this is easy advice in hindsight, but it was.

Hard to do that, taking more risks. Don't over optimize. Almost like, choose your battles. Don't over optimize on the things that don't matter. And enjoy more moments, be more in the present, maybe not so much focused on getting to the next stage, into the next stage. Wonderful.

Exactly.

Kaushik, thank you so much for taking the time to share with us your story.

My absolute pleasure. Thank you so much. This was a very enjoyable conversation.