Brian Tolkin，Opendoor 产品负责人：如何组建最优秀的产品团队 | E1257

Upfront pricing for Uber Pool. When we first launched it, pricing was variable depending on whether you matched or not and the quality of that match. At the time, you opened the Uber app, said, “This is where I’m going,” and based on minutes and miles, the cost would calculate post hoc, until we built upfront pricing where you’d see that beforehand.

Brian, dude, I am so excited for this. I’ve wanted to make this happen for a while, so thank you so much for joining me today.

Thank you for having me. I’m super excited as well. This will be great.

1. Lessons from Launching Uber China Pool

Dude, I spoke to so many people who worked with you at Uber, and I heard that you were instrumental in the China Pool 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?

We were launching in China at the same time we were standing up a Chinese data center in China, and there were all sorts of technical issues. The day before launch, we were trying to get everything to work properly. We were launching in what sounds like Chengdu, which is a city in China and, by the way, a city of around 20 million people that most people at Uber had never heard of.

We were launching for rush hour because the product relies heavily on liquidity to make efficient matches. All that stuff wasn’t working, and it was 9:00 p.m., 10:00 p.m., 11:00 p.m., midnight, 1:00 a.m. I think I slept for 30 minutes on the floor of what sounds like the Chengdu Uber office. We launched at around 5:30 or maybe 6:00 a.m., and, knock on wood, we were able to figure it out and it sort of worked.

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

My biggest product lessons are, first, that the underlying data—the components that make your product work—really, really matter. In our case, we were trying to make matches between 2 riders for Uber Pool. The things that customers care about are the quality of the match and the price of the ride. What drivers care about is also, to some extent, the quality of the match.

Those things depend on having really good mapping and routing data. The reality is that in China there’s no Google Maps, so it’s much more difficult to have routing and mapping data. We had to work really, really hard to figure out how to make good matches work.

When we first launched, the matches weren’t that good, and the road infrastructure in China is very challenging. You have massive highways and overpasses and all of this complexity that is just a little bit simpler in places like the U.S. I think we underappreciated the complexity of making good matches without awesome underlying road data.

What do you know now that you wish you’d known then, when you think back to that time?

We probably could have done a better job at the start acknowledging the cultural differences between building apps in China versus the U.S. You go to China and it’s different. The sleek, elegant design where design sort of falls into the background isn’t as prominent. There’s a lot more color, red, big buttons, and that type of thing.

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

I think there’s absolutely a convergence. Probably the influence is being pulled a little bit more toward us, but the reality is that apps like TikTok have a lot of things going on—things flying around, scrolling, and all of that stuff. As our attention spans shrink, I think we’re certainly meeting in the middle.

2. Worst Product Decision at Uber

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

Back in the early days of Uber Pool, the way you accessed the product was a sort of subset of UberX. It wasn’t all on the slider as it is today. You would go to UberX, and above it you’d see this little toggle where you could pick Uber Pool or UberX. You’d see some differences around the price or the time that you would get there.

For a little while, the default was Uber Pool, and I think that was a poor product decision. Even if you had chosen UberX on your last ride, it defaulted back to Uber Pool. The UI wasn’t clear enough about what was happening, so people were accidentally choosing Uber Pool. They thought they were getting an UberX, which was maybe what they were accustomed to, and then someone else would show up in the car and they’d say, “How did that happen?”

3. How AI is Changing the Role of Product Managers

I think we prioritized the need and desire to test the bounds of liquidity. We prioritized the needs of some of the business above the needs of the user in that case, or respect for the user’s choices and wishes. That’s a lesson I’ve deeply internalized. Good PMs have to do both: understand what works for the user and what works for the business. In this case, we prioritized too aggressively in 1 direction.

That’s a tough one. You said there about good PMs being able to balance the needs of the business with the needs of the user. The role of the PM itself is changing so much, especially in a world of AI. Can you talk to me about how the PM role changes in a pre- versus post-AI world?

Most significantly, the tools, means, and mechanisms will change. Your primary tool or artifact—writing a PRD versus building a quick demo—may change as AI makes it easier, cheaper, and faster to build. I think we will see a collapsing or converging of the engineering, product, and design triad. They will never be the same, but I think everything will be pulled in tighter.

I think all of that will change. What won’t change is the core of the PM job. You have to go talk to users, figure out what people want, build it, and build it in a way that makes sense for the business.

Trying to figure out the creative part of the job is still core. You have some customers telling you this, other customers telling you that, your customer experience team telling you something else, user interviews telling you something, and your data telling you something different. What do you actually build? What do you do? How do you make a good decision that works, and how do you do it with velocity? How do you know Type 1 decisions from Type 2 decisions? Those core components don’t change in a pre- or post-AI world.

What changes is your ability to communicate those ideas, your ability to do more upfront, and your ability to do better user research because you can show prototypes more easily. The tool chest gets bigger, but the core skill set of figuring out what people want and whether it works for the business is the same.

Does Figma get replaced by what sounds like Replit in this world? I’m seeing more and more people jump to that.

I don’t know. Maybe the generalized version of that question is: do more PMs start in prototyping land rather than in strictly designed land? I think the answer to that is yes.

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.

4. How AI is Transforming Product Development

How does the product development process change in the world of AI? I’ve heard from many people who have worked with you that you’re the master of the actual process of product development. How does that change in a world of AI?

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, the process was pretty waterfall, and I think as an industry we’ve moved away from that.

You still have the PM owning the initial PRD or one-pager, design owning the Figma file or design prototype, and engineering owning the actual implementation in code. That creates a process in and of itself. The PM is at the top of the funnel, developing the idea; then the designer comes in, you work with the designer, and it moves down the funnel.

I think AI completely collapses that cycle and accelerates a lot of the upfront work. You can build a prototype and show it to customers. The PM and designer might work collaboratively and say, “Let’s just build a prototype. Let’s skip the document stage and do that instead,” rather than talking as a first step, showing some flat files, and then building 1 or 2 prototypes to refine your hypothesis.

The development process just accelerates a lot.

You mentioned the one-pager there. Let’s keep it for now. You’ve seen many different types of one-pagers. What is a great one-pager, and where do most people go wrong?

If you’re early in the process, which is probably when you’re writing a one-pager, the important thing to get right is the problem definition—the why. What is the core insight that is the reason we’re even talking about this project? That’s usually a user insight, a business insight, or both.

Anybody should be able to pick up that one-pager and say, “I understand where we’re going, why we’re doing this, and what the problem is.” It’s totally fine, and expected, that the solution is probably underexplored in those one-pagers.

I think people get it wrong when the one-pager is a solution description rather than a problem statement.

5. Speed vs. Taste: What Matters More in Product Development?

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

The standard way would be impact, confidence, and effort. I think that’s a reasonable, good framework. There’s a reason it’s been around forever, and there’s a reason people use it.

The part that has to be mashed up with that is something about time horizons and the priorities of the company at any given time. One tension that often arises is how much we build new features now versus stabilizing existing features versus paying down technical debt.

These can become spiritual debates or religious debates. It is more challenging when you’re public, but it doesn’t change the core principle: you still need to decide at the highest level what time frame you’re optimizing for.

Experience debt and technical debt are apt descriptions. You trade paying it down now for paying later, or you trade taking it on now to pay later.

6. Balancing Growth vs. Technical Debt at Series A

You’re an angel investor in my company in a hypothetical situation. I’ve got investors, and I’m Series A-style, so they want me to go from $2 million to $8 million in a year. I’m mindful that I’ve got growing technical debt. Do I focus on new product expansion and just let the technical debt wear out, or do I solve the technical debt at the cost of maybe lower growth and fewer new products?

When you’re at an early-ish stage like that—seed or Series A, doing $2 million and trying to get to $8 million—you have to earn the right to exist in the future. Paying down technical debt doesn’t pay the bills, so I think at that stage it’s probably a little bit early to start paying down technical debt.

It depends a little bit on whether you’re in a land grab. Uber was in a land grab for many years. It had to be first. It had to get riders and drivers. There was a competitive dynamic that pushed a certain philosophy and velocity.

I think most early-stage companies tend to be in that situation. You have to figure out whether the thing you’re building in that $2 million ARR business actually has value, whether people want it, and whether people will pay for it. Slowing down early to pay down that debt is often challenging.

7. Should the CEO Also Be the CPO?

Should the CEO always be the CPO?

Always? No. In the early stages, yes.

There are certain scales of companies where that may not make sense anymore, but in the early days, I do think they should. If you think the most important asset your company has is the product it’s delivering, outsourcing that to someone else in the early stages can be really, really challenging.

8. Lessons in Expanding from Single to Multi-Product

We mentioned the focus on new products or expansion of products versus technical debt. You’ve gone from single- to multiproduct. What are your biggest lessons on how to go from single to multiproduct? It’s a challenge so many people face.

It’s a challenge. There’s a product challenge, and then there’s a cultural challenge.

The product challenge is a likely classic innovator’s dilemma: you have this chasm to cross—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. You have a bunch of users who care about your core product, so I think the best way I’ve seen this approached is by giving new products a little bit of a contained sandbox that relaxes a bunch of the constraints of the company, but in a way that, if it completely fails, it doesn’t harm the overall core product experience.

Uber and Opendoor have an advantage because you can do this geographically, by city. In Uber’s case, an even more extreme example is Uber Eats, which was a totally separate app, a totally separate organization, and a totally separate everything.

It doesn’t harm it. Does it have to benefit the first product?

I don’t think it has to benefit the first product, but it has to take advantage of some competitive advantage that your company has.

If you think about a classic 2-by-2 matrix, you have your customer set and 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.

You’re either taking your core capabilities and attaching them to a new customer set, or taking a new customer set and attaching them to your core capabilities. You can play in either one of those spaces, but in both cases it doesn’t have to make the core product better. It does have to make the core experience better for your customers, and it obviously has to make the business better.

What fuckups did you make in going from single to multiproduct?

The biggest challenge with going from single product to multiproduct—I actually described probably the biggest fuckup previously. It was Uber going from UberX to Uber Pool in 1 step, and that was actively harming the overall user experience. That was probably the single biggest one.

At Opendoor, we initially started building heavily on the buyer side of the business. We knew we wanted to be multiproduct, and we had a bunch of initiatives over the years: building a retail buyer business, building a mortgage business, and so on.

9. The Power of Simplification: Finding the Kernel of Truth

I think we could have been better about focusing on our core strengths and not being in that new-customer-set, new-capability quadrant. We should have focused on a new capability set with our existing customers. I think that’s where the company is heading now, with a lot of its new products focused on helping sellers sell their homes in a variety of ways.

You said to me before that the most important product skill set is simplification and finding the kernel of truth. This is a brilliant one. It’s a sea of cacophony. I read this and thought, “My God, it’s like Ernest Hemingway has fallen into my email.” Can you explain why a kernel of truth is in a sea of cacophony?

The product job is challenging. You have executive pressure, your independent thoughts, what customers are telling you, scaled customer feedback from your customer experience team, and your sales team yelling at you with other feature requests. It’s the prioritization exercise we talked about.

All of these different pressures often come in the form of solutions: “We need this feature,” “It would be great if the product did this,” “We lost a deal because of that,” and so on.

The core of the product job is to say, “There’s all of this feedback and all of this noise. What actually matters to the user?”

In the Uber example, there are a ton of things that make the product work, or that made it work in the early days. At the end of the day, is there a car available? Can it get to me quickly, within 5 minutes, at a reasonable price? If you can do that, all the other product nuances fade away.

That’s the simplicity that matters for that product. You try to align everything and say, “How do we prioritize everything that moves 1 of those particular dimensions?” You have to understand that when someone says cancellations are a big problem, our CAC is too high, and all these other things are problems, those may be real problems or potential solutions. You have to find what you really need to focus on and what matters.

Who is the one to set that OKR, the thing that you need to focus on? Is that the CEO, the CPO, or the head of product?

That level needs to come from the top down and say, “This is the success metric for the company.” Then it cascades to the rest of the organization.

In the Uber case, trips may just be the metric—the objective and key result that matters. I’m doing Uber Pool, so as a product leader for my area—not the whole company, obviously—I can say, “How do I ladder up to that?” What matters to me in this case is easy: Uber Pool trip count. I can match my OKRs, and everyone else can ladder their OKRs to the top-level one.

OKRs are cascading trees. Wherever you are in the organization, you should be layering up to the 1 or 2 levels above you.

What are the big mistakes people make with OKRs in product?

The biggest one is having too many. Teams can generally have a few—3 at any given time that really matter, maybe 3 to 5 depending on the size of the team.

If you’re focused on everything, you’re not focused on anything. In the OKR process, it’s important to have a manageable number, but then also be able to articulate what important things you’re not doing and the tough trade-offs you had to make.

If you’re doing everything, doing it all, and doing it all at once, it wasn’t necessarily a rigorous prioritization exercise.

Where did you focus at Opendoor where, with the benefit of hindsight, you shouldn’t have? How does that impact your mindset?

Opendoor had different variations of a mortgage product that didn’t succeed. Those were well-articulated, well-reasoned decisions. The outcome wasn’t necessarily what the company wanted at the time, but I think it’s hard to divorce bad decisions from bad outcomes.

10. Are People Naturally Suited for Certain Company Stages?

Hindsight makes it very easy to say we should have focused elsewhere, but I think those were well-reasoned decisions at the time. 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.

Can I ask you, when you think about single to multiproduct and technical debt, do you think people are destined for certain stages of company development? It’s often said. Do you agree with that?

No, because I believe in human agency and people’s ability to adapt their skill sets. Certain skill sets are better adapted to certain stages of a company, but I think people can grow with companies and grow in their careers. They can adapt their skill sets. People want to have to do that, and that may be the hardest challenge.

People can be very good at 1 thing, and it’s easy to stay good at that thing and continue doing it.

So, at any given time, you agree that people can adopt new skill sets?

I do think people can adopt skill sets. I think people can grow with companies and grow in their careers. I do think people can adapt their skill sets.

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

Teams should be developing their own OKRs. They should be defining the work that matters most to the strategy and the top-level OKRs that are outlined.

There are a couple of philosophies here. Generally, the quarterly planning process makes sense. I don’t think you should be changing your objectives that frequently, because otherwise it’s an unfocused strategy. It’s unlikely that you officially completed your objective in a quarter. Maybe it should be every year or 6 months.

The more nuanced answer is that you earn the right to set OKRs on longer time horizons by proving you can execute on shorter time horizons. For super early-stage companies, having an annual, year-long OKR process when it’s not clear what you’re going to build in 3 weeks doesn’t feel like a worthwhile exercise.

You earn the right to plan on longer time horizons by proving that you can set and execute over shorter ones.

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

I personally fall a little bit more on the velocity side. That’s not an extreme version of it. The reality is that, as good as your product intuition is, you throw something out into the world, ship something, and figure out whether people like it.

The more shots on goal you take with that feedback loop, the more likely you are to succeed. I don’t think you can throw out crap, because the risk is that you get a negative signal when the problem was actually just bad execution. You have to have a minimum bar, which is what the “viable” in minimum viable product is.

Velocity matters a lot.

Dude, how do you determine whether your new product, product update, or redesign is shit versus users just not being used to the transition or change? I remember the iPhone losing its home button. All of the people around me were saying, “This is terrible. Swipe up now? It’s preposterous.” Now it’s hard to imagine anything else.

How do you think about whether it’s a bad decision or just user preferences changing?

The iPhone example is particularly challenging because it’s hardware, and hardware is hard.

In software, you tend to have the ability to give people time. What you need to do is be more rigorous in how you think about your metrics and your definition of success.

The classic approach is, “We’re going to make a change, roll it out until we get statistical significance, pick the winner, and then move forward.” That may lead you in the wrong direction, because you may have a novelty effect where the numbers decrease, or you may have a novelty effect where the numbers increase, but it’s temporary.

If you think there’s a risk that the change is just a shift in customer behavior, you may set up your experiment differently. You might say, “We’re going to look at all the data, but we’re not going to make a decision in the first 2 weeks. We have to have the gumption to say that we might see patterns in behavior where behavior is slowly changing over time.”

We may need to evaluate the experiment on weeks 5 through 8 rather than weeks 1 through 4.

To what extent are you a gut-driven product leader or a data-driven product leader, if I were to put you in 1 camp?

If you put me on a continuum where 0 is 100% gut—gut only—and 100 is data only, you’d probably put me at 65, with 1 caveat: data is not just quantitative A/B tests.

Opendoor has this lesson for sure. 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 looking at 150 data points and finding an insight.

So, 65 is the answer because true gut is just, “I went with what I thought.”

Is simple always better in product?

For a given necessity of complexity, simple is better. Take the Uber example: “Push a button, get a ride.” That’s the original Uber thesis. It was Uber Black: push a button, get an awesome ride.

That’s much simpler than opening the app, seeing a slider, picking a car type, and pushing a button to get a ride. But the reality is that, if you want options to serve different customers and different use cases, the slider is a pretty simple UI for doing it. You can articulate everything within 1 paradigm.

For a given necessity of complexity or feature set, yes, simple is always better. But you can be very reductionist and say, “If simple is always better, then Uber moving to a second car type in 1 app was a bad choice.” I don’t think that’s true.

11. Dictatorial Product Leadership vs. Collaborative Decision-Making

One thing I think about often is Gustav at Spotify, who is a dear friend and one of the best product leaders in the world. He always says that talk is cheap, and so we should do more of it, in terms of internal discussions being so valuable and actually encouraging more of them.

On the 1 hand, I think he’s wrong, which is incredibly bold and arrogant given that he’s the CPO of a $100 billion company and I have a podcast. I actually think 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?

Consensus-based product decision-making is challenging and wrong.

So you think A. I think B: let’s meet in the middle. I’m not going to ask you, because I think you think B, and I don’t want to hear a difference of opinion.

That’s not good either. I think “talk is cheap, therefore we should do more of it” means getting all the opinions on the table, making sure to gather everyone’s expertise, and then making the best decision given the information.

Slow decision-making is expensive for the vast majority of decisions, but so is not listening to anybody else and gathering opinions. If “dictatorial” means, “I have all the right answers and my opinion always wins,” I don’t agree with that. That’s different from consensus.

I find very rarely that a slower decision leads to a better outcome.

I agree with that.

I agree with that one. When it comes to hiring for product teams, I do want to discuss this because you talked about hiring for true product teams, and I thought that was interesting. What do you mean by true product teams versus just good PMs?

Earlier in my career, I thought, “If you find someone who’s smart and hardworking and can do that distillation, they’re 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.

There are PMs who grew up as designers and then became PMs. There are engineers, people with technical backgrounds, data backgrounds, business backgrounds, or operations backgrounds. We can be more nuanced in our thinking and ask, “What does this team need, and therefore is this PM the right fit for the team?”

It’s the same way you have founder-market fit. You have PM-team fit.

How do you know the PM type that you need? Do you look across the team and say, “We’re missing a consultant or a former consultant, an analytical brain who wants to be CEO of the product,” in a pithy way?

Someone at Opendoor I worked closely with had this phrase: “You hire your strategy.” The person you pick to play that role will dictate how that person defines the success of that product. You need to have a perspective on that when you’re hiring.

There are 2 dimensions. First, what does the team, or maybe the product they’re working on, need? For example, if it’s a backend infrastructure project where the key to success is the algorithm we put forth, then the PM needs to be able to deeply understand optimization or have a more mathematical background.

Then there’s your functional product team. You might say, “Our functional product team has a lot of people who fit this type of mold. We need somebody who’s going to push us in the direction of being that crazy, out-there tinkerer who’s always trying the newest technology and tools. They’re going to bring that energy into our product team because we’re also a team.”

Both of those dimensions are important.

12. Lessons from Hiring Mistakes

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

I believe poor hiring decisions are never just the person’s fault. They’re almost always the fault of the company or the hiring person, not just the responsibility of the person being hired.

In that context, what I’ve seen most often is that the person wasn’t set up for success. They didn’t have enough clear direction, a definition of success, or clear outcomes. They had the wrong skill set for what we were talking about: their interest was on the design side, but what the team really needed was a more technical engineering leader because those were the challenges the team was facing.

A corollary to the first point is that the ambiguity of the role and the ambiguity of the challenge were above that person’s ability to distill the ambiguity and find what really matters.

Do you give candidates take-home assignments in the interview process?

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

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

The best option is people you’ve worked with before, because that’s a lot better than a 1-hour interview.

You can either ask them to show a previous work product they’ve worked on, or give them some type of consistent case study. Depending on the role and seniority, you can give them a somewhat ambiguous problem and ask them to talk about how they would handle it, or put together a document, deck, or whatever on how they would approach it.

The important part is that it can’t be too narrowly scoped. The tactics of the job—you can learn how to run a sprint or how to do prioritization. That stuff can be learned. That’s not what the test is. The test is clarity of thought and getting to the outcome.

I totally get you, and I agree. 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?

Just be clear. The biggest tip I have is to be clear on what you’re trying to accomplish in that sprint and make sure everybody is aligned on it. I’m a big fan of alignment.

The ideal timeline for a sprint?

Probably 2 weeks for most teams. Growth teams can often run 1-week sprints, and that’s okay.

Brian, I’m enjoying this a lot. I find alignment to be 1 of those bullshit management terms. It’s overused and put in the same culture bucket, which means nothing, but it’s meant a lot in the last 5 years. Am I being unfair?

Let me give you what I mean by it. Everybody, at any given time, should ideally understand the most important thing they can be working on, why that matters, and how it ladders up to customer or company goals. They should be able to fluently discuss those things.

If they can do that, and it aligns with the right company goals that have been set, then you’re aligned. I’m not talking about agreement, necessarily. I can understand why I’m doing it.

Do you believe in “disagree and commit”?

Yes, I do.

You don’t think that—I don’t understand how people will work weekends, stay up late at night, and give everything when they fundamentally disagree. You’ll get the mediocre. You’ll get participation and commitment.

It’s a good push. It’s a good question. This goes back to Steve Jobs’s Stanford commencement address: if you look in the mirror too many days in a row and realize that you don’t like what you’re doing, you should probably do something else.

I think that applies to “disagree and commit.” For a sprint or a month, can I disagree and commit? For sure. That’s how we make velocity-based decisions. If I’m disagreeing and committing too much, then I agree with you: I’m in the wrong place because I’m not fundamentally aligned with where we’re going, and it’s probably time to start thinking about something else.

13. The Best Backgrounds for Hiring Great PMs

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

There’s a tremendous amount of undervalued appreciation for internal transfers from other functions into product at the same company: engineering, product design, or other functions.

Which becomes less important and which becomes more important in a world of AI?

Engineering becomes more important.

I would say less. That would be my bet. Why would you say less?

Unless you’re talking about the top 1% of performance-based model optimization and the truly difficult technical challenges, you’re going to see a commoditization of engineering challenges. 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. I think design will have an even bigger place, because you’ll see the de-skilling of design, with AI doing things that are good enough. A lot of people will be happy with good enough, but the design pros will be up here.

Fair. I think what you just articulated is the top 1% of designers, the top 1% of PMs, compared with the average engineer. The ability to architect a system that thinks ahead and thinks around corners will still matter.

To answer the question the way you were answering it, the top 1% or top 5% of all the skill sets get a lot more valuable, and the median gets a lot less valuable.

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

At Opendoor—and I think this is true at a lot of operationally intense companies—we actually consider the classic triumvirate of engineering, product, and design to be product, operations, and design. It’s so difficult to divorce your digital product from the physical embodiment of whatever you’re doing.

By the way, this was also true in a slightly different format at Uber.

What I find really challenging with you as a product leader who loves hard, physical product businesses is that you could have the most beautiful consumer software experience, whether at Uber or Opendoor, but something completely out of your control—a third-party externality—could destroy the customer experience and make users think you’re shit when you’ve done everything you can.

That’s very different from another business that is a pure-play software business.

The reason I potentially enjoy thinking about those problems is that computers are deterministic, while humans in the real world are not. You have real-world entropy, and you have to think about how your product adapts to that real-world entropy.

That’s hard, for sure. I don’t want to pretend that it’s easy. It’s completely challenging. But I acknowledge that some of the most important and 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.

14. Managing Momentum as a Product Leader

You said before about being biased because I asked which was your favorite. How do you think about managing momentum as a product leader? It’s very difficult to do well.

One of the things I try to think about is that, if you feel like the team needs a momentum boost, that might be because the team is newly formed. It might be because you’re coming off an extended break. Some people take a break around the holidays. It could be that you just had a difficult business outcome, a reduction in force, or something like that.

You might say, “We need to inject and infuse some positive energy and momentum here. Let’s perhaps unnaturally ship something that’s a little bit lower impact but higher confidence and lower effort, so we can prioritize speed and confidence of impact.” The team gets some excitement moving forward, and that compounds.

You may have a slightly unnatural prioritization that says, “We just came back from the holidays, and everyone’s excited about their plans. We just thought about the next year, but let’s ship something that matters in the next week.”

15. The Case for Staying Longer at One Company

I agree. I think it applies to broader teams as well. You have to manufacture hype, management, and goodwill. When someone does something that’s normally a small thing, make it a much bigger thing, because everyone wants to feel that, especially in harder times, they did something great.

The final one before we do a quick fire: you talked before about the benefits of staying for longer periods of time at 1 company for individuals. That’s different from how most people operate in the Valley. People are incredibly promiscuous as a group and jump from 1 AI company to another right now, it would seem. Why do you believe in the benefits of staying at 1 company?

I’m biased because I’ve spent 2 longer stretches at companies, but the reality is that you just become more effective and therefore can do more, more quickly. You have deeper relationships and deeper context on the company and customer base, so you can be more effective.

If you’re hopping every 18 months or 2 years, and you assume it takes 6 months to ramp, that’s a lot of time before you’re effective. To really deeply understand and gain context, and then at some point start 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 your goal shouldn’t be to move on every 2 years, as you can read about canonically, because I think you just become more effective with time.

You’re advising a student coming out of university today. Do you tell them to start a company, join a startup, or join a big company?

Join a relatively early-stage company.

Why?

It’s the right balance between seeing some of what works and allowing you to make your own mistakes.

16. Quick-Fire Round

Okay, listen, I want to do a quick fire. I’ll say a short statement, and you give me your immediate thoughts. No nuance. I got it.

You mentioned before that you have a 6-month-old. My brother’s having a baby literally now.

Congratulations.

She’s in the hospital now. What would you advise him? It’s his first child.

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

Yeah, don’t worry. Mom’s there.

Exactly.

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

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

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

The hiring lesson I gave earlier: make sure to really understand what the problem needs, and then find the person who’s really good at that type of problem.

What was the single best product decision you made?

Upfront pricing for Uber Pool, meaning, “This is the price. Know it definitively.”

When we first launched, pricing was variable depending on whether you matched or not and the quality of that match. At the time, you opened the Uber app, said, “This is where I’m going,” and based on minutes and miles, the cost would calculate post hoc. We built upfront pricing so you’d see that beforehand.

What other function has the most tension with product?

Operations. The speed, cadence, and types of problem-solving are very, very different, so it can be challenging to speak the same language on things that have a product or technical solution versus an operations-based solution.

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

It’s cheating, but the honest answer is ChatGPT.

Really? You didn’t think it was amazing?

I found the Meta glasses to be an amazing product experience.

I haven’t tried them, but I’ve been with someone who did.

The product experience is amazing—an incredibly thoughtfully crafted and beautifully done product.

What about Suno, the AI music generator?

Unbelievable. That is unbelievable. I think the multimodal ability to upload a screenshot, picture, or video and say, “Analyze this, tell me about this, think about this,” in ChatGPT is pretty incredible.

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

I think the breaking down of silos is important. The use of AI tools to break down the silos between functions will be more challenging than a lot of people are giving it credit for.

I would love to see that change, where PMs more quickly say, “Yeah, let’s just go to a prototype.”

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. This has been so much fun.

Thank you, Harry. This was great. Good luck to your brother, and congratulations if it’s his first.

Done—becoming an uncle.