EP 112 - Building Products for Scale - Kaushik Subramanian (Product Leader)

My advice approach would be find a customer segment, find a problem that they have, try to solve for that, find product market, fit there, generate good amounts of revenue, find the next customer segment, or find a different problem in the same customer segment, start building for adjacencies and go from a point use case to a platform rather than vice versa.

Hello and welcome to the Startup Operator podcast. I'm Roshan Kariyappa. My guest today is Kaushik Subramaniam, who is a senior product leader, advisor and investor. He's had a fascinating career, from launching and growing skincare and hair care products to building products at some of the world's largest technology companies. In this conversation, we spoke about the consumer insights that bind these seemingly disparate worlds, general principles for product building, and how to hire a great product team and enable them to succeed. This was a very interesting conversation and it's full of practical insights that you can apply at your startup. I'm sure you like it. So let's dive into this episode of the Startup Operator with Kaushik Subramaniam. Hey, Kaushik, welcome to the Startup Operator podcast. Thank you so much, sir, for making the time.

Thank you, Roshan. Thrilled to be here and finally to be able to speak with you.

Yeah, we've been trying to make this happen for a while and really, really grateful for you to finally be able to join us on the podcast. So thank you again.

My pleasure. Really?

Yeah. So, Kaushik, I mean, you've had a very interesting career, you know, from growing shampoo and face wash products at Garnier to a brief stint in consulting to, you know, finally the largest consumer product platform, Facebook. Right. Where you worked on monetization and so on. Is there some underlying theme to all of these career changes, like seemingly disparate worlds and, you know, what would you attribute your success to in all of these different stints that you've done?

Yeah, I think there's a huge factor of luck, I would say. But I think the one theme that is common is people taking bets on me and placing their faith in me to say that, hey, like, you're not the typical candidate, but we think that you have what it takes to succeed. And as a result of that, me having that innate desire in me to say that, hey, like, this person's trusted me and I should live up to their expectation. I think when I think l' Oreal was straight from university, so that, that was. That was pretty straightforward. But I never thought, for example, that with my background, I would probably get hired at a McKinsey and I was hired because of one person who decided to take a bet on me and think and thought that I would do well and I would add value to that role. Similarly, when I moved from McKinsey to Facebook, it was a very entrepreneurial person who hired me who said that, hey, you've not really worked in tech before, but I can see that you have all the basic things that you need in place. You have built and grown businesses before. You know, you will understand this and you will ramp up really quickly. You understand how strategy works, you understand how advertisers think, and therefore, I'm willing to take this bet on you. So I think, I really think, like, if I try to find a theme, it is people placing their faith in me and then me feeling the need to prove it to them.

Yeah, that's a damn good start to the podcast. Right. I mean, because oftentimes I feel like you may not be ready for a particular circumstance, but, you know, you just need someone who believes in you and who can sort of enable you to take that bet and make it through. Right. So what are you doing in your current role? I believe that, you know, you're just starting up and it's focused at developers specifically. So, you know, you've. You've largely been on the consumer side of things. What is it like, you know, moving to B2B, focusing on this sort of a developer market as such.

Yeah, sure. So I can actually give you maybe a brief background of my career. Right. So I started off in my entire career, has been around building for, like, building products and businesses that scale to a very, very large extent. Right. So the first stint was at l'. Oreal. L'.

Oreal.

I learned a lot of the basics of business. Right. So I did a sales stint in, like, rural India and, you know, parts of North Bengal and Sikkim and so on, so forth. I did a chief of staff role. I scaled a new brand at the time, which was called Ghana Men. I also did a product development role. Post that at McKinsey. I did a lot of work around, like, strategy, due diligences, board strategy, a lot of the things that I was not really very familiar with. And in my last role at Facebook, where I've recently just left, I built the developer monetization platform, which is known as Audience Network. Audience Network essentially delivered Facebook advertising to app developers, apps. So if you're an app developer and you wanted to make money or monetize your app, you essentially had two ways to do it. One is to do in App purchase. And then the other way is to do in app advertising and to do in app advertising you could integrate our SDK and get the full power of Facebook advertising on your app. So that's the product that I really worked on. What I was hired to do there was basically change the way these ads were delivered on the open Internet. I won't go into too much technical detail, but basically ads delivery on third party platforms used to happen using a very antiquated technology known as the waterfall, which was in my opinion really, really bad for advertisers, publishers and users as well. And my job was to build a new technology called app bidding, which is basically a real time auction, and then take that to market with some of the largest players in the ecosystem and essentially change the plumbing of the ad tech ecosystem, which is what I successfully managed to do in my first couple of years there, which was start off with app bidding, take it from an alpha to a general availability, work with other players in the ecosystem in order to build that. And app bidding is now a significant part of the ad tech ecosystem. My last role there I was managing a few teams on, on audience networks. So not just looking after the infrastructure which is app bidding, but also looking after the developer facing platform which is monetization manager and a few other teams that generally in the app developer side of the business. So I've recently left and I'm just about to start a new role in a different company which is also in the B2B SaaS space. So can't reveal more details for now, but I'm sure you'll hear soon.

So you know, as you mentioned, I mean you worked at these large consumer companies where your catering to, you know, millions if not tens of thousands of users and consumers. What are some guiding principles that you've picked up irrespective of these different worlds? That are some underlying thoughts on, you know, how you should build product for large masses of people.

Sure. So I think generally product principles, I think, you know, some of them kind of stay the same across both B2B and B2C. Obviously there's a lot of nuances depending on the size of company and the sector, et cetera. But I would say there are a few kind of like rules that I like. Basic rules I tend to follow. Right. Number one is speak to your end user as much as possible. I find that especially in larger setups, you tend to go further and further away from your end consumer or your end user or your end developer, whoever is the end user of your product. And Especially in large setups. That tends to happen because, you know, you have a research team, you have a product development team, you have a, I don't know, user insight team. Like, you know, you will have all of these teams that will basically create abstraction layers between you and the end user. And while it's great to have all of these processes and systems and these teams speaking to you, ultimately if these other teams and end up going and speaking to the user, you will only see a very polished version of user feedback. And that's really, really good. And you know, that helps you scale and that helps you really get some insights at a high level. At the same time, I feel that it is, it is not a, it is not a complete waste of time to go spend an hour, maybe or a couple of hours every month to actually just go and have a conversation with the user, try and validate a few hypothesis. If you don't have any hypothesis, just go and see how they use your product. I feel like in addition to the very polished corporate artifacts that you get from any kind of user research team, I feel that anybody who works in product should go and talk to their end customer. I think that really helps kind of form a view of how people are actually interacting with your product, how they're using it, and also helps you get insights. That's number one. Number two, I would say, is the use of data in creating products and informing what to build. So I think data is very, very important. But in general, users use product with emotion, not reason. And while I think data should kind of form the bedrock of you deciding what to build, there has to be some kind of emotion or some kind of craft or, you know, some kind of product sense that needs to come in that ultimately is not really rooted in any data whatsoever, but is more rooted in some kind of qualitative feedback or some kind of observation or some kind of insight that, that you have. And I think that's. That's really important because if data could decide everything in terms of what we should build, you know, then there is, you know, I don't think we'd end up with the kind of products that we do today that are highly successful. So I definitely think that there is a. So there is a pretty, you know, significant. Right. Brain aspect to building products as well. I think the third thing I would say is not solving for everything and iterating as much as possible. And this is something that I learned in my last stint at Facebook, where the, where the philosophy is more around build and iterate as much as possible, which I really think works well because it gives you both the speed and it gives you the flexibility to try out different things. It also gives you the room to fail and also limits your downside because you've not really spent that much time or that much resources because you're, you know, testing or building, like, feature by feature or, you know, small increments at a time, rather than, you know, spending five years in development and then going to market with one beautiful thing that may not work eventually. Lots more I can say there, but I would say these are kind of the three big principles I can think of across, you know, that cut across both B2B, B2C. Physical and technical products.

Right. No, these are very relevant insights, and I have seen this myself, where, you know, teams get siloed and somebody is working on a feature of a feature and, you know, it's a case of Chinese whisper where, you know, I mean, by the time it reaches the developer, I mean, it's not really useful at that point of time.

Right.

I mean, you just get platitudes at that time. But is there a way to kind of prevent this siloing of teams or product teams, especially? Because, I mean, you see this, for example, you know, product manager of PAYTM experience. Right. For example. Right. It's so siloed that, you know, you tend to lose the holistic picture of the product itself. Right. I mean, and oftentimes, I mean, you know, product teams are working against each other. Right? Because who's to say one. One thing is better than the other? So as teams grow, how do you sort of still maintain that holistic experience of what the end product experience should be like?

So I think there's this two. Separate this out into two aspects. One is how do you induce that sense of customer empathy in everyone who is working on the product? And I think I would answer that by saying that it is important to get developers to also be in your customer interviews or to get. Basically get anybody who's working on the product to be involved in your customer interviews. Not all of them, but I don't think that, you know, you should have a significant amount of time go by without everybody in the team actually speaking to your end customer. Otherwise, I think that level of customer empathy will just not exist. And as you mentioned correctly, people will be building in silos and Chinese whispers will happen. Right? So I think that's number one. Number two is around how do you enable, like, different teams to, you know, not have overlaps, not work against each other? And also not ship for shipping sake. Right. Like in terms of pushing out some vanity metrics just because it's, it's something that one team is particularly incentivized on. I think that is the job of like the product leadership team in an organization. Right. Like, for example, when I would look at. When I would look at what all my teams are working on, I would like. It is my job to make sure that that overlap does not exist and also that the teams are not working together. And most importantly, the metrics actually make sense in isolation and in aggregate, because oftentimes they would make sense in isolation. So at a team level, this, like a metric X would make sense. But the moment you bring it up to a different level of abstraction at an org level or at a company level, you will see that there are different opposing metrics to each other. So I really think that that is, that is literally the job of like a, like a product leadership team, that is engineering leadership, product leadership, or business leadership. I think it is an important part to make sure that that kind of crisscross does not happen and that people are focused on the right things at that right level of abstraction.

Right. I think the first order of business for any product leader is the organizational design itself. Right. As you mentioned, you know, sort of put together in that cohesive way so they don't really tread on each other's toes, but rather amplify each other's efforts.

Yeah, yeah. And I think that for that, I think there's, you know, there's a lot of systems that exist. I mean, and I find this very different across different levels of maturity. Right. I think the one that I have seen closely and the one that I'm pretty sure works very well is, is how most Silicon Valley companies function, which is where you have, you know, like a shared microservices model where you have different teams that are like pods that have. And have engineers, have a pm, have a designer, have a researcher that are basically working towards a particular North Star metric. And a number of these teams come together as shared microservices to create a product suite or a platform. That system, I think, works quite well. There are different, like, there are other systems that I've seen that I am. I'm quite against. So, for example, I've seen some weird systems where you have everybody reporting into the pm, where the PM becomes like a manager of people. I don't think that works like a.

General manager of sorts.

Yeah, exactly. I don't think that works. And I've seen that in less mature Ecosystems. Right. And I generally feel that like any product leader's job is to kind of be like an orchestra conductor. Right. You are picking the symphony, you are picking how long the concert is going to last. You are going to pick what success looks like, you're going to pick what the tunes are, you're going to make sure that the notes are correct, but you're not going to be a particular expert in the trumpet or in the saxophone or in the guitar or the violin. Right. And you're probably going to guide the violinist to say that like, hey, in, in the concerto, it sounds like, you know, it sounds like this when you bring all the instruments together, but you're not going to individually tell the violin player to say that you should play your violin this way. You will tell them to say that when all of it comes together, your violin should sound like this. Right. I'm obviously not a musical expert, but that is the closest analogy that I find to any of product leadership role.

Right. So you mentioned metrics. Right. And I have more than a few points to, you know, double click upon on that. In general, I feel like we tend to underestimate the qualitative aspects of some, some of the product building stuff that you mentioned and overestimate the quantifiable things. Right. Because God knows we have enough funnels and dashboards and analytics right now to pour over. And oftentimes, I mean, it also, it, it also feeds into one's own bias, I feel, because you could, you could be a really like a numbers person, like a typical type of person and may not be comfortable like thinking of stories and whatnot.

Right.

But meaningful product building requires a significant overlap of both of these worlds. Right. So, you know, how do you bring those both things together, you know, because I feel like sometimes it's easy to be swayed by all of these vanity metrics, like, you know, Dao or Mao or whatever else. Right. And really prioritize endlessly over some of the more, less. Some of the less obvious but more realistic sort of things that one should do. Right. So, so how do you marry both of these worlds?

Yeah, I mean, there's no silver bullet or formula to this because then if there was a formula to this, that would be quite ironic. Right? So I think, so I think it's a combination of having the right kind of metrics and the right number of them and the right kind, I would think of, you know, like, you have a basic framework which is you have like a North Star metric, you have maybe one or two countermetrics to make sure that the North Star metric is actually making sense and, you know, is not being gamed. And then you have a set of hygiene metrics. I think qualitatively, I think it's important to make sure that you have a very clear articulation of the user problems that you're trying to solve. You have a clear idea of the use cases that you are building for, and most importantly, that the users are actually, actually using your product for the use cases that you built for. Because I find that, you know, a lot of times it ends up happening that you say that, hey, like, I know the user problem is this, this is the job to be done, therefore I am building this product. But when you go and do a usability test, you will see that the users using the product in a completely different way, right? Like, and maybe like a beautiful onboarding flow that you had designed. Users just skipping through all of that because that just seems to be really, really painful. And the user wants to go see a number that appears on in your product, right? So I think having the right kind of processes in place to get and jump to a higher level, right. I think in terms of like a process answer to this, I think it's number one, do you have the right processes to get scale feedback from your users, whether that is via your local teams or whether that is directly from the user himself or herself, depending upon whether it's a B2C product or a B2B product? Are you doing that at regular intervals? Are your product teams going and talking to users? And are you really seeing your product out there in the wild in terms of conducting a usability test with different cohorts of users? And are you able to very, very clearly identify the use cases that your product is being used for? I think that that is the most important thing. I feel like once your product has found a level of product market fit, you should be able to prioritize very ruthlessly to say that, like, hey, I'm building for like the 80% of my users. And, you know, the rest I think are edge cases really in that, in that definition, right.

You know, one of the things, one of the most abused terms is this move fast and break things, right? I mean, obviously there is a certain value in it and there's that ethos of like, you know, tinkering and experimenting and everything. But it's also often an excuse to ship really shitty products and releases, right? So because people want to like, you know, get to scale really quickly and they, you know, they foist all of these sort of things on the, on users and kind of use them as guinea pigs. What is your benchmark for when something should be a product release versus, you know, when something should be validated internally and like, you know, should pass a certain test before, like, you know, test or rigor or whatever it is before it's actually good for, you know, public, basically.

Yeah. So, I mean, there's a theoretical, like, set of criteria that you can do, right? So I'll give you both the practical answer that I've seen and like, theoretically, what you're supposed to do. Like theoretically, like, you know, you have like an alpha exit criteria, you have a beta exit criteria that gets your product into general availability. You decide those right up front to design those metrics right up front. You put all of this in a document, you have a very clear articulation amongst your users to leadership, everyone to say that, hey, I'm going into alpha. This is what alpha recruitment looks like. This is what alpha exit looks like. Same thing for beta and so on, so forth, right? That's like how, that's the, that's how you do it. And I think that's hygiene, right? Like, I think you should do that for every product. I don't think you should, like, you know, just forget about it. And I think writing this down helps because it also helps align people. It helps you, it helps keep you honest and also doesn't it solves the shifting goalpost problem, which is, hey, you know, I still don't think that the product is ready. Let me move alpha to two months later. But if actually hit the criteria, you don't actually have to shift the goal post. That's like one, like, how do you solve it from a process perspective, from a practical point of view? Like, I think it also depends a lot on the company and the kind of product that you're working on, right? Let's say, for example, your product is existential to the customers that you are serving. So let's say, for example, I'm a creator payment company and my product allows podcast creators to get paid and, and that can only happen when the podcast is playing. I want, because that is existential to the business of the customers that I serve. I probably don't want to like move fast and break things because that is existential to people. It affects like, you know, it affects some significant monetary aspect. I want to have a high level of uptime. I want to be more mindful about how I build that kind of product. Let's say I'm creating A voice filter that makes me sound like a cat. It's a good feature to have, but it's not something like if I sound like a high pitched cat, it's not really going to make that much of a difference versus sounding like a low pitched cat. Right. It's just a fun feature that, that I'm, that I'm launching that doesn't really have that much of a downside. So I think tldr, I would say, like if you, if the product that you are shipping has a very, very high downside for your users, if it goes wrong, you need to be more and more mindful if the downside is not that low and the upside is quite high, if it actually works, then I would think that, you know, it's okay if it's not perfect.

Right. It also depends on the subset of features that you kind of abstract and work on. Right. Because in any large platform, for example, let's say Facebook or maybe on the enterprise side, you know, take something like Salesforce for example, right? Now, if you look at the product releases and features and so on and so forth, you know, one might think that these are very superficial kind of changes that happen periodically, right. I mean, it doesn't affect too many people in any large scale product platform, right. How do you sort of move away from incremental thinking and get people to think big, you know, because there is that risk of downside, as you mentioned, you know, and people are generally wary of pissing people off, right. I mean, it's hyper competitive and it might actually have an impact. So how do you, how do you get people to think outside of that?

Yeah, see from a large scale, and just to close the loop there, right, from a large scale shipping perspective, you would never, you would never build something and ship it to 100% of users on day one, right. Like if you are a scaled product, you would probably have a number of tests that would run before you even like, you know, push it out to a single digit percentage of your user base and then gradually increase it. Right. And you'd probably do it by Geo or you do it by a particular customer segment or something like that. You would never push it out to 100%. So in general, even if the, if the product is not existential or the feature that you're shipping is not existential, you would never just press the button. And it's not a binary outcome over there, Right. You have to be very, very gradual and it'll happen with a fair amount of testing, testing in place. So I think that, that definitely is cap. How do you prevent incremental versus exponential thinking? I think this comes down again, and I don't think people talk about this enough is like, what is the difference between like, like a product leadership role versus like product non leadership role, Right. In terms of like actually being the person who is doing the job, I don't think any of them are better than the other. One is a promotion to the other. I just think they're very different jobs. Right. The job of the product leadership team is to help make sure that the thinking is actually exponential and not incremental, to make sure that the roadmaps are actually making that big jump versus just making like gradual steps forward and to make sure that people are not like going around in circles or iterating in the edges versus solving for the main problem. Right. So I think that's number one. Number two is to make sure that when you are doing road mapping, you start directly from the customer problem rather than starting from what exists. Because a simple trap to fall into is to make a better bounce trap, right? Is to say that like, this is my product. These are the five most requested features. So let me put these five features on the roadmap versus going back to base. And this is why the roadmapping process exists, right? You don't actually need to do that process except for the fact that it's a reset on your thinking, you know, so in that process you go back and say, hey, like, what is the actual problem that I set out to solve? And do these five features that are requested actually, you know, further my path in terms of solving that problem? Or do they just. Are they just a good to have? I think asking those kinds of questions while you are the person doing road mapping will help quite a bit. Right.

So even though, you know, you were within Facebook, I mean, you were building for developers, right? I mean, so and it was a sort of a B2B kind of a scenario setting, right. You know, having operated at the intersection of both B2C and B2B, what are some, you know, stark differences between both these worlds? Like, for instance, I mean, B2B, your user may not be the buyer in some cases, right? So that could be one nuance. Any other things that you can call out?

Yeah, so and I can speak to my, like, past experience at Facebook and also with the other companies that like, I advise, right. In terms of, like, I advise a few startups in the B2B SaaS space, I can speak to those as well. I think from Facebook, what I Learned is like, it's hard not to fall into the trap of building for your largest customers only because there is a fine balance to be struck between in. In most B2B businesses, I would believe that a significant amount of revenue would come from a very small number of customers. Right? And it does follow that paradox principle. So falling into the trap of only building for those is a very, very easy trap to fall into because the revenue downside there is quite high. They also usually have the loudest voice in the room. They also have the strongest relationships with you. So I think one, it's important to balance that building for largest customers versus building for new customer segments that you actually want to target. Because your job then is to make sure that you maintain and keep your largest customers happy while being able to enable your small customers to grow into large customers. And I feel that success in B2B is predicated more upon how can you make your small customers your large customers and grow with them rather than how can you keep increasing, just keep increasing your large customers. Right. I think that's one important balance to solve for. The other thing is also I think it changes by, it changes by stage. Like, for example, like at a seed stage, especially like around the time when like folks find product market fit, I think it is very easy to fall into the trap of becoming for all practical purposes, a service provider to your largest customer. Right? Especially if you're like a seed stage company, let's say you have three or four customers who are giving you more than 90% of your recurring revenue. I find that a few companies fall into the trap of, hey, if these customers go away, my company does not exist. So let me just keep building for these customers and as a result of that, they become a service provider to them rather than becoming a product company. I think that's the other trap to avoid. Those are like the two main things that I would say, especially in the B2B space, in terms of like actual execution. I think the one thing that I would like to call out is making sure that you're actually solving for the job to be done versus what you think the user wants. And especially this is more, more true of like dashboards, analytics and those kinds of products versus versus anything else, right? So the metrics. So like, I'll give a simple example, right? Like while we were building this, like, you know, when, when we started like looking at a dashboard, one of the things that we, I think, made the mistake of was to assume that the metrics that we look at is what customers would ultimately want to look at. And we didn't really like go into depth as as much over there as we did. And we did a lot of user research, we realized that customers actually look at those metrics in an entirely different way. And while our internal metrics might be X, user metrics are actually Y. And you know, what those ad managers would want to look at is actually a completely different set of metrics. So we had to go and design that ground up. What I learned from that is that data cuts that internal product folks might look at could be very, very different to what the end customer would look at, especially when it comes to monetization products.

Right. So I want to delve a little deeper on the latter point that you mentioned, which is, you know, don't turn into a services firm, right. And so the contra point to that would be that, you know, a lot of times when you're looking at B2B SaaS especially, right, your product roadmap gets built with the customers, right? So you are building your product with the customer in partnership, right? And a lot of the cases you don't really understand the market well enough or you don't really understand the business well enough. And so, you know, it's natural to sort of default to, hey, you know what, this large customer probably knows what they're talking about and so on, right? And how does one balance the temptation? You know, I mean, because you're absolutely right. I mean, you could morph into this, you know, do anything kind of a services firm and in India, God knows, I mean, we have plenty of people to put on stuff like this, right? But how do you balance the both between saying yes to the customer and also actually thinking that, hey, is this something that I can sell to five other customers or 10 other customers?

I think this is again another point. I think I've pointed out two points so far and this is I think point number three of the hard to articulate product sense, right? And I think this is another aspect of product sense, which is I don't think you should build up your roadmap with the customer as much as for the customer. The customer should definitely involve customer problems, should inform what the roadmap looks like. But I feel like if you are only building your roadmap with a customer or with a set of customers, you're probably not going to achieve like your North Star, you know, you're not going to go in that direction because then you're going to go achieve the customer's North Star metric. You're not going to go achieve your North Star metric and you're going to go in like the customers, like the problem that the customer is trying to solve, rather than solve the customer's problem, if that makes any sense. Right. So but at the same time, like practically speaking, in early stages of the company, you also don't have the luxury of saying that, no, I will not go do this in case the customer goes away. So I would say that a good way to do this is to try and try and balance this out. And as the PM or the founder or the CPO or whatever you want to call it, whoever is calling the shots, make sure that you are able to carve out a chunk of your capacity, both mental and roadmap capacity and engineering capacity, to make sure that you are actually building to solve the problem that you set out to solve while making sure that you do enough to keep your customers happy. In terms of building, I also think though that if, let's say, for example, if your customer is asking you to go significantly outside your product area and significantly outside the problem that your company set out to solve, you should refuse. I'll give you an example. So let's say that you're a company that provides like, I don't know, E commerce analytics and that's what your product does. And let's say your customer comes to you and says, hey, I now want you to build like an end to end dashboard for me that not only looks at E commerce analytics but also looks at like payments, also looks at CRM, also looks at this and that and so on, so forth. If you've decided that the problem that you want to solve is E commerce analytics and you know, maybe help people get like lost card conversion or something like that, you should not go that far from the direction that you've decided. You need to be able to draw the line there. And I think this is again where, where it comes down to like that balance and product sense.

Right. I also feel like in majority of the cases, I mean it's about doing a proper jtbd, right? I mean like, because customers are excellent for sourcing problems and challenges, but they're terrible for sourcing solutions. Because if you just go to a customer and say, hey, what do I build for you? I mean obviously you'll get a long mile long list of things that you can build, right? But that's not necessarily solving the problem and it doesn't really support your cause as well.

Yeah, yeah, spot on. Right? And I think in B2B especially that happens a lot because like, if you go, if you go to a B2B customer, I have not at least heard a B2B customer say, no, I don't want you to build this. When I ask them, like, hey, do you want me to solve this problem for you? Or do you think we should build this? They will always say yes, but the moment you launch it, you will see that they're not using it. And, you know, if you dig deep enough, you'll realize that they're not using it because they didn't want that in the first place, because it doesn't really solve a problem for them. So I think the job really is then to make sure that you have a very clear understanding of the jobs to be done or the problems that need to be, need to be solved and that you are building to actually solve those problems rather than going and validating solutions with them. So I would say validate problems, don't validate solutions because.

And also I guess like, you know, giving them some vision in terms of what your roadmap is, right? I mean, that really assures them because especially B2B folks, I mean, they want to know that, you know, it's a multi year commitment, right? Because God knows that you're going to take about six months deploying the product and then another six months getting adoption and whatnot. So you want to tell them what's in the pipeline basically, for sure.

I think that's very important. And to the earlier point that you made building with customers, I would limit it to being able to validate problems, being able to share your latest thinking with them, being able to share best practices with them, being able to share roadmap with them. I wouldn't let the customer decide what you build. I think that is a big, big, huge red flag.

Okay, so you know, Kaushik, simple question to you. What are some of your favorite products both on, Both on the B2B and B2C side of things? What makes them special? And you know, what are some things that the operators and founders listening to this podcast can emulate specifically about those products?

I think from a B2C point of view, there's loads. But I'll tell you, like, my, my recent one that I really liked is probably Masterclass. And the reason why I liked it is both from, I'll go first from a technical product point of view and then the actual content point of view. So I think from a technical product point of view, I think it gets out of your way, which is basically what I want most of these ott products to do. I don't want complicated onboarding flows. I don't want to log in on every single device. Masterclass, I think you log in once you like, pair it with a code and then it's, it's there. There's a really strong, like, community, really strong help. Discovery is super easy. You know, it does all the right things and it doesn't take a lot like, like, I don't think you need to build anything complicated to get that right. But few people have got it right. I think outside of Netflix. That kind of discovery I don't think really exists anywhere. Amazon prime is also not really great when it comes to simple things. Right. Like scrubbing, for example, on Amazon prime is a, is a nightmare. So, so that's, that's, that's that. Right. And on the content side of it, I think they've cracked the learning or learnertainment pace. I feel really, really well because you can sit like the duration of the, of each segment is like five, seven minutes. So it feels very easy to consume. It does not have significant mental overload. So it doesn't feel like you're, you're sitting and doing a course, but at the same time it feels like informative yet entertaining. So I, I quite like, I quite like that balance in terms of, you know, masterclass, I think, I think B2C, that's, that's one that I've quite like. A more simpler one, I would say is, Is Zero, the fasting app.

Yeah.

Which again, like, gets out of your way, like, doesn't try to like, aggressively upsell to you. You know, it still has other things that are there if you want to buy it and, you know, take advantage of. But if all you want is a fasting timer with beautiful graphics, you know, you get there in like two taps from download, which is, which is great. I like that. I generally like simple products that get out of your way rather than super complicated graphics that are like super complicated. Use of those.

Right. So I had a product slash platform question. I'll get to that. But, you know, before that, you know, from all of the products that you experience and use every day, what are some pet peeves for you? You know, this could be a long list, but maybe your top three pet peeves in terms of what people are doing wrong. Very obviously, yeah.

Login. I mean, it is such a big problem and I don't know why. I mean, I don't think it's solved. Right. Like, I mean, definitely not solid. So I think probably the biggest opportunity on the Internet if anybody can figure out a solution for it. But why would you want someone to have a password? Like why can't you do email link? Like why is not. Not. Why is that not a default option everywhere? Like, you know, if you are, if you're not Gmail or if you're not my bank app, I'm probably not going to remember your password. Yeah, I don't have the mental capability to do that. And you know, I may not have one password last pass. Most people don't. Right. I feel like there are some hygiene things that people should do which is.

Like just authenticate the browser.

Right.

I mean like done over or IP or whatever it is. I mean.

Exactly. So but assuming that, you know, you don't even want to do that. I feel like it's so basic to like those things like Google login or.

Exactly.

Or like email me a link to login. Like those are all like great things to do. I don't know why people don't do that. I think that's number one. Number two is clutter. I don't deal with very well. Like I don't want like the first screen of an app giving me a seizure. And I feel that like this happens in a lot of apps. I don't want to name apps where this happens, but especially in a lot of Indian apps like this is. This exists like it becomes super clunky and it's like things added and like it'll literally give you a seizure. Plus there'll be an interstitial on top that will be like special Diwali offer. Don't like that is just so bad. And you know, I'm not a designer and I have no design expertise whatsoever, but even I can tell you that's really, really bad. So I think that's number two. Number three I would say is like identity, which is for example. I mean Google does this really badly. For example, right. Like you know, click on a meet link and it goes on a completely different email id. And most people have more than one email id. I think at least in the tech world are you able to solve for that identity properly. Simple things that I feel that people can get. Right. Which they don't.

Right.

I think last thing, sorry. It is like it is literally how people, it is literally how developers make money. Why would you add friction there? Like what is the reason? Like why would. Why would you not have as many payment methods as possible? Why would you not have like really, really simple payment flow? Why would you not have native payment flow? All of those kinds of things. So.

Yeah, no, for sure, for sure. I mean, some of the apps just make it a. Like they're testing your patience in terms of whether you really want that product or not. Right after you decided. So you know, a lot of this personalization and you know, data and AI and all of these things. Right. And there's a huge impetus on intelligence. Right. On being just right for you. Right. And you could call this the whole uberization of like products or whatever you want to call it. Right. And I think people also like focus on being like expertly wrong than naively right about some of these things, I feel. Right. So what are some simple things that one can do to make products more intelligent?

So make onboarding easy. Like you want to capitalize on user interest. I feel. So if a user has downloaded your app, you don't want the user to go through 28 steps before they can see the home screen and actually see the functionality of the app. Like, keep it simple. You can also get user information incrementally. Right. So if you want to personalize, there is no reason why all of that information has to happen on the first date.

Exactly.

So if you use a dating analogy to this, on the first date, you're probably just going to give very high level information about yourself and you want to try and make sure that the other person leaves with a very good impression of you. You can get more information on successive dates. Right. You don't, you don't need to get all of that in the first 10 minutes of meeting someone. So why would you want to do that, for example, within the first 10 minutes, within the first 10 seconds of meeting your user, try and get as much information as you want. So I think that's one really easy thing I think that people can do to make users have a better experience.

Yeah. And LinkedIn solved this fantastically well years ago when they said that, okay, you know what, you give what information you want. I'll just show that your profile is 65% completed. And if you have that sort of OCD, then you will make sure that it's 100% completed. Right. I mean, you'll volunteer that information rather than putting obstacles in the way.

Yeah, yeah, yeah. And you know that that makes sense, right? Versus saying that you have to have everything required or before you go ahead. The other thing I would also say is things like otp. I know in some places you have to do it because it's payments and authorization and this and that, but I would try and see if there's a different way to authenticate or give people an option because I feel like the more external dependencies you have, the more voluntary cracks you're creating in your product.

So, okay, the platform question, right? I mean, today everyone wants to be a platform ultimately, right? And that goes against the grain in terms of like, okay, build something like a narrow solution, get inside and then understand the customer and then, you know, widen your solution scope. Right. But on day one, if I'm thinking of building a platform, you know, versus, let's say a product, right. When should I think of building a platform and how should I go about it on day one? Like if I was, if I was to go about building this.

Yeah. Honestly, the approach that I would follow is to have a point use case that I solve for, find product market, fit in, do really well there, and then start expanding to adjacencies I do not know of. And maybe I'm completely badly informed, but I do not know of anyone who woke up and said, I want to build a platform, went and build a platform and became highly successful in building said platform. Right. I think it is very, very hard to build a successful product and therefore it would follow that building a platform is almost impossibly hard on day one. So my advice slash approach would be find a customer segment, find a problem that they have, try to solve for that, find product market with their generate good amounts of revenue, find the next customer segment, or find different problem in the same customer segment, start building for adjacencies and go from a point use case to a platform rather than vice versa.

Right. So you had this thread on Twitter on influencing without authority, right. And how that is super important for product folks, especially because if you look at product folks, right? I mean, they must have such severe imposter syndrome, right? Because they don't necessarily build anything nor do they sell anything. They're at the overlap of that. Right. But they play such a critical and such an integral role for a company.

Right.

So, you know, what are some things that have worked for you, you know, if you could lay out your principles of dealing with this?

Yeah. So I think one which is very important is to have really low ego and be as humble as possible. Because I think the definition is that you are not an expert in anything and the person that you are speaking to is an expert in something. Right. So if you're talking to an engineer, they're an expert in engineering for teaching or data sciences, the data scientist and expert in data science. I am not an expert in any of those spaces. So ergo, I cannot have a very high ego or I cannot have any kind of authority over there to say that you are wrong, I am right. So I think number one, that helps a lot. Number two is going with a very, very high level of curiosity, genuinely trying to understand versus trying to validate. Right. And I think this was a very, very hard thing for me to do and learn and I think I've gotten to a good, good degree of proficiency in it. Where initially I would go and I would be like, hey, like what do you think we should do? Or do you think we should do this? When I knew that this is what I wanted to do and I was just trying to go validate it versus nowadays where I go and say, hey, I don't know anything about this. Can you tell me what, like can you start explaining to me like I'm seven and, and then let's go from there, right? And I think that usually helps in forming better decisions. I think the third thing I would say is solving for collaboration, even if that means paying the collaboration tax. There is a collaboration tax which I think increases, with which I, which I think decreases with the number of people you add to the consensus loop. Right. So for example, if you and me were building something, if I want to get you aligned, it's probably going to take a lot of effort. If there's one more person, it's probably going to take a little less effort than convincing you and then so on, so forth. It reduces over this. But I think that is a tax that you have to pay and I think that it is important to pay that tax even if it means that things go slower or it takes more effort from you because that ultimately means that you have longer term buy in versus people doing things just for the heck of it. That's number three. Last I would say is just be very human. I mean it's not a very hard thing to do, but especially in like very fast paced corporate environments, I think we tend to forget about being human, just be empathetic, try and form a genuine bond with the person in front of you and with your team versus being very, very transactional. And you know, do this for me by tomorrow. Like you don't want to be that person in my opinion.

Yeah, no fun to work with them. So one of the amazing things that's happened over the last 10 years is the kind of product talent that we have developed in India. Right. And it's been great to see this. You know, I've, I think both of us have had a ringside view of this in the Indian startup ecosystem, what are some things that have worked really well? For example? I mean, I think the wide base of engineering talent that we have here lends itself to a more seamless transition to product. But what are some things that we are lacking when we compare some of the other ecosystems, like let's say the Silicon Valley or let's say, you know, Southeast Asia or somewhere else. Right, yeah. So how, what should we do in order to bridge that gap and be truly world class?

Yeah. So let me start off with the positive, right? I think in terms of like what has worked really well, I think is like the hunger and I think coming from a very resource cars environment and I relate to the same thing considering I spend most of my time in India, is that I think there is a like very high level of hunger to say that, hey, I want to learn this and I want to be the best at it. Because unless you're in the top 1%, you know, we're kind of used to not really being anywhere unless you're in the top 1 or 5% or so on so forth. Right. So I think that that, that leads to a certain level of curiosity, that leads to a very high level of learning. I think the biggest gap that I've seen is two things actually. One, three I would say. Sorry. Okay, so one I think is like a lack of narrative and framing narratives. One of the things that I've seen in the best, like product leads, PMs, etc is the ability to shape the vision and shape the narrative of the product. I feel like that is a skill that is severely lacking in most of the talent. That product island that I see from India when, when I like have conversations or when I do hiring for any of the startups that I help out, I feel like that's missing a lot. I think that the reason why that is missing is because empowerment is not very high in India. This brings me to my second point, which is that I find the system to be inherently still very hierarchical to an extent and decisions being more top down than bottom up. Right. In more. In a lot of companies, you know, product decisions are still promoter driven even after scaled. And I get why until series A probably like the founder probably will be the cpo, but at some point you want to start delegating product decisions to the teams and you want to start developing that bottoms up culture so that empowerment actually exists. If you don't do that, then you end up with a bunch of executors. And I think that that is the majority of product talent or experience in India that I've seen at least, which I think is a very big gap, because you want people who are able to frame and make and take their own decisions and stand up for the consequences and have that kind of empowerment and accountability, not just folks who are going to say, okay, this is what I have to build. Let me go find the best optimal way to build it, rather than figuring out what to build. So I think that's. That's number two. So narratives was one, empowerment was two, and hierarchy I'm including in that. The third one, I would say is confidence. But I think that has changed a lot from the time that I was there and I left. But if I think of, like, my confidence when I left India was really low, and I used to always feel very inadequate and had a significant amount of imposter syndrome, I think that's reduced with a lot of the people that I see, you know, who just moved from India now. But it's still there to an extent where folks are like, no, maybe I'm not as good as the next person. And, you know, like that imposter syndrome, confidence is missing, which I think should be fixed. And last I would say is communication. In terms of being like, to the point, in terms of being succinct, in terms of being simple, I think that that is not a skill that I would, you know, put Indian product talent in the top 20 percentile of. Right.

So product is such a tricky thing. Right. I mean, because any other role, I feel like if you hire like a mediocre person or mediocre skill, then, I mean, the person at the very least will lend you extra capacity. But in product, what happens is that they tend to slow you down, actually, they have a negative impact on the team. Right. So hiring product talent is, like, super difficult. What are some ways to kind of recognize who would be relevant for your team when and you know, how to really enable them, maybe get out of the way and, like, you know, help them succeed?

Yeah. So I think it depends totally on the. Okay, so one, it depends upon how the product function is structured in your company. Number two, it depends on what your company does, what sector you operate in, and what exactly you need the product person to do. And number three, it depends upon the stage of your company. I think in early stages, when hiring any, like, your first product person, it's very important to. For the founder to figure out and for the founder to be sure that they actually want to delegate decision making down to, you know, down to that person. Because most founders that I speak to, they're like, hey, I want to hire my first pm. I'm like, great, so will you give product decisioning down to your first pm? And they're like, no. So I was like, so why do you want to hire someone like that, right? Like you can do some, you can hire someone a lot cheaper. If you don't want someone to set the vision and you want to be that, then essentially you're the first pm. So I think that makes a big difference in terms of like, do you want to delegate decision making? Ultimately, if I think of like PMs, especially early stage startups, like, you want, you want to be able to do four things, right? One is you want to be able to articulate a vision, you want to be able to develop the roadmap, you want to be able to gather buy in and you want to be able to execute, right? Typically around Series A probably is when you would see PMs being able to do all four things because that decision making would be delegated. How you want to test for this, I think number one is again, it depends on the company. But broadly speaking, you want to test some level of like leadership and working cross functionally and how people do that. How do you drive consensus? How do you make decisions? How do you drive collaboration? How do you get buy in? You know, these are kind of questions that I would test on. Number two, I would test for some level of like technical capability and I wouldn't say writing code, but like, can you, can you have a informed debate with an engineer about something that is supposed to be built? Can you talk about timelines reasonably? Can you understand what you know the engineer is saying, right? I think that's, do you work well in engineering teams? I think that's important. Number three, I would say data. Again, you don't need to design the metric because you probably have the data scientists to do it for you, but can you have an informed conversation with the data scientist about it? Are you able to identify certain trends, you know, if required, are you able to go run a SQL query, like some basic hygiene stuff that I would look at four, I would look at product sense and I think this is the trickiest one. There are different ways to do it. Like Google, Facebook have their own interview processes for it. Different companies have the different process. I would look at that. And last, again, this depends upon whether PMs in your company do GTM or not. But I would broadly check. Are you able to design a good alpha? Are you able to design a good beta? Are you able to to, you know, for the positioning and the packaging of your product? Sometimes you'll have a PMM will do this but you know, if it's early stage, maybe, you know, there's one product person who does everything. So these are kind of the five aspects that I would check and you know, the four things that I said that an early stage PM should do.

So this has been a fascinating conversation, Kaushik, and you know, I could go on for another hour but you know, I understand we've overshot our time and you know, I want to be mindful of your time as well. So, you know, what do you have coming up? You know, where can people find you? And you know, before we leave the podcast, any words of advice to people who are listening?

Yeah, sure. So I think the only word of advice is find people who will take bets on you and don't give up. I think the hustle is usually at the end of it. Worth it is at least what I found. So keep at it. I can be found on Twitter at the Holy cow. That's the best way to reach me. And yeah, you'll find other details on my bio on Twitter. That's the best place to reach me where I respond the fastest as well.

Super. Thank you so much for your time, Kaushik, and that's a fantastic note to end the podcast on. Thank you.

Yeah, thank you so much, Roshan. This was, this was a real pleasure and I really, really enjoyed the conversation.

Thank you so much for listening. If you liked this episode, then don't forget to subscribe to us on your favorite platform and share this episode with all of your fellow startup operators. Also, follow the startup operator on LinkedIn and Twitter for more updates. Stay safe, take care and see you soon on a brand new episode of the Startup Operator.