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

The episode opens with a preview of its two central ideas. Lenny Rachitsky frames Sachin Kansal as someone who takes dogfooding "to a whole other level," and Kansal describes setting aside half a day once or twice a month to drive and deliver. His core observation is that features that look polished in the office can stop making sense when the phone sits three feet away in a car moving at 45 miles per hour. The second idea is the motto "ship, ship, ship": once you have felt and documented a problem, the only output that counts is shipped code. A third thread, career advice, is teased through his claim that great product managers are made by micro decisions about buttons, screens and copy rather than by a handful of strategic ideas.

You don't ship documents, you don't ship brainstorming meetings. What you ship is code in your product.

In his introduction, Rachitsky sets out Kansal's background: more than eight years at Uber, where he is chief product officer over product management, design and product operations; earlier roles as chief product officer at Flywheel and VP of product at Lookout; and an early career at Palm as director of product management for webOS and its mobile apps. Rachitsky says Kansal has done hundreds of drives and deliveries himself and that much of what Uber's product team works on comes from these experiences. He also previews topics including autonomous vehicles, Uber's shift to efficiency and profitability, and tips for not annoying drivers and couriers.

The interview proper is preceded by sponsor segments for Paragon, an integrations platform for AI products, and Stripe. These are advertising claims rather than part of the conversation with Kansal, and the discussion resumes when Rachitsky welcomes him to the show.

Asked to describe the scale of his dogfooding, Kansal reframes it as an obsession with using the products Uber asks customers to use. He lists four apps: the Rider app, Uber Eats, and the driver and courier apps. On a typical week he takes roughly five to 10 rides and places about three Uber Eats orders, with more when travelling. The harder part is the supply side: once or twice a month he spends half a day or a full day driving and delivering in the Bay Area, completing about 10 to 12 rides and deliveries each time, and he calls this one of the best parts of his job.

Kansal is explicit that the experience itself is the easy, enjoyable part; the discipline lies in what follows. He takes screenshots, maintains running documents for the driver, rider and Uber Eats experiences, tags the people responsible, and sends his observations into an internal process that triages and prioritizes them. He concedes that "not everything that I thought is a great idea is necessarily a great idea," so his reports are inputs to prioritization rather than orders, but he personally follows up to make sure the issues that should be fixed get fixed quickly.

On totals, Kansal estimates his driving and delivering at around seven to 800 trips, and says he cannot count his trips as a passenger or his Eats orders. Rachitsky adds second-hand detail from Kansal's colleagues: 40-page reports cataloguing what is broken, with screenshots and suggested fixes, followed by persistent follow-up that holds people accountable. That characterization comes from Rachitsky's conversations, not from Kansal himself.

Kansal explains his follow-through as a kind of impatience driven by scale: if he hits a problem in 10 trips in a day, it has likely happened many times to Uber's eight million couriers and drivers. His impatience is calibrated to severity, and he argues that without follow-up the exercise is just fun rather than impact. He also stresses that he is not the only one dogfooding; the goal is a culture in which leaders, not just individual product managers testing their own features, do it, and he says many people at Uber now write such documents.

it's the culture of we are not just going to accept certain problems in our products, we are actually going to fix them.

Rachitsky presses on why a CPO with hiring, firefighting and other demands would prioritize this. Kansal answers with a spectrum of user feedback. At the quantitative end are charts in which every user is an MAU or DAU; next come surveys sent to thousands of riders; then focus groups and the roundtables with drivers and riders he holds on visits to offices such as Brazil, India and the UK; then one-on-one conversations, including the informal interviews he conducts with drivers during his own rides, where he can also watch how they handle the driver app, for example leaving it to answer a text message. He values every point on the spectrum and says each is useful.

However, until I get behind the wheel or I'm a passenger or I'm using Uber Eats, what I miss is the visceral reaction that you get when something happens.