Brian Tolkin, Head of Product @Opendoor: How to Hire the Best Product Teams | E1257

Summary

• AI collapses the product development funnel but not the PM job. Brian Tolkin’s core claim: the PRD-to-Figma-to-code relay compresses into “let’s just build a prototype, let’s skip the documents stage” — yet the actual skill, “you got to go talk to users, you got to go figure out what people want… and how do I know type one from type two decisions,” doesn’t change in a pre- or post-AI world. The tool chest gets bigger; the judgment stays scarce.
• On the AI skill curve, host and guest split then converge: Brian says engineering becomes more important; Harry argues less, because tooling commoditizes everything below “top 1% performance-based model optimization” while design pros pull away from AI’s “good enough.” Brian’s synthesis is the tradeable line: “the top 1%, the top 5% of all of the skill sets get a lot more valuable and the median gets a lot less valuable.”
• Tech debt at Series A is probably premature: posed a hypothetical $2M→$8M company, Brian’s answer is that at that stage it is probably too early to pay it down — “you have to earn the right to exist in the future, and paying down tech debt doesn’t pay the bills.” In a land grab (Uber for years), velocity philosophy wins; slowing down early to pay down debt is “a bit challenging.”
• Multi-product has a 2x2: new products need a contained sandbox (Uber/Opendoor can do it by city; Uber Eats was “totally separate everything”), and the second product needn’t benefit the first — but new customer set plus new capabilities “is probably just a new company.” Opendoor’s own miss: years building buyer-side (retail buying, mortgage) when the win was existing customers/new capabilities — “the right to win for sellers is where a lot of the magic is.”
• Consensus product decision-making is “challenging and wrong.” Brian’s middle path between Spotify CPO Gustav’s “talk is cheap so we should do more of it” and Harry’s “dictatorial product leadership is underrated”: gather every opinion, then decide — “slow decision making is expensive… very rarely does a slower decision lead to a better outcome.” Disagree-and-commit works for a sprint, not a career: “if I’m disagreeing and committing too much… I’m in the wrong place.”
• “You hire your strategy”: the person you pick defines how success gets defined, so hire for PM-team fit (a mathy PM for an algorithm product, a tinkerer to energize a staid team), not generic smarts. Failed hires are “never just the responsibility of the person being hired” — it’s unclear success criteria, wrong skill-set match, or ambiguity above the person’s ability to distill.
• Best and worst Uber Pool decisions bookend the episode: best was upfront pricing (replacing post-hoc minutes-and-miles calculation); worst was defaulting riders into Pool even after they’d chosen UberX — “we prioritized the needs of the business above… respect for the user’s choices,” a lesson he says he deeply internalized.

Deep dive

1. The likely Chengdu launch: match quality lives and dies on road data

• Brian described Uber’s likely Chengdu launch — “a city like 20 million people that most people at Uber had never heard of” — while Uber simultaneously stood up a Chinese data center. Things weren’t working the night before; he thinks he slept 30 minutes on the office floor and launched at ~5:30–6:00 a.m. to hit rush hour, because pool “relies heavily on liquidity to make efficient matches.”
• The durable lesson: understand the components that make your product work. With no Google Maps in China and “massive highways and overpasses,” match quality suffered — “we underappreciated the complexity of how you would make good matches without awesome underlying road data.” He also wishes they’d acknowledged cultural design differences earlier: Chinese apps run to “color and red and big buttons,” not sleek recede-into-background design.
• On whether product design is globalizing: convergence is real, pulled slightly Westward, but “as our attention spans shrink… we’re certainly meeting in the middle.”

2. AI collapses the funnel; the PM’s core job doesn’t move

• The old relay — PM owns the PRD, design owns the Figma file, engineering owns the code — put the PM “at the top of the funnel.” Brian’s view: AI completely collapses that cycle; PM and designer just build a prototype together and show customers, skipping the documents stage. What survives untouched: talking to users, distilling what to build, making it work for the business, and knowing “type one from type two decisions.”
• Does Figma lose to what sounds like Replit? His generalization: more PMs will start in prototyping land than design land — yes — but Figma keeps building for designers, PMs, and engineers and moving closer to production code.
• The engineering-vs-design debate: Brian says engineering becomes more important in an AI world; Harry pushes back — commoditization below “top 1% performance-based model optimization,” while design pros separate from AI’s “good enough.” Brian concedes the shape: top 1–5% of every skill set gets more valuable, the median less.
• His closing wish is a hedge against the hype: “the use of AI tools to break down the silos between the functions will be more challenging than a lot of people are giving it credit to.”

3. Tech debt doesn’t pay the bills — and OKRs are earned, not scheduled

• Harry’s hypothetical — Series A, $2M going to $8M in a year, mounting tech debt: Brian’s answer is that at that stage it is probably too early — “you have to earn the right to exist in the future, and paying down tech debt doesn’t pay the bills.” The caveat is competitive context: Uber was in a land grab for years, and most early companies still don’t know whether anyone will pay for the thing at all.
• Prioritization is impact/confidence/effort plus an explicit, top-down decision about what time frame the company is optimizing for — “debt” is the apt word because you trade paying now against paying later.
• On OKRs: they’re “cascading trees”: teams ladder up to the one or two levels above (for Uber, trips; his slice, pool trip count). The biggest mistake is having too many — three, maybe three to five — because “if you’re focused on everything, you’re not focused on anything,” and a real process can articulate the important things you’re not doing. Cadence rule worth keeping: “you earn the right to set OKRs on longer time horizons by proving you can execute on shorter ones” — an annual plan may not be worthwhile when you can’t say what ships in three weeks.
• Should the CEO be the CPO? Not always, but early on yes: if the product is the most important asset the company has, “outsourcing” it early is really challenging.

4. Multi-product: sandbox the new thing, know which quadrant you’re in

• The product challenge is a likely classic innovator’s dilemma — “you can’t degrade your core product to build a new product on top of it.” His preferred approach: give new products a contained sandbox that relaxes company constraints without risking the core. Uber and Opendoor can sandbox geographically by city; Uber Eats went further — “a totally separate app… a totally separate everything.”
• Against the common rule that product two must benefit product one: it doesn’t have to — but it must exploit a competitive advantage. His 2x2 of customer set × capabilities: new customers plus new capabilities “is probably just a new company.”
• Opendoor’s own error: building heavily buyer-side (retail buyer business, mortgage) instead of new-capability/existing-customer. Mortgage failed, but he resists hindsight: “it’s hard to divorce bad decisions from bad outcomes” — those were well-reasoned calls. The right focus now: sellers.

5. The kernel of truth, velocity over taste, and 65% data

• His signature framing — the product job is finding “the kernel of truth in a sea of cacophony”: feedback arrives as solutions (features demanded, deals lost), and the job is to distill what actually matters. Uber’s kernel: is a car available, within five minutes, at a reasonable price — “all the other product nuances kind of fade away.” That distillation failure is also his quick-fire answer for why founders miss product-market fit: “falling in love with the solution, not the problem.”
• On speed versus taste he’s openly on the velocity side: “the more shots on goal you take with that feedback loop, the more likely you are to succeed” — but you can’t ship crap, or you get a false negative from bad execution; that’s the “viable” in MVP.
• Gut versus data: he puts himself at 65 on a 0–100 data scale, with an Opendoor-learned caveat — “talking to users is data… if you talk to 10 customers and they tell you something, that is just as much data as I looked at 150 data points.”
• On redesigns and the novelty effect (Harry’s example: losing the iPhone home button), you may need to set up the experiment for patience: evaluate the experiment on week 5-through-8 data, not week 1-through-4. And on simplicity: “for a given necessity of complexity, simple is better” — “push button, get ride” was simpler, but the slider was the simple UI once multiple car types became necessary.

6. Consensus is wrong, and disagree-and-commit has a shelf life

• Harry sets up the fight: Spotify’s Gustav says “talk is cheap and so we should do more of it,” while Harry — “incredibly bold and arrogant given he’s CPO of like a hundred billion dollar company and I have a podcast” — thinks dictatorial product leadership is underrated. Brian threads it: “consensus product decision making is challenging and wrong” (“you think A, I think B, let’s meet in the middle”), but so is not hearing B at all. Gather everyone’s expertise, then decide — both agree “very rarely does a slower decision lead to a better outcome.”
• Harry’s sharpest pushback of the episode: people who fundamentally disagree won’t work weekends — “you’ll get participation,” not commitment. Brian’s concession via the Steve Jobs Stanford test: disagree-and-commit works “for a sprint, for a month,” but “if I’m disagreeing and committing too much… I’m in the wrong place.”
• His defense of “alignment” against Harry calling it a BS management term: everyone, at any time, can fluently state the most important thing they’re working on, why it matters, and how it ladders up — “not necessarily agreement.” Related craft: after holidays or a reduction in force, deliberately make an unnatural prioritization — ship something high-confidence, low-effort fast — because momentum compounds.

7. Hire your strategy, then stay long enough to matter

• Not all PMs are created equal — they grew up as designers, engineers, data people, ops people — so hiring is PM-team fit, the analog of founder-market fit, on two axes: what the product needs (a backend algorithm product needs a mathy PM) and what the functional team lacks (sometimes “that crazy out-there tinkerer” to inject energy). The Opendoor phrase he keeps: “you hire your strategy.”
• When hires fail it’s “almost always the company or the hiring person’s fault”: no clear definition of success, the wrong skill set for the actual problem, or “the ambiguity of the role was above that person’s ability to distill.” Interviews: the best signal is people you’ve worked with; otherwise an ambiguous case study — the test is clarity of thought, never the learnable tactics (sprints — two weeks for most teams, one for growth — and prioritization can be taught). His single most undervalued source of PMs: internal transfers from other functions.
• Against Valley promiscuity (“you jump from one AI company to another right now”): if you hop every 18–24 months with a 6-month ramp, “you just don’t have that much time to be effective” — context on company and customers compounds. His advice to a new grad: join a relatively early-stage company — “seeing some of what works but allowing you to make your own mistakes.”
• Why he potentially enjoys operationally heavy products, where a third party can wreck your beautiful software: “computers are deterministic, humans in the real world are not” — at Opendoor, he describes the core triumvirate as product, operations, and design.