 Good afternoon everyone. My name is Aakash and I am the guy standing between you and your lunch. I am well aware of that so I am going to try to go through this faster and make sure that this is worth your weight. I work at Gojek, I head products at Gojek. How many of you know what Gojek is? I do. That's a lot more than I thought. Actually, you know, outside of that context, you have come across before that. Another thing is, let me actually get to what Gojek is. I will try to keep it very short, quite difficult though. Primarily because very few of you actually know what it is and the talk needs to be in that context. So we have nine distinct products although all of them are in the same app. I know most of the UI, UX, mobile people will already cringe with the thought of that. We have basically Swiggy, Ola, Bookmashow, UrbanClap, Grofus, Paytm, 1MG and few as being lazy not yet born in India. That's the NYBE part. All of these into the same application. In most of these, we are already the market leaders in that segment, which means there is a lot of scale happening over there which comes with problems. We have about 250,000 drivers. We do about 12 completed orders per second, which is not interesting enough. We wanted to come up with a little fun metric to figure out the scope in general. If I'm not on currently, we are on 25, but the last calculated one was about 22 round trips to moon per month. That's the distance our drivers travel. Now, all of this is still fine. We basically launched in January 2015. This is roughly 20 months to do all of this. This comes at a really heavy price. This is massive chaos. This is not beautifully done. This is worlds of problems in that. What I really wanted to share when Zanab called me that cake. Can we do something from Gojek? Gojek is sponsoring this. If you can just share your experience. The difficult thing to pick was, what is it that we talk about primarily because Meta Refresh is such a varied audience. As we were introducing the product stream for the first time, I thought let's just talk about that. Obviously, if it was about design, then I wouldn't be here. To get that context, how many are product managers or people who are running their own startups are involved in making decisions on a day to day or a weekly basis about where the product is going to go? How many product guys? That's eight or nine. I hope everyone else as well finds this interesting. Happy to talk about anything else as well outside, but let me get started. Even on the product side itself, the learnings that I want to talk about is not about how to get a product market fit. I don't know about that. How to really grow fast. It's completely market dependent. The only thing that I can actually share over here is what is it that we did, which actually slowed down our progress. Once you hit a product market fit, any startup, any product goes through two phases, before product market fit and after product market fit. There is a world of difference between these two. What really happens after you have hit the product market fit is the only reason you are not growing is because of your company. That's literally what it translates into. What is it that you can do to make sure that once you hit that milestone, whatever decisions you have taken in the past or how you are going to go ahead in the future does not slow down your progress. That's what I wanted to focus on. Very simple learnings in this case where build for future versus releasing fast. I'm just giving you an overview. We'll get into the details of each of these. Proactive product refactoring, build versus buy and your internal customers are important too. How many are engineers over here or come from software to background? Refactoring is not an alien word. Another background over here. In product management, there are no real black and white calls. There are very few such decisions which are black and white decisions. Most of the guys who got hired into startups as product managers, the way I got as well, weren't there when the company started. Or even when the company started, there was no product manager role. Either you were a developer or you were a designer or you were a sales guy or someone like that. All of these people come together and decide how the product is going to run, how it is going to be designed. What you need to have a product manager is when you want to have a considered judicious calls about how do we do this. There is no clear solution and that's when you really hire a product manager, which means that everything we talk about over here, there are no clear guidelines. There can never be. It's just things to think about. Let's start with this. Building for future versus releasing fast. This seems like a very trivial topic that obviously you want to build for future and make sure that you're not going to do any rework and stuff. But when the pressure starts building that your competitor has launched something, you need to release something. There is another issue and there is a payment gateway that you need to fix and then you release something. Over there, you are constantly trying to release as fast as possible and that has to be the goal for your company. The other extreme on that though is that you want to release for everything. You want to build a feature for everything that can potentially happen, which obviously is impossible, but a lot of people try to achieve that. Unfortunately, I did as well. So let's look at the spectrum. We have just enough for now, which is literally what I know today. I'm going to build that, release it out. It can happen really fast. Other is what I talk about a ludicrous one. I see three gaps, three points in between. One is just keeping it flexible. What it means is very simple, simple practices, like if you are planning a mobile application, by the way, Gojek is a mobile only application. So a lot of what I'm saying would come from that perspective. When you're designing a mobile application, please don't keep any logic on the front end. Seems 101, but has bitten me back badly. Don't keep your assets, your text, everything. Don't keep it hard coded. Either take it from configuration, take it from the back end, wherever you want to take it from, but don't hard code it. Like for simple changes to your application, you will have to have another release. And obviously on Android, that option rates are really bad, which means that 90% of your consumer base is not going to get what you're releasing now, although they could have if you had just taken two minutes to think about how to package the whole thing. This is very easy to do. And as a product manager, this is something you should be doing all the time. Look at what the product is, like what the feature is. Think of all possible branches in which this can grow. I'm not even talking about roadmap. Roadmap is linear. This is like a complex tree. It can go in any direction. Just keep it flexible. No extra development effort, just half an hour of more thinking. Then you want to keep it configurable, which I was talking about as taking things from remote config, having your variables being configurable, that will really allow you to play around with your product without troubling your designers or developers. The last one is a pluggable, which takes a little more development effort, actually. But depending on what you're releasing, this can be incredibly useful. For example, if you are launching one payment gateway integration, if you can design it in a way where you add another payment gateway and it starts working, beautiful. Yes, but that takes a little more development effort. There is really no excuse for any person not to at least get at least this level, the configurable part. Let's take an example I mentioned already. When you're accepting payment, accepting payment, this is basically online payment. Initially, when Gojik started, we used to take only cash. Then we added GoPay, which is yet another way of paying for it. Now, are you going to add more payment methods there? Do you want to block any of these based on some metrics? Maybe there was a vulnerability on a particular version. There was an issue with some integration. There was a problem with a particular service. How do you provide or should discount in many ways? Obviously, whenever you are promoting something like GoPay, which was our own product, you want to give discount. Now, when we began giving discounts, we were giving it on only one way. That is like a percentage discount with some text over there. The first cut that I got of the product was hard-coded discount text. Dude, what happens when I move from 25% to 30%? That's a basic one, but it just goes on and on and on. You really want to make sure that you are thinking about how this product can potentially evolve. Make sure it is flexible enough that it can take your imagination and run with it for a long time. The key goal I believe is just this. Make sure what you are pushing out is the most flexible system for the lowest possible cost. That's where the judgment comes in. It's your call where you draw the line. Now, how do you do that? Most important is unless you yourself come from a tech background and know exactly how all parts of your systems work, you will never be able to decide how exactly it can be achieved. It's going to be your tech team who will be able to tell you or your designers will be able to tell you how we can actually do this, which means whatever branches that you're talking about, what you're thinking about, please communicate it clearly to each of your team members and ask them if you want to do this. Is it possible for me to get to the state without doing much development just by configuring things, just by pushing things, having some toggles in place? It's really them who are going to do this. You are just an enabler in that case. Things like web views. I don't know what the UX standards on that are. We should talk about it later on. But for certain pages, we have a way of topping up your GoPay account. We went ahead with web views over there rather than a native implementation because we will keep adding more and more bank supports over there. That was far easier for us to do and then I don't have to worry about making another app release or something. The load on a product manager goes on massively once you start following these practices. This is an interesting one actually. Things go wrong all the time. When we talk about configurability or when we talk about being prepared for the future, we are generally thinking about the positive scenarios. Quite frequently, negative scenarios come into play and you need to be ready for those as well. For example, let's assume that we launch some sort of a payment gateway or a top-up mechanism and that has an integration with a bank. Once you launch and once things start scaling, the bank gateway goes down because they can't take the load that you are really pushing at them. What are you going to do? Are you just going to keep things out there and let every customer feel that whenever I do something, it crashes because the customer doesn't understand why things are crashing. For them, it's your product which is crashing. For them, it's your service that is not really working. You need to also think about the contingency scenarios and have a plan for how you are going to roll back or how you are going to communicate with the users when things go wrong. You will have security vulnerabilities in a certain API version. For example, you are using v2 and v3 for booking a ride. You are on v7 at this point, let's assume, and you realize that on v2 there was a security vulnerability that you need to address and that's leaking some very critical data. What are you going to do? It's a mobile application. It's out there. I want to just shut down the whole thing. Are you going to shut down those APIs and how are you going to communicate to those users? They are not going to read the push notifications that you are sending to them. Their application just stops working. You need to have a way of force upgrading those people or giving just that user-based warning that please upgrade. Come to this version. There is a problem in this version. Have a very seamless way of moving from whatever the current state is to the future state. I'm just giving examples. In your products, things can be different. Things failed will be very, very different. But please go through all the negative scenarios as well. And if there is an easy way of addressing those, please invest in those. Because this is where you will spend a massive amount of your time. When you are working, when you have actually hit that hockey stick, you don't want to be bothered by these things. You don't want to be bothered by all the problems that are coming in and they are going to come in purely because of the scale that you are hitting. Purely because of the PR focus you have on your startup at that point. We had an interesting one actually in this. So we launched Gokar application. By the way, Gojik is, as you would have learnt outside on the boots, we primarily do two-wheeler transportation. Be it courier, be it food, be it groceries or people. That's where most majority of our drivers are. But we wanted to launch four-wheeler transportation as well. Now, when we were ready with the app, we had submitted the app to the App Store. Hadn't published it. Our backend systems were not ready. We were still waiting for testing a few things. It was about two days before we wanted to launch. And somehow by mistake, the app actually gets published. So nobody's ready. The PR statements have not gone out. People think it's some sort of a secret launch that has actually happened where we just weren't ready. And because of some complexities about the app store policies and stuff, we could not roll it back because rolling back itself would have taken us around four hours for some reason. The whole company was working on it. It was not possible. So we had to take a call as to, hey, are we just going to go live? We finally went live. Just last minute shuffled through everything, made things happen, and we went live. But after that day, whenever we launch something new, we basically have a toggle to kill things. So whenever we launch a new product, everything is switched off from the backend. I will launch it. Once I know everything is stable, then I'll enable it. So we learned it's not that I had planned for this, but even this kind of thing can happen at any scale in your company. It's not that just because it's a big company, everything goes goody-goody. Quite the opposite, I would say, actually. So be ready for absolutely anything happening because everybody's evaluating you at that point. Build versus buy seems like a very boring topic, actually. You're just basically figuring out if I'm going to use a marketing solution from outside, or I'm going to build it in-house. But as a product manager, this is where you decide whether you're going to spend two months building your own product or building something else. If you are going to buy from outside, you will have to continue supporting it for next one year, two years, you're going to have data blockage over there. So this is probably one of the most critical choices you will be making as a product owner. As a product manager, for the team. The considerations that you want to have when you are doing something like this is as specifically in the earlier days when things are not sorted out, I would personally incline towards the buy decision rather than the build decision. As you start maturing and you even understand what does it really mean for me to actually have an advertising platform or a recommendation engine or anything else that you're building, only then think of building it yourself. Because many times what you perceive it as the system that you're building and what it ends up being can be completely different. So especially if you come from engineering background or your engineering team is very accuracy in general, you will end up making the build decisions, which may not be the right thing to do in this case. So let's take a scenario of you actually hitting the hockey stick. In an ideal case scenario, what you want to spend your 50% of the time on is to actually maintain the current system, support things, take care of bugs and you want to spend 50% of your time on building new features, acquiring new markets, experimenting with new systems. What would happen in a general case scenario is you'll spend close to 100% of your time just firefighting because you haven't really designed the original systems to hit the scale that you had actually hit. Which means you're really, really... you're really short on development bandwidth or management bandwidth in general. In the worst case scenario, if it's really taking off, then it's just going to be horrible. You won't even have enough time to take care of all the things that are going wrong. This is all normal. There is really little that you can do about it. The interesting part over here is at the same time, you have internal stakeholders in the company, your finance team, which has some finance portal and some basic accounting parts that are there. You have your customer support team which is doing your daily customer support, like taking Zendes tickets and answering those customers or drivers refunding the tickets, figuring out where the lost items are. There is a business which is running as usual. Now, when all of this is happening, how much time do you think you're going to spend with them to fix their problem? The intuitive answer is just no. You don't do that. That, yes, makes sense in the short term because you want to put out some fires. But as you start putting out those fires and you scale up, things can get really ugly, really bad and the whole system can stall because you did not support these auxiliary functions. So as a product manager, yes, all of this is happening. It is important. Please pay attention to your internal customers. Who are these internal customers? Generally, these customers are your ops teams, customer care, finance and accounting, recruiting. If there is one thing that you are allowed to get distracted by, it's recruitment. That is really what's going to break your company or your product. Marketing as well. Let's take an example of customer care, actually. I think it's very common everywhere. So you are at a level X, right? When you build your customer support team of, say, 20 people. You've got a Zendes license. You are talking to your customers. You are paying a lot of attention to how the customer care team is set up, what kind of data they have access to, how they're talking to the customers. And then, overnight, you go from X to 1000X. You had set up some systems for these 20 people to work. Obviously, you have not done every possible automation needed because you had no idea that it would be needed. What happens to these 20 people? They will still scramble around. They will get some guy, like, they will start prioritizing. They will start prioritizing tickets about, oh, this ticket is more important than the other one. All of this will happen. They will hire, like, maybe 20 more people or 30 more people. You can't hire, like, 200 people. And start dealing with the problem. But that 1000 is going to very quickly go to 10,000 and 1,000,000 and 2,000,000. If during the 100 to 1000, obviously it was not easy on you or on the infrastructure on the dev team, right? If you're not paying attention to the customer support team at that point, when you go beyond, say, 1000 or when you go beyond 10,000, what's going to happen is your app ratings will start crashing down and people are not now worried about the app rating. They're actually saying that, hey, your service is so bad that I'm not able to get any answers. So I'm going to downgrade your app. Once that starts happening, you will have your PR issues. Your competitor will actually jump on to that. Pretty much your whole system can stall because you did not pay attention to this. The same goes for finance. Like, you will be getting into next fundraising rounds. You need to make sure that you're managing your finances well and your cash flows well. Please pay attention to this. However bad other things are, right? It's very easy to ignore it and this is really what can take you down even after you have found a product market fit. That happens so many times with so many companies, right? It's not even funny, actually, how bad this can get. This is where I'll take a little more time. Refactoring is... So I come from an engineering background, which is probably why this came very naturally to me. It's just taking a system and it's taking a system is just taking a system and breaking it down into the correct abstractions and making sure that those correct abstractions are working fine, right? It's very simple and we do that intuitively all the time. When you start any product, you will see that, hey, my mobile application is one product and there is a product manager for it. You are the whole backend system or the overall product is like one product. There is a product manager for that. And then you will pull out maybe a user communications system, right? Which takes care of your push notifications, emails, everything. You will put up a product manager for that. It's something that every one of you, irrespective of which background you come from, will do naturally because that's just logical. The key learning there, though, is before product market, we have one product manager, if at all, actually. After about two years of struggle, you will have like a very complex system like this, right? You have like unknown number of internal products and you basically have a travel location service, customer owner, auto management system, notifications engine, travel rating service. All of these will become your very detailed small, small products and that's how every company operates, right? Like even within a notification engine, if you go to a very large company, like say Facebook, I'm sure they'll probably have like a 20 product managers over there looking at each nuance over there. Now, what I wish I had done differently is you're going to get there one way or another, right? It's like having a kid, like either you can ask the kid to walk from point A to point B or you kind of drag it, kicking and screaming. What happens with most of the companies, you get dragged, kicking and screaming to get there, which means it's inefficient. So what is really important is once you know that you are hitting a product market fit, please be proactive in building up the structure, right? Start proactively splitting out your products, delegating it to other people, make sure that they're working on their own. Now, in a very larger context, it's very easy to imagine what a product is, right? But once you start splitting down into these levels, what do you even mean by product? So I have a few examples on this. Generally, when you're talking to your tech team and assuming they are following what is the current latest and greatest in the trends in general, you will start hearing words like microservices or service-oriented architecture or like asynchronous systems. These are services, right? Which means that let's take an example of a driver location service, which is what Uber would need or what we need is, at any point of time, I need to know what is the location of the driver. It's very simple. So your engineer will recommend you that, hey, let's just build a separate system that will scale on its own, that is going to have a different text tag, it will have its own different database, it will have its own load balancers, all of that is correct. He's absolutely not wrong anywhere, by the way. I'm not really talking about this, this, that. But as a product manager, what you think about that service is, where is it going to be used? It will be used to show the drivers on the map. Let's just take an example of Uber. You basically see various cars on the map, how they're moving, that is one use case. Then you will need that same service to tell you, which is the nearest driver from your location, where you are actually making the booking. You will need the same service when a driver is going from whatever location is at, to your location when you are waiting for him to pick you up. There will be fraud There will be fraud prevention systems or fraud detection systems, which will need the driver location as he is projecting to know if he's really fooling the customer or maybe he's just trying to simulate that he's over there. A lot of things happen, you can get into fraud later. That is what, as a product manager, you look at. Now, if you have a dedicated product manager to look at that as a service, rather than just pulling it, look at that as a product, rather than just looking at it as a service, what's going to happen is you will start thinking about how to optimize that part. For example, in case of a driver location service, it's just like a backend code base which sits with a database and some server. But once you start looking at it as a product, it is everything, which means it's the SDK that you're installing it on the driver app. It's the SDK that you are potentially installing it on the consumer app or on the, giving it to other services. It's the logic that you have or the rules that you have to capture these locations, which means you will start thinking about how do I make sure that I get the most accurate location without draining my driver's battery. How do I make sure that without putting too much load on the system, I try to find as much accurate location as possible at different states, like the frequency at which the driver needs to update the location when it's stationary is different than the frequency at which he needs to update if he's moving. And start getting into all of these have rules around if he moves from point K to point B at like 200 kilometers per hour, right? Obviously he's faking it. So, is something else happening? Flag that driver location. Figure out what other, you know, if there are other markers which tell you that there is some fishy behavior happening over there. But all of this you will do only if there is a dedicated product manager looking at that one piece. Now you will get there once your driver fraud rates go through the roof. Let's say, right? You will think about it. But the cost that you're paying during those three months of four months where you learn that I need to do this and I have losses and my customers have had bad experience. That is really the cost that you that you are paying for this if you do it reactively. So the learning in this case is let's try to pull out all of these smaller, smaller internal products, have dedicated product managers, not just engineering teams, have a dedicated product manager for those as early as possible. And obviously this makes sense only if you know that you're hitting that hockey stick and things are going to get chaotic really fast. In the earlier phases, it's completely useless. Same goes for user communication service. I'll just quickly cover this standard, right? You are sending push notifications, you are sending emails, you are sending snail mails in actually for certain financial for certain financial companies you are making calls. All of this data is there. Yes, you can have a very simple stupid codebase which takes care of this. But is there anybody who is looking at that, hey, this particular person responds to remind us on push notifications better versus the other person responds to remind us on emails better? Right? So you have a certain segment of people actually respond to better on emails from morning 8 to 10, whereas some other set of people respond better between evening 5 to 9. So is there someone who is dedicated thinking about it? If not, you will start thinking about it when your conversions really go down. If you are able to create these product teams upfront, you will not feel the pain, you just start seeing benefits from day one. So I think as a product manager specifically for a company which is making that transition, if you go down this path your overall friction over a period of next 6 to 8 months will be very, very low. I think I really moved fast. I still have almost 10 minutes. Any questions? Hi, great talk. Thanks. I just want to ask that when you say that you divide your teams into smaller chunks of teams. So how do you manage the friction between those teams? There may be a part, for example the customer care you said. So say the order management team or something decided to give them some feature and which the customer care is not able to perform well. So how do you manage this kind of friction between these teams? Or between the product managers as you said? So one is it's not really one team giving feature or giving something to another team. It always has to be a product manager who is looking at one aspect of your business and then talking to other aspects saying that hey we need to change certain things. Now the conflict over there happens like if there is a conflict fundamentally we are looking at wrong optimizations. That's how I would actually put it. Yes there will be certain things which are difficult for a particular team to do but as long as both of them collectively are looking at global optima saying that hey how do I make my end customers life better? How do I increase my throughput over there? How do I reduce my drop rate that is there? How do I increase my app rating on the Play Store? The conflict over there should not be there in our ideological sense. It will be there in terms of resource allocation. Yes like do I have enough people, developers or QAs to work on something and release it and that always exists all the time over there. The way to take care of that is de-paradise something else and that's a tough call and which is why I'll just go back to the previous slide saying that everything is a judgment at the end of the day and whoever is a product manager over there has to take the judgment call saying that what do I think is the best for the company as a whole? Not for my product, not for my team, for the end customer. What is better? I have a question. Nice talk by the way. I had one question about one of your slides where you mentioned that do not put much logic in the front-end side. There are basically two schools of thoughts here. One is about the applications with everything on the back-end side and the new thought is about the single-page applications where you provide much better use by having a lot of your let's say half of your logic or validations on the UI side. So for a product which is struggling to jump into the market like struggling to really retouch as soon as possible what are your thoughts about these two options? One is, is it really difficult to put that let me actually caveat my statement right? It's not possible to have the front-end as a pure dumb view layer. Obviously that's not possible and you will end up creating a monstrously ineffective product if you really go down that path. While saying that is it really difficult all the time to push that logic in the background or have that decision or assets coming from the back-end have it cached if you want have it like cache updated every one day or something or one month is kind of impractical but one day if you think that I need to really read it from the file system to have a certain transition with certain efficiency or whatever UX guidelines that I have do it that way if that is required. If it is really about validations see if the validations themselves can be pushed to the back-end where I actually make a call and get certain data if it is absolutely not possible then yes. Now coming to the last part of your question is to depending on which state the product is in, if I want to really push it out to the market then should I do this or not really worry about optimization because I don't know if I need that much flexibility or not. That's a judgment call I can't really take that call for anyone. In my experience it has been relatively easy to have a lot of these things done within Gojek. Gojek is unfortunately the only mobile app that I have worked on I come from a, I have primarily worked on web apps before that. So all of my context, knowledge, problems, everything is heavily influenced by my exposure over here. I'm sure there are use cases where you can't really put this logic on the front-end or sorry on the back-end then yes you don't really have an option but yeah, please try to move as far away from as possible from hard coding anything that you can't change later on if you want to. So you started this product in 2015 that's correct right? We launched the app in 2015 yes it was actually like it was a call center based company the way Meru started in India for almost four years but with very low number of drivers it's like in 2015 when we launched the app if I'm not wrong we had either 200 or 800 I'm not sure 200. So your app is hybrid or native? It's a combination so there is no one, yes it's a single application in Play Store but as you can see there are 11 services already few of those services are hybrid, few of those are native but I would say almost 80% is native. So how do you take this decision when you have to go to native and when you have to go hybrid? I mean we always keep having discussion which component we want to go hybrid or which one we want to go native so that's a very, I know it's a debatable topic but if you can give your insights that when do you decide to go native and when do you decide to go hybrid? Absolutely happy to. The considerations for me over there I take it with a pinch of salt because this is heavily biased from the business side which means I need tech and design to push back on me where I'm not making sense so this is those this is just my take It's a function of how awesome an experience that I need for my current market versus the cost I'm paying by losing efficiency by increasing the app size by potentially adding more chaos to the overall code base so similar to the scale that we had around when to build I would just see the same scale and have my gut feeling around that hey if it is going to give me let's say like 0.5% of my business I don't want to add two more MB to my application and you know increase the threshold at which users download my application or potentially have bugs which are going to crash my system or potentially have security vulnerabilities over there so I would rather not have that at the same time it's a function of what kind of application is it like am I just submitting some form to get some service for example we have go clean where you order for a cleaner at home immediately right it's just submitting form there are no complex interactions over there whereas if it is food I want people to browse through like a lot of restaurants over there and go through menus select something so for go clean I'm actually more than happy to have net non-native implementation, hybrid implementation or even just pure web view to be honest whereas for go food I do not want that right because you don't want to launch something where people don't take it up because it's bad because the user experience is not good so it's really some sort of middle ground between all of these plus mine UX and developers inputs yeah I've had similar learnings from razor pay I think my question is more towards prioritization so most startups tend to work in a crunch mode right you as a product manager you never think that you have enough tech bandwidth to do all the things that you want to do right what if let's say this scenario where you can either refine a particular feature and make it 10% better 15% better maybe the experience becomes better for your users but it still works it's not a broken feature versus making something new you have to prioritize bandwidth between these two things how do you go about that okay so I had to struggle a little to come up with a formula for that because with 11 products we run into that all the time basically so the formula for that the way I look at either features or any of these end results is I personally start from my market then from there to customer segments assigning what is the weightage for these customer segments and for which of this customer segment what is the importance of this feature and then have an estimate about and again we can come to what that means to even have an estimate right just don't want to pull a number out of thin air but have an estimate for what is the impact of improving it by 10% and even that 10% is such a subjective part versus adding something new which you haven't tested whereas we know what that the current drop off rates look like let's assume that I know for a fact that my search while looking for location search whenever my location search is take say two seconds to load there is a X drop off it goes to three seconds there is a X plus Y drop off I know that for a fact right so over there if I do something which is going to pull down for let's assume for lower end android devices that always happens I want to shave off that Y and get to X I pretty much know exactly how much market share I'm going to gain right and that certainty also actually comes into picture over there for new features that I'm going to add we'll need to figure out how we're going to even estimate the growth that we're going to see because of those so I would actually say that have like a 10 or 20% budget for such experiments which is going to help you make the larger decisions of prioritization so it really boils down to having a separate bandwidth for experiments which are going to give you inputs in your prioritization which will really give you a 20% and again that 80-20 is like a random number but what works for you depends on how mature your product is or how mature the ecosystem is like I'm not going to re-invent Uber to be honest I've spent like 5 years perfecting it so the amount of experimentation that I need to conduct over there is lower whereas something like GoFood because in Indonesian markets a very new product they don't even have a culture of food delivery restaurants over there never used to deliver so for people over there it's a very new market so over there my experimentation budget would be higher because I don't even know which direction the product is going to go to Just a follow up to that question I mean you still said that there is you can say in you sort of have some numbers around like there's a drop in so many customers but what if it is like an engineering backlog you know there's just something that it's become very messy and it has to be then the product manager will be like no we do not have the bandwidth we have to push out these features so how do you sort of you know do you actually take it up From whose perspective are you asking that question because I'd rather not say this is a call for the product manager right so I think the real question is for a product manager when engineering says that hey dude this is unmanageable now right how do I say that to just push for another 2 days 2 weeks and let's just get this out you the way basically I was trying to like the reason it took me a while to get to the formula that you know for the question that you asked I think the same formula we can apply over here as well at the end of the day the reason that conflict exists is there is no metric based on which you can take the decision so as long as we are able to provide that metric saying that hey anytime I touch this and I'm giving a very textbook answer over there there is a spectrum but if there is a particular module all the stories that we run over here go you know like take like 20% more time than expected then I can make a case thing that hey like look at this like this is always taking more time like give me 2 days I'll clean this up and after that we won't have bugs we won't like we'll move faster in this direction and you need to have a common metrics around which you can have conversation otherwise it's just subjective right it doesn't go anywhere so you earlier talked about breaking down your product into smaller products or services how do you go about making that decision that this now needs to be a separate thing what can be some pointers to help making that decision yes that gets too theoretical actually which is scripted altogether from here so when I look at a go right as a product right or let's take uber actually as a product in uber world actions or end goals you are trying to achieve if I ask you to describe how you use uber you will basically say that I login to uber I look for vehicles I select a certain vehicle type then I make a payment or making then I'm looking for that guy to come up then he picks me up and then he completes the trip I can give feedback this is the end thing that you see when someone describes an existing product in this way what you are really doing is saying my looking for a driver does not care how payments are being made right my login does not care about how a driver is being found or how a driver is being tracked or is being displayed so once you start finding all of these orthogonal systems all of these actually are products in their own measure because they have business complexity they need to have their own dev team they need to have their own vision they need to improve their efficiency without affecting any other part of the system but now if I really follow this it can go to end level where I'll have probably like 10,000 products within my company like including validations so for example my login does not really care about how validation is done I'm not gonna really create another product for validation right so where do you draw the line so the line for me is let's assume that you start with like 5 product managers in your company you basically see all of these systems group together all the systems which are as similar as possible to each other and call them one product that's really what we do intuitively anyway I'm just putting a structure to that once a certain part either starts getting very complex that someone needs to constantly think about that right again going back to why I say that you need to do this proactively is once it starts becoming more complex very likely you're already late which means your business is paying price for it that product is well integrated like badly coupled with other parts of the system which means pulling it out is going to be very difficult like the boat has already left in some way right but that is 99% of the cases but once you start seeing either things which are getting complex the module the team that actually handles the module it is getting request from multiple sources sales comes and tells them something maybe even within our application for example go ride will tell them something go food will tell them something and they are getting request from different peripheral systems very likely that has an existence of its own right that's another indicator that this needs to be a separate product yeah these two are at a higher level one of the best things that you can actually do is talk to your teams your teams will suggest services the dev teams because they look at the code right they know how exactly these things work so they will actually suggest that this needs to be a separate service this needs to be a separate service very likely each of these services can be a product on their one the key idea like the care that you need to take over there though is don't just look at the service and take that as a product because very likely that service with few of its consumer few of its mobile applications some BI system logic all of this put together provides the service right and that now in this case service is not the software service but the end user service and that end service that you are trying to optimize is the real product so now you have this product manager saying that hey your goal is to optimize this obviously each of these will have different metrics and so on and so forth but yes I think it's just about making the right call about where is to draw the boundaries they are always drawn in sand so like there are around 12 products which you are building right so depending on which month you ask me yes so like every product will have its own operations will be different how do you get the focus like in India there are 1-1 companies around each product so yes and you guys are like one team so don't you face problems like you are not able to go deep into problems all the time yes all the time I think that's true any company right even if I look at Facebook and just getting taking that as example you just call it a social media like a social platform the chat is a completely separate product there is a huge team working on chat the BI system over there has a different product like the post that you see is a separate product so in our case it's just that the abstractions are far more visible to the regular public but that's true everywhere it's not really special you are a very early stage cut up so yes getting into so many verticals does not dilute your so let me rephrase the question that you are actually asking as per classical wisdom conventional wisdom you should not split focus into too many things you should not try to catch too many birds you will end up not having anyone which is what we did as per the standard mobile application guidelines you should not put too many products into the same thing and don't cross 10 or 12 MB there is some magical threshold over there don't cross that we have to cross that so we have basically defied everything the rules were wrong perfectly valid rules because of the ecosystem because of the product market fit that we were able to find because of the cross selling we were able to do on top of all these products existing together the very fact that the Indonesia as an ecosystem did not have a lot of alternatives to what we are offering because of all of these things we were able to do this doesn't mean it will work for everyone a lot of people ask me that are you guys coming to India and I am like I don't think it will work over here right so it depends on the ecosystem that you are in but coming back to the management bandwidth yes it is painful but I think it is worth it I don't know how else I can answer it thank you Akash please feel free to bug him once he is off stage