You've worked at two businesses that have done incredibly well combining product and Ops.
Uber always have this mentality, and Opendoor does too, of the product operations twin turbine jet plane, where you can like 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?
Give a really deep understanding of how the business actually works.
It's a pretty good foundation for them going on to say, okay, what do we you 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 Tool and like when you reflect the stress onto your teams, everybody tenses out.
It counterintuitively doesn't produce better outcomes.
Today my guest is Brian Tolkien.
Brian is currently Head of Product and Design at Opendoor.
before that he spent nearly five years at Uber where he joined as employee 100 before Uber had Uber X 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 a 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, Bryan 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 Opendoor successfully.
The story behind Zillow trying to compete with Opendoor failing and then partnering instead, plus a ton of great stories from the early days of Uber and Opendoor, and so much more.
If you enjoy this podcast don't forget to subscribe and follow it 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, and welcome to the podcast. Thank you, appreciate it, thanks for having me.
First of all, just a huge thank you to Kevin Bakpour 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 opposite.
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 Opendoor, which have both huge operational components.
I think it's really rare that people one T a company scale to the heights of Uber and Opendoor with such a heavy operational component that are still tech companies.
And also it's really where someone starts in ops and then moves into product and ends up where you are, where your chief product officer 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 that you operate as a product leader?
Starting on the operations side, gave a really deep understanding of like, how the business actually works.
You are truly operating it day in and day out.
And the success of the city is, you know, in large part 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, 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, OK, what do we actually want to build in a more scalable technology way.
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 Replays, a very cool way to visualize user sessions.
I'm not pendo .io slash Lenny to create your free pendo account today and start building better experiences across every corner of your product.
PS You want to take your product led know -how a step further?
Check out Pendo's lineup of free certification courses led by top product experts and designed to help you grow and 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 Xplo, 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 in 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 Xplo. Xplo is a fully white labeled embedded analytics solution designed entirely with your user in mind.
Getting started is easy.
Xplo 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 Xplo's 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 Daze.
Try it for free at xplo .co slash leh -nee.
That's E -X -P -L -O dot CO slash leh -nee.
I've seen that in 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 great. It's a great question.
And I think Uber always had this mentality in Open Door Desk 2 of a 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.
I think that's really true.
The reality is operations teams, local teams can iterate faster, can scale talking to customers much more efficiently have great qualitative insights.
So, if it's seen more as like a harmony instead of a competition, I think 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?
A PM sitting in San Francisco can't be in, in open doors case, 50 markets walking houses every single day.
In Uber's case, whatever thousand cities understanding the nuances of safety in South America, that's just 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 with sort of that insight as well.
Can you say more on that?
Yeah, sure. So sorry, I should probably define what what Project Operations was at at Uber.
It was basically this notion that we've had a centralized this was later in my career at Uber, but we had a centralized product team building stuff, mostly in San Francisco, not strictly to the Rosses, but at this point around the world, but mostly in San Francisco.
And then we had a very globally distributed operations team.
And there are sort of a bi directional feedback loop that wasn't wasn't super strong.
The feedback loop was basically when the EPD teams in San 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?
So one solution to that problem or 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 think so because at the time, I believe Google 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 and 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's just a formalization of it and their actual building up of the organization.
So none of that... sounds like you basically helped make it a thing.
I know you're being very modest, I think.
Coming back to your point about decentralized operations teams, 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 gonna 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 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, Monday through Friday, there would be no surge, it couldn't flip on and then Friday nights and Saturday nights, it would flip on from whatever, you set 7pm to 3am, and the cap was x, whatever the cap was.
And then within those parameters, the algorithm would optimize for what the price was.
But yeah, GM's controlled whether it was on or off and what geographies were searching.
Wow, I don'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 gonna help them a lot.
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 and dangerous.
And so let's make sure we understand what's happening.
The second is this belief that, yeah, local city teams know their city's best. And so, you might know that an event is happening, a baseball game gets out.
And it's like, oh, I know that this baseball game is going to get out at 10 PM, so I'm going to set surge at 945.
And the algorithm 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 not 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'd like help scale in China, Uber Pool?
Yeah. Maybe that's the 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 random mainstream product, but it 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's going to be a placeholder.
So what do you put in as a placeholder?
X. So UberX and then the company was moving quickly enough.
The product got green light.
It launched and here we are, I don't know, 12 years later, 11 years later or whatever it is, and UberX is the name that stuck.
That is hilarious. I love it.
So it was a placeholder.
It's like many products start that way where they're like, This is just the temporary name and a like, oh yeah, I guess everyone just knows it this way.
Now we're going to stick with it.
It's too expensive to change and rebrand at this point.
That's an awesome story.
One that is good about scaling Uber pool in China.
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 launch and myself and a few other folks were in Chengdu, China, which is the first Chinese market that we were launching Uber Pool in.
And we were going to be on the ground to launch. We wanted to go live at, I believe, it was 6 AM 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, is it working, and we're like oh my God, now it's whatever, it was 5 pm the day before we're supposed to go live, 6 pm, 7 pm.
Okay, let's get on the phone with the U .S., try and figure out what's going on.
I remember I slept about 30 minutes that night between 2 and 3 am.
Being like okay, like we have to go live at 6 am, I think there was some press around it, We were planning on going live, and I think we got everything finally working at probably about 5 .30 or 6 in the morning and launched just in the nick of time.
I'll never forget. We launched.
It was great. We monitored.
Everything was good.
Then we walked out for breakfast at 7 .30 in the morning.
Everyone sleep -deprived.
No one slept all night.
We got these pancake street food things.
And, I have to imagine they were not that good, but in my mind, they were like the best meal I've ever had in my life.
So... Like a meal after a marathon, or a big hike.
Exactly, yeah, exactly.
Everything is 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 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, another one more recent for Open Door was when COVID hit.
We physically buy and sell homes, and so we were physically going into people's homes, and suddenly in March 2020, going into people's homes was not something people were comfortable with.
And you look at the real estate day that 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, and we said, Hey, we can't go in and we don't know if anyone's 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.
Then it was pretty stressful, right?
Cause 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 very, very difficult.
Just since you mentioned Opendoor, I think many people have heard of Opendoor, maybe just give a quick explanation of what Opendoor 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 simplicity and certainty.
So the product really works for people who have a want something 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 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 you basically sell your house to Opendoor and it's just like, cool, done, move on.
Yeah, it's out of your own, 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 functions have their time and their place and their skill sets, and you just don't build like to build big businesses of this type without respecting the fact that not both mean 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 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 type of 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, et cetera, et cetera.
we are okay not investing in right now and that needs to be an explicit decision and very transparent.
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.
Someone may not be home, scheduling may be off, the Uber driver may cancel, there may be low GPS.
All these things happen, right, computers are deterministic, but humans aren't, right?
And so building products that have a little bit more flex or a little bit more fail -safes in case those things happen 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 it 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 long.
Now there's a centralized all of these functions as the company got bigger and more mature and scale and optimization started to be more important and 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.
colors. 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 this tipping point where the product and organic growth or 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 we're open door when you talk about like there's in a place, in a skill set for Ops, how that evolved?
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 when it was Uber Black drivers, every driver was individually onboarded in 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 ops driven.
The next version of that is kind of like a small classroom type setting of three or five or six drivers at a given time.
So very ops driven.
And then as we got into more mass market products like Uber taxi or Uber X, those like, okay, maybe 20 or 30 at a time.
Okay, so now it's a little bit bigger classroom setting 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 that now suddenly we have a different problem, which is, okay, you have to validate all of these credentials.
So most drivers license and 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.
a 20 at a time, okay, you're starting to run up onto it.
Now you can fast forward six months and you're doing 1 ,000 a week or whatever, suddenly your system breaks.
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 licenses isn't 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.
I 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 what, 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 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 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 there.
Yeah. I actually don't fundamentally.
It depends on what the operations is, but I don't fundamentally disagree.
But I think that 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.
Yeah. We were just talking about driver onboarding may now be solved with technology, so now you have 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 thinking about higher capacity vehicles?
How do you think about a better feedback loop for those manual surge pricing sort of toggles that we talked about, right?
So I generally agree, and just generally freeze that capacity and solve more problems. And it feels like a big part of this is making sure the operations teams understand there is more opportunity.
Even if this ends up being automated, your job is not gonna go away.
We're gonna find something new to try and experiment and do 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, big fan of doing them actually in particular to maybe bridge the conversations in companies that have ops -driven cadences because—or start out very ops -driven because the cadences can sometimes be different.
And so the operational cadences that you might have something like a 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 timeframe?
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 I've 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 accountability and inform to an audience, but also most importantly, I think this is the primary goal is to help make the product better, 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 can think through how to make the product better.
So the two goals you try to communicate for your product are accountability slash informing people what's happening, but also just like, we are here to make the product better and setting that context.
Yeah. Is there anything you'd do specifically to make it not feel like a firing squad, like you're coming in here to be attacked and criticized is there you set context at the beginning of the meeting?
Is this just a part of the culture?
Yeah, I think that 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 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.
So you bring a breath.
The team brings the depth and hunting maria.
I don't know if you heard the Dharma Shaws 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, uh, to suggestion to a plea.
Yes. Sorry. I pleaded 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, I'm actually a big fan.
I think that's great.
Yeah. Just said I'd get everyone on the same page.
Okay, maybe one last question here.
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 question.
And we, I would say, have oscillated over time.
But in general, big subscribers of the best conversations happen when they're relatively small.
So try and keep it under 10.
Could be wide distribution of the document.
The artifacts created are actually really powerful.
And they're powerful for the whole team to understand.
And sort of secret powers, they're very powerful for new people who are onboarding.
so we got here, here are the last 20 product reviews.
You'll get a pretty good idea of what's going on, right?
But generally the conversation itself tried to keep it relatively tight.
I'm going to try to keep it that way.
And these artifacts, you mean the recordings of the meeting that people can watch?
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 review that people can sign up for?
Does every team have, how do you, how do you like to set this up the cadence?
Yeah, obviously it scales are with the size of the company for us right now it's working well is our, yes, signup cadence.
We have two, two slots a week that um, anyone can, can turn up or as their product area needs it.
And then if there's something that, um, we would love to see that we haven't seen that we do a little bit of ball and telling to make sure that the work is generally seeking, cycling through on a quarterly basis.
This episode is brought to you by Attio.
a radically new type of CRM.
There's a world where your CRM is powerful, easily configured, and deeply intuitive.
Attio makes that a reality.
Attio 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.
Attio 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 atio .com slash lenny.
Adjacent topic, I hear you're a big fan of drops to be done, Which is, okay.
So it's a fun recurring topic on this podcast. We've had many people that love it and many people that hate it.
I love seeing both sides of it.
I love that you find it helpful and you implement it at Opendoor.
I'd love to hear just how you actually apply it at Opendoor, what 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 Airbnb is we are not, most people at Opendoor are not, we don't have homes to sell every week or every month nor do we buy homes every week or every month.
This is, on average in the U .S. is something people do once every seven years, you know, I'm sure the average at Opendoor is something similar.
And so it's a little bit harder to like be a customer.
I took Uber every day, you probably used Airbnb a number of times a year.
and so, you know, 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 that they might be going through.
And in our case, buying 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 operates?
I 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, 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, but 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 our product review, the person running it and coming is like filling out this document.
Correct, pre filling it up, 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 what you expect but it's also just easier often for people 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 it for a while I think there's there's been an internalization of the culture where people also just start commenting about it or writing about it and say like hey what is the what is the job to be done here or like what is the user trying to do which is another colloquial phrase in it.
And so 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 primordal, 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 the very end of the process, like, hey, we're getting ready to ship, speak now for a whole other piece.
Those two artifacts will also be very different.
OK, so it's not like I, as a blank, like the standard jobs to be done language.
It's not exactly how you implement it, 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 living.
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 Opendoor, I'm 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, um, uh, correctly implementing a framework, any framework.
But jobs to be done in particular, we can talk about, um, takes a little bit of, 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 like cultural internalization of like, Hey, this might be phrased as the job to be done, but is this actually the job to be on?
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 would be like the job to be done was to get an offer from open door.
And it's like, 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, my like, my goal is to get an offer from Opendoor.
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 cultural 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?
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 jobs 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 or blogs and stuff, but your blog is a common one than the past round.
Not about jobs to be done, but just about many, many topics, so.
I'm flattered. Thank you.
Yes. I really appreciate that.
I was also thinking, as you were talking, you're friends with Kavon 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 weight - Yeah, I think they're more dogmatic about it.
Very dogmatic. And so I guess it's a lesson here.
Don't maybe don't take it that far.
Yep, yeah, and I think it probably, 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 there's one framework to rule them all and this is the only framework that works and we're gonna force every problem to it, then yeah.
The way I think about jobs to be done is exactly the way you're describing it where it's just think from the lens of the job to be done for a customer is 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 kinda the way you guys think about it at Open Vue.
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.
Opendoor is completely different.
You have like very few, very large transactions.
Yeah. I'm curious how you do experiments, if you do experiments.
You do A -B tests, what have you learned about just how to think through low sample sizes plus A -B testing.
Yeah. Very hot topic of conversation.
We do A -B test. It is obviously the gold standard until 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 the tunnel A -B testing is significantly easier than down funnels.
A -B testing surely product or tech Features easier than a be testing processes operational processes But but you're totally right we are not doing hundreds of millions of transactions a year and so experimentation can can be More challenging and so I think one one way to think about it Is a knowledge the problem right?
What's just 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 we'll detect?
And what is the runtime of that experiment?
And is that, and be honest, like is that acceptable?
For there are certain, 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 a six month runtime is an acceptable outcome, and we're gonna start it in June, and we will be smarter for it for 2025 planning.
And we're gonna set it and forget it, and we're grateful we did.
Right? And that's okay.
The only mistake here is 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 this and, okay, 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.
Right? 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 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, but maybe possible, you may be able to use observational data.
You may be able to do with this and Def, you may be able to look at sister cities or twin cities, you may be able to send that 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 95%, because that's a worthy trade -off.
And if we're wrong one more time out of 10, that's okay.
You can do a long -term hold out 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 than sometimes you just got to press your intuition and ship it.
And if that's what you believe, then that's what you believed and you shouldn't spend time trying to get false precision.
I want to spend more time on that last point.
But real quick, the power analysis you talked about.
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 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 minimal impact and then you can gut check your own intuition so you can play around with it.
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 how you think about when 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 exactly, like you talked about OpenDoor.
I'm not buying houses myself, so I don't know how much I can trust my intuition.
Just what'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 OpenDoor, for example, Well, I'd say on the relative spectrum we're quite data driven.
And then it's when we come into this challenge, 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.
We saw something. We put it out there.
It just was very...
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 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 around 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 just medium, low, or high conviction?
And if I have anything low or medium conviction and it's a decision of consequence, I should, yeah, talk to more customers, got to check it with another person and see if their intuition matches, something that gets me personally to the 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 it's where you want to see the product go, do you have a reasonable feedback loop to understand whether or not you are correct?
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 A -B test but some more rigorous system that says, hey, I had this hypothesis.
We just shipped it for X -Y -Z constraint reason for when we write.
I think that's awesome advice, I agree with everything you're saying.
You mentioned this word humility, and it's a good segue to something I want to talk about, which is Zillow.
One of the most interesting things that's happened in your space is Zillow basically decided, Hey, we're just gonna do what OpenDoor is doing.
They launched it. You were basically frenemies for a while, and then they're like, no, we're not, we're not working.
now you partner and say now you work with Zillow on the stuff.
So are you able to share what went down there with the story of what happened, how it went, and where things are at now?
Yeah. I mean, we do partner with Zillow.
Zillow's 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, they have a tremendous amount of, of reach and audience and all these sort of like online platforms, um, have tremendous reach and, and audience.
And we happen to have a fairly unique selling solution.
And so, um, there's, there's sort of a nice, uh, not to use a business world word, but there's a nice synergy so to speak, between, um, A high intent, the end who's doing a lot of browsing and, and, and, 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 symbiotic relationship there with the Zillows and the Red Gen Zillow.
And so both of those have been great partners for us.
What do you think Zillow maybe 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 a 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.
So you have to put all of these functions together to build a vertically integrated product, and that's the reality.
So that is something that's been in Open Door's 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?
So I think 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's very software driven, right?
Like, I'm like, going to simplify what they do, but it's like a website, very software.
And obviously as we talked about, we're a huge operational component.
And then as you said, the pricing piece and the debt stuff.
Yeah. Yeah, totally.
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 to 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.
Anything there? Yeah, I mean, it's certainly stressful.
I think in general, we try to live by with Zillow or anybody else being competition aware, but not necessarily competition focused.
And the reality is vast, vast, vast, in our space, a vast majority of people still move the traditional way.
And so this isn't something that's like, The size of the prize is it's isn't particularly large and I'll show her anything like that is the largest asset class in the United States.
And if we just say she were focused on like, Hey, who are the customers that we serve really well?
We talked to everyday.
There's a little bit of confidence that comes from being able to stay focused on that.
Grab us in a competitive environment again, because it's not like the market is fully saturated.
And this is the same thing back in the Uber days as well.
We're just like transportation is almost infinitely large, you know?
And so yes, there's, it feels like there's heated competition, between Uber and Leicestershire back in the day.
But the reality is there's plenty of trips that happens and people need to get around the city in plenty of different ways.
That's neither Uber nor Lyft. And staying focused on how you can vote for your customer.
I think is the best way to 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 Angelist launched direct competitor to Angel, to Atlas, and then they realized Atlas is so much better, forget it.
We're just gonna 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.
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, two, 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 little bit of an intellectual answer of when you reflect the stress on to 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 keyed demeanor, I think allows you to have a clearer head when you're operating under the pressure, to think more clearly.
I think one of the 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 the cycle paths, the things paths, and that remaining calm is what matters.
And so, maybe the advice there is reflecting on when 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, you know, I've been here before.
I've slept on the floor in China before launching UberTool and thinking we're going to miss a launch deadline.
And like, what were the tools in my toolbox and my toolkit that would show me there in terms of getting it done, or not, and what were the lessons.
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 some 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 not never as bad as people think it is, never great as people think it is.
Yeah. I think exposing yourself to other people's stories, or however you may learn, is really, really helpful.
Again, whether it's your podcast or books or biographies or one of the podcasts that I love is Founders podcast, which talks about historical, famous entrepreneurs.
And obviously, these are elevating 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.
Okay. Yeah, totally.
We'll make it, we'll make it through.
I have this note here that I think either someone mentioned about you or you may have mentioned that product is finding the kernel of truth in a sea of ambiguity and signals.
Does that mean anything to you?
Yeah, absolutely. I mean, I think in most organizations and to do the job effectively, you're gonna 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 watched that sparked an idea and maybe 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 where people think you should do next.
And I think that 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 and what is back to the jobs we've done, like, what is really going to move the customer forward?
And unfortunately, that means 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.
And it dovetails even back to our earlier conversation, if you don't, in the early days of building tech and ops companies, is where's the tech leverage?
Like the same question, where's the kernel of what really matters that tech can uniquely solve?
And let's go do that and be comfortable with other fires maybe 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 would 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 if you think about the early Uber network from the simplest form, you've got a rider and a driver, and you need to connect them, price the transaction, and issue some receipts probably, collect payment.
So it's like, okay, do we do that really well?
and until we do that really well, all the other stuff is noise.
It's immaterial how efficiently the answer support tickets.
That's not critical.
Now it's super critical.
But in the early days, it's not that critical.
And even the customer acquisition costs may not be super critical.
In this case, it's growing rapidly on the things, and so, pouring fuel on the fire may 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 feel, frankly, constantly work on and try to get better at is all these ideas and feedback that comes from everywhere.
Like 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.
Right. And then you can look at it all and say, like, okay, but what actually really, really, really matters here.
And, yeah, that's a another tip.
When you say written down, is it is there like tools you find really helpful here?
Is it just like, put it in a big doc that we're keeping?
Is there anything you find to actually operationalize that I've seen different companies do it do it differently.
But wherever you tend to try and keep a backlog, whether that's a Google sheet, or your actual backlog of JIRA.
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.
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 the Uber pool and kind of the like first launch, if you will, in San Francisco.
So carpooling products, multiple riders in Mes Amcar.
And we had this idea that it would be effective for commuters.
This was very, very early days.
And so part of the launch was, okay, we're gonna beta it with just some popular sort of commuting corridors with specific companies, maybe the marina to Google, whatever.
And try and match people according to their companies and that's how we're driving liquidity.
And we very quickly realized 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, all failures is learn from it, you pivot, and you go on to the next thing.
And obviously we did that and then spent a lot of our time and effort trying to say, like, 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 can remember this sort of $5 anywhere in San Francisco, the workflow promotion, which is obviously a great deal, obviously cost a lot of money.
But the whole idea here is like, okay, if 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 more sustainable ways to do that.
But it was an interesting fail case from launching and learning to say, hey, this initial strategy is just not going to work, we got to go.
And then any other part of it was a hedging strategy where we're with a small audience and there'll be a paid population, and 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 trying to make a perfect beta test. We're realizing okay we just need a lot more people in it.
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.
And by the way, a example of like fully distributed, the benefit of having those early Petri dishes, 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, and it started out, I can't remember if the first one was ice cream or puppies.
I think it was ice But yeah, we 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 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 I'm 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 building out the practical 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 you can operate in the physical, in the digital or the product and operations world.
But even within that, there's more technical PMs who grew up in the engineering discipline.
There are people who came from ops.
And there are people who came from design and grew up in sort of more user experience background.
And one thing that I've been using as a build out team is thinking similar to a product roadmap is like, it's not really about like is this person good or bad or whatever.
It's this person's skillset and contacts match 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 skillset as a PM well -suited for 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 field.
Job posting niche field.
up as product manager or whatever, but it's actually like, well, like, how can we be a little bit more thoughtful about what the actual skill set needs are in this type of thing?
Awesome. It's kind of like a person product fit.
There you go. And I think it's, because a lot of companies hire generalists and they're just like, well, 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 or like very unique type of business with 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, Chanterelle.
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 you go. Next question, do you have a favorite recent movie or TV show that you've really enjoyed?
I like the sports, sort of docu -ones on Netflix.
So full swing, draft to survive, breakpoints, tennis, golf, F1.
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 Shoe Dog, I feel like you've enjoyed it.
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.
We've been, my buddy gifted us the FiCauler for our dog.
And so we been really enjoying that.
Another one as I'm getting busier for news and stuff is Particle, which is great news aggregation tool, AI needs.
So. Okay. Von's wife's business, I'm a huge fan actually.
I think it just came out of Beta and now it's a full app that anyone can download.
I just actually installed it yesterday again and I love it.
I get these pushes every future time.
I don't know, it's a couple times a day, just here's what's happening.
Also congratulations, I should've said on your pending child.
Thank you. Lucky for you.
I have a newsletter post with all the products you should buy.
It's called A new paired gift guide 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 their spreadsheets of all their favorite stuff.
Exactly. Okay next question.
Do you have a favorite life motto that you often come back to share with people either in work or in 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 early about founders or books or mentors or it would be a lot from other people's journey.
But one person who was personally important to me early in my product journey and very supportive was this guy named Jeff Holden who was the chief product officer at Uber back in the day, and it's sort of like a young PM transferring into product really took me under his wing, and I think I'm forever grateful for that, for helping grow my career, but also kind of pay it forward a little bit in terms of people who work early in the career.
That was really the meaning of venture.
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 decided to go our separate ways.
So I hadn't done, traditional recruiting before and my buddy called me up and was like, hey, we're looking for smart, hardworking people at this Uber saying, are you interested?
And quick aside note, I had actually done some very early diligence work on these taxi apps back in 2011, looking at what time was Uber cab and cabulous and tax stuff and probably something like that, names that knew nothing news days.
And so I knew what, what, what, what Uber was.
And so I said, yeah, sure, let's, you know, I would love to.
And so I had the first round of interview, went well and they said great.
And then that stage is to come off site or should the whole enchilada.
When works in this was in 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 at them and went, Oh, Tuesday, July 4th.
I'm like, I scheduled my interview for July 4th.
And so I called my buddy, and I'm like, hey, I'm so sorry.
I don't want to make people come in on July 4.
Should I cancel? Should I reach out?
Everyone's sort of accepted.
Whatever you do, do not cancel your interview.
OK, I'll be there on July 4.
And so I went in to the office on July 4, and there was a very small handful of people there.
It was actually launching that day.
It was launching Uber's second ever product type, which was Uber SCV, and I sort of had this, I think it 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 the re -ed.
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 were four or five people The two of 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 all their computers and it was sort of writing potential emails to drivers then actually you have the driver come in and you do a chat.
So I was in this room sort of by myself typing away on the first part, which was building in the model and I hear a knock on the door and Travis comes in and he just sits down and says, I am Travis and I am Brian and here we have a 45 -minute chat or maybe it's been about half hour, 45 minutes and clearly I'm not 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.
I clearly have done nothing, chat with the CEO and hear a knock on the door and the door opens and person sees that I'm trying, oh, continue, continue, and it was very good.
Also pretty intense conversation with Travis that definitely set the expectations of working.
And it clearly worked out and Travis was happy, it was my, I imagine.
I hope so, yes. Amazing.
Brian. Thank you so much for being here.
We went through everything that I was hoping to get through.
Two final questions work and folks find you online and is there anything you want them to check out that you might be up to?
And how can listeners be useful to you?
Super kind. They can find me online on Twitter or LinkedIn, both just Brian Tolkien, my name.
In terms of being useful, if you have a home to sell, feel free to go on to Opendoor.
More more importantly if you have feedback on the product, we'd love to hear it, otherwise, any feedback on what people liked or would you love to learn more about from what we chatted about would be super great, so I'd love to hear from you.
Bryan, thank you so much for being here.
Mani, I really appreciate it.
This was 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, So 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 lennyspodcast .com.
See you in the next episode.
