 Hey all, welcome to another webinar by the Project School. Today we'll focus on the topic 0 to 1 versus 1 to end problem statement as a product manager. Before that, I'm Niveeta. I'm a senior product manager currently at Delveroo, working on the grocery, consumer experience set of things and based out of London. Previously, I started as a data scientist and actually an electronics engineer by degree, but transitioned into product management a couple of years back and since then, there's been no looking back and I worked across a couple of startups back in India, namely Flipkart, Sweeney Kyofit, e-commerce, footpeck and health tech players. That's a brief about me. Today, we will firstly focus on what are the different type of problem statements as a product manager, especially 0 to 1 versus 1 to end. What are the differences between that? How can we approach these sort of problem statement across the product lifecycle and also probably cover one to two case studies to like sort of explain the approach that I've followed and also quickly recap before we close up. Starting with what are the different type of problem statements, let's demystify that. So 0 to 1 and 1 to end problem statements generally differ based on the nature of the problem itself. To detail a little bit more, 0 to 1 means building something that did not exist previously in the same form, in the same domain or organization or a business model. Say, for example, you're starting a new business from scratch or you are in an organization that is looking to pivot to a new business model. Say, for example, Deluro starting groceries is one example and there might be other such examples as well, which helps the company or an organization move to say a different market, different scale, etc. 1 to 1 is a type of problem statement where you're basically having a foundation built in but you're trying to work on improving it, iterating it or scaling something that already exists. Let me give an example. Say, for example, you're working in a B2C organization which has a consumer funnel and you're working on optimizing one part of the consumer funnel in terms of conversion, growth, etc. Or think about a personalization problem which is a sort of a 1 to end problem statement you could say and also in terms of logistic networks or food tech players, I think improving on optimization efficiency of these logistic network is a part of 1 to end problem statement. Let's now go to how do we move towards, how do we understand these and probably one framework that we can use to understand the difference is like let's go through the product, software product lifecycle I would say and to ensure we're all on the same page, I'm sure most of you here are aware of these concepts. To ensure we are going to revisit this concept again and again through the next set of slides, it could help to align on the same points. So starting with one of the key components of a software product lifecycle is the product discovery. So this is a space where you come up with, okay, this is the problem. Is it actually a user need where you solve it through user research, you try to do impact sizing that's also part of the product discovery. We go through a couple of ideation brainstorming sessions to figure out what, how to approach this problem and probably going into like sort of prototyping usability study to like sort of mailed on on certain details of the product. So this is where we could say is all of this comes under the product discovery phase. Second is execution. So once you have had the initial understanding of what the solution looks like, you get into, okay, these are the 10 things that we want to solve. And this is how the product prioritization looks like and say things like planning it for like say in a spin, agile mode or in road map phases and also working with design software developers, DSML, in terms of requirement grooming and as well as flushing out, say QA test cases, bug bashing, backlog grooming, all of it is a part of the execution phase. The third one is a collaboration phase where it can happen in parallel as well with the execution phase where you try to work around with the different stakeholders of the business, let it be like marketing, ops, finance, business, etc. You also try to work across different cross product teams, like say consumer teams, working with logistics teams, etc. If you're in a marketplace, you have more players involved. So that comes under the collaboration as well. And also another key part of collaboration is where you keep the entire team updated, keep a progress tracker, etc. The last part of the product lifecycle is a launch and I trade phase, where we could say things around experimentation, deeper analysis, iterating on the launch in itself, figuring out if we want to expand, kill, scale, etc. And also probably looking out for improvements which goes back to your backlog grooming and also keeping a focus on consumer feedback as you launch and iterate. So some of these processes is not linear, most of these processes are linear. Some of these are like in loops, you might go from one phase to another, etc. So reason for touching upon this is to touch base on this as we go into the next set of case studies. So now let's start with a case study. This is one of the examples that I worked on and when I launched a product back in CureFit, CureFit is an organization or it's a health tech player. So I'll quickly walk you through what the business problem was, what the problem statement was. I don't go too much into the detail of the solution, but rather try to explain through a product management or product lifecycle what differed for a 0 to 1 here. Quickly, quick view on what the product looked like. So imagine we were in this was back in 2020 when COVID hit. So the business was having a lot of problems in terms of and one of the biggest business that got hit was the health, gyms, etc. So CureFit had this physical gym that was the main source of revenue. But since COVID, we had to like sort of move from the offline setup to an online setup. Firstly, that itself was the biggest challenge. Second, the consumer behavior, because not most consumers were used to the online setup and where you work out through a digital space. So business problem, what was the key focus that we wanted to do as a company and as a product team? So first thing was how can we move from an offline to an online and probably ensure we still run the business and get the revenue that we need. We wanted to ensure, a couple of things that we want to ensure was keeping the consumer experience impact and probably driving at least partial part of the revenue. So while I hope you understood what the scenario was and to go a slightly deeper into what we did end up building, one of the things of after a lot of ideation and strategic calls, etc. we landed up on building one of the biggest profitable offline mode of health offering that we were having at that point in time is personal training. So basically personal training is a set up where a trainer like works with the consumer on a one-on-one setup and it was one of the biggest part of the revenue. So what we had to do was how can we bring this to a digital setup? So this by the nature of the problem statement and the scenario itself is a 0 to 1 problem. So basically there was no online experience before this. So we had to build an entire online experience 0 to 1. Next, I think we have to like sort of ensure we continue building on the revenue and as well as keep in power the consumer experience and also build the capabilities that's required to like sort of build this or run the show on an online setup. So 0 to 1 again. So what did we build? So given from a problem statement you understand there are two pieces of play here. So one is a trainer, one is a consumer. So we had to build an entire structure from a trainer and the consumer side of view. So and some of the key components that we had to build was in terms of how can a trainer set their own slots, time booking for consumers and how can the consumer choose a slot to book. Second from a consumer experience, how can we like, they had variety of offering in an offline setup in terms of we can choose a boxing class or a dance class or a yoga class etc in a personal training. So we want to like sort of make sure we build an approach to the product which made sense for the consumer but also ensure they had an offline setup. So there were certain things that could not fit into this mode. Thirdly, we also wanted to ensure that the marketplace works seamlessly. While going through all of these, I'll be walking you through how the product life cycle went but without going into the solution, the problem space in itself was complex because firstly, I'll go through the five parts. So going to the product discovery phase and execution etc, what we did understand was this is not the eventual, at least from my experience, having worked in mostly one-to-one sort of problems, zero-to-one differed basically because you did not have the foundation behavior that you needed from a consumer side. So starting with product discovery. So always I think what helped us like sort of nailed down on where do we start with building the solution was trying to firstly understand what are the user problems and user needs. Well this does not, this I think would be I true in most of the pieces across product management. I think this is the key focus when we had to start from zero to one while strategically we wanted to build in something that came from offline to online but on ground what we understood was users are not used to doing this on an online setup. So starting with actually what the problem user problems are and the user needs are and second, doing an intensive market research solely because it's a new concept. We did not know if there was a market for this. Second, because we do not want to build something that we had a hypothesis on but rather is there a need for the market or something around these lines. Has this been done anytime in the past like market research helps us understand all of these aspects. So basically the market size, total address of the market etc. These two parts should be a key focus in your product best of the piece. And the third one I would say while doing this one of the thing that we had understood was given this a new idea like there was always idea paralysis. You might have heard of the term called analysis paralysis but we had an idea paralysis. What it means is there are so many stakeholders a new concept. So can we do this? Can we do that? Can we like sort of bring in this new innovative idea? All of these had was a part of our product discovery phase as well. But what did we do? We had to like sort of firstly as a product manager, I think it's very, very important to set the right set of product goals and philosophy or product principle that you want to achieve. And for us, we nailed it down to one key aspect, bring the offline to online, keeping in power the consumer experience. So the first key aspect was to first start driving revenue and then building on innovation later, right? Like innovative virtual experiences later. So that was very, very important. And second, we also had to like sort of align this across the team, which wouldn't be that the tech works differently from the marketing etc. So I'll be touching upon this as well as we go down the other slides. So I think it's important to align this across different parts of the business. So I would say to summarize the slide, I would say keep an eye for product market fit. When we mean product market fit, I think there's a term that would be used across. I think 0 to 1, one of the ways to say yes, the idea worked or the hypothesis worked or the solution worked is through ensuring product market fit. When we say product market fit, it says yes, there is adoption for this part of your service and consumers actually like it. And for sure, I would refer you to a book called Lean Product Playbook by Donaldson on because he's detailed out the product market fund very, very in depth. So coming back to product market fit, one of the key aspect again is to figure out if you have hit the product market fit and one of the metrics probably that could help you drive is retention. So once you have a recurring consumer base, it's when you can like sort of say and that number differs for different businesses, but you have to have a benchmark and that's when you say yes, 0 to 1 is sort of clicking in. Second, from an execution perspective, I think one of the things that we had faced with when we built this challenge is we had to shift fast because we were already coded when you was getting hit. So we had to like sort of get back on the ground with the online experience as soon as possible. And this is where one of the two framework that helped us firstly like how can we use re-use existing capabilities and which is why all the more it's important to build your tech and work with a tech team to like sort of build capabilities. So we had to like sort of go through the entire consumer funnel and services to understand what are the existing capabilities that we can use in a quick manner, of course not completely hacking, but like in a quick manner so that like we get to the minimum viable or minimum allowable product as soon as possible while iterating on it. So we wanted to get the early feedback rather than wait and build an exhaustive product. So that was the first step. Second, I think on the capabilities piece, some of the times you might have neat things that you might not already have like especially when we're going online and virtual. So we had to go with we couldn't build that like there is a choice to build versus buy. So it's always a complex decision, do we want to build it in-house or do we like sort of work with different SaaS players to like sort of get this going. And this is a key aspect in 0 to 1 and whenever you're in a decision dilemma and like should we spend in so much time, it's going to take so much effort but it's always scalable. I would surely suggest going via this curve to figure out can we do a buy versus a build. So that helped us a lot. Second, in terms of requirements, I think it's so easy in a 0 to 1 to like sort of get scope creeped while it's common across but it's more common in 0 to 1 solely because of the sheer amount of ideas and probably ambiguous nature of the problem space which is all the more reason as a product manager it is important to have focused requirements. What is the exact requirement and what is it driving as a goal is something that we need to be like really, really crisp and clear on rather than like trying to figure out like different hundred different parts of the service in itself. Third, I think while agile sprint sort of a mode works for most of the businesses, I think being flexible in the way that you work towards a 0 to 1 will be really helpful. You're working as a start in a startup mode. So you wouldn't want to have this set two weeks, three weeks time frame and you want to only work in that time frame. So you might want to be like sort of agile and flexible in some of these concepts or methodology in which the team works and it should and I think it also helps to like sort of reprioritize and kill ideas as soon as possible rather than waiting for the entire build etc. So I think this was something that we had to as a team get into as a process for while we built we will be shifted from non-covid time to a core time and like sort of ship faster. So that helped us. Third in terms of collaboration. So one of the key aspects in 0 to 1 is that we need to work with different aspects of the business and one of the key things for sure as a product manager is you have to wear the hat of a product marketing and plan for it since day one when your idea launches because there is no point of working and building something the consumer need but you do not know how to actually when you build the product go and sell it to the consumers or get the traction for that. So you need to build your product marketing from day one and also probably think about what are the different ways in which your purchase model works is it going to be a premium is it going to be a premium etc. to ensure that your revenue is also in place and you're not always offering a free product. Second I think in terms of collaboration one thing that could help in a 0 to 1 when you're working on big bets etc. is small and focused teams rather than like trying to have multiple teams typically a nature when you have bigger teams so you have to work across different cross teams and this sort of a structure could help reduce clash on the road map puritization etc. and you as a team work as a pod in itself and that helps reduce any overlaps. Third I think as a team I think it's important to be aligned on the philosophy which is what I touched upon briefly in the previous slide as well. So in terms of collaboration I think all of the team members like including the business counterpart should be aligned on what the outcome is. There's no point building something in a product and then product marketing is using some of the concept and the whole thing goes for a toss and in fact this is something that we learned from experience and when we did launch the first version of it we had slight challenges or changes in terms of what we were trying to market versus what we had built as a product so we had to learn course correct on this so it's important to keep this from the start on the launch phase. One of the important things from a 0 to 1 is being able to explain learn iTrade so this look keeps continuing as long as you sort of hit your PMF and your goal metric and as a team it's important to like have this philosophy rather than like say okay I've launched I'll move on to the next one so that is a big no for a 0 to 1 I think as a team you might need to have this mindset that we would be like sort of experimenting learning iTrade and killing wherever required and that look keeps continuing so I think as a team when we were aligned that we had said these processes as a team I've said this process that like okay let's do an experimentation but we should be willing to like sort of course correct learn iTrade on top of it and being very specific on what the experiment success looks like is very very important second in terms of launch given these are more high level big hypothesis that you have ensuring you reduce the blast radius is really really important so when we say experimentation and blast radius I think these are running like say in a small subset of consumers or a small set of market so when we did launch it we had this key market that we had in a part of a city in India and we had to like we tested all our hypothesis in one specific set of location in couple of areas so and that helped us like sort of hypothesis course correct and reduce any impact negative impact and reduce the blast radius as well third in terms of innovation I think one of the key things that's really really important from a 0 to 1 is you have to have your early consumer feedback on every stage of your journey so you can like sort of think about what are the different innovative ways to get consumer feedback and one of the things that we had built in was we were completely tied up with the consumer support team when we built the entire entire product we were always in love with the consumer support team in terms of trying to get any feedback that comes out with respect to this particular product sent to us working on all of these feedback anecdotal etc so that was one way another way we tried to do was we had regular workings for consumers to like sort of say Thursday consumer chats and we used to bring in consumers and like we used to like sort of talk to them and actually going and specifically talking to ad treated users I think it's really really important because you get your early feedback as well as you understand what's not working with it with your service and also one more innovative way we tried to like sort of go is through a CRM mode so basically like sort of getting as much as survey in possible across the consumer journey so consumers were interacting with trainers so can we like sort of pop in user friendly and easy to use surveys and like sort of get more feedback as soon as possible so that was the third point and the fourth point was I think set and track your key metrics like a hawk so I think it's really really important to be on top of your key metric and also defining the right set of metrics for your launch and that's up to the product teams and the DS team to like sort of work together to like figure out what are the key metrics that you want to track so the entire journey I want to touch upon some of the attitude or soft skills that I've called like which helped us go through the entire journey firstly I wouldn't I trade this more but aligning the entire team on the key goals because the last thing you want to have is autonomy without alignment so you wouldn't want to work like you don't want the team all of them to work in different directions but without an alignment right so this is the last thing that you want to have so aligning the entire team on the key goals is important second I think working through ambiguity given the nature of zero to one sort of problems ambiguity is by nature going to be heavy because firstly as a product manager you're not going to be very clear on what exactly is the problem space that you want to work on is it going to which one comes in first versus second because you don't have an impact sizing because it's completely new so you might want to take you might take these calls which is more subjective and hence you have ambiguity and hence you it is responsibility of the PM to like sort of limit the chaos with the ambiguity and drive through the ambiguity with clarity so ambiguity can be within one layer but you shouldn't proclaim to the entire team third I think if in case you're working on a competitive space and more so zero to one problems you might want to always keep velocity as a key so basically you want to ensure you go to the market faster explore experiment learn and then course correct rather than wait for like six to one year to build something and then test your hypothesis last but not the least yeah I never never goes over like the consumer voice try to do like all sorts of consumer feedback as early as possible and through the entire consumer journey and don't keep it to the last try things around like say fake door testing so toss around if in case if a consumer is like trying to like sort of adopt to a service and we've tried it in the past and show that the pricing etc is also adaptable for consumers so that was another key piece that we had to work through and I treat multiple times after our launch so that was one learning that I would redo if I have to redo this again and yeah there comes an end to like the zero to one problem statement but I want to call out that what did we achieve after all of this right and this was a close to five to six months build and launch and I creation the first launch went with in like two months but we had to I treat and like we had a retention of close to 65% plus which is a pretty good retention number for consumers and online personal training next let's go to a next let's switch gears and move to another case study right this is I'll set up the business context again given the context switching a common problem for problem pms right so this is at swiggy swiggy is a food tech company back in India it was at that point in time serving close to 2550 plus cities but it had soon expanded to 300 plus cities or the problem statement this was pre-covid this was close to 2018 we had to work on profitability and like that was a problem statement that the company was working towards and I was a part of the delivery team which means working on team that was working with the rider side of things and so basically we want to improve on how can we like sort of reduce the cost incurred in delivery and one highlight I want to make regarding food tech is it's typically a three-way marketplace so there's a consumer there's restaurant and there's a rider so when a consumer places order so there are two moving parts the restaurant is going to be preparing the food and the rider is trying to get your food delivered so let's go into what the problem statement was right so given it's more nuanced and we might need to like sort of deeply focus on what the problem statement is like slightly more complex one so this current state was given there's a one-to-end problem reminding you we had we were across a couple of cities we had existing rider network restaurant network and consumers ordering say a few millions of consumers and the issue that we had was typically when a food is placed there's a in the graph that you can see here on the right so you have two parallel processes one process which is talking about the preparation time so the restaurant is preparing your food but you wouldn't want to wait till your food is prepared for your rider to go to the restaurant right so there's this huge intensive complex logic that runs behind to figure out which rider can go into the restaurant and pick your order and who can also deliver to you so this logic let's say it's called assignment logic so what it does is trying to figure out the best rider who can go and take your item and deliver to you the challenge that we had here though from a cost incurred while delivery is because now that the problem statement that we have is reduce the cost that's incurred in the delivery so which is the second part of the parallel line that you can see here so rider goes from a space that they are in to the restaurant that they allocated to wait for a couple of times more so times to get the food prepared and then deliver to you so basically there's a first mile which is going to the restaurant there's wait time and then the last mile so here the problem statement that we wanted to like sort of go towards and address as a part of the delivery team is how can we like sort of optimize this and if you think about it right like if you give it a thought the wait time that happens in the restaurant is completely an unutilized part for rider because you're just waiting there for restaurants as well it's just too much crowding in the place it's not helping the rider it's not helping the consumers it's not helping the restaurants it's neither helping Swiggy because every minute of wait time is paid to the rider so there's a cost unnecessary cost involved here so we wanted to see how can we like sort of go deeper into this and like sort of solve optimize for this and the way to optimize for it I wouldn't go deeper into solution but quickly touching upon it we have to predict what time the food can be prepared and accordingly allocate which is a pretty complex operation research problem and it is not just one rider right so you're going to have like millions of riders millions of consumers across different restaurants solving at the same time so you need to have it's a huge optimization problem so I'll keep the solution aside and there's this huge blog that we have written to like sort of for you to understand so do go through the reference at the bottom here but this is one to end problem and what are the different challenges that we faced here right if you observe this it looks like a backend logistics optimization problem but in fact it was not if in case we have to change anything related to the wait time first thing we had to change was for the restaurants the behavior of the restaurant was typically that they were assured that the rider is there so that they start preparing because they don't want to deliver cold food so they don't want to they don't want to prepare food and keep it and wait for the rider so when we are changing the assignment time so the the confidence that the restaurants had that we are going to allocate on time was reducing so we had to change the behavior from a restaurant side second from a consumer side think about how it gets impacted right so typically if you've placed an order on a food tech platform you would know that like as soon as you place an order you want to see the first status change on your attacking screen is it not so the first change here at that point in time at Swiggy was getting your rider allocated so that was assurance for consumers that the food is on the food is anyway going to come to them so having said that changing anything related to the assignment time for the rider was impacting consumers directly or that was a hypothesis so given it looks like an optimization problem it was impacting all three parts of the funnel and hence we had to like sort of go very very deep into every aspect to like sort of nail this down and let's go now how into how did we do that right so again I'll walk you through the entire journey and probably we'll discuss what's different from the 0 to 1 starting with the product discovery I think as you mentioned and as you went if you had observed we went from Swiggy profitability and delivery team wait time so we went so much in depth so going down to the problems rate and kneeling down to the depth is very very important in a 1 to n because you're not working on a 0 to 1 anymore you're working on a specific aspect of a specific service on a specific leg so you might want to like sort of kneel to the bottom and for you to kneel to the bottom as a PM you need the exact strategic need and detail understanding of what the consumers are what the downstream impact is etc so which drives me to the second point going deep with the current experience funnel or impact metric so trying to understand not just at a high level okay this is the wait time but why does the wait time happen what changes when a wait time happens and what is it changing the restaurant is it changing consumers how does it impact profitability can we reduce for some set of restaurants and not have it for others what's the changes there so I think going to the depth of these metrics and understanding these in depth helps so try to focus also on your impact estimation it's pretty almost most of the times you would be able to in your product discovery phase of 1 to n figure out an impact estimation okay what is the probable wait time reduction that we could get if in case we reduce say or optimize by X percent right either by a guesstimate or via deeper analysis you should be able to get an impact estimate and why it's important it's important to keep your focus on one specific metric and track it keenly to ensure you're not deviating from the main topic right and third thinking about scalability is really really important if you need say for example in this aspect while we were building this logic Swiggy was growing from a 20 to 200 plus cities we wouldn't and it took us six months and like six to nine months so in that time frame you wouldn't want to build something that's just fitting into the current scale you want to think about scale and keeping scale in back of the mind is very very important in 1 to n problem statement so for summarize I think I am for the specific goal and having defining the right set of target metrics is very very important in 1 to n I'm going to the depth second from an execution perspective I think one mindset that held us was what brought you here may not take you to the next step so we didn't have what it needed for Swiggy to deliver food and almost all the time like was a good one with a good consumer experience code but what are we trying to do here we were trying to optimize on top of it without impacting the current baseline so what took us here did not take us to the next step which is why contradicting to the 0 to 1 0 to 1 you want to try to reuse existing capabilities because you're testing and shipping it faster here you might want to like ensure what's existing now may not take you to the next step so trying to build on intelligence and capabilities intelligence here might be things around say here it was an operation research problem and optimizing on top of it and bringing more innovation was one step right second trying to work and plan for enhanced metric like and also trying to ensure what are the trade-off metrics given you already have a baseline experience built you're trying to whenever you're trying to like sort of build something say growth versus profit etc you always have a trade-off right so which is why it's important to define the right set of success metric and check metric when we say check metric what is the non-negotiable for your changes that you're trying to do so here for us it was we're trying to improve on the profit or the cost per delivery but also not impacting anything related to the consumer experience that a restaurant or the consumer or the right experience right so we want to keep that intact as much as possible but also defining the right set of consumer metrics you cannot always track okay if the consumer experience metric was how many users got it within 30 minutes or 40 minutes should not be the only number right now because we're trying to optimize probably before 80 percentile of your users we're getting it within a specific speed but now you're trying to optimize for the entire network while the average might remind similar or even higher you're impacting the NTN network so that was a key aspect that we wanted to like sort of try to work towards and also align leadership and stakeholders on this point of view because this is a changing behavior there's a new metric which actually talks about more depth about the consumer experience so we had to bring bring this into picture so I think it's important as well to go to the entire details of the requirements while this is pretty straightforward in a one to win in a zero to one it's while you have ambiguous nature of the business and you might be willing to like sort of work with a very high level requirement in a one to win I think given that you have a very very specific problem it's always important to nail down the details because it is going to take some time for you to implement and you don't want to end up with the wrong requirement at the end and take six months to build something or four months to build something and then change it right so put in as much as a PM put in as much as possible and where you had on attention to details to defining these requirements going to the depth thinking about all the stakeholders all the different parts of the marketplace if you're working on a marketplace etc third collaboration right what changes um as I said as I was defining this change consumer behavior restaurant behavior I think you would be put up with a challenge you're challenging the status quo and this is something that's always difficult in difficult situation so you might want to like sort of be very very clear in terms of how you're collaborating with different stakeholders keeping them in loop in terms of what's changing what what might have as an impact and how you're monitoring to keep to ensure that you're not impacting different parts of the business in a different way in our example I think there was there were teams that were very very conscious on how we were looking to build the consumer behavior so we had to like sort of work with them align with them and keep them in loop in terms of how we're approaching the problem statement and how we are not interacting or impacting consumer experience in a negative way second I think it's important to have you're going to have multiple downstream impact and hence it's important to have cross team collaboration early on and go deeper into the user stories so here example restaurant the restaurant changes would have been missed if in case we had not consciously tried to like sort of think through what are the different downstream impact what's impacting what's changing etc and we had to like sort of go and have specific brainstorming sessions to understand what happens outside of this logic third embrace failure you're going to have a lot of it because these are like it happens both across 0 to 1 and 1 to n but in 1 to n the problem is like you already have a baseline and it's easy for people to go back and say let's just continue as we are right and you might have that issue time and again and you might want to go back to the drawing board as a team and embrace your failure and learn from it which is where it's all the more important to build a team that has this mindset and also like as a PM it's important to communicate this with your team to understand why it's okay to fail and like sort of learn from it because some failures consistently also puts the team in a mode where it's difficult to continue further next on the launch I want to surely touch upon how this differs from 0 to 1 in a 1 to n sort of a setup you might and especially in this example that I mentioned it's an optimization algorithm it has network economics playing into it simpler ab sort of an experimentation was not something that we could go with because it's not a user level separation what we're trying to optimize is network network level optimization so what we understood was as I mentioned in the previous point on execution current capabilities did not help us and we have to build a robust experimentation methodology or a simulation platform to specifically test our hypothesis with respect to optimization every time we tweak a part of the optimization how does it change for the on the on ground how is it impacting the wait time right so in fact if I have to give you a good insight we had to go with four to five different methodologies of experimentation and we also were willing to learn from different counterparts across the globe to figure out because these were very unique problem and we were one of the first few companies to sort of figure out this sort of an implementation and also test that right so simulation is was an easier option but we didn't go with simulation because it does not actually replicate what's on ground while it's directionally good we had to like sort of build an experimentation which works at a network economics level basically one writer would be having an algorithm which is trying to optimize by time while the other does not and like it's and you can understand right so like it's a pretty complex network economics that's playing here so we had to go with being open to like sort of experiment explore different options on how we can like sort of understand the impact so that was the first step and we were okay to do this and this itself consumed us more than like six to seven iterations of how we are experimenting second on the scalable experiments um so basically as I mentioned before on the scalability aspect um so given that this is an established business you wouldn't want to build experiment that just transfer runs a lot for a long time but it's only probably feasible within a particular zone in contrast to what I said in zero to one you might want to build something that like you've tested in two to three cities but you're able to like sort of expand it to probably like the entire five hundred plus cities that are currently launched towards so the time to go to market should be reduced for short given the impact of it thought always be on top of consumer experience and this never gets old one thing that I wanted to call out here was the difference in consumer experience might be slightly more towards quantitative because you already have a scale and you already have consumers so anecdotes and sample sizes might not would be helpful but it might not be the entire picture so you might want to go more quantitative and try to figure out based on probably DS metrics analytics metrics on how the consumer experience are changing and as I pointed earlier we were trying to work on customer support and metrics around those so to summarize like what did help us with one to end I think patience, grit and resilience is key it's very very important and one to end the entire project that I spoke about took us more than nine to ten months including all the challenges that we faced at the restaurant level then building things for restaurant then building for things for riders etc and of the entire cross-collabation no I don't have to tell about that right so it did take a lot of time but it'll be very very worth it and when I say worth it we did save a lot of millions of dollars for Swiggy based on this project and it's something that's scalable so it still exists as much as cities are expanding to the logic still exists so second be ready to have a team downtime and I mean that what I mean by that is that there might be scenarios where the team motivation fails because you're working on something for a very long time it's a hockey stick success that you're going to have so you're going to wait work on it for six to nine months and then you get the impact in the last two months right so this is where you might need team members who can strive through have have the patience or you as a product manager sort of pull in the team through such time frame as well alongside your engineering managers third velocity is important as we touched upon before but velocity is not the only thing you need to have sustained gains what I mean by that is you have to keep monitoring your changes and once you've launched you shouldn't stop there so the reason why when we did launch this and they were like consistent skepticism or in terms of the consumer impact that we were creating is it negative is it okay etc so we have to have a hold out group for six months and consistently monitored there was no negative impact and that's how consumer focus we were at that point in time and last but not the least I think you need folks who can like sort of give and take constructive feedback so there were times where we were like actually in a water room and it's sort of trying to figure out what was the thing that we could have done differently and being objective about it is really really important and the learning never stops so we had folks coming in from different parts of the world like so to help us like sort of improve on our PhDs etc like especially on this particular project so that was another last point so having said all of this right these are the compare and contrast between 0 to 1 life is not always black and white right so there's always gray area so I want to touch upon that a lot of these aspects is not one size fits all so there might be scenarios where you might be working on a combination of 0 to 1 or 1 to n problems and which is one of my current scenarios so I'm currently at Delvedo building the consumer experience for grocery and we have in the last one year improved the consumer experience a lot but there's a long way to go as well and like we are working towards building an experience which has both 0 to 1 sort of a problem and 1 to n and which is where your hat which keeps shifting between 0 to 1 helps and also driving the team alongside that so when you're working on certain things which is 0 to 1 you want to go explorative and then converge but when you're working on 1 to n you might want to go very very deep and this sort of switching gear as a skill is really really important as a product manager hopefully my talk helped you and please feel free to reach out to me on my LinkedIn thank you