Lessons from scaling Uber and Opendoor

Brian Tolkin is head of product and design at Opendoor and previously spent nearly five years at Uber, joining as employee 100 and starting on the ops team before moving into product and helping launch uberPOOL and product operations. The conversation covers how operations and product work together in heavily operational tech companies, how he runs product reviews, applies jobs-to-be-done, experiments with low sample sizes, and stays calm under pressure.

01Key learnings

• Treat operations and product as complementary engines rather than rivals; a company runs best when both feed each other with on-the-ground insights and scalable technology.
• Start with manual, human-in-the-loop processes to learn, then automate with technology once volume makes manual work break, freeing people for the next problem.
• Be explicit about where scarce engineering effort goes, focusing on the core leverage point (like dispatch and pricing early on) and transparently deferring other investments.
• Keep product reviews small, around 10 people or fewer, with the primary goal of improving the product rather than acting as a firing squad, and set that context up front.
• Use a jobs-to-be-done lens with a lightweight template, but treat it as a cultural practice that requires examining the real customer context rather than just filling in a form.
• Before running an A/B test, run a power analysis to check whether the traffic can detect the effect in an acceptable time; when that fails, build conviction through customer interviews and other techniques.
• Stay calm under pressure because stress spreads to teams and reduces quality; remind yourself that you are rarely as good or as bad as you think.
• Find the kernel of truth amid noisy feedback by asking where technology or effort can uniquely create leverage, and write down every idea so contributors feel heard.

02Frameworks mentioned

Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.