Brian Tolkin
Head of Product and Design at Opendoor, formerly early Uber employee (employee 100) who led UberPOOL and started product operations
Where to hear and read about Brian Tolkin1 episode or test
Brian Tolkin is Head of Product and Design at Opendoor, who joined Uber as employee 100 in ops, led UberPOOL and started product operations. The most useful thing to learn from him is to aim technology at the few places it gives the most leverage, keep product and ops working as one, and build conviction without perfect data.
When you reflect the stress onto your teams, everybody tenses up and tightens up.
Lessons from scaling Uber and Opendoor | Brian Tolkin (Head of Product at Opendoor, ex-Uber)
Brian Tolkin: the story and the lessons
1Brian Tolkin's path from Uber ops to Opendoor product
Tolkin joined Uber as employee 100 and started in ops. He arrived before UberX or uberPOOL existed and spent nearly five years at Uber before Opendoor. He moved from the ops team into product.
He had looked at taxi apps like Uber Cab back in 2011, so he knew what Uber was before he interviewed.
Running a city by hand gave him a feel for the real business. He onboarded drivers one-on-one and answered support tickets with no central support team, so he had no closer view of the customer.
City results came largely from the daily inputs operators put in, though outside factors such as weekend rain also moved the numbers. That showed him which inputs actually drive results.
His Uber interview fell on a chaotic July 4th. The onsite ran from noon to five on the day Uber launched Uber SUV, and included a job simulation with a model and driver emails. Travis walked in and chatted for 30 to 45 minutes, so little of the model got built.
He offered to reschedule, and a friend told him not to cancel.
Jeff Holden mentored him into product. Holden was chief product officer at Uber and took Tolkin under his wing as a young PM.
Tolkin tries to pay it forward to people entering the field.
At Opendoor he turned off the core business to survive Covid. In March 2020 people would not let others into their homes, so Opendoor stopped buying homes for a few months and rebuilt its process.
It came out with the whole process virtualized. Opendoor makes all-cash offers, and sellers pick their closing date and skip showings.
2What Tolkin learned launching UberPOOL
The first UberPOOL beta failed by matching riders within companies. The San Francisco beta paired commuters inside the same company on corridors like the Marina to Google. The team quickly saw this could never create enough liquidity.
The small beta was partly a hedge. His lesson: don't overthink it or get too cute, because you just need a lot more people in it.
He pushed liquidity as high as possible to find the product's limits. The $5 anywhere in San Francisco promotion cost a lot, but showed how high the metrics could climb. The team then chased sustainable ways to hold that liquidity.
The ice cream, kitten and puppy promotions came from local marketing managers, a benefit of early distributed Petri dishes. "Liquidity is the only thing that matters."
He got the Chengdu launch live after a night with no sleep. The first Chinese market was set to launch at 6 AM Monday rush hour. Data center testing broke the matching algorithm the evening before, and the fix landed around 5:30 or 6 AM.
He slept on the floor, about 30 minutes in all, afraid of missing the deadline. Breakfast at 7:30 was street-food pancakes, remembered as the best meal of his life.
3How Tolkin makes product and ops work as one
He treats product and ops as twin engines. A PM in San Francisco can't walk 50 markets or know the safety nuances of South America, so field teams feed insight back to product. Ops teams also iterate faster and hold strong qualitative insight.
He frames it as harmony, not competition: "a twin turbine jet plane where you can fly the plane on one engine for a little bit."
He formalized product operations at Uber. The team sat with product but reported into ops. It carried new features out to global markets and brought market input back to the central team.
Google had a similar function under another name, and others had dabbled at Uber before him. His contribution was formalizing it and building out the organization.
Early Uber aimed scarce engineering at dispatch and pricing. Technical resources were scarcer than operational ones, so most engineering went to dispatch and pricing. Support efficiency, growth tooling and acquisition cost were left to ops.
Skipping the rest was an explicit, transparent decision. "Until we do that really well, all the other stuff is noise."
Early surge pricing kept a human in the loop. Through 2012 and much of 2013, local GMs set the parameters, such as the cap, which areas surged and which hours. The algorithm set the price inside those limits.
The reasons were that surge was new and powerful, local teams knew their cities, and a fully dynamic system was hard to build. A GM who knew a baseball game ended at 10 PM could set surge at 9:45.
He automates a process once manual iteration stops scaling. Driver onboarding grew from one-on-one sessions to classes to video. At roughly a thousand drivers a week the manual checks broke, so license validation moved to OCR and automatic checks.
This freed the people running onboarding sessions for analytics and the next process to optimize. "We have gone from the iteration stage to the scale stage and technology is uniquely good at scaling."
He designs ops-heavy products with fail-safes for real-world mess. Drivers cancel, GPS fails, and a seller may be out when Opendoor visits. Products need flex and fail-safes for these cases.
"Computers are deterministic, but humans aren't."
4How Tolkin decides when A/B tests are underpowered
He runs a power analysis before committing to any test. Free calculators take traffic and acceptable runtime and return the minimum detectable impact. That lets him gut-check his intuition and decide whether the runtime is acceptable.
Opendoor has made the mistake many times of forcing a test and expecting an answer in a month that never came. "Don't just force yourself into A/B testing without running the power analysis."
He accepts a six-month runtime for decisions that truly matter. For an important bet with no other signal, he sets a long runtime, starts early and plans around it. His example: start in June and be smarter for 2025 planning.
The real mistake is expecting an answer in a month, then pretending an insignificant result means something.
He builds conviction by other means when a clean test is impossible. Start with more customer conversations. Then try observational data, diff in diff, twin cities, geo segmentation, a long-term holdout, or 80% confidence instead of 95%.
80% confidence means being wrong one more time in 10, which can be a worthy trade-off. "Experimentation is all about increasing your conviction in the problem or the solution."
He trusts intuition when no method reaches significance, with a conviction check. He rates conviction as low, medium or high. For a consequential decision at low or medium conviction, he talks to more customers and checks whether another person's intuition matches.
If he ships on intuition, he sets a feedback loop such as support ticket volume or feature adoption, tied to the original hypothesis.
5How Tolkin runs product reviews and builds the team
He aims product reviews at improving the product, not judging it. Accountability and informing people come second to making the product better. Reviews give ops-driven companies a longer view than weekly business reviews.
Senior leaders probe and offer ideas as thoughts, not mandates. The team has depth from 40 to 60 hours a week on the problem, while the leader brings breadth from about three. "Product reviews hopefully are not feeling like firing squads."
He keeps live reviews under 10 people and shares the documents widely. Opendoor offers two sign-up slots a week, and leadership calls in work it hasn't seen so every area cycles through each quarter.
The documents also onboard new hires, who can read the last 20 reviews to see what is going on.
His review template runs from context to measurement of success. It covers context, problem and jobs to be done, potential solution, risks and premortem, and measurement of success. Reviews are bucketed by stage, up to a final "speak now or forever hold your peace" review.
He stays medium rigorous and warns against forcing content into the template or using one framework for everything.
He uses jobs to be done because few Opendoor staff are the customer. Americans buy or sell a home about once every seven years, so staff can't intuit the job from daily use as they could at Uber. The framework surfaces context outside the product, such as agents, friends and driving around looking at houses.
A home journey spans weeks, months or even quarters, with many conversations outside the product.
He challenges whether the stated job to be done is the real one. Early on the job was stated as "get an offer from Opendoor". The broader customer job is price discovery, and the narrow version was shaped by business goals.
He wants the framework internalized as a culture of questioning, not just a template to fill in.
He hires PMs for fit to the problem, not for a generic profile. PMs come from engineering, ops or design backgrounds. He treats team building like a roadmap and asks which skillset and context the problem needs.
"It's not really about is this person good or bad or whatever, it's is this person's skillset and context to the problem."
6Tolkin's rules for calm, focus and competition
He does not pass his stress on to his team. A leader's stress spreads and tightens everyone, which counterintuitively does not produce better outcomes.
He builds calm by exposing himself to stressful situations and reflecting on what got him through. His mantra: you're never as good as you think, and never as bad as you think. He also learns from books, biographies and the Founders Podcast.
He sorts the flood of signals down to the kernel of truth. Ideas arrive from CS or CX, customers, a YouTube video, executives and field visits. The test is what will really move the customer forward, and that means saying no to good ideas that don't matter most.
He calls it a hard discipline and says he constantly works to get better at it, including being comfortable with other fires burning.
He writes every idea down so its author feels heard. A Google Sheet or a Jira backlog both work, as long as the context is captured. The record lets him reference ideas later and shows people theirs was considered.
He stays competition aware but customer focused. Most people still sell and buy homes the traditional way, so the market is far from saturated. Focusing on the customers Opendoor serves well gives confidence whatever competitors do.
Uber taught the same lesson: transportation is almost infinitely large, so Uber and Lyft both had plenty of trips. "Competition aware, but not necessarily competition focused."
Opendoor's vertical integration was hard for Zillow to copy. The business demands strength in pricing, product, operations, risk and capital markets all at once. Opendoor started vertically integrated, so this has been in its DNA from day one.
Zillow once launched a similar offering, then became a partner: it brings audience and Opendoor brings the transaction. Tolkin calls it symbiotic and won't speculate on Zillow's choices.
Lessons from scaling Uber and Opendoor | Brian Tolkin (Head of Product at Opendoor, ex-Uber)
Brian Tolkin explains how product and operations teams can work together in ops-heavy businesses, how to run product reviews, and how to make decisions when A/B tests are underpowered. He draws on scaling UberPOOL globally and running Opendoor through Covid, including a vertically integrated model that Zillow could not copy and later partnered with.
Tolkin joined Uber as employee 100 and started in ops. He arrived before UberX or uberPOOL existed and spent nearly five years at Uber before Opendoor. He moved from the ops team into product.
He had looked at taxi apps like Uber Cab back in 2011, so he knew what Uber was before he interviewed.
Running a city by hand gave him a feel for the real business. He onboarded drivers one-on-one and answered support tickets with no central support team, so he had no closer view of the customer.
City results came largely from the daily inputs operators put in, though outside factors such as weekend rain also moved the numbers. That showed him which inputs actually drive results.
His Uber interview fell on a chaotic July 4th. The onsite ran from noon to five on the day Uber launched Uber SUV, and included a job simulation with a model and driver emails. Travis walked in and chatted for 30 to 45 minutes, so little of the model got built.
He offered to reschedule, and a friend told him not to cancel.
Jeff Holden mentored him into product. Holden was chief product officer at Uber and took Tolkin under his wing as a young PM.
Tolkin tries to pay it forward to people entering the field.
At Opendoor he turned off the core business to survive Covid. In March 2020 people would not let others into their homes, so Opendoor stopped buying homes for a few months and rebuilt its process.
It came out with the whole process virtualized. Opendoor makes all-cash offers, and sellers pick their closing date and skip showings.
The first UberPOOL beta failed by matching riders within companies. The San Francisco beta paired commuters inside the same company on corridors like the Marina to Google. The team quickly saw this could never create enough liquidity.
The small beta was partly a hedge. His lesson: don't overthink it or get too cute, because you just need a lot more people in it.
He pushed liquidity as high as possible to find the product's limits. The $5 anywhere in San Francisco promotion cost a lot, but showed how high the metrics could climb. The team then chased sustainable ways to hold that liquidity.
The ice cream, kitten and puppy promotions came from local marketing managers, a benefit of early distributed Petri dishes. "Liquidity is the only thing that matters."
He got the Chengdu launch live after a night with no sleep. The first Chinese market was set to launch at 6 AM Monday rush hour. Data center testing broke the matching algorithm the evening before, and the fix landed around 5:30 or 6 AM.
He slept on the floor, about 30 minutes in all, afraid of missing the deadline. Breakfast at 7:30 was street-food pancakes, remembered as the best meal of his life.
He treats product and ops as twin engines. A PM in San Francisco can't walk 50 markets or know the safety nuances of South America, so field teams feed insight back to product. Ops teams also iterate faster and hold strong qualitative insight.
He frames it as harmony, not competition: "a twin turbine jet plane where you can fly the plane on one engine for a little bit."
He formalized product operations at Uber. The team sat with product but reported into ops. It carried new features out to global markets and brought market input back to the central team.
Google had a similar function under another name, and others had dabbled at Uber before him. His contribution was formalizing it and building out the organization.
Early Uber aimed scarce engineering at dispatch and pricing. Technical resources were scarcer than operational ones, so most engineering went to dispatch and pricing. Support efficiency, growth tooling and acquisition cost were left to ops.
Skipping the rest was an explicit, transparent decision. "Until we do that really well, all the other stuff is noise."
Early surge pricing kept a human in the loop. Through 2012 and much of 2013, local GMs set the parameters, such as the cap, which areas surged and which hours. The algorithm set the price inside those limits.
The reasons were that surge was new and powerful, local teams knew their cities, and a fully dynamic system was hard to build. A GM who knew a baseball game ended at 10 PM could set surge at 9:45.
He automates a process once manual iteration stops scaling. Driver onboarding grew from one-on-one sessions to classes to video. At roughly a thousand drivers a week the manual checks broke, so license validation moved to OCR and automatic checks.
This freed the people running onboarding sessions for analytics and the next process to optimize. "We have gone from the iteration stage to the scale stage and technology is uniquely good at scaling."
He designs ops-heavy products with fail-safes for real-world mess. Drivers cancel, GPS fails, and a seller may be out when Opendoor visits. Products need flex and fail-safes for these cases.
"Computers are deterministic, but humans aren't."
He runs a power analysis before committing to any test. Free calculators take traffic and acceptable runtime and return the minimum detectable impact. That lets him gut-check his intuition and decide whether the runtime is acceptable.
Opendoor has made the mistake many times of forcing a test and expecting an answer in a month that never came. "Don't just force yourself into A/B testing without running the power analysis."
He accepts a six-month runtime for decisions that truly matter. For an important bet with no other signal, he sets a long runtime, starts early and plans around it. His example: start in June and be smarter for 2025 planning.
The real mistake is expecting an answer in a month, then pretending an insignificant result means something.
He builds conviction by other means when a clean test is impossible. Start with more customer conversations. Then try observational data, diff in diff, twin cities, geo segmentation, a long-term holdout, or 80% confidence instead of 95%.
80% confidence means being wrong one more time in 10, which can be a worthy trade-off. "Experimentation is all about increasing your conviction in the problem or the solution."
He trusts intuition when no method reaches significance, with a conviction check. He rates conviction as low, medium or high. For a consequential decision at low or medium conviction, he talks to more customers and checks whether another person's intuition matches.
If he ships on intuition, he sets a feedback loop such as support ticket volume or feature adoption, tied to the original hypothesis.
He aims product reviews at improving the product, not judging it. Accountability and informing people come second to making the product better. Reviews give ops-driven companies a longer view than weekly business reviews.
Senior leaders probe and offer ideas as thoughts, not mandates. The team has depth from 40 to 60 hours a week on the problem, while the leader brings breadth from about three. "Product reviews hopefully are not feeling like firing squads."
He keeps live reviews under 10 people and shares the documents widely. Opendoor offers two sign-up slots a week, and leadership calls in work it hasn't seen so every area cycles through each quarter.
The documents also onboard new hires, who can read the last 20 reviews to see what is going on.
His review template runs from context to measurement of success. It covers context, problem and jobs to be done, potential solution, risks and premortem, and measurement of success. Reviews are bucketed by stage, up to a final "speak now or forever hold your peace" review.
He stays medium rigorous and warns against forcing content into the template or using one framework for everything.
He uses jobs to be done because few Opendoor staff are the customer. Americans buy or sell a home about once every seven years, so staff can't intuit the job from daily use as they could at Uber. The framework surfaces context outside the product, such as agents, friends and driving around looking at houses.
A home journey spans weeks, months or even quarters, with many conversations outside the product.
He challenges whether the stated job to be done is the real one. Early on the job was stated as "get an offer from Opendoor". The broader customer job is price discovery, and the narrow version was shaped by business goals.
He wants the framework internalized as a culture of questioning, not just a template to fill in.
He hires PMs for fit to the problem, not for a generic profile. PMs come from engineering, ops or design backgrounds. He treats team building like a roadmap and asks which skillset and context the problem needs.
"It's not really about is this person good or bad or whatever, it's is this person's skillset and context to the problem."
He does not pass his stress on to his team. A leader's stress spreads and tightens everyone, which counterintuitively does not produce better outcomes.
He builds calm by exposing himself to stressful situations and reflecting on what got him through. His mantra: you're never as good as you think, and never as bad as you think. He also learns from books, biographies and the Founders Podcast.
He sorts the flood of signals down to the kernel of truth. Ideas arrive from CS or CX, customers, a YouTube video, executives and field visits. The test is what will really move the customer forward, and that means saying no to good ideas that don't matter most.
He calls it a hard discipline and says he constantly works to get better at it, including being comfortable with other fires burning.
He writes every idea down so its author feels heard. A Google Sheet or a Jira backlog both work, as long as the context is captured. The record lets him reference ideas later and shows people theirs was considered.
He stays competition aware but customer focused. Most people still sell and buy homes the traditional way, so the market is far from saturated. Focusing on the customers Opendoor serves well gives confidence whatever competitors do.
Uber taught the same lesson: transportation is almost infinitely large, so Uber and Lyft both had plenty of trips. "Competition aware, but not necessarily competition focused."
Opendoor's vertical integration was hard for Zillow to copy. The business demands strength in pricing, product, operations, risk and capital markets all at once. Opendoor started vertically integrated, so this has been in its DNA from day one.
Zillow once launched a similar offering, then became a partner: it brings audience and Opendoor brings the transaction. Tolkin calls it symbiotic and won't speculate on Zillow's choices.