Building product at ops-heavy companies: lessons from Uber and Opendoor

Executive overview

Most tech companies treat operations as a cost to be eliminated. At Uber and Opendoor, ops and product are a twin-turbine engine — the business breaks if either stops working. The result is a fundamentally different way of building: technology decisions are made around where leverage exists, not where it's easiest to ship.

Brian Tolkin moved from Uber ops to product to CPO at Opendoor. His core argument: deep ops experience makes better product leaders because it forces genuine understanding of how a business actually works.

The real job of a product leader in an ops-heavy company is deciding where technology leverage exists and saying no everywhere else.

Ops and product as a joint system

• Ops teams can iterate faster, reach customers more directly, and surface qualitative insight no PM in HQ can replicate
• Product teams bring scalability; ops teams bring ground truth — the value comes from the feedback loop between them
• Product operations at Uber was created to formalise that loop: a team accountable to ops but physically embedded with product
• Early Uber surge pricing was entirely human-operated — city GMs controlled on/off switches and parameters; the algorithm only optimised within those bounds
• Surge pricing stayed manual because local teams knew their cities: a GM could anticipate a baseball game ending and pre-set surge 15 minutes early

When to invest in technology vs. operations

• In the early days, engineering resources are scarcer than operational ones — be explicit about where tech leverage is and name what you are deliberately not building
• Uber's early engineering was almost entirely on the dispatching and pricing systems; everything else was handled operationally
• Driver onboarding illustrates the natural progression: individual sessions → small groups → video → automated credential validation via OCR
• The cycle: do things that don't scale, then scale the things that work
• As ops processes are automated, those teams don't disappear — they move to the next unsolved problem (underground experimentation culture)
• The real world has entropy: drivers cancel, GPS fails, homes aren't accessible — build products with more flex and more fail-safes than a purely digital product needs

Running effective product reviews

• Two explicit goals: accountability and information sharing, but primarily helping the team make the product better
• Keep the conversation under 10 people; distribute the written artifact widely — it's especially valuable for onboarding new team members
• Senior leaders should probe and ask questions, not mandate — frame contributions as "this is an idea, not a directive"
• Teams closest to the problem have the deepest context; leaders bring breadth; the job is to marry both
• Cadence at Opendoor: two open slots per week anyone can sign up for, with a quarterly check to ensure all product areas cycle through
• Product review documents follow a standard template: context, problem, potential solution, risks/pre-mortem, measurement of success
• Reviews are staged by phase: ideation looks very different from pre-ship

Jobs to be done in practice

• Useful precisely because Opendoor customers transact once every seven years — you can't build for yourself the way you can at Uber or Airbnb
• The framework forces attention to the broader context of the customer journey: agents, friends, driving around the city — most of which happens outside the product
• Template adherence matters less than cultural internalisation: the goal is for teams to naturally ask "what is the customer actually trying to do?"
• Watch for jobs that are subtly influenced by business goals: "get an offer from Opendoor" is not the same job as "price discovery for my home"
• Don't be dogmatic — jobs to be done is one tool; pick the right framework for the problem

Experimentation at low volume

• AB testing is the gold standard but requires honest power analysis first — know the minimum detectable effect and the runtime before starting
• Some experiments are worth a six-month runtime; set them and treat the results as input to the next planning cycle
• When AB testing isn't viable, other techniques can build conviction: customer interviews, observational data, diff-in-diff, sister-city comparisons, geo segmentation, reduced confidence thresholds (80% vs 95%), long-term holdouts
• If no technique is available, use judgment — but have a feedback loop in place (support ticket volume, feature adoption) to check the hypothesis after shipping
• The mistake is not running long experiments; it's pretending a statistically insignificant result after one month means something

Competing in large, underpenetrated markets

• Zillow entered the iBuying space and eventually exited; the business requires pricing expertise, operational capability, risk discipline, and capital markets fluency simultaneously — Opendoor was built vertically integrated from day one
• The right competitive posture: competition-aware, not competition-focused
• In both Uber and Opendoor's markets, the dominant competitor is the default behaviour (traditional home sale, pre-rideshare transport) — the market is far bigger than the competition
• Partnering makes sense when another company has reach you lack and you have a solution they can't build

Staying calm under pressure

• Reflecting stress onto a team causes everyone to tighten up — it counter-intuitively produces worse outcomes
• Useful mantra: you're never as good as you think you are, and never as bad as you think you are
• Calm under pressure is a muscle built through exposure — going through high-stakes situations, reflecting on what worked, and carrying that forward
• Learning from others' stories (biographies, podcasts, the Founders podcast) accelerates this even without direct experience

Matching PMs to problems

• There is no generic "product manager" — there are technical PMs, ops-background PMs, design-background PMs, and each fits different problem types
• As a product organisation scales, think of it like a product roadmap: match the skill set of the person to the nature of the problem, not just seniority or general ability
• Finding the kernel of truth in a sea of signals is the core job — good ideas come from everywhere (CX teams, customers, field visits, executives) but most of them are noise relative to what will actually move the customer forward