Head of Product & Design, Opendoor (formerly Uber)
MULTI-YEAR ARCHITECT
The Metaphor
Twin Turbine Jet Plane
"You can fly the plane on one engine for a little bit if you need to, but it's operating most efficiently and effectively if both are working together."
Not competition between functions—harmony
Both must exist in ops-heavy tech companies
Requires mutual respect and clear feedback loops
One team flying solo means inefficiency
The Foundation
How Ops Made Brian a Better Product Leader
Started at Uber as an ops person, deeply understood how the business worked day-to-day
One-on-one customer conversations, support tickets, understanding local markets
This "ground truth" becomes the foundation for what to build at scale
Same foundation applies at Opendoor: walking homes, understanding the seller journey
100
Uber employee #
2
companies at scale
The insightA PM in San Francisco can't be in 50 markets or 1,000 cities. But you can build feedback loops with people who understand those markets deeply.
How to Make It Work
The Product & Ops Playbook
Mutual respect: Both functions have their time, place, and skillsets. You don't build big ops-heavy businesses without both.
Clear technical leverage: At Uber, the engineering effort went to dispatching and pricing. That's where the leverage was. Be explicit about what you're not building.
Acknowledge entropy: Real world is messy. Drivers cancel. Scheduling is off. Homes have surprises. Build products with flex and failsafes, not just deterministic computer logic.
Evolve over time: Early Uber was ops-product heavy. Later Uber was more centralized. The balance shifts as the company scales and tech improves.
The GM story
Surge pricing wasn't fully automated in Uber's early days. Each city's GM manually controlled surge parameters based on local knowledge (baseball games, events). A human in the loop until the systems got good enough.
The uberPOOL launch
Slept on the floor in Chengdu, China. Launched at 6 AM after debugging all night. Stress on you = stress on team. Staying calm under pressure is a product skill.
Framework
Jobs to Be Done at Opendoor
Use a template in product reviews with: context, problem, potential solution, risks, measurement
The job isn't always obvious—surface-level job is "get an offer" but deeper job is "price discovery"
Don't force-fit the framework: the cultural internalization matters more than template compliance
Ask repeatedly: "Is this actually the job to be done?"
Key insightFrameworks take time to internalize. Don't just wedge content into a template. The richness comes from the conversation about what the real job is.
Experimentation at Scale
A/B Testing for Low-Volume Businesses
✗Run A/B tests on everything regardless of sample sizeINSTEAD →✓ Run power analysis first. If you can't detect significance in realistic time, don't pretend you got an answer after 30 days.
✗All experiments must show results in a monthINSTEAD →✓ Some experiments are worth running for 6 months. Set it and forget it. Learn for next year's planning.
✗A/B testing is the only way to build convictionINSTEAD →✓ Use observational data, diff-in-diff, sister cities, customer conversations, reduced confidence thresholds (80% vs 95%), holdouts. Build conviction creatively.
✗Always wait for statistical significance before shippingINSTEAD →✓ If you've exhausted other conviction-building techniques, trust your intuition and ship. Don't pursue false precision.