Why Uber’s CPO delivers food on weekends | Sachin Kansal

Everyone's always promoting dogfooding. It feels, though, that you take this to a whole other level.

Either once or twice a month, I will set aside half a day and then I'll go out and I'll drive and deliver. My team and I, we designed these amazing features. They look so good. And then you get in the car and you have a phone which is sitting three feet away from you. You're driving at 45 miles per hour. The world just changes. This thing that was looking so great in an office setting now maybe makes no sense.

When I was asking people about you and what you're amazing at, a motto came up again and again. It was ship, ship, ship.

If you are going to go dog food and experience this pain and we're going to document it, what's next? You have to ship this. You don't ship documents. You don't ship brainstorming meetings. What you ship is code in your product.

What are some of the most impactful pieces of advice that you share with early career product people?

What makes a great product manager is not five amazing strategic ideas. It's the thousand micro decisions that you made. Where should I put the button? Should I put the screen there or not? What should the copy say? Go to a job where you can ship multiple products as fast as possible.

Today my guest is Sachin Konsal. Sachin is Chief Product Officer at Uber, where he's been for over eight years and where he leads product management, design and product operations. Prior to Uber, Sachin was Chief Product Officer at Flywheel, a VP of Product at Lookout. He also spent the early part of his career at Palm, where he was Director of Product Management focused on Palm's mobile operating system, WebOS and their mobile apps. In our conversation, we go deep into his passion for dogfooding and how he makes this a big part of the product culture at Uber. He's personally done hundreds and hundreds of drives as an Uber driver and also as an Uber Eats delivery person. I have had a lot of people come on this podcast talk about dog fooding. I've never met anyone that takes it to the extreme that Sachin does. Much of what the product team works on at Uber comes from what he and his team discover from these experiences. We also talk about why it's important to always have a ship, ship, ship mentality. PM career advice for early career PMs, how Uber is planning for a future with increasingly autonomous cars and what changes over time. What he's learned from Uber's shift to efficiency and profitability. Also a bunch of really good tips for how to avoid annoying your Uber driver and Uber Eats delivery person. This episode is full of wisdom for anyone who wants to build better products, teams and cultures. If you enjoy this podcast, don't forget to subscribe and follow it in your favorite podcasting app or YouTube. Also, if you become an annual subscriber of my newsletter, you get a year free of a bunch of world class products including Linear, Superhuman, Notion, Perplexity, Granola and more. Check it out at lenny'snewsletter.com and click bundle. With that I bring you Sachin Console. Many of you are building AI products, which is why I'm very excited to chat with Brandon Fu, Founder and CEO of Paragon. Hey Brandon.

Hey Lenny, thanks for having me so.

Integrations have become a big deal for AI products. Why is that?

Integrations are mission critical for AI for two reasons. First, AI products need contacts from their customers, business data such as Google Drive Files, Slack Messages or CRM records. Second, for AI products to automate work on behalf of users, AI agents need to be able to take action across these different third party tools.

So where does Paragon fit into all this?

Well, these integrations are a pain to build, and that's why Paragon provides an embedded platform that enables engineers to ship these product integrations in just days instead of months across every use case from rag data ingestion to agentic actions.

And I know from firsthand experience that maintenance is is even harder than just building it for the first time.

Exactly. We believe product teams should focus engineering efforts and competitive advantages, not integrations. That's why companies like U.com, aI21, and hundreds of others use Paragon to accelerate their integration strategy.

If you want to avoid wasting months of engineering on integrations that your customers need, check out paragon@useparagon.com Lenny Last year, 1.3% of the global GDP flowed through Stripe. That's over $1.4 trillion. And driving that huge number are the millions of businesses growing more rapidly with Stripe. For industry leaders like Forbes, Atlassian, OpenAI, and Toyota, stripe isn't just financial software. It's a powerful partner that simplifies how they move money, making it as seamless and borderless as the Internet itself. For example, Hertz boosted its online payment authorization rates by 4% after migrating to Stripe. And imagine seeing a 23% lift in revenue like Forbes did just six months after switching to Stripe for subscription management. Stripe has been leveraging AI for the last decade to make its product better at growing Revenue for all businesses, from smarter checkouts to fraud prevention and beyond. Join the ranks of over half of the Fortune 100 companies that trust Stripe to drive change. Learn more@swepe.com. Sachin, thank you so much for being here and welcome to the podcast.

It is great to be here. Lenny, thank you for having me.

When we were exploring what to chat about and where to spend our time, there's like a bunch of themes that came up both in our conversations and also when I was talking to people that work with you at Uber and other places. And the theme that came up over and over is dog fooding. And dog fooding is something that comes up a bunch on this podcast. Everyone's always promoting dog fooding. It feels, though, that you take this to a whole other level and you do this better than anyone I've ever spoken to. You're basically world class at dogfooding. There's a lot I want to talk about here, but before we get into it, just like give us a sense of what dog fooding looks like in your world. What is the scale that you go to to dog food?

Uber, I mean, call it dogfooding. Call it just obsession about the products that we ask our end users to use and we should be using it ourselves. So in my world, what it looks like, there are a few apps in my world. There's the Rider app that everyone's familiar with, there's the Uber Eats app, and let's not forget there's a driver and a courier app as well. So dog fooding looks like the following for me. In general. On an average, I end up taking maybe five to 10 trips, Uber rides every week, which is, you know, just happens because I'm an Uber rider now. When I'm traveling, that's even. That's probably even more. I end up placing maybe three orders, three Uber Eats orders every week. Sometimes that's too much. And again when I'm traveling, that could increase. If I'm traveling with family, it can be a lot. It could be literally all our meals. So those are probably more explainable, more understandable. The volume goes up and down. But then how do you test the driver app? So I actually go out either once or twice a month. I will set aside half a day or a day and then I'll go out and I'll drive and deliver here in the Bay Area. So I've been doing that for many, many years now. I will say that's probably one of the best parts of my job. I really, really enjoy it. Doing Trips, as well as doing deliveries. And I'll do, maybe every time I go out, I'll do about 10 to 12 rides and deliveries. So that's what dogfooding looks like at the outset. That's the fun part. The painful part then is, okay, what did I learn? Because it's very easy for me to do this and then just completely forget about it, not document it, use it anecdotally in some conversation, but not be able to go into a lot of detail. So what I do after each of these instances, whether it's using the Rider app or whether it is driving, I take a lot of screenshots and then I come back and I write documents or I add to an existing document. So I have a driver document, I have a Rider app document, I have an Uber Eats document. And I'll come back and I'll just write everything that I learned that is probably not ideal. I'll add a lot of screenshots to that doc. I will tag people because I know who works on what, and then I'll just send people my thoughts on what we think we can improve. And after that, we have a process internally where we go through all of those issues. We prioritize them. Not everything that I thought is a great idea is necessarily a great idea. So we go through all of that and then we fix issues. I'm not the only one dogfooding in the company, but I do follow through on the things that I reported and make sure that things that should be fixed get fixed and as quickly as possible. So that's the sort of the end to end journey of dog fooding for me in my work.

How many trips have you taken? How many rides have you driven? How many food delivery trips have you done total? Like, what are the numbers here? Just like over your time at Uber.

I think from a driving and delivering perspective, it's in the 7 to 800 range now. And I don't know as a passenger how many trips I have done. I can't count that. And same for Uber Eats, but the driving and delivering is many hundred trips.

Wow. Yeah. I think on the riding on Uber and getting food delivered, that's not so hard. To your point. The real hard part is driving and delivering people's foods and taking them places also on the docks. I think you're also underselling yourself. One of your colleagues, Ricky, told me that you write 40 page reports on what's broken with screenshots and suggested fixes, and then you, like you said, you follow up on all these fixes, like, you don't just put them out there and then hope people do something with it. You're actually stay on top of them and make people feel accountable.

Lenny I get when I find those issues in our app, I develop a bit of impatience because if I faced it in my 10 trips that day, we have 8 million couriers and drivers in the world, right? So imagine the number of times that thing may have happened to our customers, which are drivers and couriers. So I develop a bit of an impatience that we have to fix it. We can't. Now, some things are small, some things are big. I develop different levels of impatience for different things depending on the level of severity. And then if I don't follow up or my team doesn't follow up, and if you don't fix it, then it's a moot point. Then I'm just doing it for fun, which is not bad. It's great for me to be doing it for fun, but I want to do it for impact and I also want to do it for setting an example with my team as well. Now, again, I'm not the only one dogfooding. We have hundreds to thousands of people at Uber. We want it to be a part of the culture, but we don't want the culture to be that every individual product manager should be going out and dogfooding their own feature. We want the culture to be that every leader is doing that as well. And that's why I don't want to be shy about or want to shy away from writing these documents, because I want everyone to. And now there are many, many documents written by many, many people at Uber. And honestly, it's making our products better and even more, I would say, even more important than the specific features that we fix or we add. It's the culture of, you know, you're not just going to accept certain problems in our products. We are actually going to fix them. That's really, really important.

So let's talk about just why this is so important to you. I want to talk about how you operationalize this in the culture of it at Uber. But just, you know, as a cpo, I don't know of many that go drop people off, you know, hundreds of times, deliver food to people's houses hundreds of times. I imagine you have many things you got to do day to day. There's hiring, there's drama, fires, all these things. Why do you prioritize this so highly?

Here's my framework of how we think about end users of Course, end user feedback is important. Everyone would agree with that. Every product manager, every product leader would agree with that. How do you get that? End user feedback, I think falls on a spectrum. There's the extreme quantitative end of the spectrum and there's the extreme qualitative end of the spectrum. And I like to believe that you need to be across that spectrum. So on the extremely quantitative part, we all love data, we all look at charts, and in those charts, every user is an MAU or a dau. Every user is a number. And collectively as those numbers, users are showing certain behaviors. And we learn a lot from that. And that's a very valuable exercise, right? You move a little bit to the left of that spectrum. And now you may go into things like service, where you're actually sending out surveys to thousands of riders. You are quantitatively understanding, do they like A, do they like B, do they like C? Which is also very, very valuable. Then you get into a little bit, you know, to the center, maybe. I have a room of 10 drivers and I'm asking them. It's a focus group, it's a discussion. And for an hour, I learn a lot from them. It becomes very interesting. We do this, you know, anytime I go to a Brazil office, I go to our India office, I go to a UK office. At a minimum, I do one or two roundtables with drivers. I also do roundtables with riders. It's just extremely valuable to hear from them directly. You move one step further, and now I may have a one to one conversation with one of them. By the way, in the rides that I take every single day, it's such an amazing opportunity for me to do two things as a passenger. I'm talking to the driver for 30 minutes off my commute. I'm basically one on one interviewing them. And because the driver app is placed in a certain way, I can actually see how they use the driver app. So that actually drives me a lot of learning. And every day there's an aha moment that, oh, this is what he just did. A text message came in and then he left the driver app and then he went and addressed the text message and so on. So this is a lot you learn. All of that is great. However, until I get behind the wheel or I am a passenger or I am using Uber Eats, what I miss is the visceral reaction that you get when something happens. So now think about it. I sit in my office, my team and I, we design these amazing features. They look so good on my, you know, MacBook or on a zoom screen. And then you get in the car, and you have a phone which is sitting three feet away from you. You're driving at 45 miles per hour. The word just changes. This thing that was looking so great in an office setting now maybe makes no sense, or there's a lot of stuff that you have to change, so that's sort of what you feel. But then as you are trying to make money doing that, every single little inefficiency, every single flaw is costing me my earnings. And while I don't do it for money, so I don't think I can get to the extreme, extreme end of how drivers feel, I think I can get close, and the only way for me to feel that emotion is by doing it myself. And I do think that that emotion is very important. I'm a big believer in then bringing that emotion to my work. Whether it's an emotion of joy. I have many, many moments of joy, and I bring that back, and I celebrate that, and that's very motivating for my team and I. But there are many emotions of outreach, and I want to bring that to work as well and make sure that we can use it as a motivator to do better. So those are my reasons to be dogfooding.

What's an example of something that super outraged you that you experienced as a driver, especially, and. Or something that maybe is the most surprising that you learned as a driver?

Let me start with the surprising, and then I think we'll get to the outrage part of it, and there may be things that you may not expect. The surprising thing, as I mentioned before, was how the app just feels different when it's actually in a moving car at 40 to 60 to 70 miles per hour. That was a surprise for me. The positive surprise is there's a dopamine hit you get when you get an offer. I get an offer. It's 20 bucks. I'm picking someone up from point A. I'm dropping them off at point B. There's a bit of an excitement angle, and I don't want to overplay it. Owners, drivers work really, really hard to do their job, but I think that part of our product, there's a bit of an excitement to it that was a surprise to me. I will go into a few individual features, but even at a more meta level, the thing that surprised me the most is we obsess about our app, and our app is the center of our universe. But when a passenger gets in the car, the center of the driver's Universe is that interaction with the passenger, that human touch between the driver and the passenger is something that we don't talk about in the office enough. And if you talk to the driver and when I'm a driver, if the passenger is friendly, it lifts my mood. If the passenger is grumpy, then I'm unsure what to do. If the passenger is rude, which has also happened, that can really be demotivating. I want to share one anecdote with you. This was way back, like almost eight years ago when I started driving. This was probably my fifth or sixth trip. So I was very, very early in my journey of dog fooding. So it was early morning, I think it was a Saturday morning, maybe about 7am I was picking someone up. It was a lady. I stopped my car at the curbside. She got in, she was going to the airport. She was going to San Jose airport. And she had a suitcase which she left on the curb. And she's inside the car. And I'm like, what's going on? And it suddenly dawned on me that she's expecting me to get out of my car, grab her suitcase, open the trunk, and put the suitcase in the car. But she didn't say anything. And then I suddenly realized that there is an expectation of me as the driver doing that part of the job as well. And since I was very early in my journey, I had not internalized that. And the kind of emotions that ran through me at that time just explained to me, hey, what does a driver actually go through? That was a somber ride for me. That was a somber day for me. And since that day, I have not forgotten what it feels like to be a driver. And I carry that emotion with me. And that has built a level of empathy in my mind for drivers. And I want to make sure that my team understands that's their life. And everything we build for them has to have that level of empathy. So. And I would say that was a big surprise for me. It's not just about the app. Yes, there are many features in the app that we can talk about which are also surprising. But what does a driver feel day in and day out as they interact with other human beings? Was a big one.

I love that I want to talk about how you actually disseminate this culture within the product team. But out of curiosity, I always wonder what pisses off a driver as a rider. For example, do drivers like short rides or do they like long rides? Does it not matter?

I think the short or long rides can be very personal. There are some drivers and the great thing about our driver base is there's a lot of heterogeneity in terms of their preferences. Some of them do like short trips because it keeps them closer to their home. They can make a decision to go back whenever they want. Sometimes we have incentives which if they do 20 trips, then they get something more. They are able to do that. And some of them just like a long trip because they don't want to do multiple pickups and drop offs. So I think there's a lot of heterogeneity. If you want a tip for what not to do to annoy a driver, I'll give you a couple of tips. It's totally okay for you to be on the phone. We have to do that. Just ask them for permission to say, are you okay if I'm on the phone? They will always say yes, but it will just annoy them a lot less. So that's number one thing that I've learned. The number two, on your way out, do not slam the door. It is their car. It is their final moment of interaction with you. Close the door and do it softly. That will ensure that you actually get good ratings from the driver.

These are great tips. I know you can check your actual rating now in the Uber app as a passenger and so it's not 5.0 for most people, including myself. So this is good to know what might have caused that. Oh man. Okay. One other just that I want to follow here is like you. Spending so much time on the experience implies that that is a huge lever for growth and retention and long term success. A lot of people in growth and product don't see it that way. They focus on what's a metric we can drive. What's like a conversion opportunity here. They're not just like how do we just make this experience better? Can you just talk about that insight of just like we why you believe just making that experience better so important?

I think it's not an or, it's an end. I do think that obsessing over your metrics, especially when it's funnel metrics and understanding all the points of friction, numbers do tell the story. So I think you do need to have the experience points, whether they are observed anecdotally or they come through some other means as well as understanding the points of friction because of drop off in your conversion funnel, they are very important. But you can't just have that because if, I mean you're talking about end users, if it becomes just a mathematical exercise, I don't think that is enough. Because as I mentioned, what they're actually feeling in the moment is something that numbers will never show, and numbers will not bring the level of intensity that emotions will bring. Now the question is, do you have a culture that allows coexistence of both? Does it allow a coexistence of you bringing emotion as well as the numbers? And that's what I am trying to create every day. Our leadership team is trying to create every day. The product team, the engineering team is trying to create every day. And I think we have done a good job of having a coexistence of those two in the company.

Okay, and then so how do you operationalize this and make this a part of the culture at the company? Clearly, part of it is modeling it and just doing a lot of it yourself. What else do you do to help product people build this empathy in dog food as much as you do or to some extent, I mean, I do it.

Tara does it. So there is definitely, you know, just doing by example or teaching by example. We also organize around it because I think creating a little bit of an organization around it just helps. We are a large company now, and we try to assist with this by centrally organizing. This means let's make sure that everyone understands what it means to be an Uber driver, how to sign up for an Uber driver. Some people may be on visas and so on. So there is a regulatory part of that. So we make sure that everyone understands how to sign up. Then we also organize every year, we organize every quarter. We organize one week of driving and delivery. And we have a little bit of a competition. So we have hundreds of employees who go out and drive and deliver. And there's a competition of who can do the most number of trips and who can bring in the most amount of feedback in terms of things to improve. And we have prices and so on. And that's just taken off over the last, I would say, especially the last two to three years post Covid, because during COVID I think it was a little bit harder for us to gather everyone together. And then the last thing I'll say is, what do you do with all of that feedback? Because that's when the quote, unquote, boring part starts. Now you're gathering all these documents, you're taking all those issues, you're putting them in your JIRA tracking or whatever tracker you may be using, and you're fixing them. So what we have done is you have set a six monthly OKR. So we have set an OKR that we are going to fix 300 of these issues. Every team actually, the driver team will fix 300 of those issues. The rider team will fix 300 of these issues. And same for the Uber Eats team. Now, I don't really care whether it's 300 or 200 or 500, the number actually doesn't matter. But the fact that there is a number is what matters. And we have been hitting those targets every single over the last two to three years. So these are some of the things that we do to operationalize it and make sure that people understand that this behavior is not just expected, but it's also rewarded.

I imagine what's challenging about this is there's also work to do that will clearly drive growth, will clearly cut down. Like support tickets, will help with infrastructure costs. So these okrs, there's like just fix these things that we know suck. We don't know what good they'll do, but we know they're not good. How do you kind of balance that in resource and prioritization versus like all these other things on the roadmap that you know are going to drive a metric?

We have a pretty good balanced set of OKRs. So let's say one of our teams has six OKRs. Just illustratively over the next six months, one of them would be, we call them fix it. So we sign up for 300 fixits for the next six months. In addition to that, we do sign up for a growth goal, we sign up for a retention goal, we sign up for a cost savings goal. And each of them have projects behind them. And the executional rigor is a pretty big part of Uber. So for all of those projects we actually have, and I get engaged in that as well, we have pretty serious executional rigor. Now, OKRs are not meant to be hit 100%. I think we celebrate if we hit about 75 to 80% because you do want to set stretch targets. And then every half we do planning and we will allocate resources between all of those okrs. So fix it. For example, don't get all the resources, but they also don't get zero resources, which may have been the case if we had not set a culture which celebrated this and allocated resources towards this and rewarded.

Awesome. Okay, like clearly an important ingredient here is the CEO and C suite on down values this as something we will invest in and we'll trade off all focus on growth for this because we believe this is going to help us grow and win long term.

Absolutely. Absolutely.

Some people hearing this just as a final Question along this area are going to feel like, okay, Uber so easy to dog food. Of course I'll order UberEats every day. I'll go and ride. So good is what a dream. I'm dog fooding like crazy. But a lot of people work at like, you know, Oracle and, and Snowflake and like, I don't know, 5tran all these companies where it's much less, you know, non consumer products essentially where it's more difficult to dog food. Just any advice for folks that want to create a culture of dog fooding and, and kind of up their dog food game at a product that isn't consumery.

So first of all, we thought the same when we thought about the driver app as well because it was a little bit distant for people. Now I would say while it is more difficult than just ordering food and taking a ride, it is not as difficult as perhaps some of the other products that you mentioned. But I do think that you just stretch that even further. We do have a product we call Uber for business where it's a business admin using it. We do have our merchant products or Uber Eats is actually three sides of the marketplace. The eater, the consumer, the courier who's bringing your food and there's a restaurant. Now how do I dog food the restaurant product, for example? So these questions are very, very valid. So my guidance would be, and what I try to do is try to get as close to that customer as possible. So in the case of a merchant, we go spend time at restaurants. I'll give you a latest one. So we have a cafe here at Uber on campus. We also have a barista. So we enable the barista to be an Uber Eats restaurant and they have an Uber Eats tablet and I can actually order from that barista. So now you're dog fooding being an eater, you're dog fooding being a courier and you can dog food being a merchant. So some of my product team, they actually will go to the barista, they'll stand behind the counter and they'll experience what it feels like for these orders to come in. We have very close relationships with our big customers such as McDonald's or Domino's and all of them. We also have a lot of small medium business restaurants and we have relationships with them which allows us to go and spend days with them so that we can observe what life is like behind the counter for a restaurant worker, for a kitchen worker. How does our product show up? And we learn a lot of stuff. Lenny and I would ask everyone who's listening irrespective of the product that they're working on, go to the nth degree of how much you can stretch. And if it's really an IT admin at your customer who's using your product, I would do two things. A, go to that ID admin and sit next to them and observe them using the product. And B, set up what we call test accounts and try to pretend to be an IT admin and set up that account. I went through our merchant setup flow, which I can just do by setting up a test account, and I learned so many things of all the points of friction that we are putting in that flow. So I think there is still a lot that you can do even if you do not have a consumer product.

Awesome. So the advice there is just find a way, get as close as you can. You may not be able to ride an Uber, drive an Uber car, get an Uber ride, but there's some way you can get really close. It may not be exactly do the thing. Awesome. Okay, I'm going to go in a different direction. And there's another theme that came up again and again when I was asking people about you and what you're amazing at. And a motto came up again and again. It was ship, ship, ship. Talk about that. Why is this motto, this way of working, so important to you? Why is it something you try to encourage everyone to always think about?

I think it's actually a natural extension of what we just talked about. If we are going to go dog food and experience this pain and we are going to document it, what's next? You have to ship this. I'm a big believer in you don't ship documents, you don't ship brainstorming meetings. You don't even ship designs in a figma. What you ship is code in your product. That is the only thing that actually ultimately has impact on the end user. So as I mentioned before, I develop a sense of impatience. It's a positive impatience, if you will, that. Okay, I just observed a problem for our riders or for our drivers. They have to get a solution to that as soon as possible. And for that you have to ship, ship, ship. Now, you could interpret ship, ship, ship to be just mindlessly shipping. No, this is not about mindlessly shipping. But once you know that you're working on something that is important, that is solving a problem, it could be a big feature or a small feature, then you have to cut down the cycle time. My biggest enemy is the cycle time of we know it is a good thing. All the way to our user seeing it, you have to minimize that time. So that's why ship, ship, ship has become such a motto for me. And we try to do a lot of things internally, operationally for us to enable that. And I'll say we still are not there. In my opinion. I think we can still be faster, we can still cut a lot of that cycle time, but we are on a constant quest to get as good as we can.

What does this look like in practice other than just reminding people, ship, ship, ship, ship, ship, ship, just repeating this mantra, how do you help people ship faster to your point, not just work all night and all day, shipping long, staying long hours, just what are some ways to actually operationalize this?

I think it stems from the cutting down cycle time, which is the time it takes to make decisions. I realized that a lot of the time is not. I mean all the time that you spend documenting the requirements or designing the product or actually writing code is time really, really well spent. All the time that is spent in between those activities to align, to discuss a decision, to not make up your mind, then have a meeting the next week or let's regroup two weeks from now. That happens in our companies a lot. The question is how do you cut that down? And for that what we do is we have product reviews and as much as possible we try to come out with decisions in those product reviews. And you have to operate in a one way door versus two way door concept. If something is a two way door, you have to be able to make the call quickly and you want to make a good call, but if you get it wrong, it's okay. We can turn it back if it is a one way door. If it's a massive launch, sure it's okay for it to take some deliberation. Maybe it even goes through the C suite and we have a discussion. But my guidance to my team is cut down the decision making that has to happen or to cut down the time required for the decision making between those various steps.

A few things I heard that you do that Yunan mentioned that I think help with this one is that there was a period where you ran daily standups with cross functional teams during COVID just to keep things moving. There's another story I heard where you wrote a 15 page PRD over the weekend to unblock a stall team. Feels like these are kind of look for opportunities to unblock essentially.

Well, I want that to be an exception rather than the rule. But yes, I want to be able to step in or I Want all our leaders to be able to step in when needed. I think you have to be hands on. You have to be hands on when needed. Those two examples, we were coming out of COVID we had a massive shortage of drivers on our platform and we were talking about growth earlier and we had clear goals on how we grow the number of drivers on our platform all the way from getting new drivers in and improving the funnel as well as retaining existing drivers. And Lenny, there was no shortage of the number of ideas, but again, there was a problem with cycle time. So I said, great, our cycle time is going to be 24 hours. And so there was, I think there was a period of about six months when we did do daily standups and they were extremely helpful to unblock the teams on making certain decisions. And we shipped a lot and I think it took us about nine to 12 months, but we were able to come out the other side having a great number of drivers. And the great thing is that what we did in our driver and courier funnel at that time is still paying off because the number of drivers and couriers continues to. Continues to grow. And now we are worldwide at about a 8 million number. And we were probably close to half of that when, when we were just out of COVID So that's an example of where daily standards help. I try to minimize that. The PRD exam, yes, I did write a PRD. It was a 15 page PRD. We were working on a pretty big concept and it was a risky concept and it was driver facing and that's always sort of high stakes. And we had about, by this time we have had about 20 conversations and brainstorm meetings and documents that had been written with the best intentions. But thing that was not becoming clear is, hey, what should we actually ship? Because there were a lot of good ideas and not so good ideas, but no one was actually putting it all together to say, this is what we're going to ship. So it was one Sunday night and I literally, it took me two hours. And I just wrote down, I'm like, guys, this is my stake in the ground. We can completely change it, but this is the product we will ship. Agree or disagree. Now, the product that we eventually shipped was at least 50% different than what I had written down, but it just catalyzed us getting to that endpoint. Now if I were to do that every single day or every single week, then I would say there's a problem.

You wouldn't have time to deliver food and give rides.

That is exactly right. Or I would not have time to do hiring or I would not have time to do performance reviews and so on. So. But once in a while, I think it's totally fine for product leaders to step in. Especially if you're trying to remove ambiguity and you're trying to just speed decisions up, it's okay to step in and be hands on.

Another tactic that I heard that I think that I want to ask you about. Someone anonymously said that you ask for live demos, and here's the question. He always insists on doing live demos that make everyone nervous when they present. The question is why?

So I think they may be talking about when we do product announcements. So when we do product announcements externally, on stage, et cetera, I do insist on actually live demoing the product. Part of this comes from I grew up as a product manager back in the day in the 2000s at Palm Palm, the Palm Pilot Palm sort of was cut from the Apple clock. There were a lot of ex Apple people there. And you're in the consumer electronics business. And every single year, the way you would announce your product is you would get up on stage and you show the product working. And leading up to that moment was a lot of massive amount of work to make sure that it actually works on stage. Now, I will say there's an internal reason and an external reason to do this. The external reason to do this is you have to tell a story. One of my other beliefs is, which I may not have shared before, is no one actually really cares about the feature that you want to talk about. People are way too busy. You're obsessed about your products. Your products are your life. But for your end users, your products are maybe 10 minutes of their life once a week. So their life does not center around your products. They don't care. How do you make them care? You have to tell a story. And that story comes from actually showing the product in action.