Lenny's Podcast: Product | Career | Growth - Lessons from scaling Uber and Opendoor | Brian Tolkin (Head of Product at Opendoor, ex-Uber)

Episode Date: August 4, 2024

Brian Tolkin is the Head of Product at Opendoor. Previously, he was one of the early employees at Uber, where he was instrumental in launching and growing UberPool, UberHop, and UberExpress and started one of the first product operations teams in tech. In our conversation, we dive into:• How to enable product and ops to work well together• How to run great product reviews• How to make good decisions with limited data• How he uses the jobs-to-be-done framework at Opendoor• How to stay calm under pressure as a leader• Wild stories from his time at Uber• Challenges faced at Opendoor during the pandemic• Much more—Brought to you by:• Pendo—The only all-in-one product experience platform for any type of application• Explo—Embed customer-facing analytics in your product• Attio—The powerful, flexible CRM for fast-growing startups—Find the transcript and references at: https://www.lennysnewsletter.com/p/scaling-uber-and-opendoor-brian-tolkin—Where to find Brian Tolkin:• X: https://x.com/briantolkin• LinkedIn: https://www.linkedin.com/in/briantolkin/—Where to find Lenny:• Newsletter: https://www.lennysnewsletter.com• X: https://twitter.com/lennysan• LinkedIn: https://www.linkedin.com/in/lennyrachitsky/—In this episode, we cover:(00:00) Brian’s background(02:14) Career beginnings at Uber(02:49) Transitioning from product operations to product management(06:47) Product and operations synergy(10:00) Surge pricing at Uber(12:18) Scaling challenges, and stories(15:47) Opendoor and Covid adaptations(25:38) Product reviews and Jobs to Be Done(40:30) The challenges of A/B testing(42:23) Increasing conviction in solutions(44:33) Leveraging intuition in product decisions(47:07) Partnering with Zillow(52:55) Staying calm under pressure(56:25) Finding the “kernel of truth” in product management(01:00:21) Failure corner: Early days of Uber Pool(01:06:11) Lightning round and final thoughts—Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email [e-mail].—Lenny may be an investor in the companies discussed. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.lennysnewsletter.com/subscribe

You've worked at two businesses that have done incredibly well combining product in ops. Uber always have this mentality and Open Door does two of the product operations, twin turbine jet plane, where 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. What has having been in ops done to make you a better product leader? Gave a really deep understanding of how the business actually works is a pretty good foundation for them going on to say, okay, what do we actually want to build in a more scalable technology? Something else I've heard that you're very good at is staying very calm under pressure.

I've slept on the floor in China before launching Uber pool. And like when you reflect the stress onto your teams, everybody tenses up. It counterintuitively doesn't produce better outcomes. Today, my guest is Brian Tolkien. Brian is currently head of product and design at Open Door. Before that, he spent nearly five years at Uber, where he joined as employee 100, before Uber had UberX or Uber Pool or any kind of shared rides. He actually started on the ops team at Uber, moved into product,

ended up leading product and launch of Uber Pool and then taking it global. He also started the product operations function at Uber before that function was really even a thing, which I didn't know until the chat that we had. In our conversation, Brian shares a ton of lessons about building products with a heavy operational component. Also how to run great product reviews, how he implements the jobs to be done framework, at Open Door successfully, the story behind Zillow trying to compete with Open Door, failing and then partnering instead, plus a ton of great stories from the early days of Uber and Open Door, and so much more. If you enjoy this podcast, don't forget to subscribe and

followed in your favorite podcasting app or YouTube. It's the best way to avoid missing future episodes, and it helps the podcast tremendously. With that, I bring you Brian Tolkien. Brian, thank you so much for being here. Welcome to the podcast. Thank you. Appreciate it. Thanks for having me. First of all, just a huge thank you to Kavon Bakeport for connecting us, introducing us. He said all kinds of amazingly nice things about you. He also gave me some very hard questions to ask you. I hope you've come prepared. Terrific. Put me in the hot seat.

Okay, I want to spend a bunch of time talking about product and ops. You started your career in operations. At Uber, you actually started on the ops team and you moved into product. You've also worked at both Uber and at Open Door, which have both huge operational components. I think it's really rare that people won. see a company scale to the heights of Uber and Open Door with such a heavy operational component that are still tech companies. And also, it's really where someone starts an office and then moves into product and ends up where you are, where your chief product

officer is really successful company. So I have a bunch of questions here. Maybe the first is just what has having been in ops done to make you a better product leader? How does that change the way you operate as a product leader? Starting on the operation side gave a really deep understanding of like how the business actually works. You are truly operating it day and then day out. And the success of the city is, you know, in large far driven by the inputs that you are putting into it every single day on the ground and whether or not those rain that weekend, which was a nice driver of metrics.

But talking to customers every single day, like one-on-one onboarding drivers, responding to support tickets. There's no centralized support team. there was no closer to the customer, right? And so I think that foundation actually for really understanding what moves the business and being super close to the customer actually is a pretty good foundation

for then going on to say, okay, what do we actually want to build in a more scalable technology way? This episode is brought to you by Pendo, the only all-in-one product experience platform for any type of application. Tired of bouncing around multiple tools to uncover what's really happening inside your product.

With all the tools you need in one simple-to-use platform, Pendo makes it easy to answer critical questions about how users are engaging with your product, and then turn those insights into action, all so you can get your users to do what you actually want them to do. First, Pendo is built around product analytics, seeing what your users are actually doing in your apps so that you can optimize their experience.

Next, Pendo lets you deploy in-app guides that lead users through the actions that matter most. Then, Pendo integrates user feedback so that you can capture and analyze what people actually want. And the new thing in Pendo, session replace, a very cool way to visualize user sessions. I am not surprised at all that over 10,000 companies use it today. Visit Pendo.io slash Lenny to create your free Pendo account today and start building better experiences across every corner of your product. P.S., you want to take your product-led know-how a step further?

Check out Pendo's lineup of free certification courses. led by talk product experts and designed to help you grow in advance in your career. Learn more and experience the power of the Pendo platform today at pendo.io slash lenny. This episode is brought to you by Explo, a game changer for customer-facing analytics and data reporting. Are your users craving more dashboards, reports, and analytics within your product? Are you tired of trying to build it yourself? As a product leader, you probably have these requests on your roadmap, but the struggle to prioritize them is real. Building analytics from scratch can be time-consuming, expensive, and a really

challenging process. Enter Explo. Explo is a fully white-labeled embedded analytics solution designed entirely with your user in mind. Getting started is easy. Explo connects to any relational database or warehouse and with its low-code functionality, you can build and style dashboards in minutes. Once you're ready, simply embed the dashboard or report into your application with a tiny code snippet. The best part, your end users can use Explos AI features for their own report and dashboard generation. Eliminating customer data requests for your support team. Build and embed a fully white-labeled analytics experience in days. Try it for free at Explo.com.com slash Lenny.

That's EXPLO.O.com slash Lenny. I've seen that a lot of companies, and this was definitely true at Airbnb, where the product team kind of looks down a little bit on the ops team, where they're like, oh, we're doing things that are going to scale to millions of users. We're doing these things that are going to apply to everyone. There's this like ops team over there doing a few things that are going to not scale. They keep asking us for things to build, for their one-off ideas. What do you think that product teams often maybe miss or don't understand about the ops teams

that would help them see them in a different light? Yeah, it's a great question. And I think Uber always had this mentality in Open Door Desk, too, of kind of like a twin turbine jet plane where 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.

And I think that's really true, right? The reality is operations teams, local teams can iterate faster, can scale talking to customers really much more efficiently have great qualitative insights. And so if it's seen more as like a harmony instead of a competition, I think that that's really, really helpful where it's like, okay, how do we get the insights that are happening day in and day

out in the field, on the ground, whatever that may be, and help us build better products because of that, right? Like a PM sitting in San Francisco can't be in open doors case, 50 markets, walking houses every single day. In Uber's case, you know, whatever, a thousand cities. understanding the nuances of safety in South America, right? And it's just like not possible. But what you can do is foster a really good relationship

and a really good feedback loop of how people who do deeply understand those things can help give insights. Now it's actually the birth of product operations was sort of that insight as well. Can you say more on that? Yeah, sure. So I should probably define what product operations was at Uber. It was basically this notion that we had centralized, this was later in my career at Uber, but we had a centralized product team building stuff mostly in San Francisco, not strictly

truly wrong, but at this point around the world, but mostly in San Francisco. And then we had a very globally distributed operations team. And there was sort of a bidirectional feedback loop that wasn't super strong. And that feedback loop was basically when the EPD teams in terms of. Francisco built new features, how do we effectively put it in global markets? And then how do we effectively get input from global markets to better build features? And so one solution to that problem, our solution at the time, was to start up a new function called product operations, who had accountability and reported into operations, but physically sat with and operated much

like a member of the product team to help solve that. Is that maybe the first time there's a, like, did you invent product operations as a function? I don't, I don't, I don't, think so because at the time, I believe Google had had a function. I can't remember what Google called it. It was something slightly different, but I met with a few folks who had been in similar type roles at Google in a couple other places. So I don't take credit for certainly for inventing it. And other people have sort of actually dabbled in this model at Uber before me. There was just a formalization of it and their actual building out of the organization. None of that. Sounds like you basically help make it a thing. I know you're, you don't want to

You're being very modest, I think. Coming back to your point about decentralized operations team, something I've read is that search pricing came out of one GM in a market, just testing, emailing all the drivers. Hey, we're going to give you extra if you drive on Saturday night. Is that true? That would have been probably a little bit before my time. But that being said, one thing that is true is that surge pricing for actually quite some times,

probably all of 2012, certainly, 2013, probably, I don't know, when we necessarily switched, was very much a human in the loop system or a very manual system where GMs in every city would control basically the parameters in which surge would operate. And so much of the time that would need, for example, like Monday, it's and Friday, there would be no surge. Like it was just, it couldn't flip on. and then Friday nights and Saturday nights, it would flip on from whatever you set 7 p.m. to 3 a.m.

and the cap was, you know, X, whatever the cap was. And then within those parameters, the algorithm would optimize for what the price was. But yeah, GM's controlled weather was on or off and what geographies were serving. Wow, I didn't know that. Was that out of we believe we are better than the algorithms or we just don't have time to make them amazing yet. So we're just going to help them along.

Yeah. I think it was probably a function of a bunch of stuff, one of which is like, hey, this is a fairly new concept. And it's powerful and dangerous. And so let's like make sure we understand what's happening. The second is kind of this belief that, yeah, local city teams know their cities best. And so you might know that an event is happening, a baseball game gets out, right? And it's like, oh, I know that this baseball. a game's going to get out at 10 p.m.

So I'm going to set surge at 945, right? And the algorithm may not be, may not be able to pick that up. And then the third is, yeah, the technical constraint of like nowadays, clearly it's all automated. But it's really hard to build a fully dynamic, always on geospatially aware pricing system. And that's just a little bit of time. That makes sense. I feel like you're full of wild stories from your time at Uber. is there one that comes to mind of just, I think you help scale in China, Uber pool.

Yeah. Maybe that's one. I don't know. Can you share a wild story from early Uber days? Yeah. So in the early days of Uber one kind of fun story is obviously UberX is a very mainstream product, but has a kind of funny, silly name, UberX. This product in the early days was going to be all hybrid and had a bunch of different

potential names. I was not personally driving this. This was someone else on the operations team, but they built the model for what this product could be. And there's no name for it yet. So it was going to be a placeholder. So what do you put as a placeholder? X. So Uber X. And then the company was moving quickly enough. The product got Greenlight. It launched. And here we are, I don't know, 12 years later, 11 years later, whatever it is. And UberX is the name that stuck. So That is hilarious. I love it. So as a placeholder, it's like many products start that way where they're like, this is just the temporary name. And I'm like, okay, I guess everyone just knows it this way. Now we're going to stick with it. Too expensive to change and rebrand at this point. That's an awesome story. One that is good about scaling Uber pool in China is yes. So we were launching Uber pool in China. And this was going to be China at the time was pretty big for Uber, but Uber pool was not there yet. And so we're going to. We're going to. launch and myself and a few other folks were in Chengdu, China, which is the first Chinese market that we were launching with a pool in. And we were going to be on the ground to launch.

We wanted to go live at, I believe it was 6 a.m. for rush hour on Monday morning. And so we're there over the weekend, getting ready to set up. And at the same time, we were doing some data center testing. And so we flipped on all the testing infrastructure and thought it was going to work and nothing works. And the matching algorithm just isn't working and work. Oh, my God. Now it's, you know, whatever, 5 p.m. the day before we're supposed to go live, 6 p.m., 7 p.m. Okay, let's get on the phone with the US, try and figure out what's going on. I remember I slept about 30 minutes that night between 2 and 3 a.m. being like, okay, well, we like, we have to go live at 6 a.m. I think there was some press around it, right? Like, we were planning on going

live. And I think we got everything finally working at probably about 530 or 6 in the morning and launched just in the nick of time. And I'll never forget. It was, we launched. It was great. We monitored. Everything was good. And then we walked out for breakfast at like 7.30 in the morning. Everyone's sleep depred. No one slept all night. And we got these like pancake street food things and I have to imagine they were not that good, but in my mind, they're like the best meal I've ever had in my life. So. It's like a meal after a marathon or a big hike. Exactly.

Yeah, exactly. Everything's so delicious. This comes up a lot of just like these moments that are so incredibly stressful and hard and sleep deprived end up being like the best memories and the best stories to tell and things you look back at fondly. It's so weird how human nature is like that. Yeah, I mean, another one more recent for, for, open door was we, when COVID hit, right, we like physically, we buy and sell homes. And so we were physically going into people's homes and, you know, suddenly March 2020, like going into people's

homes was not, not something you were, people were comfortable with. And you look at the real estate data coming out of China at the time. And it looked like sort of coming to a standstill. And so we actually turned off. the core business and we stopped buying homes for a few months. Hey, we can't go in and we don't know if anyone was going to be buying any homes. And so, you know, what do we do? And we took those few months and then came out the other side and had virtualized the whole process. And it was pretty stressful, right? Because you're looking at a business that relies on going into people's homes. And suddenly you can't do that anymore. What do you do? So again, a fond memory to look back on

a very stressful time in the moment where it feels right. already ready to school. Just since you mentioned Open Door, I think many people have heard of Open Door. Maybe just give a quick explanation what Open Door does for people that aren't exactly sure. So we're a digital platform to buy and sell real estate. The core product today is a seller-focused product where people can go online, enter some information about their home, and we'll make an all-cash-offer to be able to sell sort of with simplicity and certainty.

And, yeah, so the product really, works for people who have a want something that that is certain and simple and easy. I don't know if you've ever sold a home, but it can be a very, very, very, very successful, difficult process with showings and open houses and how to price it and will it sell and all of that stuff. And so we offer basically a way to skip the whole process. So basically sell your house to open door and it's just like, cool, done, move on. So you pick your closing date, you move out when you want.

Yeah, there's no hassle. Sounds amazing. I want that. Coming back to ops and product, just to kind of close this thread, again, you've worked at two businesses that have done incredibly well combining product and ops. Are there any just broad lessons you've taken away from how to make these two teams and functions work well together and to build a business that's very ops heavy, but also offer driven? Yeah, the first one we touched on, which is, A, there's just, got to be mutual respect, right? Both both functions have their time and their place and their skill sets and you just don't build big businesses of this type without respecting the fact that both need to exist. The second, particularly on the product and engineering side, is really

understanding where and how the technology leverage comes from the business and then being really focused on making sure generally, especially in your earlier days, you, you, are more limited on the technical resourcing side than you might be on the operational resourcing side. And so how do you be really focused on where to invest your time, effort, and energy technically, which is why most of the engineering effort for Uber was on the dispatching system and the pricing system. That's just where the leverage was at the time, given the scarcity of resources.

And so I think the second one is being really intentional about where those tech resources are and then being really forthcoming and saying, hey, That means all these other places where, yes, it can make things easier, more efficient, etc., etc. We are okay not investing in right now, and that needs to be an explicit decision and very transparent. And then the last bit, I would say, is a deep understanding that the real world has entropy and it's hard and it's messy. For us, at open door, we go into homes. you know, someone may not be home, scheduling may be off, that Uber driver may cancel, there may be low GPS, all these things happen, right? Computers are deterministic, but humans aren't.

And so building products that have a little bit more flex or a little bit more fail safes in case those things happen, it becomes a little bit more of a paramount. One other thing, the last thing I would say is I think that the companies evolve as well. So when I talked about at the beginning of Uber being very focused from an engineering and product side on the dispatching system and the pricing system, obviously over time, not to evolve. Now, there's essentialize all of these functions as the company got bigger and more mature and scale and optimization started to be more important than expansion and sort of that petri dish of trying new stuff and the tools got better and the tech got easier. and there was more internal infrastructure. And so over time, things can start one way and shift over time as the business needs. Let's actually spend more time there.

You keep saying things that make me want to dig deeper. So at Airbnb, we went through the same thing where there was all these local ops teams, driving supply, finding homes, bringing down the platform. And then there's like this tipping point where the product and organic growth, the word of mouth, ended up driving more and then orders of magnitude more. So there's no need for these folks to spend time doing these sort of things. Can you just maybe share an example either at Uber or Open Door when you talk about like there's a time and a place and a skill set for ops, how that evolved, like what was the team doing initially and then what did they end up doing as things grew? Yeah, I mean, maybe a very easy, good example to pick just one part of the Uber process in the early days is at small scale, actually back one is Uber Black drivers.

every driver was individually onboarded in like a 90 minute to a two hour in person in the office onboarding with deep setting of expectations. The next version of that, so that's obviously very obstruven. The next version of that is kind of like a small classroom type setting of three or five or six drivers at any given time. Also very obstruven. And then as we got into more mass market products like Uber Taxi or Uber X, it was like, okay, maybe 20 or 30 at a time.

Okay, so now it's a little bit bigger classroom standing and we said, okay, let's make a video. Instead of giving verbally the same presentation, let's just make an onboarding video. And that was the next set of scale. But now suddenly we have a different problem, which is, okay, you have to validate all of these credentials. So most driver's license, who they are, all that stuff. At one person, easy. At three to four at a time, easy. 10 at a time.

A little more challenging, but fine. At 20 at a time, okay, you're starting to run up onto it. Now at you fast forward six months and you're doing a thousand a week or whatever, okay, suddenly your system breaks. And it's like, okay, we have reached the point where like operational system improvements is like no longer viable. So you say, okay, what are the, like that we've gone from the iteration stage to the scale stage. and technology is uniquely good at scaling.

So now we say, okay, instead of having a bunch of folks around the world, taking pictures of driver's lessons and validating and doing all that stuff, how do we integrate with some type of OCR technology or auto recognition of driver's licenses, that feeds to a system that knows what a driver's license is, we can do automatic validation. And suddenly you've done two things, one, you've scaled your system, and two, you've just created a ton of time for,

at the time was probably dozens, if not hundreds of people running these onboarding sessions all over the country, the world at the time, to do other stuff. And so now you can sort of level that up and say, okay, do we do more analytics? Do we do more, figure out the next process that needs optimization or whatever. The case may be in that virtuous cycle just continues. The way I like to think about this is do things that don't scale and then scale the things that you're doing. That's the phrase I always come back to.

Exactly. This reminds me of a hot take that a previous podcast guest shared in a new. newsletter post Casey Winters, he talked about that operations is usually, and this is kind of, it's a hot take, the operations is a sign of inefficiency. And over time, your job is to kind of squeeze that away and make it product software as much as possible. Doesn't mean you always get their thoughts. Yeah, I actually don't fundamentally, it depends on what the operations is, but I don't fundamentally disagree. But I think the right lens to think about it is, And then those folks can move on to the next challenge.

And so there's always another hill to climb, right? And so I think that was one of the things at Uber and Open Door, where there's sort of this culture of on the ground experimentation that's really helpful. Or yeah, like we were just talking about driver onboarding may now be solved with technology to need a few extra hours a day. Like, how do we get better at optimizing the UberX system? How do you start tinkering with food delivery? How do you start, you know, thinking about higher capacity vehicles?

How do you think about better feedback loop for those manual surge pricing sort of of how we talked about, right? So I generally agree. It just generates capacity to solve more problems. And it feels like a big part of this is making sure the operations teams understand there's more opportunity. Even if this ends up being automated, your job is not going to go away. We're going to find something new to try and experiment

and do you think they don't skip. Yep. Awesome. Okay, going a completely different direction. Good. I hear you're very good at product reviews. Okay. A few people, a few people tell me this.

I'm curious how you set up a product review and any things you've learned, any tips for how to run an effective product review. That's very kind of whoever mentioned that. But yes, a big fan of doing them. Actually, in particular, to maybe bridge the conversations in companies that have ups-driven cadences because or start out very ups driven because the cadences can sometimes be different, right? And so the operational cadences that you might have something like WBR, a weekly business review may not be conducive to always picking your head up and saying like,

hey, where's the product going on a slightly longer time frame? And so I think product reviews in general for all companies are probably really helpful, but actually in particular for some of the product and operations-led companies. In terms of things have learned, I think being really intentional about what the goals are, I think it's okay to say that there are two goals, a goal of sort of like accountability

and informed to an audience, but also most importantly, I think this is the primary goal is to help make the product better, right? To help the teams think through a problem and to have that, again, back to our earliest conversation, be a very intellectual conversation about the work and how to make the product better and not super

scary. Like product reviews hopefully are not feeling like firing squads. That's a scary environment to be in and not necessarily one that's conducive to how do we make the product better. Obviously, sometimes the conversations have to get a little intense, but in general, that's what we're shooting for is something that helps the team go back and think through how to make the product better. So the two goals you try to communicate for.

product reviews, accountability slash informing people what's happening, but also just like, we are here to make the product better and setting that context. Yep. Is there anything you do specifically to make it not feel like a firing squad, like you're coming in here to be attacked and criticized? Do you set context at the beginning of the meeting? Is this just a part of the culture? Yeah, I think definitely part of the culture, but also I'm a firm believer in general that the

people closest to the problems also have the best context to solve that problem. And so as a more senior voice in the room, often the job is probing, asking questions, throwing out ideas in a way that says like, hey, this is an idea. This is not a mandate, right? This is a thought, right? And if there's context missing, that would inform the product direction, then providing that context in not a question asking sense, but are they, hey, this is context that you might not be aware of.

And so I think it's all in how you show up as a leader. and what that looks like in terms of probing and pushing the team on dimensions that they may not be thinking about. And then understanding that the team is bringing a perspective that you don't have, which is they think about this problem 40, 50, 60 hours a week. And you might think about this problem three hours a week, right? So you bring them a breath. The team brings a depth and honey marry that. I don't know if you heard Darmesh Shaw's episode or his thing on flash tags. Have you seen this?

I have not. No. Okay. He has a whole system. So you talked about how as a leader, you want people to not take everything you tell them as feedback as I need to do this. Yeah. So he has a whole set of hashtags that communicate how important this is to him from hashtag FYI to, it to, it's a suggestion to plea. Yes. I plead at you. This was actually explained to me. I don't think I've seen the original source. So I'll go back and watch it. But this was explained to me as this. I'm actually a big fan. I think that's great.

Yeah. Just set, set, get everyone on the same page. Okay, maybe one last question here. Who do you, who do you try to invite to product reviews?

Do you have any frameworks and ways of thinking of who to invite who not to invite? Yeah, good, good question. We, I would say, have oscillated over time, but in general,

big subscribers of the, the best conversations happen when they're relatively small. So try and keep it under, under 10. Could be wide distribution of the document, right? The artifacts created. are actually really powerful and they're powerful for the whole team to understand. And sort of secret power is they're very powerful for new people who are onboarding.

Here are the last 20 product reviews. You've got a pretty good idea of what's going on. But generally, the conversation itself, try and keep relatively tight. And I'm trying to keep it under time. And these artifacts, you mean the recordings of the meeting that people can watch? Yeah, or just the document. Depends on what the company culture is, whether you want to record it or just have the document either way.

And then is there some kind of specific cadence you operate on? Is it like a weekly product of you that people can sign up for? Is every team have, how do you like to set this up the cadence? Yeah, obviously, scales are with the size of the company. For us right now, what's working well is, yeah, sign up cadence. We have two slots a week that anyone can sign up for as their product area needs it. And then if there's something that we would love to see that we haven't seen that, we do a little bit of all in telling to make sure that.

to work is generally cycling through all a quarterly basis. This episode is brought to you by Atio, a radically new type of CRM. There's a world where your CRM is powerful, easily configured, and deeply intuitive. Atio makes that a reality. Atio is built specifically for the next era of companies. It syncs with your data sources, easily configures to their unique structures, and works for any go-to-market motion from self-serve to sales-led. Atio automatically enriches your contacts, syncs your email and calendar, gives you powerful reports,

and lets you quickly build Zapier style automations. The next era of companies deserves more than an inflexible, one-size-fits-all CRM. Join modal, replicate, 11 labs, and more, and scale your startup to the next level. Head to atio.com slash Lenny, and you'll get 15% off your first year. That's ATTIO.com slash Lenny. adjacent topic. I hear you're a big fan of jobs to be done, which is, okay, so it's a, it's a fun recurring topic on this podcast. We've had many people that love it, many people that hate it. I love seeing both sides of it. I love that you find it helpful and you implement it at

Open Door. I'd love to hear just how you actually apply it at Open Door, which you've learned about how to apply jobs to be done effectively. Yeah. I think like all frameworks, the right answer is to pick your set of frameworks, have more tools in your toolbox, and then actually understand when and how to apply them. So we try to avoid being a hammer and everything's a nail. We try to force the framework if it's not working. But I think what I really like about it is it forces you to put yourself in the customer's shoes, I think in a slightly deeper way and be a little bit more empathetic. When I think about building at Open Door versus, say, building at Uber or when you're building at Airbnb is we are not, most people at Open Dober are not, we don't have homes to

sell every week or every month, nor do we buy homes every week or every month, right? This is the average in the U.S. is something people do once or seven years. I'm sure the average at Open Door is something similar. And so it's a little bit harder to be a customer. I took Uber every day. You probably used Airbnb a number of times a year. And so, you know, in some in some senses for some of those companies, you can build for yourself. You intuit the job to be done because you're just kind of doing it for yourself. We don't necessarily have that context. And so a framework that forces us to be really thoughtful and intentional about how a customer might perceive our product is really helpful. The other thing that I like about it is sort of the canonical version of it encourages you to

think about the context in which the user's operating or the other things outside of your product that they might be going through. And in our case, home buying or selling journey often is certainly multi week, if not multi month or multi-quarter journey with a lot of complexity and a lot of conversations outside of our product. You may be talking to an agent. You may be talking to a friend. You may be driving around the city, trying to find a house. And the framework is very flexible and encouraging of saying what is actually the job to be done

of this user when they're thinking about our product and what is the context in which that operate. I'd love to go one level deeper to talk about how you actually implemented. Do you have like templates of like, you have a startup project? There's like as a blank, I blank, blank, blank, blank. How do you? So we do have, I would say we're medium, rigorous on sort of template standardization or adherence. So we do have a template, the standard product review template talks about jobs to be done

and sort of has a section for like what is the problem statement and what are the jobs to be done. And this is a doc that when you're coming to a product review, the person running it and coming is like filling out this document. Correct. pre-filling it up. I'm sorry, pre-filling it out. And, you know, again, I think we are not sticklers about always using that template. But, you know, I think the beauty of a template is, yes, it sets expectations of what you expect,

but it's also just easier often for people to be able to work off something. And so, yeah, it's part of our product review template and then part of our planning process as well. Because we've used it for a while, I think there's been an internalization of the culture. where people also just start commenting about it or writing about it and saying, like, hey, what is the job to be done here? Or like, what is the user trying to do, which is another colloquial phrase of it. And so, yeah, I think there's a cultural seeding that has had to do. From memory, just like, what is in this template? So like, what's the phrasing that you try to use for setting up a problem?

Yeah, yeah. I mean, the specific framing, I would have to go remind myself on the template itself. But generally it looks like, you know, context problem, potential solution, risks, risk, slash pre-mortal and, you know, measurement of success. And then we also try to sort of bucket our product reviews by stage. So you could be in the ideation stage, which might look very different than at the very end of the process. Like, hey, we're getting ready to ship, you know, speak now for a holder piece. those two artifacts will also. Okay, so it's not like I, as I blank, like the standard jobs to be done language,

it's not exactly how you implemented. It's more just make sure we're thinking of it. What is the problem for the customer? What is the context of their problem? Correct. Yeah, yeah. We're not, we're not living our time. Okay.

Awesome. Any other tips or lessons about just working well with this concept of jobs to be done? Maybe like when you come into open door and like, hey, everyone, we're going to be thinking this way. Is there anything there that would be useful to people if they're trying to operate this way? Recognizing that correctly implementing a framework, any framework, but Dubsfield in particular we can talk about, takes a little bit of time and getting used to and understanding. And so I don't, I don't think you can just like, okay, we're going to make the template and then that makes the content better. That just takes people's content and they wedge it

into the template. It's actually the cultural internalization of like, hey, this might be phrased as the job to be done, but is this actually the job to be done? Like, let's talk about why the customer might be in that situation or not be in that situation or I think the job to be done might actually be something else. You might say, hey, the job to be done is, you know, maybe an early day version will be like, the job to be done is to get an offer from open door. And it's like, well, kind of, but like the broader job to be done might be like price discovery for the customer, right? And so you can have a rich conversation. where it's like, well, one might be like a little bit influenced by our business

goals, right? I don't think you just run around and people are like, yeah, I'm going to sell my house, my job, but like my goal is to get an offer for open door. And it's like, well, like, you know, and so that's like, okay, the template might be the same, but like it's actually the content that takes a little bit of culture of instantiation. Got it. And it sounds like people talk from what is the job to be done. That feels like a core part of the way you think about it. What is the job to be done? Yeah. Just that language alone feels really powerful. Is there a resource or a book that you point people to to help your team learn about the way job to be done work?

Is there like one kind of thing you find useful? Not about jobs to be done. We have, I point people, I do a lot more pointing people towards like internal examples of where I saw other EMS maybe do this well for blogs and stuff. But your blog is a common one when you pass around. Not about jobs to be done, but just about many topics. So I'm flattered. Thank you. Yes.

I really appreciate that. I was also thinking as you were talking, your friends with Kvon, and jobs to be done at Twitter was quite the journey for them. Traumatic for a lot of people, I think it went very far to the extreme of the way. Yeah, I think they're more dogmatic about it. Very dogmatic.

And so I guess it's a lesson here. Maybe don't take it that far. Yeah. Yeah, and I think it probably, and I don't know if Kavon would agree with this. I imagine he would, the generalized version of like, you pick the right framework for the right job. And if you say, you know, there's one framework to rule them all, and this is the only framework that works.

And then, of course, every problem into it, then you job. The way I think about jobs to be done is exactly the way you're describing it, where it's just, just think from the lens of the job to be done for customers of this. So for my newsletter, like, what is the job to be done at my newsletter? It's to help you become better at your job as a product person, building product. And that actually ends up being really helpful. And it feels like that's kind of the way you guys think about it at opening it. Yeah, absolutely.

And you're crushing it, by the way. Thank you. So are you. You talked about, I'm going to go into another question to deflect your compliment. You mentioned that Uber, there's a million transactions happening every second. It's massive scale. Open Door is completely different. You have like very few, very large transactions. I'm curious how you do experiments. If you do experiments, do you do AB tests. What have you learned about just how to think through low sample sizes plus AB? testing. Yeah. Very hot topic of conversation. We do A-B-Test. It is obviously the gold-standard, and so we do as much as we can of A-B-testing. There are parts of our funnel and flow that have more volume than others. So top-of-pulling testing if it would be easier than down-funnel. A-B-testing surely product or tech features, if easier than A-B-testing, if easier than A-B-testing. A-B-testing, surely product or tech features, if easier than A-B-testing processes, operational processes. But you're totally right.

We are not doing hundreds of millions of transactions a year. And so experimentation can be more challenging. And so I think one way to think about it is A, knowledge the problem, right? Which is to say, don't, and we've made this mistake many, many times. but don't just force yourself into A-B testing without running the power analysis and say, like, hey, are we going to get results? What is the size that will detect? And what is the runtime of that experiment? And is that, and be honest, like, is that acceptable? For there are certain, so a second lesson here is there are certain experiments that are important enough

and it's hard to try and give it signal in any other way that you may say, say six-month runtime is an acceptable outcome. And we're going to start it in June and we will be smarter for it for 20 to 25 planning. And we're going to set it and forget it and we're grateful we did. And that's okay. The only mistake here is like thinking you'll get an answer in a month when you won't and then pretending you do and then waking up a month later and being like, well, it was insignificant and this and that and we could have known that. And so. And then the third thing is like, experimentation is all about increasing your conviction in the problem or the solution. And so the generalized version of the statement is if there are parts of your funnel or flow that are low end and you can't run a canonical AB test, how might you otherwise increase your conviction in the solution that you're building?

And there turns out there are a decent number of other ways to do that. the first best, most obvious is talk to more customers. But, you know, there are other sort of statistical techniques that, again, aren't as rigorous or good, but what may be possible. You may be able to use observational data. You may be able to do it diff and diff. You may be able to look at sister cities or twin cities. You may be able to segment by geo.

You may be able to reduce your power and say, hey, we're going to run at 80% confidence for all of our experiments instead of this traditional line. 5% because that's a worthy trade-offs. And if we're wrong, one more time out of 10, that's okay. You can do a long-term holdout to match your intuition. And so there's a lot of other techniques to hone your intuition. There's a lot of other techniques to build conviction and confidence. And so we try to be very creative on doing that. And then the last last bit, I would say, is if you're not going to get significance, if there's no other techniques at your disposal, then sometimes you just got to press your intuition and ship it.

And if that's what you believe, then that's what you believe. And you shouldn't spend time trying to get false precision. I want to spend more time on the last point. But real quick, the power analysis you talked about, there's people don't know. There's calculators out there that you could just plug in. Here's how much traffic I'm getting. Here's how much of an impact difference I want to see.

Here's how long it'll take to find out. Yep, exactly. Totally. And some of the calculators are great where you can also plug in the traffic and your acceptable runtime. And it will tell you the minimum detectable impact. And then you can gut check your own intuition. So you can play around with that. Awesome.

We'll try to link to one of those in the show notes. So on the intuition piece, is there anything more there just like how you think about when you, you know, you run the product team, just how you recommend people leverage intuition versus not? because some companies are like, we're just going to trust the data. I don't really trust your opinion. You don't know. Like, you don't know. You don't know this customer. Like you talked about Open Door.

I'm not buying houses myself. So I don't know how much I can trust my intuition. Just let's your general advice to your product team of how to think about their intuition and when to rely on it versus not. So at Open Door, for example, I'd say on the relative spectrum, we're quite data-driven. And then it's when we come into this challenge, right? where we say, okay, that is another technique or tool in the toolbox. I think the generalized version of that is customers, products, people can surprise you. And so this happens all the time for people who build products.

I'm sure you've got great stories from Airbnb where you saw something, put it out there. It just was very good. All the time. All the time. Right. And so I think there's definitely a humility to say, you know, if you can, if it's relatively easy to test your assumptions or test your hypotheses, that is always better to gut check yourself. And yeah, that takes a little bit of humility to say that. But like, we've all been wrong

plenty of times. But if that's just like not on the table, I think the reality is you can't pretend it is. And sometimes you got to use taste and judgment. And then you say, okay, what is my conviction level? And do I have, you know, just medium, low or high conviction? And if I have anything lower medium conviction and it's a decision of consequence, I should, yeah, talk to more customers, got check it with another person and see if their intuition matches, something that gets me personally to the high, high bucket category. And then I think the last part, which is some part of experimentation, is if you just ship something because it's your intuition or to where you want to see the product go, do you have a reasonable feedback loop to understand whether or not

you are correct. So that could be customer support or ticket volume or feature adoption, whatever the case is. It may not be an output metric in the traditional AB test, but like some more rigorous system that says, hey, I had this hypothesis. We just shipped it for XYZ constraint reason for WM. Right. I think that's awesome advice. I agree with everything you're saying.

You mentioned this word humility. Yeah. It's a good segue to something I want to talk about, which is a good segue to something I want to talk about, which is Zillow. Okay. One of the most interesting things that's happened in your space is Zillow basically decided, hey, we're just going to do what Open Doors doing. They launched it.

You're basically frenemies for a while. And then they're like, no, we're, we're, we're, we're, it's not working. Now you partner and say now you work with Zillow on, on this stuff. So are able to share what went down there with the story of what happened, how it went and things are at now. Yeah. I mean, we, we, we do partner with Zillow. Zillow has been a fantastic partner.

for us and we've really enjoyed sort of a working relationship with them. I think when you think about it, you have a tremendous amount of reach and audience and all the sort of online platforms have tremendous reach and audience. And we happen to have a fairly exiled solution. And so there's sort of a nice, not to use a business school word, but there's a nice, synergy, so to speak, between a high-intend audience who's doing a lot of browsing and searching and discovery and starting their process on one of these online platforms. And what we offer, which is transaction services that allow people to actually move particularly on the seller side.

And so there's just a pretty nice symbionic relationship there with the Zetas and the regions of the world. and so both of those companies have been great. What do you think Zillow may be underestimated or didn't get about the space that made it harder than they anticipated? Because it seems obvious. Of course, let's go down funnel. Let's just do it all. And they're like, oh, shit, not working.

What do you think they didn't get or what do you think they missed? I guess continuing on the humility point, I won't necessarily pretend to be in their shoes. But I will say, like, the business is challenging and it's complex from a number of different dimensions, right? It's not a traditional software-only product, but you have to be really good at pricing. You have to be really good at product. You have to be really good at the operations. You have to be really disciplined at risk. You have to be really good in the capital markets.

And so you have to put all of these functions together to build a vertically integrated product. And that's the reality. And so that is something that's been in open-dorce DNA from day one because we started with a vertically integrated product. And so we can't deliver unless we have all of those things. Right. And so I think that that's something that continues to help us to this day is that vertical integration requires all of those pieces coming together. That makes a lot of sense.

And I think it's a good reminder of there are adjacent markets and businesses that always feel like, oh, we can expand to that someday. Such a big opportunity. This business could be so much bigger. And then you realize your business is completely not set up to operate this way. Zillow is very software driven, right? Like, I'm not going to simplify what they do, but it's like a website, very software. Yeah.

And obviously, as we talk about, Open Durer, a huge operational component. And then, as you said, the pricing piece and the debt stuff. Yeah. Yeah. Yeah. So I think it's a really good reminder that it's just like when you're taking on something completely different, you may, it may not fit into the way your company operates. And partnering makes sense. Anything else there that's interesting?

share around the Zillow thing. I guess one is maybe it was just like, I imagine it was very stressful. Zillow's getting into it. Oh shit, what are we going to do? They got all the traffic. Yeah. Yeah. I mean, it's certainly stressful. I think in general, we try to live by Wadzilla or anybody else being competition aware, but not necessarily competition focused. And the reality is a vast, fast, fast in our space, a vast majority of people still move the traditional way. And so this isn't something like the size of the prize isn't particularly large and allsh or anything like that. The audience is the largest asset classroom in the United States. And if we just stay super focused on like, hey, who are the customers that we serve really well that we talk to

every day? There's a little bit of confidence that comes from being able to stay focused on that. We're rather some competitive environment, again, because it's not like the market is fully saturated. This is the same thing back in the Uber days as well. It's like transportation is almost infinitely large, you know. And so yes, it feels like they're seated competition between Uber and Lister or ever back in the day. But the reality is there's plenty of trips that happens.

And people need to get around and sit in plenty of different ways. That's neither Uber and more lift and staying focused on how you can vote for for your customer, I think is the best way of focus. There's a podcast that will come out before this episode with Jeff Weinstein from Stripe, who's building Stripe Atlas. They had a similar experience with Angelus launched a direct competitor to Atlas, and then they realize Atlas is so much better. Forget it.

We're just going to send everyone to Atlas. Really? And yes. And I think it's the same exact lesson that if you just stay focused on jobs to be done, let's say of what is the job to be done and do the best possible job. And knowing that the market is much bigger, that you're not really competing with someone else, another company. It's like it's the default behavior in your case.

It's like people are just buying their house the old fashioned way. That's the actual competition. Exactly. Yep. Yeah. Okay. So kind of along these lines, something else I've heard that you're very good at is staying very calm

under pressure and staying very level-headed when things are really crazy. This is something that a lot of people are not. good at, especially leaders. They stress everyone out. Things go crazy. They don't create a good vibe. And then, too, something people want to get better at leaders and non-leaders alike. Any lessons? Anything you've learned about just how to develop this skill? You know, I think part of this may have been sharpened in the early days of Uber where everything felt like a fire drill all the time. And so it's the only way to operate. But, you know, I think you almost hit the nail on the head in the question.

which is like a little bit of an intellectual answer of when you reflect the stress onto your teams, everybody tenses up and tightens up, right? And so it doesn't, it counterintuitively doesn't produce better outcomes. And so I think the other reality to sort of remind ourselves, and these are a bunch of like mantras that just like are helpful in these moments is you're never as good as you think you are. You're never as bad as you think you are. And so sort of that, that more even keeled demeanor, I think a little. allows you to have a clear head when they're operating under the pressure and to think, think more clearly. I think we want to be like maybe least helpful answers, but unfortunately is

sort of a reality is you kind of got to be in some stressful situations to also have the perspective that cycles past, the things pass, and that remaining calm is what matters. And so maybe the the advice there is reflecting on one of these situations happen, exposing yourself to them, not running from them, and then learning from them so that the next time it comes around, you can say, hey, I've, you know, I've been here before. You know, I've slept on the floor in China before launching, you know, Uberpool and thinking we're going to miss a launch deadline. And like, what were the tools in my tool box and my toolkit that work show me that in terms of getting it done or not in what we're the lesson.

I love that. So part of it is just go through this experience many times and you will start to realize, okay, it's not actually going to be as bad as people may think. You mentioned this toolkit instead of tools. Is there anything else there that you come back to that ends up being helpful? You mentioned this mantra of like it's never as bad as people think it is never great as people think it is.

Yeah, I mean, I think exposing yourself to other people's stories or however you may learn is really, really helpful. So, again, whether it's your podcast or books or biographies or, I mean, one of the podcasts that I love is Founders podcast, which talks about historical, famous entrepreneurs. And obviously, these are elevating, like, very famous people already. But there's a lot to learn from a lot of these stories as well and understanding that the journey in the pack is non-linear. It never is for anybody, right? And so I think being able to expose yourself to other stories that even may, if you don't have those personal experiences and then understanding how others navigate. Got it. So just hearing of other people's crazy experiences and kind of building on this muscle of like, okay, they've gone through crazy stuff.

Things work out. Yeah, totally. We'll make it. We'll make it through. Okay. I have this note here that I think either someone mentioned about you or you may have you may have mentioned that product is. finding the kernel of truth in a sea of ambiguity and signals. That mean anything to you? Yeah, absolutely. I mean, I think in most organizations and to do the job effectively,

you're going to get signals from everywhere, right? And good ideas come from everywhere. It may be your CS team or CX team. It may be a customer directly. It may be a conversation you had. It may be a YouTube video. You watch that sparked an idea. It may be feedback from an executive.

It may be whatever. you went out and did a field visit. Like you are going to get a lot of inputs around what people think about your product or people think you should do next. And I think the core job is to understand what really matters, right? Like, what is noise? What is a good idea? What is a suggestion?

What is, you know, back to the jobs to be done for, like, what is really going to move the customer forward? And unfortunately, that means, you know, saying no to maybe what sounds like some good ideas along the way. But if you can really figure out, like, this is really what matters, that's the core part of the job. It dovetails even back to our earlier conversation. You know, if you don't, in the early days of building tech and ops companies, is where's the tech leverage? Like the same question, right? Where is the kernel of what really matters that tech can uniquely solve? And let's go do that and be comfortable with other fires may be burning.

that's what really really really matters. It's a hard discipline. I love that. If there's not an example that's totally fine, but when you talk about this, finding this kernel where tech could be highly leveraged, is there any example that comes to mind of that working out really well? I mean, I think back in the Uber days,

I think it was like, hey, we're not going to build sophisticated tooling infrastructure. We're not going to build a centralized growth team. We're not going to build any of that because like if you think about the early Uber network from the simplest form, you've got a writer and a driver and you need to connect them, price the transaction, and issue some receipts probably, you know, get collect payment. So it's like, okay, do we do that really well? And until we do that really well, like all the other stuff is noise, right? It's actually, it's immaterial how efficiently we answer support tickets. Like that's not critical, right? So now it's super critical, right? But like in the early days, it's not that critical.

And like even like customer acquisition costs may not be like super critical. Like in this case, scraw, all the things. And so, you know, pouring fuel on the fire may not be super efficient there. So I think that's like a good, a very good generalized example. One other tip that that maybe is helpful here that I frankly constantly work on and try to get better at is all these ideas and feedback that comes from everywhere, make sure it's written down for a number of reasons. One, you can then go reference it.

But two, part of the job is making sure the people who present those ideas are heard and respected and know that it's at least somewhere where it was considered. And then you can look at it all and say, okay, but what actually really, really, really matters here? And yeah, that's another tip. When you say written down, is there like tools you find really helpful here? Is it just like put it in a big dock that we're keeping? Is there anything you find to actually operationalize that?

I've seen different companies do it differently. But wherever you tend to try and keep a backlog, whether that's Google Sheet or your actual backlog, but at least it feels like, okay, the context was captured and the idea is there. Awesome. Okay, I'm going to take us to a recurring segment on this podcast called Failure Corner. Okay. Is there a story you can share of a time you failed in your career, had a big failure, and how that experience made you better? We can talk about like the very early days of Uber pool and kind of the like first launch, if you will, in in San Francisco. So carpooling product, multiple riders in the same car. And we had this idea that it would be effective to,

for commuters. This was very, very early days. And so part of the launch was, okay, we're going to beta it with just some popular sort of commuting corridors with specific companies. Or, you know, maybe the marina to Google, whatever, right? And try and match people according to, you know, with their companies and that's how old driving liquidity. And it, we very quickly realized that. that back to sort of like what the kernel of truth is here is like liquidity is the only thing that matters. And there just wasn't enough. There was never going to be enough to sort of do this company-based thing. That wasn't the strategy that was going to work for us.

And so, you know, the reason I don't know if it's like a full failure is like maybe this is true of all failures is you learn from it. You pivot and you go on to the next thing. And obviously we did that and then spent on long. lot of our time and effort trying to say, okay, what are the bounds of liquidity and driving liquidity that we can do to understand what the most important or what the sort of limits of the product are? So as an example, we launched and maybe people in San Francisco. Remember this, sort of $5 anywhere in San Francisco. We work for all promotion, which is obviously a great deal.

Obviously, it costs a lot of money. But the whole idea here is like, oh, okay, liquidity is what really matters. if we were to juice that and really drive liquidity, how high can our metrics get and then we can go chase, you know, more sustainable ways to do that? But it was a sort of an interesting fail case from launching and learning to say, hey, this initial strategy is just going to work. We got to go. We got to go. And any part of it was a hedging strategy with a small audience and there will be a beta population. It's like, well, this one, you just got to go.

I think a lesson there is also don't overthink it. Don't try to get too cute. just like this is a yeah that we're uh we're trying to make a perfect beta test versus like realizing okay we just need a lot more people in it yeah uh also your five dollar promotion made me think of the early promotions of like the ice cream and the bunnies delivery and all that stuff yeah that was by the way uh a example of like fully distributed the the benefit of having those early petri dishes um someone, a local marketing manager, like, hey, this would be fun.

It would be really fun. The platform can support it. And those promotions were fantastic, right? And it started out, I can't remember if the first one was ice cream or puppies. I think it was ice cream. But yeah, branched into all sorts of stuff, boats, ice cream, puppies, kittens, I think. And all credit goes to sort of like local ideas of inspiration, just being focused on trying to to grow within.

I love that we've circled back to the beginning of our conversation, product and ops working together, the benefits of both. Before we get to a very exciting lightning round, is there anything else that you wanted to share, any last nuggets of wisdom that you think might be useful to people when they're trying to build product companies' teams? This was great. We covered quite a bit of ground.

I think the only, I don't know if this is a generalized wisdom, but something I've been thinking about as my career has progressed a little bit. especially going out of the product organizations, especially as more tools come online, it's very clear that there's different types of PMs. And we spent a lot of time talking about once we can operate in the physical and the digital or the product and operations worlds. But even within that, there's more technical PMs who grew up than engineering discipline And there are people who came from ops and there are people who came from design and grew up in more user experience background.

And one thing that I've been moving on as he built out the team is thinking similar to a product roadmap. It's like it's not really about like is this person good or bad or whatever. It's this person's skill set and context matched to the problem that is really needed. And so back to that conversation on, hey, where do we get? tech leverage. It's like, hey, is this person who has this unique skill set as a PM well-suited or this problem type? I don't know if that's helpful, but it's something I've been spending a lot of time thinking about, especially in this view, job posting niche view. Product manager or whatever. It's actually like, well, like, how can we be a little bit more thoughtful about what the actual

skill set needs out of this type of piece? Awesome. It's kind of like a person product fit. There you go. And I think it's because a lot of companies hired general. and they're just like, we'll hire someone smart, ambitious and with experience and general experience, and then we'll put them on different things. So I think these are two different philosophies. And it probably makes a lot of sense for an open door where it's like very unique type of business, very specific skills that are necessary to be really good there. Okay, amazing. Brian, with this, we've reached our very exciting lightning round. Are you ready? Let's do it. Can't wait. Let's do it. First question, what are two or three books that you've

recommended most to other people. Shoe Dog, Black Swan, design of everyday things, and for a fun one, Shantoron. Amazing, four books. Four books for the price of two to three.

I love it. Apologies. I'll stick to the rules. No, no. There's no rules. There are no rules. There are no rules. Next question. Do you have a favorite recent movie or TV show that you've really enjoyed? I like the, sports sort of dockey ones on Netflix. So full swing, draft to survive, breakpoints, tennis, golf, F1, all of them. And wasn't there that Nike documentary recently with Ben Affleck?

There is, which I have not seen. So if it's good, I don't know if that's a recommendation or just an acknowledgement. It's worth watching. If you like Shudog, I feel like you have enjoyed. It was entertaining, Michael Jordan, things like that. Next question. Do you have a favorite product that you have recently discovered that you really love. So we just got a puppy, and we are about to have our first child. And so all of my purchases recently are puppies and children focus. My buddy gifted us the phi caller for our dog. And so we've been really enjoying that.

Another one, as I'm getting busier for news and stuff, is particle, which was great. It was news aggregation tool. AI news. Okay, Vaughn's wife's business. I am a huge fan, actually. I think it just came out of beta. And now it's like a full app that anyone can download.

I've been, I just actually installed it yesterday again. And I love it. I get these pushes every, every few to time. I don't know, it's like a couple times a day of just like, here's what's happening. Also, congratulations. I should have said on your pending child. Thank you. Lucky for you.

I have a newsletter post. With all the product you should buy, it's called New Pair and Gift Guy for product managers. Love it. I will definitely probably buy all of them. If you don't already have them all. And now everyone's probably sending either spreadsheets of all their favorite stuff. Exactly. Exactly. Okay. Next question. Do you have a favorite life motto that you often come back to, share with people, either in work, your life? Well, mostly just stay curious. Stay curious. I love it. Two more questions. who has most influenced you in the course of your career?

One of the people who inspired me very early on in my product journey, I've been fortunate to have a number of very good mentors. And obviously, we talked about earlier about founders or dogs or whatever, sort of lead a lot from other people's journey. But one person who was personally important to me early in my product journey, very supportive of this guy named Jeff Holden, who was the chief procrector officer at Uber back in the day. And as sort of like a young PM transferring into product really, you know, took me under his wing.

And I think I'm forever grateful for that, for guests for helping grow my career, but also kind of pay it forward a little bit in terms of people who are going to go there in the trade. That's why I mean to venture me. Last question. I hear that your interview at Uber was pretty wild. Can you tell that story? Yeah, I can. So long story short, I was starting a company my senior spring before graduation and we decided to go our separate ways.

So I hadn't done traditional recruiting forever. And my buddy called me up and was like, hey, we're looking for smart, hardworking people at this Uber thing. Are you interested? And quick a side note, I had actually done some very early diligence work. on these taxi apps back in 2011 looking at the time was Uber Cab and Cabulous and taxi mentioned and probably something like names that mean nothing these days and so I knew what what what what what Uber was and say I said yeah sure let's you know I would love to and so had the first round of interview went well and they said great and then that stage is come on site

or should the full enchilada one works. And this was post-graduation. I was helping out some companies but didn't have a full-time job. So I said, hey, like, I'm pretty flexible. How about next Tuesday? I said, great. So he scheduled it. And then on Friday or Saturday over the weekend, I looked and I looked, and I'm like,

oh, Tuesday's July 4th. I'm like, I scheduled my interview for July 4th. And so I called my buddy. I'm like, hey, I'm so sorry. I don't want to make people come in on July 4th. should I cancel? Should I reach out? Like, everyone's sort of accepted. Whatever you do, do not cancel your interview. Okay, I'll be there on July 4th. And so I went in to the office on July 4th. And there was a very small handful of people there. It was actually launching

that day was launching Uber's second ever product type, which was Uber SEV. And I sort of had this kind of was probably five-hour gauntlet interview on July 4th. from noon to five and missed my July 4th barbecue. And it was quite the experience. But I think maybe set the stage for some of the early days. Chaos. I'm very glad I didn't cancel. And was Travis involved in that interview?

Or is it just? Travis was involved in the interview. She was one of the, I think there are four or five people. The two who were generally guiding my interview process and Travis and one other person starting that day. And part of the Gauntlet interview was sort of a simulation of the job, if you will. And so some of that was building some models on the computer. And it was sort of writing potential emails to drivers.

And actually had the driver come in and you did a child. So I was in this room sort of by myself typing away on the first part, which was building the model. And I hear knocking the door. And Travis comes in. And we have a, he just sits down and says, you know, hi, I'm Travis. I'm Brian. And, yeah, we have a 45 minute chat, or maybe it's been about half hour, 45 minutes. And clearly I'm not like producing the work that I'm supposed to of the interview.

I'm supposed to be building this model. I'm supposed to email it back to the person who sent it to me. Clearly have done nothing. Chat, chat with the CEO. And here knock on the door. in the door out and the person sees that I'm time trying. Oh, continue, continue. And it was very good.

Also pretty intense conversation with Travis that definitely set the expectations. That was working. And clearly worked out. And Travis was happy. It was my, I hope so. I imagine. Yes. Amazing.

Brian, thank you so much for being here. We went through everything that I was hoping to get through. Two final questions. Where can folks find you online? and is there anything you want them to check out that you might be up to you? And how can listeners be useful to you? Super kind. They can find me online on Twitter or LinkedIn, on both just Brian Tolkien,

my name. In terms of being useful, if you have a home to sell, feel free to go on to Open Door. More importantly, if you have feedback on the product, would love to hear it. Otherwise, any feedback on what people liked or would love to learn more about from what we chat about would be super great. So I'd love to hear from you. Brian, thank you so much for being. Lenny really appreciate it.

This is great. Bye, everyone. Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review as that really helps other listeners find the podcast.

You can find all past episodes or learn more about the show at Lenny's Podcast.com. See you in the next episode. Thank you.