Behind the Wheel: How Uber's Product Chief Dogfoods His Way to Better Products

Kansal says dogfooding is simply obsession with products Uber asks users to rely on. He takes roughly five to ten rides and orders around three Uber Eats meals a week, and once or twice a month he sets aside half a day or a day to drive and deliver in the Bay Area. Each session yields about 10 to 12 rides and deliveries, and he estimates his driving and delivery trips are in the 700 to 800 range.

The hard part, he says, is what happens afterward. He takes screenshots, writes up what he learned in standing documents for the rider, driver and Uber Eats apps, tags the relevant people and runs an internal process to prioritize. Lenny notes colleagues describe 40-page reports. Kansal follows up to make sure the fixes ship, because otherwise he is "just doing it for fun".

He also notes that with eight million couriers and drivers worldwide, an issue he hits in ten trips has probably hit customers many times over. He wants dogfooding to be a leadership habit across Uber, not a requirement that every PM test their own feature, and says the lasting value is a culture that refuses to accept known problems.

Kansal describes a spectrum of user feedback, from quantitative charts and surveys to focus groups, roundtables with drivers and riders in places like Brazil, India and the UK, and one-to-one conversations. He chats with drivers on his own rides and watches how they use the driver app. Yet only by getting behind the wheel does he get the visceral reaction when something goes wrong, and every flaw costs a real driver earnings.

The biggest surprise, he says, was that the center of a driver's universe is the interaction with the passenger, not the app. Early in his driving, a passenger heading to the airport left her suitcase on the curb and waited for him to load it without saying anything. That somber ride, he says, built lasting empathy that he wants his team to share.

He offers two tips for riders: ask the driver's permission before taking a call, and close the door softly on the way out. On metrics versus experience, he insists it is an "and": funnel numbers show friction, but they will never carry the intensity of how people feel. The job is building a culture where both coexist.

Beyond leading by example, Uber organizes central onboarding for employees to sign up as drivers and runs a week of driving and delivery each quarter, with hundreds of employees competing on trips and feedback submitted. The feedback is then tracked like any other work: every six months each team, whether driver, rider or Eats, commits to fixing around 300 issues.

These "fix-its" sit alongside growth, retention and cost-savings goals. Kansal notes that OKRs are not meant to be hit fully and 75 to 80% is a celebrated result. Fix-its do not get all the resources, but because the culture rewards them they never get zero, which Kansal suggests would otherwise be the default.

For non-consumer products, he says to stretch as far as you can. Uber's merchant side has staff spend days behind restaurant counters and use an on-campus barista with an Uber Eats tablet. For an IT admin product, sit next to the admin or create a test account and go through setup yourself, which exposed many friction points in Uber's merchant flow.

Kansal says shipping follows naturally from dogfooding: you ship neither documents, brainstorms nor Figma designs, but code that reaches users. He describes a positive impatience, and says the motto is not mindless shipping but cutting the time between knowing something is good and users seeing it. He admits Uber can still be faster.

The lost time, he argues, is rarely in writing requirements or code but in the gaps between them: waiting a week to meet, regrouping in two weeks. Uber tries to make decisions inside product reviews and distinguishes one-way from two-way doors, moving fast and accepting reversibility on the latter.

He gives two examples of stepping in. Coming out of COVID, with a severe driver shortage, he set a 24-hour decision cycle and ran daily stand-ups for about six months; drivers and couriers have since roughly doubled to about eight million. Another time, after about 20 meetings and documents, he wrote a 15-page PRD on a Sunday night, and the shipped product was at least 50% different.

Kansal insists on live demos when Uber announces products on stage, a habit from his days at Palm, where Apple-influenced colleagues showed working products each year. Externally, he says, users spend perhaps ten minutes a week with your product, so you need a story, and showing it in action beats slideware.

Internally, he argues, a live demo creates rigor before launch because it has to work, and gives the product and engineering teams pride in seeing their product working on stage. It is stressful and a lot of work, he concedes, but he sees it as his responsibility to create that moment.

For early-career product people, Kansal recommends joining a company where you can ship multiple products quickly, aiming for three to five product cycles in two to three years. Do not try to be the smartest person in the room. What makes a great PM, he says, is the thousand micro decisions such as button placement, copy and launch city, which build the gut sense that separates good from great.

After 24 years in product, he says tools and data have changed enormously, and AI is now changing research, PRDs, mockups and storytelling every week. What stays constant is understanding what end users want, which is harder than people think, especially across 75 countries and many demographics. He expects knowledge to remain important but judgment and product sense to matter even more.

Asked what he hates from engineers, he says it is hearing that work is blocked without a PRD. The best engineers co-create with PMs and designers at a whiteboard, and he is deliberately boundary-less about whose product opinions count. With AI tools turning meeting notes into first-draft PRDs, he sees no excuse for blocks.

Kansal explains that Uber had its own self-driving unit but divested it during COVID, choosing a partner approach. It has since signed about 15 AV partners, with May Mobility announced on the day of the recording. Partners integrate through a rich set of APIs and gain access to a hybrid marketplace of human drivers and AVs.

The logic is utilization. If a city has 500 AVs, they are underused at 10:30 on a Tuesday morning and insufficient at 6:00 on a Friday evening. Uber's human drivers cover peaks and its demand density keeps vehicles busy off-peak. He cites launches with Waymo in Austin and Phoenix, an upcoming Atlanta launch and WeRide in Abu Dhabi, plus sidewalk delivery robots.

He expects a long need for human drivers, because of regulation and pickup spots AVs cannot reach, and because Uber is expanding earning opportunities such as groceries. He has carried crates of water upstairs himself, and notes that Uber refunds his earnings to the customers.

On the shift from blitz-scaling to profitability, Kansal says taking inefficiency out was hard but rewarding, because the savings go back into the business or into users' and drivers' pockets. His example is batching deliveries so a courier can serve two nearby drop-offs, multiplied across a thousand ideas in marketplace logic, promotions, support, payments and background checks. Uber became profitable about two years earlier and continues to grow margins.

He notes Uber divested self-driving and Uber Elevate during COVID, when mobility dropped 80% overnight. His framework is concentric circles: the core, 33 million daily trips with many possible failure points, must be flawless and efficient, and that earns the license to expand to growth bets such as Eats, Groceries, Reserve, Uber for Teens and taxis, which together are in the billions.

Kansal gives three gut-driven examples that he says could have got him fired. On safety in 2017, he pushed for features that deliver a feeling of safety, not just incident reduction, since even when 99.9% of trips are fine people can be concerned, and safety sentiment rose. He also championed working with taxis despite data on their decline; yellow cabs in New York City are now hailable in the Uber app.

The third was Uber for Teens. Parents and risk teams objected, but as a father of a 16-year-old and a 12-year-old he saw transportation as a real household problem. The product has grown well after launching two years earlier, and he still gets emails from California parents after it was turned off there. His conclusion is that growth bets often lack supporting data and need an intrinsic understanding of user problems.

Kansal says Uber's teams use ChatGPT and Gemini heavily for prototypes, mocks and user research. He uses ChatGPT to summarize 50 to 100-page research reports, and uses deep research to test a long-discussed driver feature: asking whether drivers would like it and what to change. He calls it an amazing research assistant and a starting point for brainstorming, and says it will make people better at their jobs.

For his failure story, he describes Palm, which was slow to respond to the iPhone and Android and was eventually bought by HP. His lesson is that being the third or fourth player in a consumer market is hard when two scale players compete ferociously, so he stays paranoid about challengers and never takes the status quo for granted. Flywheel's struggle to scale reinforced urgency and resilience.

Closing, he says the relationship with users is not reciprocal: he thinks about them each morning, while they are busy with their own lives. For the roughly 15 minutes a day they use Uber, the aim is to dazzle them or be so seamless that opening the app is muscle memory. His life motto is to focus on inputs, since you can only control inputs, not outputs.