20Product: Product Secrets Behind Uber and Opendoor | How AI Changes the Role of the PM & The Product Development Process | How to Hire the Best Product Teams & What No One Does That Everyone Should Do with Brian Tolkin

Summary

Podcast Summary: The Twenty Minute VC (20VC) Episode: 20Product: Product Secrets Behind Uber and Opendoor | How AI Changes the Role of the PM & The Product Development Process | How to Hire the Best Product Teams & What No One Does That Everyone Should Do with Brian Tolkin
Release Date: February 7, 2025
Host: Harry Stebbings
Guest: Brian Tolkin, Head of Product at Opendoor

---

Introduction to Brian Tolkin

In this episode of 20Product, host Harry Stebbings welcomes Brian Tolkin, a seasoned product leader with extensive experience at both Uber and Opendoor. Brian discusses his pivotal role in Uber's aggressive expansion, particularly the China Pool launch, and shares valuable insights on product strategy, team building, and the evolving role of Product Managers (PMs) in the age of Artificial Intelligence (AI).

Lessons from Uber’s China Pool Launch

Launch Challenges and Overcoming Technical Hurdles

Brian recounts the intense experience of launching Uber Pool in Chengdu, China, highlighting the technical obstacles faced:

“We were launching in China at the same time we were standing up a Chinese data center... I slept 30 minutes on the floor of the Chengdu Eater office.” [04:20]

He emphasizes the importance of understanding the fundamental components that make a product successful. In China, the lack of reliable mapping and routing data compared to regions with robust infrastructure like the U.S. posed significant challenges for efficient ride matching.

Cultural Differences in Product Design

Brian reflects on the necessity of acknowledging cultural differences when building products for diverse markets:

“We probably could have done a better job at the start acknowledging the cultural differences of building apps in China versus the U.S.” [06:07]

He notes that design preferences, such as color schemes and interface complexity, vary significantly across regions, necessitating tailored approaches.

Product Strategy and the PM Role in the AI Era

Balancing Business and User Needs

Brian discusses his most regrettable product decision at Uber—defaulting to Uber Pool over UberX—which led to user dissatisfaction:

“We prioritized the needs of the business above the needs of the user... We prioritized too aggressively to one direction.” [07:50]

This experience reinforced his belief that effective PMs must balance business objectives with user satisfaction.

Evolution of the PM Role with AI

Exploring the impact of AI on product management, Brian predicts a convergence of design, engineering, and PM roles:

“I think the core of the PM job... does not change in a pre or post AI world.” [08:35]

While AI tools will enhance prototyping and user research, the fundamental responsibilities of understanding user needs and aligning them with business goals remain unchanged.

Prioritization and OKRs

Effective Prioritization Frameworks

Brian advocates for the widely adopted Impact, Confidence, Effort framework to prioritize product features:

“The standard way would be like impact, confidence and effort. And I think that's a reasonable good framework...” [12:25]

He stresses the importance of aligning priorities with the company's time horizons and strategic goals.

Common OKR Mistakes and Best Practices

Discussing Objectives and Key Results (OKRs), Brian warns against setting too many objectives:

“The biggest one is having too many... teams can generally have a few, like three at any given time that really matter.” [20:14]

He recommends maintaining a manageable number of OKRs to ensure focus and effective execution.

Scaling from Single to Multi-Product

Navigating Product and Cultural Challenges

Transitioning from a single to a multi-product strategy involves both product and cultural shifts. Brian explains the innovator’s dilemma:

“You can't degrade your core product to build a new product on top of it until you know that the new product is working right.” [15:11]

He highlights the importance of isolating new products to prevent negative impacts on existing offerings, using Uber Eats as a prime example of successful multi-product expansion.

Lessons from Opendoor’s Product Expansion

At Opendoor, Brian reflects on early missteps in building multi-product offerings:

“We could have been better about focusing on what are our core strengths... but new capabilities at existing customer.” [17:44]

He underscores the necessity of leveraging core strengths to enhance new products without diluting the primary user experience.

Hiring for Product Teams

Defining True Product Team Fit

Brian differentiates between generalist and specialized PMs, emphasizing the need for PM team fit:

“Just like you have founder market fit, you have like PM team fit.” [28:42]

He advises tailoring PM hires to the specific needs of the team, whether it requires technical depth, design expertise, or strategic thinking.

Best Practices in the Hiring Process

To identify the right candidates, Brian recommends incorporating work samples and case studies into the interview process:

“The best is people you've worked with before... or some type of consistent case study.” [30:47]

He emphasizes assessing a candidate’s clarity of thought and problem-solving abilities rather than just their tactical skills.

Leadership and Decision-Making

Dictatorial vs. Consensus-Based Leadership

Brian shares his perspective on leadership styles, advocating for decisive decision-making over prolonged consensus:

“Consensus product decision making is challenging and wrong... slow decision making is expensive.” [27:02]

He believes in gathering necessary input but ultimately making swift, informed decisions to maintain momentum.

Disagree and Commit Philosophy

While supporting the concept of “disagree and commit,” Brian cautions that persistent disagreement may indicate misalignment:

“If I'm disagreeing and committing too much, then yeah, I agree with you. Then I'm in the wrong place.” [32:33]

He advises that true alignment should negate the need for constant compromise.

Balancing Speed and Refinement

Emphasizing Velocity in Product Development

Brian leans towards prioritizing speed of execution, asserting that frequent iterations and feedback loops lead to better products:

“The more shots on goal you take with that feedback loop, the more likely you are to succeed.” [23:05]

He acknowledges the necessity of maintaining a minimum quality standard to avoid shipping subpar products.

Assessing User Reactions to Changes

When implementing significant product changes, Brian advises a data-driven approach with extended evaluation periods:

“You need to be a little bit more rigorous in how you think about your metrics... have the fortitude, the guts, the gumption to say we might see patterns in the behavior...” [24:01]

This method helps distinguish between genuine user dissatisfaction and temporary resistance to change.

Managing Momentum and Company Growth

Injecting Momentum When Needed

Brian discusses strategies for maintaining team momentum, such as prioritizing high-confidence, low-effort projects to boost morale:

“Let's ship something that matters in the next week.” [36:25]

He believes that strategic, deliberate actions can help sustain positive energy within the team.

Long-Term Commitment vs. Frequent Job Changes

Advocating for longer tenure at companies, Brian highlights the benefits of deeper relationships and greater effectiveness:

“You just become more effective... you can do more, more quickly.” [37:40]

He argues that staying longer allows for a more profound understanding of the company and its customers.

Final Advice and Insights

Advice for New Entrepreneurs and PMs

For aspiring entrepreneurs, Brian recommends joining early-stage companies to learn through hands-on experience:

“The right balance between seeing some of what works but allowing you to make your own mistakes.” [38:34]

Common Pitfalls in Achieving Product-Market Fit

Brian identifies the primary reason founders fail to achieve product-market fit:

“Deeply understanding the problem and falling in love with the solution, not the problem.” [39:11]

He emphasizes the importance of focusing on user needs over attachment to specific solutions.

Top Product Decisions and Lessons Learned

Reflecting on his career, Brian cites upfront pricing for Uber Pool as his best product decision:

“We built upfront pricing where you would see that beforehand.” [39:32]

He explains how this transparency improved user trust and satisfaction.

Conclusion

In this insightful episode, Brian Tolkin offers a wealth of knowledge drawn from his experiences at Uber and Opendoor. From navigating complex product launches in international markets to adapting product management roles in an AI-driven landscape, Brian provides actionable advice for product leaders and entrepreneurs alike. His emphasis on balancing speed with quality, making decisive yet informed product decisions, and building specialized product teams underscores the nuanced skill set required for successful product management in today’s dynamic environment.

---

Notable Quotes:

• “We slept 30 minutes on the floor of the Chengdu Eater office.” — Brian Tolkin [04:20]
• “We prioritized too aggressively to one direction.” — Brian Tolkin [07:50]
• “The core of the PM job does not change in a pre or post AI world.” — Brian Tolkin [08:35]
• “The biggest one is having too many [OKRs].” — Brian Tolkin [20:14]
• “Consensus product decision making is challenging and wrong.” — Brian Tolkin [27:02]
• “If I'm disagreeing and committing too much, then yeah, I'm in the wrong place.” — Brian Tolkin [32:33]
• “The more shots on goal you take with that feedback loop, the more likely you are to succeed.” — Brian Tolkin [23:05]
• “Deeply understanding the problem and falling in love with the solution, not the problem.” — Brian Tolkin [39:11]

---

For more insights and detailed discussions, visit www.20vc.com and subscribe to The Twenty Minute VC (20VC) podcast.

Transcript

[Harry Stebbings]

This is 20 product with me, Harry Stebbings. Now 20 product is the show where we sit down with the best product leaders in the world to deep dive on product strategy, growing product teams and hiring amazing product people. Now joining us in the hot seat is Brian Tolkien. Brian is the Head of Product at Open Door where he spent an incredible six years and is responsible for product strategy and managing the product and design team. Before Open Door, Brian spent an amazing five years at Uber through their wildest growth periods and shares some pretty incredible product stor stories and lessons from the Uber days. But before we dive into the show today, are you struggling to beat model benchmarks or implement gen AI in your product? If so, you need Turing Turing is an AGI infrastructure company backed by incredible investors like Foundation Capital and Westbridge Capital and they do two things. Number one, they help leading companies in AI labs like Salesforce, Anthropic and Meta enhance their LLMs with advanced reasoning, coding, multilinguality, multimodality and more. They combine human and artificial intelligence expertise to deploy cutting edge AI systems for awesome companies like Rivian and Reddit. Right now Turing offers a free 5 minute self assessment to help you pinpoint your place in the Gen AI journey, get tailored next steps to optimize your model strategy and then finally learn how Turing can refine and implement your models for better performance. Take the guesswork out of Genai. Visit turing.com 20vc to start your free assessment today and talking about scaling seamlessly. Let me tell you about WorkOS. So WorkOS is the modern identity platform for B2B SaaS helping startups move upmarket with ease. Selling to enterprises means honestly really complex security requirements like saml like single sign on, like SCIM provisioning audit logs. Honestly a ton of stuff that is just a nightmare to do. Features that take months to build and maintain. Well WorkOS streamlines this with flexible easy to use APIs that make enterprise readiness quick and painful. Its suite of features include AUTH Kit, a complete user management solution free up to a million monthly users with built in mfa RBAC bot protection and user impersonation. Enterprise sso My God these enterprises love their acronyms. Supports any identity provider using SAML or oidc, while directory sync enables seamless user provisioning and deprovisioning. Oh no. For SCIM compliant directories. Fine grained authorization powers complex permissioning and it comes again. The admin portal simplifies SSO and SCIM onboarding for IT teams trusted by companies like Cursor Cursor use this if Cursor Use this. It's gotta be great. Come on. Perplexity, Vercel, Sierra. I mean these companies are awesome. And they've raised $95 million in funding from amazing people like 20VC. Try it [e-mail] 20VC. Now that you've nailed enterprise features, let's talk about creating amazing product experiences. Get your users to do what you want them to do. That's the simple power of Pendo. The only all in one product experience platform. Pendo combines analytics in app guidance, session replay, feedback management and roadmaping. All purpose built to work together. Seamlessly trusted by over 10,000 companies, Pendo is transforming how businesses understand and engage their users. Plus, they're the creators of Mind the Product, the world's largest product management community. It's awesome. See the magic for yourself. Visit Pendo iO20 product podcast to get started today.

[Brian Tolkien]

You have now arrived at your destination.

[Unknown]

Brian. Dude, I am so excited for this. I've wanted to make this happen for a while.

[Harry Stebbings]

So thank you so much for joining me today.

[Brian Tolkien]

Thank you for having me. I'm super excited as well. This be great dude.

[Harry Stebbings]

I spoke to so many people that.

[Unknown]

Worked with you at Uber and I heard that you were instrumental in the China Pool Uber launch which allowed Uber to compete directly with Didi in major cities. This is what everyone told me. What are your biggest lessons from that time and launching China Pool so efficiently?

[Brian Tolkien]

We were launching in China at the same time we were standing up a Chinese data center in China and there was all sorts of technical issues with the day before launch getting everything to work properly. And we were launching in Chengdu, by the way, a city of 20 million people that most people at Uber had never heard of. And we were launching for rush hour because the product relies heavily on liquidity to to make efficient matches and all of that stuff. And it wasn't working. And it was 9p, 10pm, 11pm, midnight, 1am, I think slept 30 minutes on the floor of the Chengdu Eater office. Launched at 5:30 or maybe 6am and knock on wood, we were able to figure it out and it worked.

[Unknown]

What are your biggest product lessons from doing that launch and from that time with Uber in China?

[Brian Tolkien]

Yeah, so I think my biggest product lessons are one, understanding the components that make your product work really matter. So in our case we are trying to do matches between two riders. For Uber Pool. The thing that works, the thing that customers care about is the quality of the match and the price of the ride. The thing that drivers care about is also somewhat the quality of the match. And those things depend on having really good mapping and routing data. And the reality is, in China, there's no Google Maps. It's much more difficult to have routing and mapping data. And we had to work really hard to try and figure out how we can make good matches work. And the reality is, when we first launched, there weren't that good of matches. And the road infrastructure in China is very challenging. You have massive highways and overpasses and all this complexity that is just a little bit simpler in places like the US And I think we underappreciated the complexity of how you would make good matches without awesome underlying road data.

[Unknown]

What do you know now that you wish you'd known then? When you think back to that time.

[Brian Tolkien]

We probably could have done a better job at the start acknowledging the cultural differences of building apps in China versus the U.S. right. And the reality is you go to China and it's different. Right. It's not as like the sleek, elegant design isn't where design falls into the background isn't as prominent, and it's a lot more color and red and big buttons and that type of stuff.

[Unknown]

Do you think we're seeing the globalization of product design? When you look at TikTok, when you look at RedNote, when you look at the intrusion of kind of Asian influence into actually Western product design, are we becoming more like them or are they becoming more like us?

[Brian Tolkien]

I think there's absolutely a convergence. I think probably the influence is a bit more being pulled towards us, but the reality is, like apps like TikTok, there's a lot of things going on, flying around, scrolling all that stuff as our attention spans shrink. Yeah, I think we're certainly meeting in the middle.

[Unknown]

What was the worst product decision you made at Uber and how did that impact your mindset going forward?

[Brian Tolkien]

Back in the early days of Uber Pool, the way you accessed the product was this sort of this subset of UberX. So it wasn't all on the slider as it is today. You go to UberX and then above it you see this little toggle where you can pick UberPool or you can pick UberX, and you see some differences around the price or the time that you would get there. And for a little bit, the default was Uber Pool. And I think that was a poor product decision because even if you had chosen UberX on your last ride, it defaulted back to UberPool. And so people, the UI wasn't clear enough what was happening. And so people were accidentally choosing UberPool and they thought they were getting An Uber X, that's maybe what they were accustomed to or whatever. And then someone else would show up in the car.

[Unknown]

How does that impact your product decision making?

[Brian Tolkien]

I think we prioritize the need and the desire to test out the bounds of liquidity, I. E. We prioritize, prioritized the needs in some ways of the business above the needs of the user in that case, or respect for the user's choices and wishes. And I think that's a lesson of deeply internalized. I think good PMs you have to do both. You have to understand what works for the user and works for the business. I think in this case we prioritized too aggressively to one direction.

[Unknown]

You said there about good PMs being able to balance between the kind of needs of the business, but also the needs of the user. The role of the PM itself is changing so much, it would seem, especially in a world of AI. Can you talk to me about how the PM role changes, changes in a pre versus a post AI world? Most significantly, the tools and means and.

[Brian Tolkien]

Mechanisms I think will change, right? And so your primary tool or artifact of writing a PRD versus building a quick demo may change as AI makes it easier and cheaper to build. And I think we will see that. We will see a collapsing or converging of the end product design triad. I think they will never be the same, but I think everything will be pulled in tighter. So I think all of that will change. I think what won't change is actually the core of the PM job, which is you gotta go talk to users, you gotta go figure out what people want, you gotta go build it, and you gotta go build it in a way that makes sense for the business, right? And I think trying to actually figure out the creative part of. Okay, I've got some customers telling me this, I've got some customers telling me that. I've got my CX team telling me this, I've got my user interviews telling me this, I've got my data telling me that what do I actually build? What do I do? How do I make a good decision that works and how do I do it with velocity? How do I know type one from type two decisions? Those core components, I actually don't think change in a pre or post AI world, I think what changes changes is your ability to communicate those ideas, your ability to do more upfront, your ability to do better user research because you can show prototypes easier. So I think the tool chest gets bigger, but the core skill set of actually figuring out what people want and does it work for the business is the same?

[Unknown]

Does Figma get replaced by Replit in this world? I'm seeing more and more people jump that.

[Brian Tolkien]

Yeah, I don't know. On the company level I think maybe the generalized version of that is do more PMs start in prototyping land than they do in strictly design land. And I think the answer to that is yes. But at the company level I think Figma continues to build for designers, PMs and engineers and make the product closer and closer to being able to be implemented in production code.

[Unknown]

So how does the product development process change in the world of AI? I heard from many people that have worked with you that you're like the master of the actual process of product development. How does that change in the world of AI?

[Brian Tolkien]

That's super kind of people to say, I don't know if I would consider myself a master. If you go back 20 years ago, it's pretty waterfall y and I think we've as an industry moved away from that. But you still have like the PM owns this artifact of the initial PRD or one pager and design owns the Figma file or the design prototype and engineering owns the actual implementation in the code that creates a process in and of itself. Right. Where the PM is at the top of the funnel and developing the idea. Then the designer comes in, you work with the designer and then and it sort of moves down funnel. And I think AI completely collapses that cycle and accelerates a lot of the upfront up funnel work where again you can just, you can build the prototype and you can show that to customers. And like the PM and the designer might just work collaboratively to say let's just build a prototype, let's skip the document stage and let's just do that instead of maybe talking as a first step and then showing some flat files and then maybe building one or two prototypes to sort of refine your hypotheses. And so I think the development process just accelerates a bunch.

[Unknown]

You mentioned the one pager there, say we keep it just for now. You've seen many different types of one pages. What is a great one pager and why do most people go most wrong?

[Brian Tolkien]

Yeah, so I think if you're early in the process, the important thing to get right is the problem definition, the why. Right. What is the core insight that is the reason that we're even talking about this project and that's usually a user insight or a business insight and, or both. And then anybody should be able to pick up that one Pager and say, okay, I get why we're doing this and I get the problem and it's totally fine. Slash expected that the solution is probably pretty underexplored in those one pagers. I think people get wrong where the one pager is the solution description, not the problem statement.

[Unknown]

How do you think about prioritization of problems to go after? There are so many different problems that you could choose A lot of teams have a lot of different opinions. How do you determine we are going to commit resources to this and not this?

[Brian Tolkien]

The standard way would be like impact, confidence and effort. And I think that's a reasonable good framework and there's a reason it's been around forever and it's a reason that people use it. I think that the part that has to mash up is something about time horizons and the priorities of the company at any given time. And so. So what I mean by that is like one tension that often arises is how much do we build new features now versus maybe stabilize the existing features versus pay down tech debt. And I think these can become spiritual debates.

[Unknown]

Does that become much more challenging when you're public?

[Brian Tolkien]

It is more challenging when you're public, but it doesn't change. I think the core principle, which is you still need to decide at the highest level what timeframe you are optimizing for. And so I think things like experience debt and the tech debt. The debt part is actually like a really apt description where you trade paying it down now for pain later or you trade taking it on now to pay later.

[Unknown]

You're an angel investor in my company. In a hypothetical situation, I've got invest and I'm series A style. So I've got investors and they want me to go from 2 million to 8 million in a year. ARR. But I'm mindful that I've got growing technical debt. Do I focus on new product expansion and just let the technical debt ride it out or do I solve technical debt at the cost of maybe lower growth and lower new products?

[Brian Tolkien]

Think when you're early ish stage like that at Seed series A doing 2 million, trying to get to 8 million. Like you have to earn the right to exist in the future and paying down tech debt doesn't pay the bills. And so I think at that stage it's probably a little bit early to start paying down technical debt now. It depends. Are you in like a land grab? Uber was in a land grab for many years, right? It had to be first. It had to get riders, it had to get drivers right and so there's a very much a land grab competitive dynamic that pushes is a certain philosophy. I think most early stage companies tend to be that where you have to figure out if the thing that you're building in that 2 million ARR you may not know yet actually has value and people want it and people will pay for it. And so I think early stage slowing down to pay down that debt is oftentimes a bit challenging.

[Unknown]

Should the CEO always be the cpo?

[Brian Tolkien]

Always, no. But in the early stages, yes. There are certain scales of companies where that maybe doesn't make sense anymore, but in the early days, yeah, I do think they should. If you think that the most important asset your company has is the product that is delivering, I think at the early stages outsourcing that to someone else can be really challenging.

[Unknown]

We mentioned like the focus on new products or expansion of products versus technical debt. You have gone from single to multi product. What's your biggest lessons on how to go from single to multi product? Well, it's a challenge so many face.

[Brian Tolkien]

There's a product challenge and then there's like a cultural challenge. The product challenge is you have this chasm to cross which is you can't degrade your core product. Right. It's a classic innovator's dilemma. You can't degrade your core product to build a new product on top of it until you know that the new product is working right. You have a bunch of users who care about your core product. And I think the best way that I've seen this approached is by giving new products a little bit of a sandbox, a contained sandbox that relaxes a bunch of the constraints of the company, but does it in a way that if it's completely fails or whatever, it actually doesn't harm the overall core product experience. So Uber and Opendoor have an advantage where you can do this geographically, by city. In Uber's case, even more extreme is you do what Uber Eats was, which was like a totally separate app, a totally separate org and totally separate everything.

[Unknown]

It doesn't harm it, does it have to benefit it? A lot of people say if you're going to do a second product, it has to benefit the first.

[Brian Tolkien]

I don't think it has to benefit the first, but it has to take advantage of some competitive advantage that your company has. And so if you think about a classic two by two matrix where you have your customer set and you your competitive advantages as a company, your core product is your existing customers with your existing product and competitive advantages. If you have a new customer set and a new set of competitive advantages or capabilities. That's probably just a new company. And so you're either playing in do we take our core capabilities and attach to a new customer set or do we take a new customer set and attach to our core capabilities? And I think you can play in either one of those. But in both cases it doesn't have to make the core product better better, but it does have to make the core experience for your customers better and it does have to make the business obviously better.

[Unknown]

What fuck ups did you make in going from single to multi product? I'm very delicate with my words.

[Brian Tolkien]

I think the biggest challenge with going from single product to multi product was probably the one that I described previously. That was uber going from UberX to UberPool in one. And that was actively, I think, harming the overall user experience. So that was probably the single biggest. What about an open door at Opendoor? We had initially started building heavily on the buyer side of the business and we knew we wanted to be multi product. We had a bunch of initiatives over the year building a retail buyer business, building a mortgage business. We could have been better about focusing on what are our core strengths and how do we not be in that new customer set, new capability quadrant, but new capabilities at existing customer. And I think that's where the company is heading now with a lot of its new products focusing on helping sellers and how sellers can sell their home in a radio place.

[Unknown]

You said to me before, the most important product skill set is simplification. Speaking of product expansion, simplification and finding the kernel of truth. This is a pretty one. Is a sea of cacophony. I read this and I was like, my God, it's like Ernst Hemingway's fallen into my email. So can you explain that to me of why a kernel of truth is a sea of cacophony?

[Brian Tolkien]

The product job is challenging, right? You have executive pressure, you have your independent thoughts, you have what customers are telling you. You have maybe scaled customer feedback from your CX team. You have maybe your sales team yelling at you with some other feature requests. It's like it's the prioritization exercise we talked about. And so you have all of these different pressures and they often come in a variety of different forms, but oftentimes they come in the form of solutions. Hey, we need this feature. Hey, it would be great if the product did this. Hey, we lost a deal because of that. Whatever the core of that product job is, say, okay, there's all of this Feedback, all of this noise, what actually matters to a user in the Uber example for a second, there's a ton of things that make that product work in the early days that made that product work. But at the end of the day, is there a car available? Can it get to me quickly, within five minutes at a price that's reasonable? And if you can do that, all the other stuff, all the other product nuances like kind of fade away. And so that's the simplicity that matters for that product. And so trying to align and say, okay, how do we prioritize everything that moves one of those particular dimensions? But actually like trying to understand that when maybe someone's saying like, hey, cancellations are a big problem and our CAC is too high and like all these other things that are problems, real problems or potential solutions and find like, okay, that's what I really need to focus on. That's what matters.

[Unknown]

Who is the one to set that OKR of that is what you need to focus on is that the CEO, is that the cpo, is that the.

[Brian Tolkien]

Head of product, that level where you're talking about that needs to come tops down and say this is the success metric for the company and then that cascades to the rest of the org. So for example, in the Uber case just to extend trips may just be the metric, right? That's the okra that matters. But I'm doing uber pool, right? And so like okay, I can see that as a product leader for my area, right, which is not the whole company obviously for my area and say okay, how do I ladder to that, right? And so what matters to me is okay, in this case it's easy uber pool trip count, but I can match my okrs and everyone else can ladder their okrs to the top level one. So okay, OKRs to me are like cascading trees. Wherever you are in the organization, it should be layering up to the one or two above that.

[Unknown]

What are the big mistakes people make with okrs in product, do you think?

[Brian Tolkien]

I think the biggest one is having too many.

[Unknown]

How many can you have?

[Brian Tolkien]

I think teams can generally have a few, like three at any given time that really matter. Maybe three to five depending on the size of the team. But if you're focused on everything, you're not focused on anything. And so I think in the okr process it's important to a have a manageable number but then be able to articulate what important things you're not doing and the tough trade offs that you had to make. Because if you're doing everything and you're doing it all and you're doing it all at once. It wasn't necessarily a rigorous prioritization exercise.

[Unknown]

Where did you focus At Opendoor. Where with the benefit of hindsight you shouldn't have. And how does that impact your mindset?

[Brian Tolkien]

Opendoor's had different variations of a mortgage product that didn't succeed and I think those were like articulated reason decisions. So I think the outcome isn't necessarily what company wanted at the time, but I think it's hard to divorce like bad decisions from bad outcomes. So the hindsight becomes very easy to say, you know, we should focus elsewhere. But I think there were well reasoned decisions at the time. But I think focusing on the right to win for sellers is where a lot of the magic is today. And I think that's the right focus area.

[Unknown]

Can I ask you, when you think about we've spoken about single to multi product, we've spoken about technical debt. Do you think people are destined for certain stages of company development? It's often seen instead. Do you agree with that?

[Brian Tolkien]

No, because I believe in human agency and the ability for people to adapt their skill set. I think certain skill sets are better adapted at certain stages of company.

[Unknown]

But you agree that people can adapt skill sets?

[Brian Tolkien]

I do think people can adapt skill set. I think people can grow with companies. I think people can grow in their career. I do think people can adapt their skill set. People want to have to do that. That may be the hardest challenge because people, people can be very good at a thing and it's easy to stay good at that thing and do that thing.

[Unknown]

How often should you change OKRs? We were talking about having three to five per team. How do we think about how often we should change them and how should they be communicated to the team?

[Brian Tolkien]

Teams should be developing their own OKRs. They should be defining the work that matters the most to the strategy and the top level okrs that are outlined. A couple of philosophies here. One, generally the quarterly planning process or whatever. I don't think you should be changing your objectives that frequently. Otherwise it's an unfocused strategy. It's unlikely you officially completed your objective in a quarter. The more nuanced answer is you earn the right to set OKRs on longer time horizons by proving you can execute on shorter time horizons. So super early stage companies like having an annual year long OKR process when it's not clear what you're going to build in three weeks. That doesn't feel like a super worthwhile exercise. And so I think you earn the right to plan on longer time horizons by proving that you, you can set and execute over shorter ones.

[Unknown]

How do you think about the importance of speed of execution in product versus the importance of taste, of refinement, of beauty, of kind of human preference? How do you think about that balance and what's ultimately more important?

[Brian Tolkien]

I probably personally fall a little bit more on the velocity side. I think the reality is as good as your product intuition is, as the reality is you throw something out into the world, you ship something, something and you figure out if people like it or not. And the more shots on goal you take with that feedback loop, the more likely you are to succeed. And so I don't think you can throw out crap, right, because the risk is then you have like a negative signal where actually your execution was just bad, right? And that's the reason it didn't work. So you have to have a minimum bar, right? And that's what viable and minimum viable MVP is. But velocity matters a lot, dude.

[Unknown]

How do you determine whether your new product change, your product update, your redesign is shit versus users are just not used to the transition or the change. I remember the iPhone losing its home button. Me and all of the people around me were like, this is terrible. Swipe up now. It's preposterous to think of that. How do you think about whether it's a bad decision or it's just user preferences?

[Brian Tolkien]

Changing the iPhone one is particularly challenging because it's hardware and so hardware is hard. In software though, you know, I think you, you tend to have the ability to give people time. I think what you need to do is be a little bit more rigorous in how you think about your metrics and, and your definition of success where you know, the classic, okay, we're going to make a change, we're going to roll it out until we get stat sig and then we're going to pick the winner and then that'll move forward. Like that may lead you in the wrong direction here, right? Because it may be you have a novelty effect and numbers decrease or frankly the novelty effect and the numbers increase. But it's temporary. And so if you think there's the risk of that change being just a change to customers behavior, you may just set up your experiment differently and you say, okay, we're going to look at all the data, but we're not going to make a decision in the first two weeks. We have to have the fortitude, the guts, the gum assumption to say we might see Patterns in the behavior, where behavior is slowly changing over time. So we actually need to evaluate this experiment on week five through eight data, not week one through four data.

[Unknown]

To what extent are you a gut driven product leader or a data driven product leader? If I were to put you in one camp.

[Brian Tolkien]

So if you were to put me on a continuum where 0 is 100% gut, 0 is gut only. 100 is is data only, you'd probably put me at 65 with one caveat, which is data is not just quantitative. A, B tests. Talking to users is data that is real. If you talk to 10 customers and they tell you something, that is just as much data as I looked at 150 data points and here was the insight. So 65 is the answer because true gut is just like I just went with what I thought.

[Unknown]

It's simple, always better in production, but.

[Brian Tolkien]

For a given necessity of complexity, simple is better. And so what I mean by that, let's take the Uber example. Push button get ride. That's the original Uber thesis and it was Uber black, right? Push button get awesome ride. That's way simpler than open app C, slider pick car type push button get ride. Right? But the reality is, if you want options to serve different customers, to serve different use cases, the Slider's a pretty simple UI to do it, where you can articulate everything in in one sort of paradigm. So for a given sort of necessity of complexity or a necessity of feature set, yes, simple is always better. But you can be very reductionist and say, if simple is always better, Uber moving to a second car type in one app was a bad choice. And I don't think that's true.

[Unknown]

One thing I think about often is Gustav at Spotify, who's a dear friend and one of the best product leaders in the world, I think. And he always says that talk is cheap and so we should do more of it. In terms of the internal discussions being so vast, valuable, and actually encouraging much of them, I on this hand think he's wrong, which is incredibly bold and arrogant given he's CPO of $100 billion company and I have a podcast. But I think actually dictatorial product leadership is underrated. How do you think about that balance between strong leadership and product direction versus a real emphasis on discussion, debate and internal dialogue?

[Brian Tolkien]

So I think consensus product decision making making is challenging and wrong. So you think A, I think B, let's meet in the middle is challenging, but I think A, and I'm not going to ask you because I think you think B And I don't want to hear a difference of opinion is not good talk is cheap, therefore we should do more of it. I would interpret that and agree with the interpretation of get all the opinions on the table, make sure to gather everyone's expertise, and then make the best decision given the information. So I think slow decision making is expensive as for a vast majority of decisions, but so is not listening to anybody else and gathering opinion if dictatorial in this definition is defined as I have all the right answers and my opinion always wins. I don't think that that's different than consensus.

[Unknown]

I find very rarely does a slower decision lead to a better outcome.

[Brian Tolkien]

I agree with that one.

[Unknown]

Can I ask you, when it comes to hiring for product teams? I do want to discuss this because you said about hiring for true product teams and I thought that was just interesting. What do you mean when you say true product teams versus just good PMs?

[Brian Tolkien]

Earlier in my career it was like, okay, if you find someone who's smart and hardworking and can do that distillation and there's a good pm, you can give them any problem and they'll figure it out. For some generalist problems and generalist people, that's true. But not all PMs are created equal, right? There are PMs who grew up as designers and then became a PM or engineers or have a technical background or a data background or a business background or an ops background. We can be more nuanced in thinking and saying, what does this team need? And therefore, is this PM the right PM fit for the team? So it's the same way you have founder market fit, right? You have like PM team fit.

[Unknown]

How do you know the PM type that you need? You look across the team and go, oh, we're missing a former consultant, analytical brain, who wants to be CEO of.

[Brian Tolkien]

The product in a pithy way. Someone at Opendoor who I work closely with had this phrase, which is, you hire your strategy, right? And so the person you pick to play that role will dictate how that person defines the success of that product. And so I think you need to have a perspective on that when you're hiring. So, for example, if you look around and there are two dimensions, there's what is the team as in maybe the product that they're working on, that team need? That is, hey, this is a backend infrastructure thing where the key to success is the algorithm that we put forth. Therefore, the PM that we need to have needs to be able to deeply understand whatever the case is, optimization or have a more mathy background. So there's that sort of type of team fit that I think is most important. Then the second is like your product team, your functional product team. You can say, okay, our functional product team has like a lot of people that fit this type of mold. We need somebody who's going to push us in the direction of being sort of that like crazy out there tinkerer, always trying the newest tech tool and they're going to ingest that energy into our product team because we are also a team. So I think both of those are important.

[Unknown]

When you look back on your hiring decision, when they've gone wrong, what did you not see that you should have seen?

[Brian Tolkien]

So I believe that poor hiring decisions are never just the responsibility of the person being hired, the new person who it didn't work out with. It's almost always the company or the hiring person's fault. What I've seen most effectively is either that person wasn't set up for success so they didn't have enough clear direction or definition of success or clear outcomes. They had the wrong skill skill set to sort of what we were just talking about. Hey, their interest is on the design side. But what the team really needed was like a more engineering technical leader because that's some of the challenges that the team was facing or the ambiguity of the role. And the ambiguity of the challenge was above that person's ability to distill that ambiguity and find what really matters.

[Unknown]

Do you give them take home assignments in the interview process?

[Brian Tolkien]

Yes, most of the time. I do believe some type of work product is very.

[Unknown]

What is the best work product? Again, I'm a founder. You're helping me me. How do I test them?

[Brian Tolkien]

The best best is people you've worked with before. Because that's a heck of a lot better than a one hour interview. But I think it can either be show me a previous work product that you've worked on or some type of consistent case study of like here's a somewhat ambiguous problem. Let's talk about how you would handle it or put together a Docker deck or whatever on how you would handle it. And I think the important part here is it can't be so narrowly scoped because the tactics of the job. You can learn how to run a sprint, how to do prioritization, that stuff you can learn. That's not what the test is. The test is the clarity of thought and getting to that outcome.

[Unknown]

You said there about how to run a sprint. Sprints are incredibly common across companies. What are the Biggest tips on how to run the most effective sprints.

[Brian Tolkien]

Just be clear. The biggest tip I have is be clear on what you're trying to accomplish in that sprint and make sure that everybody is aligned on it.

[Unknown]

Ideal timeline for split for most teams.

[Brian Tolkien]

Two weeks growth teams often can run at one week and that's okay.

[Unknown]

I'm going to be honest, Brian. I'm enjoying this a lot. I find alignment one of those BS management terms which is overused and put in the same kind of culture bucket which means nothing but meant a lot in kind of the last five years. Am I unfair?

[Brian Tolkien]

Let me give you what I mean when I said it. Everybody at any given time should ideally understand the most important thing that they can be working on, why that matters and how that ladders up to customer or company goals and should be able to fluently discuss those things. If they can do that and it aligns to the right company goals that have been set, then you're aligned. I'm not talking about necessarily agreement, but I can, I can, I can understand why I'm doing it.

[Unknown]

Do you believe in disagree and commit?

[Brian Tolkien]

Yes, I do.

[Unknown]

I don't understand how people will work weekends, stay up late at night, give everything when they fundamentally disagree. Agree, you'll get participation and commit.

[Brian Tolkien]

I think this goes back to the Steve Jobs Stanford commencement address which is if you look in the mirror too many days in a row and you realize that you don't like what you're doing, you should probably do something else. I think that applies to disagree and commit, which is for a sprint for a month, whenever. Can I disagree and commit for sure. Right? Because that is like how we make velocity based decisions. If I'm disagreeing and committing too much, then yeah, I agree with you. Then I'm in the wrong place because I'm not aligned to where we're going fundamentally and. And it's probably time to start thinking about something else.

[Unknown]

If you could choose the ideal background for the one that's worked best for you personally when hiring PMs. What background type has been most effective coming into a PM role?

[Brian Tolkien]

If you forced me to pick, I think there is a tremendous amount of undervalued appreciation for internal transfers from other functions into product at the same company.

[Unknown]

Engineering, product design. Design. Which becomes less important and which becomes more important in a world of AI.

[Brian Tolkien]

Engineering becomes more important.

[Harry Stebbings]

I would say less.

[Unknown]

That would be my last.

[Brian Tolkien]

Why would you say less?

[Unknown]

Because I think unless you're talking about top 1% performance based model optimization, like the truly difficult technical challenges you're going to see a kind of commoditization of engineering challenges because you're going to have so many tools that help good engineers be in the same ballpark. I think strategic product mastery will still have a place, and I think actually design will have an even bigger place because I think you'll see that actually design become way shitter with AI doing good enough and a lot of people being like, oh, happy with good enough. But then the design pros will be up here fair.

[Brian Tolkien]

I think though, what you just articulated though, is the top 1% of designers, the top 1% of PMs, and compare that to the average and engineer the ability to still architect a system that thinks ahead, thinks around corners. I think that will still matter. But I think to answer the question, maybe how you were particularly answering it, the top 1%, the top 5% of all of the skill sets get a lot more valuable and the median gets a lot less valuable.

[Unknown]

At Opendoor, what is the best team product and your design at Opendoor?

[Brian Tolkien]

And I think this is true at a lot of operationally intense companies. We actually consider the classic triumvirate of end product and design and product ops and design because it's so difficult to divorce your digital product from, you know, the physical embodiment of whatever you're doing. And by the way, this is also true in a slightly different format at Uber.

[Unknown]

What I find really challenging with you as a product leader, loving hard, physical product businesses is you could have the most beautiful consumer software experience, say in Uber or in a open door, but something completely out of your control, a third party externality could destroy the customer experience, making them think you're shit when you've done everything you can. That's very different to another business, which is a pure play software business.

[Brian Tolkien]

The reason, potentially I enjoy thinking about those problems and the way I've articulated this is computers are deterministic humans and the real world are not right. And so you have real world entropy and you have to think about how your product adapts to that real world entropy. And yeah, that's hard for sure. I don't want to pretend that's easy.

[Unknown]

You're comfortable with the customer experience being out of your hands.

[Brian Tolkien]

Am I comfortable with it? I don't know about that. But like, I acknowledge that some of the most important impactful products exist in the real world, not just the digital realm. And therefore you have to grapple with the realities of the real world.

[Unknown]

You said about being biased because I said, which is your favorite? How do you think about managing momentum as a product leader, it's very difficult to do well.

[Brian Tolkien]

One of the things that I try to think about is you might be unnatural if you feel like the team needs a momentum boost. That might be. The team is newly formed. That might be. You're coming off an extended break. Obviously, some people take a break around the holidays. That could be you just had a difficult business outcome and so you're like, okay, we need to inject and infuse some positive energy and momentum here. Let's maybe unnaturally ship something that, yeah, maybe is a little bit lower impact, but it's higher confidence, lower effort, so we can prioritize speed and confidence of impact. So the team gets a little bit of excitement moving forward and that compounds. And so you may have a slight unnatural prioritization that says, okay, we just came back from the holidays, everyone's pumped about their plans. Yes, we just thought about the next year. Let's ship something that matters in the next week.

[Unknown]

I agree. I think it applies, actually, just broader teams. I would say you have to manufacture hype in management and goodwill and good things. Like when someone does something that's like normally make it a much bigger thing because everyone wants to feel, especially in harder times. Yeah, we did something, something great. Final one before we do a quick fire. You said before about the benefits of staying for longer periods of time at one company for individuals. That is different to how most people operate in the Valley. You are incredibly promiscuous as a group and jump from one AI company to another right now, it would seem. Why do you believe in the benefits of staying at one?

[Brian Tolkien]

So as someone who's biased, because I've spent two periods of longer stretches at companies, I think the reality is you just become more effective and therefore where you can do more, more quickly. You have deeper relationships, you have deeper context on the company, you have deeper context on the customer base, and therefore you can be more effective. So if you're hopping every 18 months or two years and you assume it takes six months to ramp, obviously that's very long to ramp to be any effective, but to really deeply understand and gain context, and then at some point you're interviewing and thinking about your next thing, you just don't have that much time to be effective. Obviously, if it's the wrong fit, you should move on. But I don't think a goal should be to move on every two years as you can canonically read about, because I think you will just get more effective with time.

[Unknown]

You're advising a student coming out of university today. Do you start a company? Do you join a startup or do you join a big company?

[Brian Tolkien]

Join a relatively early stage company.

[Unknown]

Why?

[Brian Tolkien]

The right balance between seeing some of what works but allowing you to make your own mistakes.

[Unknown]

Okay, listen, I want to do a quick fire. So I say a short statement, you give me your immediate thoughts. You mentioned before you have a six month old. My brother's having a baby, literally now.

[Brian Tolkien]

Oh, congratulations.

[Unknown]

Like, yeah, she's in hospital now. What would you advise him? It's his first child. On parenting.

[Brian Tolkien]

Say yes to all of the help that anyone offers or provides. And actually living close to parents, friends, family who can help is a superpower and a cheat code.

[Unknown]

What's the most common reason founders don't get product market fit?

[Brian Tolkien]

Deeply understanding the problem and falling in love with the solution, not the problem.

[Unknown]

What do you know now that you wish you'd known when you entered product?

[Brian Tolkien]

The hiring lesson that I gave earlier of making sure to really understand what the problem needs and then finding the person who's really good at that type of problem.

[Unknown]

What was the single best product decision you made?

[Brian Tolkien]

Upfront pricing for UberPool.

[Unknown]

Meaning like this is the price and they know it definitively.

[Brian Tolkien]

Yeah. When we first launched it was variable. Back at the time, I don't know if you remember this. Like you open the Uber app, you say this is where I'm going. And it was just like, okay. And then based on minutes and miles, the cost would post hoc calculate. And so we built upfront pricing where you would see that beforehand.

[Unknown]

What other function has the most tension with product operations?

[Brian Tolkien]

The speed and cadence and types of problem solving is very different. It can be very challenging to all speak the same language on things that have a product or technical solution versus an OPS based solution.

[Unknown]

What was the most recent consumer wow moment you had with a product?

[Brian Tolkien]

It's cheating. But the honest answer is ChatGPT.

[Unknown]

Really? I actually found the Meta glasses an amazing product experience. I don't know if you've tried them.

[Brian Tolkien]

You put them on, but I've been with someone who did.

[Unknown]

Product experience is amazing. Incredibly thoughtfully crafted. Pretty beautifully done. Yeah. All suno the AI music generator.

[Brian Tolkien]

Yeah.

[Unknown]

Unbelievable.

[Brian Tolkien]

That is unbelievable. I think the multimodal ability to upload a screenshot, a picture, a video and say like, analyze this. Tell me about this. Think about this in ChatGPT is pretty incredible.

[Unknown]

Final one for you. What would you most like to change about the world of product today?

[Brian Tolkien]

I think the breaking down of silos, the use of AI tools to break down the silos between the functions will be more challenging than a lot of people are giving it credit to and I would love to see that change where PMs more quickly are like, yeah, let's just go to prototype.

[Unknown]

Brian, I have peppered you with questions. I've loved doing this. I'm sure you feel like you've been interrogated. Thank you so much for this and this has been so much fun.

[Brian Tolkien]

Thank you Harry. This is great. Love it. Good luck to your brother and congrats if it's your first time becoming an uncle.

[Unknown]

Dude, I can't wait. It's my first time being an uncle.

[Harry Stebbings]

My word, that was a fast tempo show. If you want to watch the show, you can find it on YouTube by searching for 20VC. That's 20VC on but before we leave you today, are you struggling to beat model benchmarks or implement Genai in your product? If so, you need Turing Turing is an AGI infrastructure company backed by incredible investors like Foundation Capital and Westbridge Capital and they do two things. One, they help leading companies in AI labs like Salesforce, Anthropic and Meta enhance their LLMs with advanced reasoning, coding, multilinguality, multimodality and more. Number two, they combine human and artificial intelligence expertise to deploy cutting edge AI systems for awesome companies like Rivian and Reddit. Right now Turing offers a free 5 minute self assessment to help you pinpoint your place in the Gen AI journey, get tailored next steps to optimize your model strategy and then finally learn how how Turing can refine and implement your models for better performance. Take the guesswork out of Genai. Visit turing.com 20vc to start your free assessment today and talking about scaling seamlessly. Let me tell you about WorkOS. So WorkOS is the modern identity platform for B2B SaaS helping startups move upmarket with ease. Selling to enterprises means honestly really complex security. Security requirements like saml, single sign on like SCIM provisioning audit logs. Honestly a ton of stuff that is just a nightmare to do. Features that take months to build and maintain. Well WorkOS streamlines this with flexible easy to use APIs that make enterprise readiness quick and painless. Its suite of features include AUTH Kit, a complete user management solution free up to a million monthly users with built in mfa, rbac bot protection and user impersonation Enterprise sso. My God these enterprises love their acronyms. Supports any identity provider using SAML or oidc, while Directory Sync enables seamless user provisioning and deprovisioning. Oh no. For SCIM compliant directories fine grained authorization powers complex permissioning and it comes again. The admin portal simplifies SSO and SCIM onboarding for IT teams trusted by companies like Cursor Cursor use this. If Cursor use this. It's gotta be great. Come on. Perplexity, Vercel, Sierra. I mean these companies are awesome. And they've raised $95 million in funding from amazing people like 20 VC. Try it today at WorkOS. Now that you've nailed enterprise features, let's talk about creating amazing product experiences. Get your users to do what you want them to do. That's the simple power of Pendo. The only all in one product experience platform. Pendo combines analytics in app guidance, session replay, feedback management and road mapping. All purpose built to work together. Seamlessly trusted by over 10,000 companies pending, Pendo is transforming how businesses understand and engage their users. Plus, they're the creators of Mind the Product, the world's largest product management community. It's awesome. See the magic for yourself. Visit Pendo iO20 product podcast to get started today. As always, I so appreciate all your support and stay tuned for an incredible episode coming on Monday with Snowflake CEO.