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
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 Tolkin. 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 stories and lessons from the Uber days.
But before we dive into the show's day, are you struggling to beat model benchmarks or implement JNI 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, multi-linguality, multi-modality 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 five minute self-assessment to help you pinpoint your place in the JNI 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 JNI, visit Turing.com forward slash two zero VC 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 up market 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 painless. Its sweeter 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 four IT teams trusted by companies like cursor, cursor users if cursor users it's got to be great.
Come on, perplexity, the cell, 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.com forward slash 20 VC. 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, Pendo is transforming how businesses understand and engage their users.
Plus, they're the creators of mine, the product, the world's largest product management community. It's awesome. See the magic for yourself, visit pendo.io forward slash 20 product hyphen podcast to get started today. You have now arrived at your destination. 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. It's be great. Dude, I spoke to so many people that 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 DD in major cities. This is what everyone told me. What are your biggest lessons from that time and launching China pool so efficiently? 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 realized heavily on liquidity to make efficient matches and all of that stuff. And it wasn't working. And it was 9 p.m. 10 p.m. 11 p.m. Midnight 1 a.m. I think it's slept 30 minutes on the floor of the Chengdu Eater office launched at 5.30 or maybe 6 a.m. And knock on wood. We were able to figure it out. And it worked.
What are your biggest product lessons from doing that launch? Yeah. And from that time with Uber and China. 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.
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 of building apps in China versus the US. And the reality is you go to China and it's different. It's not as 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. I think we see in the globalization of product design, when you look at TikTok, when you look at RedNote, when you look at the intrusion of Asian influence into actually Western product design, are we becoming more like them or are they becoming more like us?
I think there's absolutely a convergence. I think probably the influence is a little bit more being pulled towards us. But the reality is like apps like TikTok, there's a lot of things going on, things flying around, scrolling all that stuff as our attention spans shrink. Yeah, I think we're certainly meeting in the middle.
What was the worst product decision you made at Uber? And how did that impact your mindset going forward? Back in the early days of Uber pool, the way you accessed the product was this sort of this subset of Uber Act. So it wasn't all on the slider as it is today. It was you go to Uber acts and then above it, you see this little toggle where you can pick Uber pool or you can pick Uber acts 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 Uber acts on your last ride, it defaulted back to Uber pool. And so people, the UI wasn't clear enough what was happening. And so people were accidentally choosing Uber pool. And they thought they were getting an Uber acts. That's maybe what they were accustomed to or whatever. But then someone else would show up in the car.
How does that impact your product decision making? I think we prioritize the need and the desire to test out the bounds of liquidity, i.e. we prioritized the needs and in some ways of the business above the needs of the user in that case or respect for the users' 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 of 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 in a pre versus a post AI world? Most significantly. The tools and means and mechanisms, I think, will change. And so your primary tool or artifact of writing a PRD versus building a quick demo may change as it makes it easier and cheaper and to build. And I think we will see that. We will see a collapsing or converging of the end product design tree ad. 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 got to go talk to users, you got to go figure out what people want, you got to go build it and you got to 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 is your ability to communicate those ideas, your ability to do more upfront, your ability to do better user research, because you control prototypes easier. So I think the tool chest gets bigger, but the core skill set of like actually figuring out what people want and does it work for the business is the same. Does Figma get replaced by the right place in this world? I'm seeing more and more people jump that. Yeah, I don't know on the company level. I think maybe the generalized version of that is do more PM 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.
How does the product development process change in the world of AI? I had from many people that worked with you that you were like the master of the actual process of product development. How does that change in the 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 ago, it's like pretty waterfolly. 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 New York with a designer, and then 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, 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. You mentioned the one page of that. Say we keep it just for now. Sure. You've seen many different types of one pages. What is a great one pager and why do most people go most wrong? 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 are we at 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 where we're I get why we're doing this, and I get the problem. And it's totally fine. So expected that the solution is probably pretty underexplored in those one pages. I think people get wrong where the one pager is the solution description, not the problem statement. 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? The standard way would be impact confidence and effort, right? 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 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 paid on tech debt. And I think these can become spiritual debates. They sound like they come much more challenging when you're a public. 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 time frame 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.
You're an angel investor in my company in a hypothetical situation. I've got invested and I'm series A style. So I've got investors. And they want me to go from two million to eight million in a year era. 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? I think when you're early-ish stage like that at Seed City, doing two million, trying to get to eight million, you have to earn the right to exist in the future and paying down tech that 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 a land grab? Uber was in a land grab for many years. It had to be first, it had to get riders, it had to get drivers. And so there's very much a land grab competitive dynamic that pushes 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 at two million AR, 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.
Should the CEO always be the CPO? 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. 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. 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. It's classic innovator still on me. 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. And I think the best way that I've seen this approached is by giving new products a little bit of a sandbox that contains 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 Open Door 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 a totally separate app, a totally separate Oregon, a totally separate everything. 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. 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, whether 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. And so you're either playing in, do we take our core capabilities and that attach to a new customer set? Or do we take a new customer set and attach to our core capabilities? I think you can play in either one of those, but in both cases, it doesn't have to make the core product better, but it does have to make the core experience for your customers better. And it does have to make the business obviously better.
What fuckups did you make in going from single to multi product and break delicate with my words? 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 Uber X to Uber pool 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 Open Door, 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 of 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?
关于开放之门怎么样?在 Open Door,我们最初专注于业务的买方部分,并且我们知道我们希望成为多产品的公司。在这一年里,我们进行了许多举措,比如建立零售买家业务和抵押贷款业务。但我们本可以更好地专注于核心优势,而不是进入新的客户群体和新能力的领域。
But new capability set existing customer. And I think that's one of the companies heading now with a lot of its new products focused on helping sellers and how sellers can sell their home in a variety of ways. You said to me before, the most important product skill set is simplification. Speaking of product expansion, it's simplification and finding the kernel of truth. This is a brilliant one. It's a sea of cacophony.
I read this and I was like, my god, it's like Ernst Hemingway has fallen into my email. So can you explain that to me of why a kernel of truth is a sea of cacophony? 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 that 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 to say, okay, there's all of this feedback, all of this noise, what actually matters to user in the Uber examples 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? And 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 to 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 pack 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. Who is the one to set that? Okay, all of that is what you need to focus on.
Is that the CEO? Is that the CPO? Is that the 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 okayer 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 ladder what matters to me is, okay, in this case, it's easy. Uber pool trip count, but I can match my okayers and everyone else can ladder their okayers to the top one. So okayers to me are like cascading trees, wherever you are in the organization, like it should be layering up to the one or two above that.
What are the big mistakes people make with okayers in product, do you think? I think the biggest one is having too many. How many can you have? I think teens 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 okay, our 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've had to mix. 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.
Where did you focus at Open Door? Where with the benefit of hindsight, you shouldn't have? And how does that impact your mindset? Open Doors had different variations of a more good product that didn't succeed. And I think those were like articulated reason decision. 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.
在 Open Door,你把注意力放在哪里了?回顾过去,有哪些地方你不应该关注?这些对你的心态有什么影响?Open Door 曾有多种不错的产品,但没有成功。我认为那些决策是经过深思熟虑的。所以结果不一定是公司当时想要的,但我觉得很难将糟糕的决策与糟糕的结果完全分开。事后来看,很容易说我们应该把注意力放在别的地方。但当时的决策有其合理之处。我认为,如今关注于为卖家提供制胜的优势是最有价值的,而这也是现在应该关注的重点。
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 said, do you agree with that? 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. But you agree that people can adapt skill sets? 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 can be very good at a thing. And it's easy to stay good at that thing and do that thing.
How often should you change your chaos? 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? Teams should be developing their own Ocares. They should be defining the work that matters the most to the strategy and the top level Ocares 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.
Super early stage companies, like having an annual year-long OKR process when it's not clear we'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 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 of refinement of beauty of human preference? How do you think about that balance and what's ultimately more important? 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 on them to the world, you ship 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 minimal viable MVP is, but velocity matters left.
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 changing? The iPhone one is particularly challenging because it's hardware. And so hardware is hard in software though. I think 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 your definition of success where the classic, okay, we're going to make a change. We're going to roll it out until you get stats, and then we're going to pick the winner and that will move forward. 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 gumption 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 fives through eight data, not week one through four data. 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? So if you were to put me on a continuum where zero is 100% gut, zero is gut only, 100 is data only, you'd probably put me at 65 with one caveat, which is data is not just quantitative AB 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. It's simple, always better in product 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 right. 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 sliders are pretty simple UI to do it, where you can articulate everything 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. That's true. 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 valuable and actually encouraging much of them.
I on this hand think he's wrong, which is incredibly bold and arrogant given his CP of 100 billion dollar 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? So I think consensus product decision 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 for a vast majority of decisions, but so is not listening to anybody else in 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. I find very rarely does a slower decision lead to a better outcome. I agree with that one. 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 earlier in my career is 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 are 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 is this team need? And therefore, is this PM the right PM fit for the team? So it's the same way you have sounder market set, right?
You have like PM team fit. How do you know the PM types 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 the product. In a pithy way, someone that opened our door, if I were closely with, I have 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, i.e. Hey, this is a backend infrastructure thing where the key to success is the algorithm that we put for us. Therefore, the PM that we need to have needs to be able to deeply understand whatever the case is optimization or have a more matty 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, and 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, Tinker are 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.
When you look back on your hiring decisions, when they've gone wrong, what did you not see that you should have seen? 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, and so they didn't have enough clear direction or definition of success or clear outcomes. They had the wrong 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 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. Do you give them take home assignments in the interview process? Yes, most of the time, I do believe some type of work product is very. What is the best work product? Again, I'm a founder. You're helping me. How do I test them? 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'd 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 out.
You said that about how to run a sprint. Sprint's 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 be clear on what you're trying to accomplish in that sprint and make sure that everybody is aligned on it. Ideal timeline for a sprint. For most teams, two weeks growth teams often can run at one week and that's okay. 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?
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's aligned to the right company goals that have been set, then you're aligned. I'm not talking about necessarily agreement, but I can understand why I'm doing it. Do you believe in disagree and commit? Yes, they do. I don't understand how people will work. We can stay up late at night, give everything when they fundamentally disagree. You'll get participation and commit. 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, whatever, 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 it's probably time to start thinking about something else.
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? If you forced me to pick, I think there's a tremendous amount of undervalued appreciation for internal transfers from other functions into product at the same company. Engineering, product design, which becomes less important and which becomes more important in a world of AI. Engineering becomes more important. I would say less. Yeah, why would you say less? Because I think unless you're talking about top 1% performance-based model optimization, 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 the 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.
I think the way you just articulated, though, is the top 1% of designers, the top 1% of PMs and you bear that to the average engineer, the ability to still architect the 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. At Open Door, what is the best team product and your design?
At Open Door, 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 opt and design because it's so difficult to divorce your digital product from the physical embodiment of whatever you're doing. And by the way, this is also true in a slightly different format at Uber. 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 Open Door, but something completely out of your control, a third party ex-denality 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 place of our business.
The reason potentially I enjoy thinking about those problems and the way I've articulated this is computers are deterministic. Humans in the real world are not. 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. You're comfortable with the customer experience being out of your hands.
Like 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. 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. 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 your coming off an extended break. Obviously, some people take rig around the holidays and 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 the plans. Yes, we just thought about the next year. Let's ship something that matters in the next week. I agree. I think it applies actually just broader teams. I always say you have to manual fact, your hype and 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 great. Final one for 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 did you believe in the benefits of staying at one? 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 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 like 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.
You're advising a student coming out of university today. Do you start a company? Do you join a startup? Would you join a big company? Join a relatively early stage company. Why? The right balance between seeing some of what works but allowing you to make your own mistakes.
Okay, listen, I want to do a quick fire. So I say a short statement, you give me your immediate thoughts. You mentioned before we have a six month old, my brother's having a baby literally now. Oh, congratulations. Yeah, she's in hospital now. Amazing. Would you advise him? It's his first child on parenting. 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 in a cheat code.
What's the most common reason founders don't get product market fit? 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 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. What was the single best product decision you made? Upfront pricing for Uberport. Meaning like this is the price and they know it definitively. Yeah, when we first launched, it was variable. Back at the time, I don't know if you remember this, like you opened 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-talk calculate until we built upfront pricing where you'd see that beforehand.
What other function has the most tension with product operations? 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 up space solution. What was the most recent consumer wow moment you had with a product? It's cheating, but the honest answer is chat GPT. Really? I actually found the meta glasses, an amazing product experience. I don't know if you've tried, you put them on. I actually have not, but I've been with someone who did. Product experience is amazing, incredibly thoughtfully crafted, pretty beautifully done. Yeah, well, it's soon though, the AI music generator. Yeah. Unbelievable. That is unbelievable. I think the multi-modal ability to upload a screenshot, a picture, a video and say like, analyze this, tell me about this, think about this in chat GPT is pretty incredible.
The final one for you, what would you most like to change about the world of product today? 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 a product. Brian, I have peppered you with questions. I've loved doing this. I'm sure you feel that you've been interrogated. Thank you so much for this. And this has been so much fun. Thank you, Nanny. This is great. Love it. Good luck to your brother and congrats. If it's your first time becoming an uncle. Dude, I can't wait. It's my first time being an uncle. My word, that was a fast tempo show. If you want to watch the show, you can find it on YouTube by searching for 20 V.C. that's 20 V.C. on YouTube.
But before we leave you 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, multi-linguality, multi-modality 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 five 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 gen AI, visit Turing.com forward slash two zero V C to start your free assessment today and talking about scaling seamlessly.
Let me tell you about work OS. So work OS is the modern identity platform for B2B SaaS, helping startups move up market 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 work at our streamlines this with flexible easy to use APIs that may enterprise readiness quick and painless.
Its sweeter 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 four IT teams trusted by companies like cursor cursor use this if cursor use this it's got to be great come on perplexity, the cell CR I mean these companies are awesome and they've raised 95 million dollars in funding from amazing people like 20 V C try it today at workOS.com forward slash to zero VC 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 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.io forward slash 20 product hyphen 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.
Pendo结合了分析、应用内指导、会话回放、反馈管理和路线规划,所有功能都被设计成无缝协作的方式。超过10,000家公司信任Pendo,Pendo正在改变企业理解和吸引用户的方式。此外,Pendo是全球最大的产品管理社区“Mind the Product”的创建者。这个产品非常出色,让自己见识一下它的神奇之处吧!访问pendo.io/20-product-podcast今天就可以开始体验。感谢大家的一如既往的支持,敬请期待周一即将播出的由Snowflake CEO参与的精彩节目。