 In a quick introduction, I spent time with, I mean, multiple companies. I used to work with TV at Yahoo and 247, subsequently Google Helion Ventures over the last year and a half, working with different startups. So when TV said, like, why don't you talk about some topic over here? So the thought was, I thought, most of the talks that are usually around MNCs, I don't know, something else, essentially, right? Where a lot of these apply more from an execution perspective. But having looked at the startup world over the last year and a half, I think it's a very different perspective. At least I have gotten about what agile means, agility means, where it does it all end up. So I thought I can talk from that perspective, share some of the experiences that I have learned, especially working with these startups. And in my experience, how I found it to be so different from even the leading tech companies, like Yahoo and Google and whatever. And I found it to be very, very different. So I thought that was the experience that I wanted to share. And anything that you guys, is that, would that be okay? Anything that you want to, good. Then the topic kind of was good and bad from that perspective, right? Because nobody had a clue what it was. And what's that? Yeah, I guess. So anyway, I think let me go ahead. I'll cut down the number of slides. I mean, we can just sit around the table and talk about this also. But I think the, I'll just skip through the slides, sir, just an anchor, right? So I think what will be more useful is if you ask some questions. Because there's tons of examples that I can share, right? So I've seen, I'm a product management background by the way, right? So spend a lot of time doing product management in a lot of the brand name companies, and I've found the startup world to be so dramatically different from that perspective, right? I mean, yes, a lot of those apply, but I think a lot are very, very different. So I think I can share a lot more, feel free to ask any questions. We can continue this discussion over lunch. So back to the topic, I mean, to be very frank, I had no idea what to talk about. I mean, when he reached out and said, hey, share something in this AGL, because I don't consider myself to understand AGL that well, yes, we do follow a lot of those methodologies. But I was clearly really not sure. But after a lot of thought, the only thing that came back to my mind was startups are inherently AGL, right? So whether you want it or not, if you're not AGL, you are just lost anyway. So the main thing that occurred to me was at least working with these guys, the difference was you get so caught up in running fast that you lose sight, I felt, of the big picture all the time, right? And when you talk about big picture, the only thing I'm talking about is impact, right? So because resources are so hard to come by. I mean, you just don't have resources to start with in the first place. And it's not that everybody knows what they're doing, right? The reality is like quite often nobody knows what they're doing, right? And just coming into terms to say that coming from a company like Yahoo or Google or any of those multinationals who have long-term strategy, like plans laid out, huge organizations in place to like five guys who are just running wild for all practical purposes, getting to accept that look, we don't know what we are doing, itself was a huge first step, right? And when you're running in that mode, you just don't have resources to waste, and all that matters is impact. What impact are you producing at any point of time? And if you don't do that, you will not exist, right? I think the biggest difference was, I mean, it's okay in a large company that you don't produce impact, the system will take care of itself. I mean, you will get your promotions if you do an average and decent job. That doesn't exist in a startup, right? So impact was the first thing that stood out. And the reason I came up with the title was it's all agile, everything is fine, but what is really impact? I mean, and if you don't think about that often enough, and at least if the right level of people don't think about it often enough, you will not succeed, right? And it was just super apparent, it doesn't matter what kind of companies that I worked with. So that was kind of the concept behind the title. And like I said, I would prefer to talk examples. So feel free to ask questions from that perspective. I have a few in mind, but there's so many. I mean, I've worked with about 15 different startups from the Helion's portfolio. So very different experiences, say, enterprise, consumer, some hardware-ish, and all of that, so that's that. So start with obviously, it's actually bad Canada. So it starts with a fail. It's not the right usage, but it sounded better. I'll just skip this, yeah, it's kind of disclaimer that I put in. So I think if you look at a startup. I think one of the main things is, I mean, in a way, this is what comes down to, right? I mean, you just have a thesis. I mean, and you talk about hypothesis testing, take it to an extreme. Essentially, that's what you're doing in a startup to a large extent. Unless you are emulating a well-established model from elsewhere. So if you take an OLA, or if you take Flipkart for that matter, you kind of by and large know what you need to do, right? It's an execution play at that point of time, right? So you're not discovering a new space. That's a very, very different concept. So a lot of companies in India at this point of time are predominantly execution place, where you just need to make sure that you're executing well in the Indian environment, and then just make sure you're doing a really, really good job. And hence, what you follow in that is very different, right? It's not, I mean, you're not discovering a lot of things. But having said that, even there, there's a lot of things that are different, right? So for example, how should your login page be for India? Right, I mean, that's different. I mean, there's a slightly old example in Yahoo, when you sign up. The sign up page, you know, a bunch of things will be there. There is a field called alternate email address. And in the Western world, everybody had a hotmail and everybody was migrating to Yahoo Mail, so it was a very well understood concept. In India, everybody is signing up for the first time, so the alternate email address doesn't exist, right? So you saw a 90% drop-off or 80% drop-off on that page in terms of sign-ups, and if you look at the data and keep staring at it, you don't know why, until you actually get down, get your hands dirty and figure out what's wrong, right? So it's things like that. But anyways, typing back, basically the point is you got to deliver something of value to the customer, and hopefully that makes the right impact in terms of solving their problems. They're delighted and they're ready to give you money, right? So it's as simple as this. If you can narrow down on something like this, then you potentially have a successful company, successful product in a successful revenue stream. If you don't have this, obviously you're not going to go anywhere. So I just skip a bunch of this, right? So I lost this, but maybe I'll just take a moment for you to read this. And this is, I took this from one of the presentations that I give, typically with the product guys and the engineering guys, it's an ever-ending problem. It's almost like the good versus bad fight that exists forever. So the product guys are never giving right requirements, and the product guys and the engineering is never doing what they want them to do, right? So it's almost like a perennial battle. So again, rehashing something that I said, you know. So anyway, I think just a quick check. You guys are, what's your background? I mean, anybody from a startup, big company, startup? Small company, okay, okay, okay. Or the agile, okay, got it, yeah. So I think the point is I think, you know, you've got to kind of, the reality is you don't know what you're doing, right? And no, I think while that may be the case, I mean, I have not seen that attitude reflect in a large company, because large company functions in a manner in which you articulate, we know exactly what we are doing or executing by and large, right? People are getting directed on what to do. In a small company, it just doesn't work that way, right? So I'll give you an example. So taxi for sure, which is reasonably successful, you know, in what they did and had an exit and whatnot. I mean, everybody is just running so wild, it's unbelievable, because the growth is just amazing. Every day you wake up, you know, you have 5,000 new guys who are, you know, taking your service. Like how do you even, I mean, and the guys who are running it are not like, you know, been there and done that. These are like practically fresh kids out of college, like three, four years. It's not like they know what they're doing, right? And it takes a lot of humility for these guys to accept that look, I don't know what I'm doing and I'm gonna empower the teams in a way in which they will step up and do what they need to do. And guess what, these kids who are running it are one year out of grad school, MBA, whatever. It's not that they know what they're doing, right? But it doesn't matter. Every day, the ridership is going up, right? The only question is how do you manage this at this particular point of time, right? So when you come up with a release, and when you say, hey, do we do this in this release or do we do that in this release, it's not like they know the techniques. It's not like you have eight steps that you go through, you know, before you deliver impact, right? You just have to figure it out, you know, and that particular point. So, I mean, anyway, I think the summary of this is, I mean, a lot of people should have to get it in them, especially if you want to work in a startup that nobody quite likely knows what they are doing, right? But there is a big picture. It's not that, you know, it's chaotic. There's a big picture. There is a big picture towards growing. You know, if we take TFS or OLA or whatever, the concept is very clear. You just need to, you know, make sure the transportation is, you know, scaled up viable. That is the big thing that you're doing. And under that umbrella, what is it that each of us will do? You kind of largely begin self-selecting, right? Nobody has time to manage anybody. So, you kind of largely start self-selecting and then start doing your own things and different things begin to matter from that perspective. But when it comes down to software, again, you know, let's kind of leave that aside from a startup world. Come down to building software. You have maybe 10 engineers, five engineers. 10 is a lot actually, a luxury in a startup, you know, in the early stages. You have five engineers who need to be building something. Now, how do you pick what to build? And the time frames you're talking about are so vastly crunched, it's unbelievable, right? So, when I started working with this team, it was like, oh, okay, this feature needs to be built, you know, maybe a month, right? And month was kind of fairly agile, you know, from that perspective, coming from, you know, whichever companies I used to work at earlier. And then these guys, you typically, their shipping time is three days, right? So, what traditionally you used to think about a month or two weeks usually happens in three to four days. Now, very debatable is the quality better, you know, should it be more, whatever, right? But it's orders of magnitude different. So, in that situation, you don't even have the right mechanisms to actually, you know, assess impact, you know, do what you need to do, et cetera. So, asking that question, because if you don't deliver the impact in those three, four days, you basically just wasted time. It's not just wasting time, you actually are draining the company. I mean, you're increasing the probability of failure of the company, right? Because, you know, if that feature didn't happen, those three to four engineers would have worked on something else, which would have actually produced greater impact. So, when you cut it down to backlogs, you know, metrics in that backlog, all of that, the only thing that really matters is, is it really going to make that deep impact which will help the company, right? Unless you keep asking this question on a regular basis, it's, you are not going to be doing a really, really good job, right? So, that's a point that I was trying to, you know, make. I'll just skip this, skip this, skip this, skip this. Yeah, so, and, you know, let's take a different cut of this whole thing, right? So, in a large company, when you look at it, and again, Agile is largely talked about in the context of software development, right? Product, you know, extend it a little bit more into product. If you take hardware, yes, a little bit of that comes into picture. But my enlarge, that's what, that's what I was exposed to when I used to work in big companies, and that's kind of what most of the industry is exposed to. Whereas, in startups, especially the ones that we are all coming across these days, that really won't cut it, right? Because the job of, let's say, Taxi for sure, is when you press a button in that software that is beautifully written, a driver has to show up, and make sure that you, I mean, he or she ensures that you have a delightful experience. That's the service, right? Your app may be the greatest ever app that is ever built, but that doesn't really matter, right? The impact, in this case, what is impact? Again, if you go back to the question, what is impact? The impact is not how great the software was. The impact is how great the customer experience was when you ordered the cap to come in, right? So, again, go to Flipkart. There's not really how great the app is, how great the website is. Yes, that's a significant part of it, but it goes to, you know, five things, six things, seven things, eight things, more than that. You know, take BigBasket, right? One of the portfolio companies. It is not really the greatest collection of vegetables that they have or the food they have. Does the guy show up on time and they say they're going to show up? If that doesn't happen, it really doesn't matter. What AI app you applied behind the scenes, what optimization app, nothing matters. It absolutely doesn't matter, right? So, the concept of how you look at impact has to change completely, right? And while it is true that you as a software person is going to look at one area of impact, if you don't stretch beyond and start looking at what are the other implications, you will fail as a company, right? So, if you don't have a culture where the average, and when I say average, I don't mean quality, when a regular software engineer or a regular product person or a regular designer doesn't think about what the end customer experience is and think about it all the way, you are not going to be building something, right? In a large company, I mean, it is all taken care of by 10 other layers that exist in the company. In a smaller company, in a startup, you don't have those layers. You are calling the shots, and you will, actually, right? Because nobody has the bandwidth to actually tell you what to do. Nobody has the time to figure out what else needs to happen, and that's the way it is working, right? And that's the way it should be. So, what produces impact is not, you know, you're also used to thinking about what features. And mostly it is that it's about really how well that feature is done, how well that feature is implemented. Is it the, that enhancement that you're talking about, like if you leave Bucks exercise aside, is it optimization, is it the marketing campaign, is it the welcome message? Reality is in a startup, it is some slice of all of the above, right? And then if you go down to operational intensive businesses, right, to beat the home joys of the world, which is talking about sending you a plumber and making sure the guy shows up on time, and it doesn't matter what AI you applied behind the scenes, if the guy doesn't show up on time, you're not going to succeed, right? It is not a software problem, right? So ultimately, how you think about impact has to change very, very dramatically. And it applies to everybody in the value chain, right? And it applies a lot more obviously to the product person. I mean, that's kind of where this comes into picture, a lot more product as well as project and program folks, because by definition, your program is not really about how great this release will happen. That releases again about ultimately what is the impact, right? So I'll give an example. BigBasket had to decide three pricing strategies or discount strategies. They don't really discount the whole lot as you know. Now, the question is, would 200 off of a thousand order work better? Does 5% off of a thousand order work better? Or does three, one KG tomato and potato, I'm just making some of this up, work better? And how do you know? You don't know, right? And the question is, first of all, it's not like the guys have figured it out. No, you got to do a ABC test in this particular case. Clearly yes, right? And this ABC test is not pure software that you just flip a switch and get data, because your inventory has to have potatoes and tomatoes appropriately. And if you want to run a campaign in, so would you run a campaign in the same city because that could produce dramatically different results because somebody in Malaysia may say, hey, my potatoes are more expensive than somebody in Kormangala. So naturally it's not going to work. So you got to do it across cities in this case, right? So, and whose job is it to actually figure this out? It's not like there is a XYZ program manager who's designing all this, it is the same team that does the product and marketing and whatnot. So again, attitude, right? So you have to stretch all the way. It's not when you ship software, your job stops, you have to go all the way. What is impact? It is not how great your quality of code was, it's not how quickly you ship. Is it, you know, which scheme worked better? Can I figure it out? And do all the efforts that we are doing helpful in figuring it out, right? And when you figure it out, essentially, again, how do you collect this data? Now, you know, software is easy. You have analytics, it's going to give you something. When you go that one step beyond, who's going to give you the data, right? So unless you instrument that and the traditional world doesn't necessarily have all of the data points as easily, as easily, you know, built out as it is in a piece of software. So can you apply your software intelligence into that world to figure out how is it that you can get the data? It's not that you're going to hire a consultant who will build something for you, not going to happen, right? So what is impact? How do you think about impact in that case? It changes a lot. So clearly, I mean, as you guys know, the right answer is, you know, we don't know. And we've got iterate and figure it out. So the only thing that at least I have been, I have learned, and hence I've shared with the teams that I work with, is all you can do is to maximize the probability of getting it right. You don't know whether you'll get it right. You have to accept that first. It's not like we know what we need to do and you're going to go execute that. You don't know what you need to do, right? You start with that premise, unless you have that well understood and the culture will not be right in terms of enabling that thing to happen. The second part of it is if you fail and you will fail along the way, how do you minimize the cost of the failure? So if you're going to run an experiment for a week, two weeks, you know, pick an experiment that is very worthwhile, obviously. And then you know you have failed. Is there a way by which you can minimize the cost of failure, right? If you spent three engineers' time for two weeks building a piece of software, I mean, is that the right thing to do or can an experiment be done in a way in which it can be done in one week so that the failure is kind of a little bit more, you know, controlled to some extent. Is that a better thing to do, right? So it's a lot of that. So anyway, I think the next few slides are, you know, kind of scenarios around which I can, you know, give examples. Maybe I'll take a pause after one or two because you guys have questions I'll take them. I think one of the big lessons that I learned, which is very valid, again, in these examples that comes into picture is can you redefine impact from a very outside end perspective, right? It's not really about what the release was. What is the success of the release? The success of the release is still fine. I mean, the success of the release is what it's talked about. But I would say, flip it from the outside, completely go out of the company. And if you are a person from somebody who's outside looking into the company, can you define success from that perspective? Can you define impact from that perspective? Right? And it matters a lot more in, it matters lesser in a big company because there are 18 layers of, you know, things around your product that ultimately goes to the customer. And a lot of the companies that are at least operating in India right now are consumer focused companies. So things are very, very real. You can actually articulate impact from the outside. Yeah, yeah. It doesn't matter at all, right? It doesn't matter at all. And the other interesting thing is that, I mean, a lot of us may have experience in that. The operations world functions very differently from the software world, right? And not many traditional software guys would have even worked with operations because they even understand that. So they have a certain expectation of what software should be doing because traditionally they've been working with oracles, I don't know, whatever the software is. And in a startup, you are actually, by definition, working on substandard, you know, product quality of code to some extent, right? So, I mean, instead of what I'm saying is that your intent is not to build the right product. I mean, intent is not to build the product right, right? It's not that, the point I'm making is don't get me wrong, but you should not be build, trying to build everything the right way, right? I mean, yes, things will crash, but that's all right. I mean, this is quite likely there is a piece of code that a typical software uses, let's say in the early stages of the life cycle, will not pass the quality standards of a largest company, right, and it's completely all right. It's completely all right. Yeah, so, and I think, you know, I think what happens, see, it changes a lot in different stages of the company, right, so the examples that I'm giving are typically between C to series B pushing it, not more than that. Things, post-series B, the company is actually as good as a big company. It's a different company. It is a lot of the traditional large company practices that do come into picture. Yeah, yeah, yeah, exactly, right? So at that stage, because you have money to afford to even do things like this, at the early stages, I mean, see, if your market, if your potential addressable market, let's say, is 30 million people. In the early stages of the company, you are realistically going to address a million, two million, right, and that is a lot, actually, you know, if you can, if you can. No, even if you take that, that one million, two million, you're gonna pick off of this 30 million. So which means you're consciously going to say, you know what, I don't want those people, and it's completely all right. Whereas, absolutely, you can't, you can't do it otherwise. You cannot, because one is you can't build the company otherwise, right? You just need to self-select which is the audience that you're going to go after, and it could be, you know, what your early adopters, yeah. So, you know, it could be that, or it could be that, you know, I mean, again, going to a, I mean, I'll take the Uber example, but same example applies to other companies. Also is, you know, you address a certain segment of the users. I mean, you take Ola, right? So Ola's and Taxi for the strategy was very different. Ola was a sedan segment, which means the, they started mid-tier, I would say. It was not high-end, it was mid-tier, whereas Taxi for sure was, you know, low-up. It basically said, look, people who take an auto, I want to give them a car, you know, in which they can go to. Whereas Ola's approach was very different, right? So he said, like, no, mid-tier segments, just to be a sedan, it should be more expensive, but that's the way we're gonna, you know, work. I mean, debatable, you know, which worked, you know, one way or the other, but you are self-selecting your audience, and that's what you're going after. And even when that happens, I mean, what are the, I mean, I think if you're engineering teams, I mean, when I say you're, I'm just generalizing to startups in general here, I think the teams should not be trying to build the right software because your software will be rewritten 10 times over from now till series B, right? So as you're growing, I mean, in the initial stages, you're just building the right software that will support many 100,000 users, not even that much potential, right? I mean, in fact, it's advisable that you don't build software. You know, I have a slide around that later. We'll talk about that. But you are building just enough so that it'll take you to the next step, whatever the next step is. Because quite likely, you're going to learn something different along the way. You're going to learn that this is not what we need to do. And what we learned from the test that we did was that we need to actually change it. So you actually have to build disposable software, which means do not over architect it. You just have to understand what you need to build, but don't like, you have no idea what you're building to a large extent. We're just building for the next step. So build for maybe two steps ahead. But it's also important that some key functions in the company should think long term, right? So the product guys should say, hey, largely this is kind of where we are headed, right? The architects at least, if you have can afford an architect in that stage, then those guys should kind of think about, oh, largely this is kind of what we need to build, right? So you are learning, you are learning and you're learning. And that's why I say you don't know what you're building. But you kind of know what you're building, but you don't know at the same time. But the big picture matters, but in the iterations, you are consciously building disposable stuff. And technology is making it easier for us to do that these days, right? It was not possible in the past, but you are not trying to build fully automated, like unit tested, all kinds of. Yes, you will do a bunch of those as long as it does a good enough job. So I mean, I'm sure you would have heard this phrase, which is like, don't build the right product, not build it the right way or some such stuff, right? So it's very valid. So building it right versus building the right thing, right? So what matters is that you're validating that you are headed in the right direction. It doesn't matter whether it's a perfect piece of software, right? I mean, it does matter at a certain level, but that is not the objective. Again, going back to impact, the impact that you produce was very valid, able to validate that this segment uses what you are building versus, oh my God, this is the best piece of code that has a maximum performance. Yes, each of us will have our own touch point. If I'm a great engineer, I'm going to say this has to be great, but that's not really impact in that stage. It's something else. So I'm going to skip a few slides, I just touch upon a few points that are close to my heart. One of the, again, it matters more in the early stages, and I think over time I've come to realize that it matters in all the stages, actually. Even a large company, even a large company, right? Please don't try to build software. You know, because all of us are here to actually solve a problem. And the problem that we are solving could be very different depending on the industry you are in. I mean, if you're an oracle building the greatest database ever, of course the problem you're solving is very different. You need to build software for that. But if you are trying to, if you are swiggy and trying to give you the food as quickly as possible, you don't necessarily have to have software built in all the time. So, and it's also amazing how when you challenge yourself to find if you can validate that in a different way, I mean, you'll find five different ways by which you can actually validate without building software, right? So, I mean, simple example, let me take a good one. Yeah, so there is, yeah, there is this company of ours called EasyTap in the portfolio. So, EasyTap makes square kind of devices for India, right? So, basically you can attach it to your phone and your phone becomes a card reader after that. And, you know, or Bluetooth, you know, variety of things. They're working on a fingerprint based, detection other, you know, all kinds of stuff it could do, right? So, the typically what happens is when you ship this hardware, it takes about two to three weeks for a merchant to activate it, right? So, basically they'll say I need this, you know, the hardware gets shipped, it takes three, four weeks, let's say, let's say a month before they could come on board and start using the system. And clearly that one month is one month that you're not making money off of the customer because the device is not even active. So, the clearly, I mean, very obvious, right? Oh, we need to bring it down to two days or whatever that number is. Yes, of course, it makes a lot of sense. Traditionally, you would have just gone out and let's go look at what is the software that needs to be built to make it self-servisible. I'll build a tool for admin guys to access this. I'll build, I don't know, a self-service tool for the merchant to come and do sign ups, blah, blah, blah, right? And that's when we kind of, a few of us got, you know, said, okay, like what are we doing exactly, right? So, okay, this is what we want to do. Now, let's kind of go through what it takes. Let's just break down the steps to find out whether we need to build software at all. And then the moment you got into second level or third level of detail, you realize that somebody anyway had to go to the merchant to actually get a bunch of KYC documents signed, right? So, know your customer, you know, signed and legally you're required to do that. So, doesn't matter how you optimize it, you cannot compress it beyond a certain level. Now, the question in that case is that, okay, does it make sense for us to build this software at this particular point of time or would do something different and then reallocate this effort there, right? So, all it took was a half an hour, 45 minute, one hour discussion to get to second level or third level detail where traditionally, if you had looked out to say, hey, self-service, let's go build the software, it'll optimize it versus, again, outside and you go out and say, when this really ships, what's supposed to happen? What's supposed to happen is that this customer will come on board and in two days we start seeing revenue, okay? Will we start seeing revenue and what does it take for us to make that happen? Just shifting that perspective essentially made us ask a very different set of questions and then we ultimately found that it's an important thing to do but it needs to be done maybe three, four, five months ahead or in the outside. Once we do some KYC related stuff and figure that out or you go change the legal clause post which you can actually activate the customer without doing it and then you can kind of decouple these two tracks essentially to some extent, right? So, and in this case, impact is not about how great your software was. We've been, you know, you didn't even have to build a piece of software for that. You know, another example could be cab quality, right? So if you take, you know, company like Ola, TFS, whatever. So most of these guys have something called, forgot the name of the team but it's essentially cab quality assessment, right? So they'll do random spot checks to make sure that the quality of the cab is clean, you know, the driver is dressed appropriately, the cab is how it's supposed to be, et cetera. So the natural thing is like, okay, if you're a software guy, if you have to build it, you'll build a randomization logic which will pick cabs at random and then somehow, you know, you'll make sure that the guys are showing up or the guys are going, let's say the inspector is in MG Road and then the person should be able to press a button, who will know what cab is coming in the vicinity, the cab guy has to be alerted to go show up in a certain place, the guy will audit it, say everything is okay, build a piece of software where he could enter a bunch of these stuff and then, you know, good, right? This is ticked. Now, the reality is however quickly you build it, it is still a two to three week software effort, right? By two, three guys, you know, working on it. Question is, do you have to put software at this particular point of time or can we do it in a different way? So, and then you challenge the team enough, you will find three ways by which you could actually manually do the whole process to find out whether this is the right way to do this at all in the first place, right? So, essentially, and we could repeat this across different companies, please don't build software, right? First, understand what you're trying to do and that happens only by you doing it. Without you doing it, you will not know what you're doing, right? So, and you have to get into the next level detail to actually, you know, get your hands dirty, understand what you're trying to do, have a reasonably confident, repeatable step and automate that with software. So, the approach completely changed to using software or automation, not really building software for the sake of building it. And, believe me, the approach is very different, right? So, no, I agree, I mean, right now I'm... No, but what I've seen is, I mean, I completely agree with you, but it's ultimately a question of bang for the buck. I think, in my opinion, the challenges of a startup and the lack of resources force them to be in this way. If you don't take it this way, you're just going to burn a lot of resources to get to where you need to get to. I'm pretty sure, I'm pretty sure, right? I'm pretty sure, and see, it's not that you need to close down also, right? The question is, can you afford to burn that? Can you afford to waste that? I mean, I'm sure you would have learned something along the way, hopefully you'll learn. If you don't learn anything, and if you still burn the resources and you didn't get what you need to get, you're not making use of the available resources efficiently. What will come out of it, I don't know, but again, what is impact in this particular case? The impact is, hey, can we test this? Can we make sure this happens? And can we do it without building software? And so, over time, essentially what I've realized is, I mean, personally, we had to, especially the product management team, attitude had to be shifted from building software, building the requirements for building software to actually go take the outside in perspective, define impact first, figure out if we can do it without building software. If so, go do it for a couple of releases or a couple of sprints. Once you know exactly what you're doing, then you come back and tell the team to build a certain piece of software, because you could actually write meaningful requirements. I mean, you and I can sit in the room today and actually dream up requirements for the aspect that I spoke about. We can do a really, really good job, but 99% will be wrong, right? So, can you get into the real world first, and then come back and actually start building stuff? And because, I mean, India-specific starts up again, the ideas are the advantages that you can actually get real, versus you being a part of an MNC sitting here, 18 levels about some PM there and technical PM translating that requirement. You're just like lost in the words in this particular case, versus you can actually get real in this case, right? So, one of the big challenges is also when people transition from a large company into a startup environment, you have to get this. There is nobody else to actually tell you what is the right thing to do. You are making the call and it's actually fairly serious, right? I mean, you can debate whether it's the right thing or not. You can argue that the right talent is not there, but guess what, this is real. When you make a call to say, I'm gonna do this, you are actually owning up to burn three engineers' time to build something and it has phenomenal impact, right? One way or the other. So, keeping that in mind is very, very helpful. Yeah. No, no, I think it's exactly there, right? I mean, I think the idea is get real, right into the real world first. And one of the things, and again, some of the companies that, at least most of the companies, see a lot of the structure starts getting in really serious B after, right? So, when the company has enough funding, when structure matters, because you are scaling at this stage, you're not figuring it out. You've gone past the stage of figuring out what to do to, okay, now I know what to do, I'm just gonna scale it. So, processes are, traditional processes are a lot more efficient during the scale stage. And in a way, the frameworks that lean startups and want to provide applies in the earlier stages, but you still don't need a phenomenal amount of process. It's more about best practices that you need to follow, can you internalize that and can you do it? Versus like, you know, I'm gonna run it in a certain way from a process perspective, right? So, it's different. And I think just repeating the point that we spoke about, essentially what you're trying to do is the fastest, the cheapest way to validate a feature or a product, right? And then when you build it, again, don't build it for a million users, build it for a few thousand users first, right? And then build it for a few hundreds of thousands of users and then build it for a million users, because no point in building for a million users when you don't have the first guy signed up in your product. It's a very, very different problem you're solving, right? So, change, I mean, that attitude matters, right? Again, thinking about impact from the perspective matters a lot, yeah, yeah. So, actually, can you do one thing? I'm gonna hang around here. Can we take it offline? It's a couple of points that I want to touch upon before this one. So, I think, and going down to this place, and you can see what I'm trying to say in that slide, we are all so, we, in a sense, most of the people in this audience in the room, so removed from real people, it's unbelievable, right? And I don't mean it in a negative way. If I were in that stage, I would be doing the same thing too. Data analytics, beautiful cohort analysis, excellent stuff. A-B testing, design experiments, just talk to real people, right? It's just so, I mean, again, depending on the product, I mean, even if you're a large enterprise, you actually can talk to real people relatively easily. All you have to do is to find one account manager, one sales guy, with whom you can tag along, who will be very, very happy to actually take you along, more often than not, to actually just listen in on a sales pitch, right? To ask two questions to a customer. It's so easy to do. It's just that we don't do it, right? We don't think about doing it that way. You know, so one of the things I mandate, you know, people in my team to do, and most of the startups I work with is, a PM's job is actually talking to real customers. At least, you pick a number. It could be one, it could be two, it could be 10. You have to do whatever you think you have to do, but talk to real people. And it's so, so amazing what you can learn from that, right? So, and especially when you're working on a consumer, you know, product, right? I mean, it just, but the attitude is not that. You're just so hiding behind, I mean, unconsciously looking at data, but we just lose the connect with the real people, right? So, simple example, again, I'll take from BigBasket. We were seeing significant drops of people, you know, who will sign up, who'd have filled the order basket, right? They have 1,500 rupee order basket, actually filled already, and then they're just dropped off. They would not have ordered, right? Now, so if somebody had ordered or added 1,500 rupee item to the cart, that is the reason why they did that. They didn't come to just browse around the site. The reason why they did that. Looking at data, see the problem with data is if you don't instrument the writing, you don't know what you're going to get, essentially, right? So you know what you got, what got added to the cart. You don't, you know that they dropped off, but you have no idea why they dropped off. Now you can sit and instrument the data all day long to figure out why, but they just, they have your phone number and email, just call them, right? And all you need to do is to identify a segment of people who look kind of similar, from whom you think you can learn, and just talk to 20 people. We found out. We found out why they were not doing it, and it was just so simple, right? So, and I'm not saying that that's going to give you an answer all the time, but it's actually such an obvious thing that we end up missing most of the time, right? Again, you know, if you want to deliver impact, you can, there are cheaper ways to deliver impact, much, much cheaper ways to deliver impact, yeah? I know in that particular case it was, yeah, I can share, I mean, this is, so, phenomenal learning, no, no, it's okay. It's nothing, no big deal. It's not preparatory or whatever. Women add to the cart, men pay for it, okay? So, basically because women are not comfortable checking out in a certain way. Like you have to have the credit card. You have to do the OTP, right? It's just complex. So, what happens is women know what to order, men pay for it. Now, you will not know this insight by instrumentation and do whatever it is, right? Yeah, I mean, and once you know it, it's so obvious. It's like, how can we not think about it, right? I mean, it's so obvious. Yeah, yeah, so, but you have to talk to real people. It's as simple as that. Now, you can build, you know, wonderful software to figure this out and instrument it. You just burnt like, I don't know, three months of somebody's time doing nothing. And all you had to do was to talk to real people, right? You know, I think this can be internalized in so many ways. I mean, each of us in our own job, big company, small company, figure out the cheapest way to test your idea. I mean, hypothesis testing, logically speaking, but really, I mean, there are cheaper ways to actually, by which you can test what you need to build. And the more you do that, the more you will deliver impact. Because this, like once you have that learning, all you need to make sure is to make sure that COD is very prominent. Now, COD may have been there, but the person who's ordering doesn't maybe understand what COD is, right? Maybe you just have to say, I pay at home, right? Just order now, pay at home. That's a lot more efficient in terms of communicating what you need to communicate. Now, you can go test what is the right message that will work. Now, somebody who's come this far, how do you flip them over, right? Now, you can solve it, you know, in a much, much better fashion. So, that's one, talking to real people helps phenomenally, phenomenally, phenomenally. And I mean, yes, there are high-fidelity prototypes, yes, the usability testing, one-way mirror, all the fancy stuff can be done. Just talk. Like, you'll find 20, about 25 people is what I've found where you start seeing patterns. 20 to 25 people, you kind of get a feel of what people, you know, have in mind. Of course, the key is to kind of select a focus group or a segment of people whom you want to talk to. So, in this particular case, it was fairly clear because drop-offs after, let's say, 1000 rupees added to cart. And we could find a lot of people and we could go talk to them, right? So, relatively easy to do. So, anyway, I think I'll, there are a few other slides. I think the main point in that case is, I mean, the point here till here is, look, understand what impact needs, right? And then, and define impact from the outsider, right? Do not articulate from your perspective, like a successful release is from your perspective, nobody cares that you actually learn successfully, especially in a startup. Basically, because the only thing that matters is the ridership go up. Did my orders go up? Did the customer satisfaction go up? In a large company, you do articulate that way, but at least in my experience, I have found, though I was a product guy running this metric, I don't think the orientation was that aggressive, right? So, you don't have a choice in a startup, but to actually be very, very aggressive. And anchoring that will also tell you what to measure, right? I mean, it's obvious, I mean, nothing dramatic. But again, I think it is really about reorienting a thought process to say, look, I don't have resources to waste. In a large company, you can afford to waste resources and it's completely all right to do it. Because the company is built for that, you just don't have the luxury in a startup. You are potentially, right? You can afford to give busy work. No, no, true. You can afford to give busy work and people will be busy. You really don't have a choice in this case, right? You're potentially working with some standard talent too, because you can't afford to pay these guys, you know? You can't afford to get the typical guys who would have worked in a large company. So, given that, given the paucity of resources, given the paucity of talent, the challenges that you have, every resource that you deploy to work on something, again, largely software related, super valuable. So, if you can get to impact without wasting a lot of resources, I mean, that could be software, hardware, in operations, whatever, figure that out. So, unless you have your eye on impact and then you go down to figuring out what is the cheapest way by which I can get there, think a lot about that and it's not gonna happen. I mean, I'll take a very different example. This is more of a marketing use case. So, one of our companies powers the gift cards for vendors like Amazon. Amazon gift card is powered by this company called Pixelva, same with the card, bunch of other things. They are maybe not controlled, essentially, they actually dominate the card gift card market. Pretty much what you see in Spencer's, Landmark, all of this is powered by this company, 90% of the market, actually. So, what they wanted to do was offline, when you go to, let's say, a shop or stop, and when you wanted to, it's a new gift card they were launching called Uhu. When you wanted to have the Uhu gift card, they wanted to drive the offline usage behavior. So, the plan was to actually dedicate two lanes for people who have Uhu gift cards, or Uhu cards. So, for which, essentially, the whole marketing, partnership, tire, business development activity had to happen. The thing was, six months, it'll take six months for us to actually make that possible. Now, the question to the team was, can we test whether this damn thing is gonna work in the first place? Because conceptually, yes, it's a great idea. You're gonna have two lanes dedicated for people who have this card, so when there is a crowd, if you have this card, it's an advantage. You can go use this, can we just test this out? So, all we had to do was just walk across to a shopper stop in Kormangala, just drop a banner or whatever it is for one day, just to see what people did. People showed up to say, hey, I'm coming. So, you're testing the fundamental theory that queues are a problem. And if you have this card, people are going to do that. Is that going to happen in the first place? Do people care? Is that even a real problem? Does shopper stop have long queues at all? Maybe that applies in big bars, big bars are not in shopper stop. So, if you have that data, and then use the data to actually go, build your business development use case, it's not going to take six months. It's going to take one month, because the guy who's heading partnerships there doesn't want to twiddle their thumb. They want to actually make an impact too. But if you can go with the data that says, dude, we just did this for a day, and this is what we learned, and guess what we could achieve by doing this? He or she is going to actually make your life a lot more easier by accelerating the whole thing. Again, go get real, get your hands dirty, collect data from that perspective, use that, it will be useful in so many ways. And this was not even a software implementation. It was a pure offline process implementation, and the company could, the reason why we kind of challenged the team to do this was, we wanted to actually launch by Holy, I mean, this is last year, by Holy timeframe, which was hardly a month from when the idea was conceived, versus six months later, and they could launch by Holy because of that. So, again, keep an eye on the impact, define it from the outside, and get cheap, get real impact. Use software to automate. Don't look at building software from a product perspective. Software is for automation, right? And if you shift the perspective to that, you can get a lot more things done. Anyway, there are a few other slides, but I'll talk about other things if you guys have any questions. How do I like to define a startup? I think theoretical definition would be what the lean startup definition is, right? I mean, a series of experiments to really figure out why you exist kind of stuff. Ah, okay, okay, that way. Yeah, yeah, got it, got it. No, it's true. I think, that's a fair point, right? I mean, in fact, somebody, you know, there are companies that have been, I've come across nine years in existence, I still call them as a startup. Like I said, essentially they're a small company, but not really a startup. So, I think, at least, mentally, I think I'm using it more in the context of classic venture-funded company, where growth, I think largely essentially it comes down to, is this growing fast, or can it grow fast? Versus, you know, it's not a growth business, essentially. Yeah, yeah, yeah, yeah, no, yeah, that's it. And again, yeah, yeah. No, I think this whole funding thing, that's a day-long discussion, right? I mean, so I think, traditionally today, it should have been, and even at any point in time, it should be that the funding is going to just like, add rocket fuel to your growth, right? And typically, you'd want it for that. Sometimes, of course, you need for hiring, even for you to validate, but that's the way it should be. I mean, but how it's talked about is as if it's a milestone by itself, right? It ideally should be a non-event, you know, in the life of a company, but that's not the way how it plays out, at least, you know, it doesn't make good press, right? That's what it is. So, yeah.