Chapters
Shownotes Transcript
David, great to see you. And Brian, wonderful to have you on the Acquired Limited Partner Show. Thanks for having me. This could not be better timing with Uber set to price and start trading next week to have an OG person on here telling us about how the magic all happened. Yeah, it was a wild ride. So happy to be on and chat through it.
One that continues. Brian is a good friend and we're super excited to have him here on the LP show. He had a front row seat at Uber through a lot of the evolution. You were one of the first hundred or so employees. I think you joined right after the Series B. Is that right? That's correct. It was summer of 2012 and I think we were just at a hundred. Wow.
Crazy. And you joined right out of undergrad. Right out of undergrad. Right out of undergrad. And so you started in the SF Ops team. Then you moved over. You started the product ops group at Uber. Then you moved fully into product and you ran UberPool and shared rides for a couple of years. So we'll get into all of that. But now Brian is running a product group at Opendoor, which is another...
tech eats the real world company, which we'll also talk about. But super pumped to have you on the show. Thanks for coming on. Yeah, absolutely. Excited to be here and talk Uber, Opendoor, and whatever else we delve into. We thought Brian would be a particularly awesome guest because on the main show, we talk about exits and sort of the
We touch in retrospect on the narrative of the stories along the way, but often the sausage is actually much more complex than I think a clean narrative would tell. And so Brian's a perfect candidate for the LP show to talk a lot about the more detail-oriented intricacies of how these great companies were actually built. And I got to say, Brian, you sure can pick them. I mean, Uber right out of college at 100 people and now Opendoor. It's a pretty good track record.
Yeah, I'd rather be lucky than good any day.
So I got asked to start. So you had just graduated from Stanford, undergrad. People had heard about Uber, but how did you get a job at Uber right out of undergrad, you know, at like Series B stage? Yeah. So I first actually heard about Uber in 2011, or maybe it was late 2010, when it was still called the Uber Cab. And I was actually in the, sounds pretty nerdy, but I was in the Stanford Venture Capital Club, which basically meant we did some... There were people at Stanford interested in venture capital?
A couple, and they all join a small, tiny club of five people. Um...
And basically what that meant is we worked with VC firms on sort of a per project basis. And basically the deal was we did some diligence to provide our thoughts and they provided some mentorship on how VC world works. And so we actually were doing a project on these new age taxi apps. And we're looking at... Taxi magic. Taxi magic. Yeah.
out of London, Cabulous, which became Flywheel, and UberCab. That was my first introduction. I actually recently got reminded that at the end of the project, and I didn't remember this, we actually recommended UberCab
Uber as the winner. So, but a fortunate guest back then too. But how I really got there was a buddy of mine who I'd worked with at Stanford had joined a year before me on the ops team and basically called me up as I was graduating and said, hey, I'm
We're looking for smart, hardworking people. Are you interested? Went through the process. Actually did my final interview on July 4th, which is maybe a little bit of a precursor to some weekends and holidays.
And then it was off to the races. Wow. Wow. So you joined on the SF Ops team. What were you doing for that first year or two when you joined? So when I first joined, Uber was... Well, it's still a little bit to this day, but particularly back then, Uber was highly distributed as an operating model. And so there was...
Very literal centralization. No centralized growth team, no centralized marketing team, no centralized funnel team, no centralized onboarding team, no centralized pricing team. And how many markets was Uber in at this point? Maybe eight, ten, something like that. It was kind of New York, Boston, Seattle, San Francisco, LA, Paris, New York.
There would be a team of four or something deployed into a city and they would handle sort of all of that stuff within the small group.
Yeah. So the atomic unit of a city was basically what we called a operations and logistics manager, a marketing manager, which was basically supply side, demand side, and then a general manager. And like I said, everything was really decentralized. There was a small product and engineering team in San Francisco, and then a team of data scientists who were working on Surge. Outside of that,
It was all pushed out into the cities. Yeah, exactly. Yeah. So how you priced, how you onboarded, who you onboarded, quality of drivers, local marketing stunts, all of that. And so it was kind of like running a bunch of small businesses that happened to share an app. And this is what's super cool. I mean...
To the best of my knowledge, Uber basically invented this model of all of that, like a huge bulk of what constitutes a tech company living within quote unquote ops distributed in the real world in cities. How did that start? Yeah, I think it was always from the very early days. Travis really deeply believed in this decentralized technology.
And I think to be clear, over time, breaks is the wrong word, but you start to realize that there are some efficiencies of centralizing some of these functions and product and engineering as it capitalizes.
catches up to how fast ops can move when you're young sort of brings some more firepower and horsepower to growth and marketing, onboarding and funnel optimization and process standardization and all of that stuff. But I think when you're young and early, especially in a company like Uber where every city kind of has some of its own dynamics, you get this Petri dish effect where basically every city has
gets to run a bunch of experiments and the whole company learns a lot faster than you could in a centralized world. What are some frameworks for making sure that you actually spread those learnings throughout the company? Because I could imagine it'd be easy to just keep them in the little field office in Seattle in a corner, you know, and... And this was the, you know, famously Uber had the playbook, right? Yeah. Tell us about the playbook. Yeah, so Uber was always really good at having a culture of playbooking and it was...
And I think that celebration was really important, which is if you did something really cool in your city, whether that's a new Excel spreadsheet or a new process or whatever,
a new stunt or whatever, like that's cool. It's way cooler if you then get on the all hands call, talk about it and say, here, I'm going to share out exactly how it worked. It would be awesome if other cities followed suit. And so celebrating those wins was great in the early days as the company got bigger. There was this team called the pro team, which was centralized in San Francisco. I think it stood for
Process resource optimization or something. I don't know. Something not awesome. And part of that team's job was exactly this playbooking process. It was being super in touch with every local city team. What was the sort of cutting edge innovation and then being responsible for playbooking that and sharing best practices. And did...
Where did this live? Was there a massive Google Doc? So it was... What's funny is, yes, Uber was very good at playbooking, very good at sharing best practices. I would say not particularly good at the organization of those best practices. So yeah, it was a collection of Google Docs and spreadsheets and...
other PowerPoints and whatever that just got passed around from person to person. There was a knowledge base over time, but knowledge bases are famously difficult to keep up to date and difficult to manage. I can't imagine the Uber culture in those days being too receptive to like SharePoint. Yeah, yeah, exactly.
for each of these city teams in those days, like what was the directive from San Francisco from on high? Like was it, each city was given like a North star of just like maximize rides and that was like go to town or like what, what were the goals? Grow, grow. Yeah. Yeah. Um, uh, get as many people on the platform as possible. There were some beautiful, uh,
network effects, local network effects in the business, but also viral effects in terms of people sharing and talking about it. And once people try it,
But I guess that's the, so was Uber HQ saying maximize number of, of participants like riders and drivers or number of rides, like, or, or just like maximize everything. I mean, yes, it was maximize everything yesterday. Um, but it was more about getting more new people on the platform. Um,
Because in the early days, that's the most... Obviously, retention and repeat is super important always and in the long term. But in the very early days, especially with competition, signing up more people gives you that head start. Yeah, exactly. And I guess kind of the beauty of having terrific product market fit like Uber does is you can defer some of those...
hard thinking around retention because it's like, yes, we know once people try this, they like it, they come back, they use it again. So how much they use it again, can we juice a little bit more from their usage? Sure. But like, let's just get as many people trying this as possible. So put another way, you can just totally optimize your metrics around new people joining the platform and then just sort of trust that all the down funnel effects will happen because of the product market fit. Yeah, I would say that's,
True. The second part that we were super, super careful of, and Uber still has to be super, super careful of, is running a marketplace and the dynamics of supply and demand. So it's grow, grow, grow, but grow in lockstep. If you bring on way, way, way, way, way too many riders, they open the app and they get what in the early days, I don't think this really happens anymore, but in the early days, what we called an unfulfilled market.
which basically meant you opened the app and you saw no cars available. Right, I remember that. Yeah, and that's the awful experience, right? Because the promise is you don't need to call a taxi, you don't need to drive, you can go out to dinner. And then if you go out to dinner and you're at dinner and you open the app and it says, sorry, no cars available, we just broke our promise. And so...
You know, in the early days, you create those experiences, I don't want to say all the time, but they happen, right? And same thing with a 12-minute ETA, a nine-minute ETA. People get frustrated. Totally. Then that's worse. They never come back. Somewhere in between, they jump to your competitors. Totally. Yeah.
We want to thank our longtime friend of the show, Vanta, the leading trust management platform. Vanta, of course, automates your security reviews and compliance efforts. So frameworks like SOC 2, ISO 27001, GDPR, and HIPAA compliance and monitoring, Vanta takes care of these otherwise incredibly time and resource draining efforts for your organization and makes them fast and simple.
Yep, Vanta is the perfect example of the quote that we talk about all the time here on Acquired. Jeff Bezos, his idea that a company should only focus on what actually makes your beer taste better, i.e. spend your time and resources only on what's actually going to move the needle for your product and your customers and outsource everything else that doesn't. Every company needs compliance and trust with their vendors and customers.
It plays a major role in enabling revenue because customers and partners demand it, but yet it adds zero flavor to your actual product. Vanta takes care of all of it for you. No more spreadsheets, no fragmented tools, no manual reviews to cobble together your security and compliance requirements. It is one single software pane of glass that connects to all of your services via APIs and eliminates countless hours of work.
for your organization. There are now AI capabilities to make this even more powerful, and they even integrate with over 300 external tools. Plus, they let customers build private integrations with their internal systems. And perhaps most importantly, your security reviews are now real-time instead of static, so you can monitor and share with your customers and partners to give them added confidence. So whether you're a startup or a large enterprise, and your company is ready to automate compliance and streamline security reviews like
like Vanta's 7,000 customers around the globe and go back to making your beer taste better, head on over to vanta.com slash acquired and just tell them that Ben and David sent you. And thanks to friend of the show, Christina, Vanta's CEO, all acquired listeners get $1,000 of free credit. Vanta.com slash acquired.
One thing that's always been in my mind is in Uber particularly, is it harder to acquire and retain the supply side or the demand side? And is that the same market to market or is it always sort of in flux and it could be either in either market? It's changed over time. But if you really pressured me and said today, like, pick a side, it's definitely the supply side.
from a demand side has crazy product market fit. And there's this beautiful flywheel where the more riders you have, the more demand obviously there is. And the more demand there is, the more drivers drive on your platform. And the shorter the ETAs means the less wasted downtime. And so that's kind of the local flywheel. But that said, I'm sure like, especially in the early days of,
That may be true in aggregate, but that's not true at any given moment of the day, right? Like, I mean, in the afternoons, right? Like, in the early days, there probably weren't that many people using Uber at 3 p.m. or whatever. Yeah. So you probably had supply-side excess in the marketplace. Yeah. So in the early days, especially when it was, like, just Uber Black or fully licensed UberX, which...
UberX when it launched wasn't originally peer-to-peer. Covered on the Lyft episode. We'll cover again on the Uber IPO episode. Back in those days, we actually oftentimes would slow down or meter or stop what we called driver onboarding because...
We were waiting for demand to catch up. There were totally times when it was like, hey, we had a lot of partners who wanted to put another car on the system. A lot of the Uber black partners there owned multiple cars and ran limo businesses on Uber. So yeah, it was really about metering that supply and making sure the marketplace metrics around unfulfilled driver earnings per hour, ETAs, were healthy. Yeah.
So even in the early days, there was a centralized team of data scientists that were managing the marketplace, but focused purely on Surge. Is that kind of how the marketplace team started? Yeah, exactly. So the early directive was dynamic pricing or Surge. And then I assume now it manages everything across the marketplace. Yeah, I mean...
Obviously, the first step for Uber, I mean, there are basically two things you need. You need an app. You need a rider app and a driver app, and you need a dispatching system. So the team was also obviously responsible for taking care of that. But in terms of the data science and heavy data lifting, in the early days, it was all about search. It was all search. Yeah, and now, obviously, it's much, much, much more complex with a much more complex
dispatching system and marketplace metrics and all of that centralized and driven by product and engineering. While you're still working in ops in San Francisco, what does the product team look like? Are you guys on the same floor in the same office? Yeah, so the first office I worked in was 800 market and everyone was in one floor and everyone in SF could fit in one conference room for our weekly all-hands meeting.
That's crazy. Uber is what, like 18,000-ish people now or something like that? I don't know. Yeah. Something in the tens of thousands. That's crazy to think through. The product and engineering team was focused on basically reliability of the apps and the dispatching system, as well as continuing to pump out new features. Obviously, we look at Uber today.
And the app is actually still relatively simple. But if you go look at a screenshot from 2011, 2012, 2013, it's like single button, kind of large icons. Hey, it got the job. Jump around. Hey, it got the job done. It totally got the job done. But the product and engineering time at that time was basically, one, keep up with growth. Two, from a scalability perspective, two, add more and more features. But back in the day when it first launched, there was one car type.
So, okay, now how do you add...
There was a map where you dropped pins, but there was no mapping system for Uber, right? Totally. Once the ride started, it was like, okay, driver, figure out how to get there, right? Totally. And if you dig in, there are obviously a lot of parts of it. Yeah, there's the mapping, the routing, the pin drop, the driver side, the driver pickup, the receipt you get after it, the support elements of what happens if something went wrong, etc.
Which never happens. Which never happens. Yeah. Yeah, there's actually a pretty complex life cycle there. Even on a per ride basis, it's like a gigantic state machine that you can optimize every single sort of moment of that experience. And it's still...
I think it's something where when these new ride-sharing services launch and try and compete just in one market, or there's ride-sharing aggregators or people that try and plug into that system, on the surface, it seems so simple. They order a ride and it comes. But there's so many states that need to be optimized along the way to actually deliver on the experience that Uber and Lyft have come to make people expect today, that it's actually a very complex piece of machinery to create that really simple experience.
Yeah, I think that's totally right. And I think, you know, starting a ride sharing business today would be super challenging from both the technology perspective, but also it would just be very hard from a network effects perspective to spin up a new Uber or Lyft and try and compete in the market. Obviously, there are ones that have different angles and carved out different niches and that can totally work and make sense, whether it's for kids or for...
Close to viable one in the US was Juno in New York, I think, right? Yeah. And Juno came in, obviously, with a lot of funding in New York. And frankly, I don't really know how it's going. But clearly, they haven't rolled out nationally and become a really viable... You still talk about Uber and Lyft. Yeah, basically. You've got the product team in San Francisco that's trying to make sure the button still works every time people push it. Then you've got everything else happening in the ops teams in the cities...
At some point, it sounds like you saw, as you said, that is great in the early days, doesn't scale super well. So you then started the product ops group. What was the goal of that group? So that was after the pro team, as we talked about, had started. And Uber at this point had gotten pretty big. I don't remember the exact size, but it was definitely quite international, maybe 100 or so cities.
A lot more had been centralized. There were a lot more product and engineering resources that had built out a lot more scalable systems, optimized funnels. We had safety teams and rider experience teams and growth teams and kind of the more standard product and engineering teams. But you still had this massively distributed ops org all over the world running experiments and doing their thing and having local market nuances and needs and whatever and basically everything
Over time, what developed was sort of a bi-directional communication gap where we were building all of our product from San Francisco for the rest of the world.
the local nuances, insights, feedback, et cetera, from the people operating the business every day in those cities weren't being effectively translated back to San Francisco. And then once a product had been built, rolling it out internationally, training the right people, getting the right buy-in, et cetera, was also a challenge. Yeah. What's an example of one of those local nuances that would have to get translated into the product that wouldn't be obvious if you were just a product manager or engineer working back in San Francisco?
I remember Neil Camerady telling me about cash in India. Yeah, that's actually the one I was going to bring up. How important cash is, is certainly one. Certain safety features in different countries would be another. I think a third, which is less, maybe more obvious, maybe less obvious, but more intricate over time,
is how different road structures can play into the dynamics of Uber in terms of, and this was more important, I think, probably in the Uber pool days when crossing the street in San Francisco isn't great, but it's not the end of the world. Crossing the street in China is really hard. It's like 12 lanes and a nightmare. Yeah.
And so you have to be really thoughtful about side of street and the matches you make because... Yeah, suddenly that's a factor in the model that is incredibly important instead of relatively dismissed.
Yeah, exactly. So a lot of that and frankly also just understanding what's important for different stages of different markets. It can be easy if you're a new product or engineering hire in San Francisco in 2015 to forget what it's like when there are 12 cars on the road. Yeah.
Yeah, yeah. But there were cities at that point that that was the case. But there were cities that that was the case, right? And they were still in that early stage growth phase and their needs were a little bit different. You start building the group. Who are the people you're recruiting into this group and what were all the different roles? I mean, this is like...
You're like the ultimate translator of actual languages and metaphorical languages here. So Uber at the time had a... Well, actually still to this day, had a model for product and engineering that it called platforms and programs, which is basically platforms are collections of engineers who build products for other engineers and programs are what you would consider your more traditional two pizza product team. Call it five.
five to 10 engineers, a PM, a designer, maybe data scientists, depending on the team mission and need. And so the original model for product ops or the vision was to have one product ops per program team. Now, obviously in the early days,
product ops and many program teams. I believed it was important and we as a company believed it was important that as much as possible, those people actually have operating experience within Uber. So all of the early product ops, and I think all of the product ops still to this day are internal transfers from people who have actually been in market.
And market. So more important to have been on the ops side than to have been on the product side before coming into. Yeah, correct. And yeah, I think it was really important that you both had the relationships with people in the cities as well as the expertise of actually understanding how the business runs day in and day out.
You mentioned two pizza teams, which any acquired listener and us too is going to immediately think of Amazon. One of the reasons we wanted to do this with you is like, it's fair to say Uber really invented all of this way of like bringing tech and option product into the real world.
But who did you guys look to? Obviously, there's a lot of Amazon DNA in Uber with Jeff Holden on down. Were there places that you were like, okay, this is sort of a model we can follow and tweak? Or were you inventing whole cloth? Yeah, I don't know if there was like...
model per se that we were looking at. Obviously, Jeff brought a lot of artifacts on the product side. Jeff Holden had been SVP of products, I think, at Amazon. Yeah. And then gone to Groupon and then came to Uber. Yeah. So he had been at Amazon for a long time, maybe 10 or 15 years, and then started his own company that got bought by Groupon and then was CPO at Groupon and then came over to Uber.
He brought a lot of stuff, including sort of the two-pizza team program model, writing narratives for each team, and sort of that six-page, which we adapted over time, pre-meeting narrative type thing for a product team. And did you guys do the whole Amazon pre-meeting narrative, sit down, read the narrative before a discusser? You guys didn't have time to do that. Yeah, I would say not nearly. I've never obviously worked at Amazon, but it sounds like not nearly as diligently as they do it. I think it was more about...
planning time, making sure that every team had an enduring mission and a narrative that laddered up to that mission. And Jeff was pretty good and thoughtful about pushing that through when he came on.
So, David, as you say, you know, Uber was really a pioneer here for Brian. Have you seen other people sort of adopt this org structure and put this product ops group between product and operations and who does this well? And, you know, what does it look like today versus when you were first sort of starting it five years ago?
We were first setting out to do it. I actually spoke to a couple people at Google who kind of had something similar-ish between sales and product and engineering. But obviously the business was much less tangible, real-world focused. I recently got pointed to a Quora post where it seems like people are now talking about this and more and more of these companies that have this real-world online-offline component
are adopting that model, including frankly, Opendoor, which also obviously has a very, even more physical, tangible, real world component and a city by city, uh, structure. So Opendoor also has been, been building a product ops, uh, over the last six, six, nine months. And so I think we are starting to see, uh,
more and more companies adopt it. I haven't really done my homework of circling back and saying, you know, who's particularly done it well. But I know it continues to be a strong emphasis at Uber. There's this amazing Ben Evans talk from Andreessen Horowitz that came out maybe six, nine months ago, where he talks about how generation one of the internet was
quote unquote, easy because you were just moving bits around and moving information around. And now we're actually into the hard part where most of those businesses have been relatively conquered. I mean, information is free to move around the internet and we all know there's plenty available, but now we're into the hard businesses of, you know, moving lots of atoms around and actually doing the, you know, there's a much greater part of GDP that can be captured if you're actually in the business of
things with atoms and things in the physical world. And it's interesting to think about how org structures broadly need to change in this world where internet businesses are now also real world businesses in the dramatic amount of cases, especially for the future big ones.
Yeah, I think Uber always thought about it as a twin turbine plane. And maybe for a short period of time, you could fly on one engine. But if you want to operate at full efficiency, you need both engines working in tandem and working effectively together. And I do think, transparently, it also kind of depends at different stages of a company's lifecycle where a lot of the benefit comes from. So when Uber was super young...
Obviously, it's much harder and longer to hire and build good software than it is to change process or just scrappily do things. And so a lot of the early benefit for those first few years of Uber was all about ops hustle. That was the engine that was providing the thrust. Yeah, exactly. The other one was just stabilizing. Exactly. It was trying to...
Yeah, EPD was all about scale and keeping up and shipping features when possible, but ops was just sprinting ahead. And then over time, obviously, as you build better and better products, more insights...
more engineering capabilities. What happened was some of the work being done in city teams no longer made sense to do on a local level. Not everyone had to reinvent the marketing email. That didn't make sense anymore. This is a perfect transition to pool and shared rides where now product is the one that's accelerating the thrust forward. Before we get there, though, we're going to cover all this on the main show on the Uber episode, but
I got to ask since you're here, you mentioned when you started ProductOps, Uber was now in hundreds of cities around the world. Was there a moment at Uber, like nobody else anywhere, no other ride sharing company kind of anywhere decided we're going to go global?
Was that a debate within Uber? Like, what was the moment where you guys were like, yep, we're going global? Yeah. If it was a debate, it was a debate that happened before I arrived, because by the time I arrived, Paris had launched. And some of the inspiration for Uber, as the story goes, is from Paris. So I think Paris was the second or third city that Uber launched. Yeah, I think Paris was right after that. Uber was international pretty early on. Obviously, it had a continued focus and emphasis to
to grow internationally, enter more geographies, enter more countries. And I think that was always part of the strategy. So never a debate. When I was there, it was, yes, we need to be in India. Like, yes, we need to be in Europe. Yes, we need to be in Latin America. Of course. It's just like, why didn't any other ride-sharing companies do that? Like,
I mean, it's really hard. Yeah, really. Like, you have to build... A, you have to hire in all those markets. B, you have to make sure your technology scales. C, you have to think about internationalization and translating your app to all different languages and left to right. Meanwhile, everybody here is still on fire in the US. Exactly. And there are local dynamics and regulations and...
nuances in every market. And so it's hard. And, you know, I think there's value in acknowledging, I mean, I don't want to say it was a distraction. I think it was deeply important to Uber. So it was core to the strategy. But,
There is value sometimes in saying, no, we're going to focus on the U.S. first, and then we'll figure out international. Obviously, Uber took a different approach, but it's a hard one, right? We fought a battle in China for a long time, and the company was heavily focused on China, heavily focused on India. It's just hard for a company to be focused on so many different things at once. So I think that's why...
A lot of other companies didn't go faster. But what you saw, obviously, is local competitors crop up all over. Didi in China, Ola in India, Grab in Southeast Asia. So I think that's how kind of the model spread. And Uber always thought it was deeply important to, which I think is the right strategy, to go...
compete early on in those markets, like knowing that there are going to be local competitors that crop up. I think it would be hard if Uber had just said US. If you're not there in the beginning, then you're not even in the game. Yeah, it would be hard if Uber had just said yes to now go to India. Was there a mantra too around we should go and do the hardest ones first because then the other ones will be easy? Or was it more around like we're going to get out-competed there if we don't go now? I think it was more about just we should do all of the biggest ones yesterday. Yeah.
And so it was more about like, oh, it's a big city? Yeah, we should be there. Like, oh, it's a big city and we can operate there, right there? So the part of the model we didn't talk about is in the early days, Uber had a pretty...
strong and large launch team. And basically, that person would parachute into a market, make sure we can operate there, do the checks, hire the initial team, and launch the city, and then go to the next one. And so those launchers would just travel from pretty much like biggest city to biggest city. Well, it's funny.
I want to move on to product. We will cover this in the Uber IPO episode. Everybody forgets Uber followed the rules. Like Uber was kind of the only company that actually followed the rules despite, you know, what people thought about it. So we'll cover all that on the main episode. Okay. Uh, pool. Yes. Cool. Um, so, so if you, if you look at, uh, kind of the narrative arc, uh,
Uber on the rider side over time, it's about more affordable and more accessible options. So obviously the company started with Uber Black and it was a premium product and fairly pricey. And then a licensed UberX product and that was a little bit more expensive than taxi. Then we actually launched a taxi product and then UberX got cheaper over time as it got more efficient and peer-to-peer stuff.
And now, obviously, it's significantly cheaper than a taxi. But at some point, you have a limit on where the pricing of UberX could go. And obviously, this was before, which we can talk to, upfront pricing, which is what you see in the app. So it's still per mile, per minute, et cetera.
And so I was like, okay, what's that next wave of innovation? The next kind of UberX to UberBlack, what's the link to UberX? I would say the X to UberX, but that doesn't work so well. UberXX is probably not a good brand. Yeah, exactly. That doesn't work. And so obviously carpooling has been around for a long time. Uber didn't invent carpooling, Lyft didn't invent carpooling, but it's hard to coordinate, right? Yeah.
Basically, we realized, hey, we have all these trips that start in similar places and end in similar places at similar times, right? There are natural commuting patterns. There are natural transportation patterns of a city. We can actually do this carpooling thing pretty well at scale. And if we do, we can actually unlock a step function change automatically.
the affordability and accessibility of Uber. So that was kind of the initial genesis. And then it was, okay, let's go make it happen. Yeah. Wow. You guys knew from the beginning, like this could be huge. Like this is a big initiative. How did you start? Yeah, it was actually a
small initiative. It's still in the earliest days was still the two pizza team model where the initial team that launched the first product I think was like eight or nine people. And so it wasn't crazy large like you hear these stories orienting the whole company around it. It wasn't like that. It was like, yeah, this is a thing that we want to try. And obviously carpooling can be big, but we didn't actually know
how people would react, right? Uber has this like amazingly simple, easy value prop. You push a button and you get a car and you get that car relatively quickly and it takes you to your destination. Now it's like you push a button,
You might get matched with someone else. You don't exactly know how long it's going to take. We didn't really know how much to charge. It's a dice roll. I remember the early days of UberPool, frankly, before all the kinks were worked out. And sometimes you could have a pretty good probability of getting a ride without another rider joining. And I remember being at the Seattle airport and it'd be $35 for an UberX or it'd be like...
for an uber pool and like sometimes i would get it all alone and i remember like feeling this rush of adrenaline when i'd be like uber pool do it yeah totally totally and it was this like super weird dynamic back then where you're like stoked when you don't get matched but like that's but what our incentive is to try and match you is like kind of weird you know
So yeah, I mean, we had no real idea how riders would react. How did you position it to drivers? I mean, imagine that was even trickier. Yeah. Yeah, totally. And frankly, I think it was something we underinvested on early on back to the conversation about who's the real customer, the rider, the driver side, and which side is trickier to build. Yeah.
So I think it was an underinvestment back then. But the positioning was, which is true, is more rides, less downtime. And so you can have these longer trips where you pick up someone, you pick up someone else, you drop someone off, you pick up someone, you know, and that means more paid time. Mm-hmm.
Obviously, wasted downtime is wasted. Like it is in, you know, I assume many cities, certainly here in San Francisco, you know, pool is like... There's no question if you do a pool that you're getting like a full car load. And, you know, I imagine...
make more money. Yeah, so I mean, I took a pool here and it was a perfect example where, you know, collectively the trip was, you know, 40 minutes or whatever, which was maybe 15 minutes longer than, 10 minutes longer than it would have been on an X and that was great for him and then he got another match while I was in the car and so yeah, he keeps driving and, and,
Yeah, that was kind of the initial pitch. But I think there is an acknowledgement that also the tricky part as the driver or the trickiest part as a driver for Uber is pickups and drop-offs. And you are adding more of those as well. Yeah, it's more complexity as well.
Tell us about Opendoor. Okay. Yeah. So you had this amazing, you know, from ops to product ops to product at Uber, you know, the pioneers real world. So then you're like, you know, you take some time off and then you're like, all right, I didn't get real world enough. Yeah. I want to spend billions of dollars on physical assets. Yeah. Yeah. It's kind of interesting. You know, Uber is operationally complex for sure. And transportation is complex and hard.
But open door from a complexity standpoint is almost an order of magnitude more challenging, right? Buying and selling a home is...
It's hard. It's hard. There are a lot of steps. There's a lot of antiquated process. It's hard when it's the most important financial transaction of your life and you are 100% solely focused on it. I can only imagine doing it at scale. Yeah, exactly. And I think there's some other interesting distinctions between Uber and Opendoor in terms of how you build product. Obviously, Uber is relatively low
low dollar value, high frequency transaction. And buying and selling a home is the most expensive and important financial transaction of your life. And you do it maybe once every decade. So you have to build product in a very different way. At Uber, it was very easy to be like, oh, let's just like build it as quickly as possible.
put it together, throw out an A/B test and see what happens. People don't like it. Right? Great. That goes in the B side. Yeah, exactly. Exactly. Can't do that. Or we iterate through it. It doesn't work as well when you have lower end and it takes a while to buy and sell a home. You just have to be a little bit more thoughtful about the products you're building and have a little bit more conviction around those things because you can't just A/B test
So what are the, what are the ops and product teams look like at, at Opendoor versus, versus Uber then? The makeup is relatively similar in terms of the product and engineering teams and those being in San Francisco. Added challenge today for, for Opendoor is unlike Uber, Opendoor doesn't operate in San Francisco. And, and we don't all buy and sell homes twice a day. Opendoor does. Every individual doesn't. Yeah.
And San Francisco is probably like the last market you will ever enter because the dynamics are so antithetical to open door. Yeah, exactly. There are a lot more easier markets out there. But I think in terms of...
that twin turbine engine and having to have both operational excellence as well as a product and engineering and, and in order to be able to operate efficiently and operate the business as it should be able to have those two in tandem. I think that tenant still holds true, right? And being able to get the local insights from people operating the business day in and day out, um, but also have bring the product and engineering, uh,
resources and process and scalability and thoughtfulness and having those two work together is what gets you the best outcome. So I think that element is still true. It just happens to be the transaction is longer and harder and more complex. So you're running a product group. Have you implemented product ops at Opendoor too? Yeah. So I run a group that we call real estate operations. But in terms of
product ops we have different groups seller buyer pricing they all have product ops uh sprinkled throughout it's not obviously as uh mature as uber eventually got but yeah it's still the same tenant of how do we make sure to bridge that gap between a growing number of cities and a centralized epd team i mean i would imagine like even just pricing as an example right like price
pricing algorithms and engineering and data science around that as a core, core capability of Opendoor, having the real world connection to each market and what's actually going on there is like super important. There's only so much you can do with an MLS speed. Yeah, that's where it becomes really important to build that really strong muscle that Uber eventually did well about
what is local operations really good at and what is centralized EPD really good at and how do we make those two hold hands and work together really effectively to drive the best outcomes for customers. Awesome. Awesome. Well, with that, Brian, as we wrap here, where can listeners find you on the internet? They can find me on Twitter under my name, Brian Tolkien. That's
That's probably the best place to find me. If listeners are curious about Opendoor and what markets do you operate? Well, probably too many to list. Yeah. What's the best way to get on the platform? Yeah. So feel free, obviously, to check out the website, opendoor.com. You can also download the app if you're a buyer looking to browse homes in your area. Yeah.
And if you're interested in potentially selling your home, yeah, go on the website. And currently, what's the... I'm thinking about selling my home. I'm curious about how quickly can I get my home sold to Opendoor? It's actually really fast and often more dependent on how quickly you would like to move. But yeah, if you go through the process, you fill out some questions, and then you can get an offer on your home really quickly within a day. Yeah.
And then from there, it's, you know, how quickly do you want to accept or think about it or kind of what's your process looking like? But yeah, the initial step to get a value of your home and get an offer is actually really, really fast and easy. So yeah, if you're thinking of selling your home, check it out. Yeah, cool. It's so cool. I mean, having...
Participated a couple times in this market that is so different from a traditional experience. Yeah, and I think it's actually really cool to bring the same tenets of simplicity and ease and convenience to buying and selling a home, which I don't think most people who have gone through the process would ever describe as simple, easy, or convenient. And I wildly understood the messiness of it before going through it. What you guys do is super interesting. Yeah.
Cool. Thank you, sir. Awesome. Thank you guys. It was a pleasure. Yeah, I can't thank you enough. Listeners, we will talk to you next time, likely on the Uber IPO on the main show. Indeed. All right. Have a good one. Cheers.
