LLenny's Podcast
← All episodes
Brian Tolkin (Head of Product at Opendoor, ex-Uber)04 August 2024

Lessons from scaling Uber and Opendoor

7Frameworks
15Insights

Frameworks in this episode

Insights & moments

The myth-busts, hot takes, explainers, and tools worth keeping.

Hot Take· 1

Hot Take31:30

Don't Be a Hammer Looking for Nails With Frameworks

Brian likes Jobs To Be Done but warns against dogmatism: pick the right framework for the right job rather than forcing everything into one. He gives an Open Door example where an early framing of the job ("get an offer from Open Door") was too narrow, and the truer job was price discovery for the customer. The value is cultural internalization, not just wedging content into a template.

  • Have more tools in the toolbox and know when to apply each; avoid the hammer-and-nail trap
  • JTBD forces empathy, useful at Open Door where customers transact only ~once every seven years
  • A shallow job ("get an offer") can mask the real one ("price discovery")
  • Templates don't make content better; cultural internalization does

we try to avoid um being a hammer and everything's a nail

Brian Tolkin · 32:00

the broader job to be done might be like price Discovery for the customer right

Brian Tolkin · 37:30
#jobs-to-be-done#frameworks#product#opendoor

Explainer· 6

Explainer02:30

Why Starting in Ops Made Him a Better Product Leader

Brian argues that beginning his career on Uber's operations team gave him a ground-level understanding of what actually moves a business. Running a city day-in and day-out, onboarding drivers, and answering support tickets put him close to the customer. That foundation, he says, is what lets you then decide what's worth building in a scalable technology way.

  • Operating a city directly teaches you what drives the metrics (down to whether it rained that weekend)
  • Early Uber had no centralized support team, so operators were the ones closest to the customer
  • Deep operational understanding is a strong foundation for later product decisions

starting on the operation side gave a really deep understanding of like how the business actually works

Brian Tolkin · 03:00
#operations#product-leadership#uber#career
Explainer06:30

The Twin-Turbine Model: Product and Ops as One Engine

Brian describes how Uber and Open Door treated product and operations like a twin-turbine jet plane: you can fly on one engine for a while, but it runs best when both work together. Local ops teams iterate faster and gather far richer qualitative insight than a PM sitting in San Francisco ever could. The goal is harmony, not competition, with a strong feedback loop between the field and the builders.

  • Product and ops run best as harmony, not a competition
  • Local ops teams iterate faster and get better qualitative insights on the ground
  • A PM in SF can't be in 50 markets walking houses or 1,000 cities understanding local safety nuances
  • Fostering a good field-to-builder feedback loop is the lever

kind of like a twin turbine jet jet plane where you can like fly the plane on one engine for a little bit if you…

Brian Tolkin · 07:00
#operations#product#org-design#feedback-loops
Explainer21:30

Do Things That Don't Scale, Then Scale Them

Brian walks through how Uber driver onboarding evolved: from 90-minute one-on-one sessions, to small classes, to a video, until validating thousands of licenses a week broke the manual system. That's the signal to move from the iteration stage to the scale stage, where technology (like OCR license validation) uniquely excels. Automating it also freed hundreds of people to go solve the next problem.

  • Onboarding scaled from 1-on-1 → small classes → 20–30 at a time → onboarding video
  • License validation broke once volume hit ~1,000/week, signaling the shift from iteration to scale
  • Tech (OCR/auto-recognition) is uniquely good at scaling once the process is understood
  • Automation freed hundreds of people to tackle the next optimization

do things that don't scale and then scale the things that you're doing

Brian Tolkin · 23:30
#scaling#operations#automation#uber
Explainer26:00

How to Run Product Reviews That Aren't Firing Squads

Brian sees product reviews as serving two goals: accountability/informing an audience, and, most importantly, making the product better by helping teams think through problems. The primary goal means reviews should feel intellectual, not scary. He keeps the live conversation small (under 10), while the resulting documents can go to wide distribution and are especially powerful for onboarding new people.

  • Two stated goals: accountability/informing, and (primary) making the product better
  • Reviews shouldn't feel like firing squads; that environment doesn't improve products
  • Keep the conversation small, ideally under 10 people
  • The written artifacts are valuable for the whole team and great for onboarding new hires

product reviews hopefully are not feeling like firing squads

Brian Tolkin · 27:00

the best conversations happen when they're relatively small so try and keep it under under 10

Brian Tolkin · 29:30
#product-reviews#leadership#meetings#culture
Explainer40:00

How to Experiment When You Have Low Sample Sizes

Open Door does few, very large transactions, so classic A/B testing is often underpowered. Brian's advice: run a power analysis before committing, and be honest about runtime, sometimes a six-month set-and-forget experiment is the right call. Where a canonical test isn't possible, raise conviction other ways (talk to customers, observational data, twin cities, 80% confidence, long-term holdouts) and don't chase false precision.

  • Always run a power analysis before starting an A/B test; know the detectable effect and runtime
  • Some important experiments justify a six-month runtime; the real mistake is faking an answer in a month
  • Alternatives to raise conviction: talk to customers, observational data, sister/twin cities, segmenting, 80% confidence, long-term holdouts
  • When nothing works, trust intuition and ship; don't waste time chasing false precision

don't just for for yourself into AB testing without running the power analysis

Brian Tolkin · 41:00

you shouldn't spend time trying to get false Precision

Brian Tolkin · 44:00
#experimentation#ab-testing#statistics#opendoor
Explainer56:30

Product Is Finding the Kernel of Truth in a Sea of Signals

Signals about your product come from everywhere, CS teams, customers, executives, a YouTube video, and the core job is deciding what actually matters versus what is noise. That means saying no to things that sound like good ideas. Brian adds a practical tip: write down every idea and piece of feedback, both to reference later and to make sure the people who raised them feel heard and respected.

  • Good ideas come from everywhere; the job is separating what truly matters from noise
  • Doing the job well means saying no to some seemingly good ideas
  • Write down all ideas and feedback in whatever backlog you keep
  • Capturing ideas signals that contributors were heard and their input considered

the core job is to understand what really matters right like what is noise what is a good idea what is a suggestion

Brian Tolkin · 57:00

making sure the people who present those ideas are heard and respected

Brian Tolkin · 59:30
#product-strategy#prioritization#feedback#focus

Story· 7

Story08:00

How Product Operations Was Born at Uber

Uber had a centralized product team mostly in San Francisco and a globally distributed ops team, with a weak bidirectional feedback loop between them. The fix was a new function, Product Operations, whose members reported into operations but physically sat with and operated like part of the product team. Brian is modest about credit, noting Google and others had dabbled in similar models before him.

  • Problem: SF-built features didn't translate cleanly to global markets, and market input didn't flow back
  • Product Ops reported into operations but embedded with the product team
  • The role formalized and built out an organization others had only dabbled in

our solution at the time was to start up a new function called Product operations who had accountability and reported into operations but physically sat…

Brian Tolkin · 08:30
#product-operations#org-design#uber#scaling
Story10:00

Uber's Surge Pricing Was Once Controlled by Hand

For much of 2012, surge pricing was a manual, human-in-the-loop system: city GMs set the parameters for when and where surge could turn on. A GM might know a baseball game lets out at 10pm and set surge at 9:45, something the algorithm couldn't yet predict. Reasons included caution around a powerful new lever, trust in local knowledge, and the technical difficulty of a fully dynamic geospatial pricing system.

  • GMs controlled whether surge was on/off, the geographies, the hours, and the cap; the algorithm optimized within those bounds
  • Local teams could anticipate events (e.g. a ballgame ending) the algorithm couldn't
  • Three drivers: caution with a powerful new tool, trust in local knowledge, and the hard technical build of always-on dynamic pricing

GMS in every city would control basically the parameters in which surge would operate

Brian Tolkin · 10:30
#surge-pricing#uber#operations#pricing
Story12:30

"UberX" Was Just a Placeholder That Stuck

The product that became UberX had no name during modeling, so someone on the ops team used a placeholder: X. The company moved fast enough that it launched under that placeholder, and a decade later UberX is still the name. Brian notes many products start this way, with a temporary name becoming permanent because it's too expensive to rebrand.

  • UberX started as an all-hybrids concept with no agreed name
  • "X" was literally a placeholder in the model
  • It launched fast and the placeholder name stuck permanently

so it was going to be a placeholder so what do you put as some placeholder X so Uber X

Brian Tolkin · 13:00
#uber#product-naming#startup-stories
Story13:30

The All-Nighter Launching Uber Pool in China

Launching Uber Pool in Chengdu, the team flipped on the testing infrastructure the weekend before go-live and the matching algorithm didn't work. Brian slept roughly 30 minutes that night while the team debugged with the US, finally getting it working around 5:30am for a 6am launch. Afterward, exhausted, a mediocre street-food pancake became, in his memory, the best meal of his life.

  • The matching algorithm broke the day before a press-backed 6am launch
  • Brian slept ~30 minutes; the fix landed around 5:30–6:00am, just in the nick of time
  • Extreme, sleep-deprived, stressful moments become the best memories and stories

I remember I slept it up 30 minutes that night between 2 and 3:00 am

Brian Tolkin · 14:30

in my mind that was like the best meal I've ever had in my life

Brian Tolkin · 15:00
#uber#launch#china#startup-stories
Story15:30

Open Door Shut Off Its Core Business When COVID Hit

In March 2020, with people unwilling to let others into their homes and Chinese real-estate data looking frozen, Open Door turned off its core business and stopped buying homes for a few months. It used that time to virtualize the entire process and came out the other side transformed. Brian frames it as a very stressful moment that became a fond memory in hindsight.

  • Open Door physically enters homes to buy and sell, which COVID made impossible
  • They stopped buying homes for a few months rather than operate blind
  • They used the pause to virtualize the whole process

we actually turned off the core business and we stopped buying homes for a few months

Brian Tolkin · 16:00
#opendoor#covid#crisis-management#operations
Story47:00

Why Zillow Struggled to Beat Open Door at Its Own Game

Zillow tried to do what Open Door does, failed, and now partners with it instead, sending high-intent audiences to Open Door's selling solution. Brian attributes the difficulty to the business being far more than a software product: you must be excellent at pricing, product, operations, risk discipline, and capital markets simultaneously. That vertical integration has been in Open Door's DNA from day one; a software-driven company can't just bolt it on.

  • Zillow went from competitor to partner, funneling its browsing audience to Open Door
  • The business demands excellence across pricing, product, operations, risk, and capital markets at once
  • Vertical integration was in Open Door's DNA from day one
  • A software-first company underestimates how hard bolting on operations and capital is

you have to be really good at pricing you have to be really good at product you have to be really good at at the…

Brian Tolkin · 49:00

being um competition aware but not necessarily competition focused

Brian Tolkin · 50:30
#opendoor#zillow#competition#vertical-integration
Story1:00:00

Failure Corner: The Early Uber Pool Launch and the Liquidity Lesson

Early Uber Pool in San Francisco tried to match commuters by specific companies and corridors, but the team quickly learned that liquidity is the only thing that matters and a company-based approach could never generate enough of it. They pivoted, running a $5-anywhere-in-SF pool promotion to juice liquidity and find the product's limits. The lesson: don't overthink it or get too cute with a beta, sometimes you just need a lot more people in it.

  • The initial commuter/company-matching strategy couldn't generate enough liquidity
  • Liquidity was the only thing that mattered for the carpooling product
  • A $5-anywhere-in-SF promotion was used to juice liquidity and probe the product's limits
  • Lesson: don't overthink the beta or get too cute; you just need enough people in it

liquidity is the only thing that matters

Brian Tolkin · 1:01:30

don't overthink it don't try to get too cute

Brian Tolkin · 1:02:30
#uber#uber-pool#failure#liquidity#marketplaces

Takeaway· 1

Takeaway52:30

Reflecting Stress Onto Your Team Doesn't Produce Better Outcomes

Brian's calm was sharpened in Uber's constant fire-drills, but the core lesson is that projecting stress onto teams makes everyone tense and counterintuitively worsens outcomes. He leans on mantras like "you're never as good, or as bad, as you think you are" to keep a clearer head. The uncomfortable truth is you often only gain this perspective by living through stressful situations, and learning from them, so the next one feels familiar.

  • Reflecting stress onto teams makes them tense and lowers performance
  • Mantra: you're never as good as you think, never as bad as you think, aim for an even keel
  • Perspective that "things pass" mostly comes from having been through it before
  • Advice: expose yourself to stressful situations rather than running from them, and learn from them

when you reflect the stress onto your teams everybody tenses up and tightens up

Brian Tolkin · 53:30

You're Never As Good As you think you are you're never as bad as you think you are

Brian Tolkin · 53:30
#leadership#resilience#stress#mindset