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
发布时间 2025-02-07 07:07:00 来源
摘要
Brian Tolkin is the Head of Product @ Opendoor where he has spent the last 6 years and is responsible for product strategy and product and design teams. Before Opendoor, Brian spent an incredible 5 years at Uber through their wildest growth periods. In Today’s Episode with Brian Tolkin: 03:53 Brian's Journey at Uber: Launching China Pool 05:07 Product Lessons from Uber's China Launch 08:22 The Role of a PM in a Pre vs. Post AI World 10:16 Product Development Process in an AI World 17:43 The Importance of Simplification in Product Management 19:21 OKRs and Prioritization in Product Management 23:12 The Importance of Feedback Loops in Product Development 23:38 Evaluating Product Changes: User Adaptation vs. Bad Decisions 25:00 Balancing Gut Instinct and Data in Product Leadership 25:38 The Role of Simplicity in Product Design 27:02 Consensus vs. Dictatorial Product Leadership 27:54 Hiring for the Best Product Teams 31:33 How to do Effective Sprint Management 38:39 Quickfire Round: Insights and Advice
GPT-4正在为你翻译摘要中......
中英文字稿 
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.
这是《20位产品领袖》节目,我是主持人哈里·斯特宾斯。在这个节目中,我们会与全球顶尖的产品领袖一起深入探讨产品策略、产品团队的成长,以及如何招聘优秀的产品人才。今天加入我们的是布莱恩·托尔金,他是Open Door的产品负责人,已经在这家公司工作了六年多,负责产品战略以及产品和设计团队的管理。在加入Open Door之前,布莱恩在Uber工作了五年,经历了公司高速增长的时期,并分享了一些来自那段时期的精彩产品故事和经验教训。
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.
在我们深入讨论这个节目的内容之前,你是否在努力超越模型基准或者在你的产品中实现JNI技术?如果是这样的话,你需要了解Turing。Turing是一家AGI基础设施公司,得到了Foundation Capital和Westbridge Capital等知名投资者的支持。他们主要做两件事情。第一,他们帮助像Salesforce、Anthropic和Meta这样的顶尖公司提升他们的LLM(大型语言模型),增强其高级推理、编程、多语言处理、多模态功能等能力。第二,他们结合了人类与人工智能的专长,为Rivian和Reddit等优秀公司部署最前沿的AI系统。
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.
图灵(Turing)目前提供一个免费的五分钟自我评估,帮助你明确在JNI旅程中的位置,并获得优化模型策略的个性化建议,最后学习图灵如何完善和实施你的模型以获得更好的性能。让JNI不再靠猜测,访问Turing.com/20VC,立即开始你的免费评估。说到无缝扩展,来让我告诉你关于WorkOS的事情。WorkOS是面向B2B SaaS的现代身份平台,帮助初创企业轻松进入更广阔的市场。销售给企业意味着需要处理非常复杂的安全需求,比如SAML、单点登录、SCIM、提供审计日志等,说实话,这些都是非常麻烦的事情。
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.
用几个月来构建和维护的功能。好吧,WorkOS通过灵活易用的API简化了这个过程,使企业准备变得快速而轻松。它的亮点功能包括认证工具包,一个完整的用户管理解决方案,每月允许最多一百万个用户免费使用,并内置多重身份验证(MFA)、角色访问控制(RBAC)、机器人防护和用户模拟,还支持企业级单点登录(SSO)。天哪,这些企业真的喜欢他们的缩略语。您可以使用SAML或OIDC支持任何身份提供商,而目录同步能实现无缝的用户配置和取消配置。对于符合SCIM标准的目录,它提供了细粒度的授权功能和复杂的权限管理。此外,管理员门户简化了IT团队的SSO和SCIM上手过程,得到了如Cursor这样的公司的信赖。如果Cursor的用户喜欢它,那它一定很出色。
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.
来吧,Perplexity、The Cell、Sierra,这些公司都很棒,它们从一些了不起的投资者那里筹集到了9500万美元的资金,比如20 VC。今天就去workos.com/20 VC试试吧。现在您已经掌握了企业功能,我们来谈谈如何创造出色的产品体验。让您的用户按照您的意图行事。这就是Pendo的简单强大之处,它是唯一的全合一产品体验平台。Pendo将分析、应用内指导、会话回放、反馈管理和路线规划结合在一起,专为无缝协作而设计。超过10,000家公司信任Pendo,Pendo正在改变企业理解和吸引用户的方式。
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.
另外,他们是“我”的创造者,也就是那个产品——全球最大的产品管理社区。这太棒了。亲自体验一下这个魔力吧,访问 pendo.io/20product-podcast 来开始您的旅程。你现在已经到达目的地了。布莱恩,兄弟,我对此感到非常兴奋。我一直想实现这件事,所以非常感谢你今天能加入我。谢谢你邀请我。我也超级兴奋,这一定会很棒。兄弟,我和很多在优步工作过的人聊过天,他们告诉我,你对中国Uber优步拼车的推出起到了重要作用,这让Uber能够在大城市直接与滴滴竞争。大家都是这么和我说的。你在那段时间以及高效推出中国拼车服务时学到的最大经验是什么?我们在中国推出业务的同时也在建立一个中国的数据中心,而且在推出前一天,解决所有技术问题以确保一切正常运作非常关键。
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.
我们在成都启动业务,顺便提一下,这是一座有2000万人口的城市,但大多数Uber员工之前都没听说过这个地方。我们选择在交通高峰期启动,因为我们的产品需要高流动性来实现高效的匹配。然而,当时我们的系统运转不正常。那时已经是晚上9点、10点、11点,甚至接近午夜1点。我在成都食客办公室的地板上睡了大约半小时,早上5点半或6点重新启动。幸运的是,我们最终解决了问题,系统成功运作。
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.
你在产品发布中学到了哪些重要经验?从那次发布以及在Uber和中国的经历中,我获得的最大产品教训是,了解推动产品运作的各个组件非常重要。在我们的案例中,我们试图在Uber拼车中为两位乘客匹配。客户关心的是匹配质量和乘车价格,司机也在意匹配质量。而这些都依赖于优秀的地图和路线数据。然而,现实是,中国没有谷歌地图,要获取路线和地图数据要困难得多。我们不得不非常努力地去解决如何实现良好匹配的问题。实际上,当我们首次推出时,匹配质量并不好。同时,中国的道路基础设施也非常具有挑战性。有巨大的高速公路、高架桥和各种复杂结构,而这些在像美国这样的地方相对简单。我认为我们低估了在没有优秀路况数据的情况下实现良好匹配的复杂性。
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?
你现在知道什么是你希望在那时就知道的?回想当时,我们本可以在一开始做得更好,更好地认识到在中国和美国开发应用程序时的文化差异。事实上,当你到达到中国时,你会发现那里有所不同。那里的设计并不像美国那样追求简约、优雅,在设计上更多使用鲜艳的色彩,比如红色,以及大按钮等元素。我认为在产品设计的全球化过程中,比如你可以看到TikTok、RedNote以及亚洲风格对西方产品设计的影响,或许让人思考:究竟是我们变得更像他们,还是他们变得更像我们?
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.
我认为确实存在融合。我觉得可能更多的影响力正在向我们这边倾斜。但事实上,就像 TikTok 这样的应用,有很多事情在发生,信息在飞速传播,我们的注意力变得越来越短。是的,我觉得我们确实在中间找到了平衡点。
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.
在Uber,我做过最糟糕的产品决策是什么?这对我之后的思维方式有什么影响?在Uber Pool的早期阶段,用户访问这个产品的方式是通过Uber X的一种子集。当时不像现在这样通过滑块选择。用户需要先打开Uber X,然后在上面看到一个小开关,可以选择Uber Pool或Uber X,并能看到一些关于价格或到达时间的差异。有一段时间,默认选项是Uber Pool。我认为这是一个糟糕的产品决策,因为即使用户上次乘坐的是Uber X,系统还是会默认回到Uber Pool。而且用户界面不够清晰,导致人们不小心选择了Uber Pool,以为自己是在叫Uber X。这可能是他们之前习惯的服务或其他原因,但结果是车上会出现其他人。
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.
我到底要构建什么?我该做什么?如何做出有效的好决策?我该如何快速做到这些?我如何区分一类和二类决策?这些核心要素,我认为在AI时代前后都不会改变。我认为改变的是你传达这些想法的能力、在前期能做更多准备的能力,以及进行更好的用户研究的能力,因为你能更轻松地控制原型。因此,我觉得我们的工具箱变得更大,但核心技能,比如弄清楚人们想要什么以及它是否对业务有帮助,这些仍然不变。Figma会在这个世界中被取代吗?我看到越来越多人在跨越这一点。在公司层面,我还不确定。我想这个问题的普遍版本是,产品经理更多的是从原型领域开始,而不是单纯的设计领域。我认为答案是肯定的,但在公司层面,我认为Figma会继续为设计师、产品经理和工程师开发产品,并使其越来越接近于能够通过生产代码实现。
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.
在人工智能的世界里,产品开发过程是如何改变的呢?很多和你共事过的人都说你是产品开发过程的大师。那在人工智能的世界里,这个过程是怎么改变的呢?这种评价真是太客气了,我不确定自己是不是称得上大师。如果你回顾20年前,流程相当类似瀑布模型。我们这个行业已经逐渐转向其他方法,但仍然存在这种情况:产品经理(PM)负责最初的产品需求文档(PRD)或一页纸文档,设计师负责Figma文件或设计原型,工程团队负责真正的代码实现。这构成了一个完整的流程,PM位于流程的最顶端,负责构思创意,然后设计师加入开发,接着流程逐步推进。而我认为,人工智能完全打破了这个周期,大大加速了前期的开发工作。现在,团队可以直接建立原型并展示给客户,PM和设计师可以合作说:“我们干脆直接做个原型,跳过文档阶段。”而不是一开始就讨论,然后展示一些平面文件,再构建一个或两个原型来完善你的假设。
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.
在一个假设的情况下,你是我公司的天使投资人。我已经获得了一些投资,处于A轮融资的阶段。有投资者希望我在一年内将公司从200万美元做到800万美元。但我意识到,我们的技术债务正在增加。我应该专注于新产品的扩展,让技术债务暂时不管,还是解决技术债务,即便这可能会导致增长和新产品减少呢?
我认为当你还处于早期阶段时,比如说在Seed City做到200万美元,准备提升到800万美元,你需要确保未来的生存权,偿还技术债务并不能支付账单。所以在这个阶段,可能还稍微有点早去解决技术债务。
但这也要看情况,你是否处在一个“抢地盘”的状态?比如说Uber很多年都是在“抢地盘”,它必须是第一个,必须获取乘客和司机。所以有一个非常激烈的竞争动态,推动了一种特定的发展哲学。
我认为大多数早期阶段的公司往往会面临这种情形,你需要弄清楚你目前正在构建的业务在年收入200万美元时是否真正有价值,是否有市场需求,是否有人愿意为之付费。因此,我觉得在早期阶段,放慢脚步来解决技术债务通常会比较具有挑战性。
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.
首席执行官(CEO)应该总是兼任首席产品官(CPO)吗?总是这样吗?并不是,但在公司的早期阶段,我认为是的。在企业达到某些规模后,这种做法可能就不再合理了。但在初期,我确实认为应该这样做。如果你认为公司最重要的资产就是产品,那么在公司早期阶段,把这个任务交给其他人可能会很有挑战性。我们提到了对新产品的关注或产品扩张与技术债务之间的关系。从单一产品转向多产品,你获得的最大教训是什么呢?这确实是许多人面临的挑战,这是一个产品的挑战,同时也是一个文化的挑战。就产品挑战而言,你需要跨越一个鸿沟,即不能降低核心产品的质量来开发新产品,直到你确认新产品的有效性。你的核心产品有很多用户关心。我认为最好的方法是给新产品一个“小沙盒”,在这个沙盒中可以放宽公司的许多限制,但这样做的前提是,即使新产品完全失败,也不会损害整体核心产品体验。像Uber和Open Door就有这种优势,他们可以按城市进行划分。就Uber来说,更极端的做法就是像Uber Eats那样,做成一个完全独立的应用程序和组织,这样就不会对主业务造成影响。
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.
从单一产品过渡到多产品时你犯了哪些错误?请你用委婉的方式表达。我认为从单一产品到多产品的最大挑战可能就是我之前提到的。就像Uber从Uber X扩展到Uber Pool。这实际上在一定程度上损害了整体用户体验。这可能是最大的问题。
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.
这就像我们之前谈到的优先级排序练习。你会面临各种不同的压力,它们通常以不同的形式出现。而这些压力往往表现为各种解决方案。比如,“我们需要这个功能”、“如果产品能做到这一点就太好了”或者“我们因为这个原因丢掉了一笔交易”等等。无论是什么,产品工作的核心就是要理清这些反馈和噪音,找出用户真正关心的东西。以Uber为例,从中找出对用户而言真正重要的事。
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?
这位是首席执行官吗?这位是首席产品官吗?这位是产品负责人吗?需要从高层传达下来的那个层面,就是要明确这是公司的成功指标。然后这些指标会传递到整个组织内部。例如,就像在Uber的情况下,可能“增加行程数量”就是那个关键指标。这是最重要的考虑因素,而我正在做的是Uber拼车。
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.
好的,我明白了,作为负责我这个领域的产品负责人,不是整个公司,当然只是我负责的领域。我会想,如何逐步实现目标呢?对我来说重要的事情是,比如在这情况下,是 Uber 拼车的出行次数。我可以将我的目标与其他人的目标连接起来,逐步对接到最高的目标。在我看来,目标就像是层层递进的树状结构,无论你在组织的哪个位置,你的目标都应该顺着层次逐级连接到上一层或上两层的目标。
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.
你认为在产品中,人们对OKR(目标与关键成果)常犯的最大错误是什么?我认为最大的错误是设定太多OKR。那应该有多少个呢?一般来说,团队规模不同,适宜的数量也不同。一般来说,较小的团队可以有三到五个真正重要的OKR。如果你什么都关注,其实等于什么都没有专注。所以,我认为在制定OKR的过程中,重要的是保持一个合理数量,并明确说明哪些重要任务没有在做,以及为了专注于重要事项而进行的艰难取舍。如果你试图做所有事情,而且一次性全都做,那就说明优先级的排序并不够严谨。
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.
你应该多久更换你的混乱目标呢?我们在讨论每个团队有三到五个混乱目标。我们应该如何考虑更换它们的频率?以及应该如何向团队传达?团队应该制定自己的重要工作目标(Ocares),定义对战略最重要的工作以及高层概述的Ocares。这里有几个理念。其一,一般来说,季度规划过程通常并不需要频繁更换目标。否则,策略就会失去焦点。在一个季度内完成目标的可能性不大。更微妙的答案是,当你在短期内执行良好时,才有资格设置更长期的目标(OKR)。
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.
超级早期的公司就好比在搞一个为期一年的 OKR(目标与关键结果)过程,而实际上我们在三周内要做什么都还不明确。这种做法似乎并不是很有价值。因此,我认为公司需要通过证明自己可以在短期内设定目标并执行计划,来争取在更长时间跨度上进行规划的权利。
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.
你如何看待产品执行速度的重要性与人类偏好中的美感和精致度之间的关系?在这两者之间如何权衡?哪个更重要?我个人可能更倾向于速度的一方。实际上,不管你的产品直觉多么好,只有当你把产品推向市场后,才能知道用户是否喜欢它。在这样的反馈循环中,尝试次数越多,成功的可能性就越大。当然,这不意味着可以推出质量差的产品,否则可能只是因为执行不佳而导致失败。所以,你需要设定一个最低标准,这就是最低可行产品(MVP)的意义所在,但速度仍然很重要。
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.
如何判断你的新产品变更、产品更新或重新设计是糟糕的,还是用户只是还不习惯这种变化?我记得iPhone去掉了主页按钮,当时我和周围的人都觉得这很糟糕,要滑动屏幕底部。现在再想想这种想法是很荒谬的。那么,你如何看待这是一个糟糕的决定,还是用户偏好正在改变?iPhone的例子尤其具有挑战性,因为它是硬件方面的变化,而硬件的改变更困难。但在软件方面,我认为你通常可以给用户一些时间去适应。
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.
我们实际上需要评估这个实验的第五周到第八周的数据,而不是第一周到第四周的数据。如果让我把你归为直觉型产品领导者还是数据驱动型产品领导者中的一类,你是哪一种呢?如果以一个连续谱来评估你,其中0表示100%凭直觉,100表示完全依赖数据,你可能会把我放在65的位置。但这有一个前提,那就是数据不仅仅是量化的AB测试,与用户交谈也是数据。这是非常真实的。如果你与10位客户交谈,他们告诉你一些情况,这与我查看150个数据点并获得洞察力是一样有价值的数据。因此,答案是65,因为真正的直觉决策就像是我只是凭感觉做决定。简单往往更好,特别是在有必要保持某种复杂性的前提下。简单更好。在这里我们以Uber为例,按下按钮,然后得到出行服务。这是Uber最初的理念。那时是Uber Black,对吧?按下按钮即可获得极好的乘车体验。这要比打开应用程序滑动选择车辆类型后再按下按钮得到服务简单得多。但事实上,如果你想为不同的客户和使用场景提供各种选择,滑动选择器是一个非常简单的用户界面,通过它可以在一个统一的模式中展示所有选项。
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.
对于某种复杂性的必要性或功能集合的必要性来说,是的,越简单越好。但如果过于简化,你可能会认为,像Uber在一个应用中增加第二种车型就是个错误选择。我不这么认为。这是真的。我经常想到Spotify的古斯塔夫,他是我亲爱的朋友,也是我认为全球最优秀的产品经理之一。他常说“说话成本很低”,所以我们应更加充分地进行内部讨论,因为这些内部讨论非常有价值,并且确实能够激励更多这样的讨论。
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.
在我看来,我认为他错了,而这种看法在面对一个市值达千亿美元的公司的CEO时显得异常大胆和自负。我有一个播客,我觉得实际上独断的产品领导力被低估了。你怎么看待在强有力的领导和产品方向与重视讨论、辩论及内部对话之间的平衡?我觉得依靠共识来做产品决策是有挑战且错误的。像"你认为A,我认为B,我们来折中一下"这样的方式是很具挑战性的,但"我认为A,我不会问你的意见,因为我知道你认为B,我不想听到不同意见"这样的做法也不好。谈话本身是简单的,因此我们应该多进行讨论。我会这样理解并同意这种解释:把所有的意见摆在桌面上,确保汇集每个人的专业知识,然后根据信息做出最佳决策。我认为缓慢的决策在绝大多数情况下成本高昂,但不听取任何人意见并不收集观点也是不利的。
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.
你需要一个像项目经理(PM)团队契合的人员。你怎么知道需要什么类型的PM?你要看看整个团队,然后说,我们缺少一个曾经是顾问的人,拥有分析头脑并且想要成为产品的CEO。简单来说,有人跟我密切合作时,我有一句话:“你的策略是通过招聘实现的。”因此,你选择的人将决定这个人如何定义产品的成功。我认为招聘时需要有这种视角。举个例子,如果你观察团队,有两个维度需要考虑:首先是团队所需的产品类型,比如说这是一个后台基础设施项目,成功的关键是我们所用的算法,因此我们需要一个能够深入理解优化问题的人或者有数学背景的人。这是一种我认为最重要的团队契合类型。其次是你的产品团队的功能角色,你可以说,我们的功能产品团队有很多人适合这种模式。我们需要一个愿意推动我们向新的科技趋势冒险尝试的人,他会把这种活力注入我们的产品团队,因为我们也是一个团队。我认为这两个方面都很重要。
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.
如果你可以选择一个对你个人来说效果最好的背景来招聘产品经理,哪种背景在进入PM角色时最有效?如果非要我选的话,我认为公司内部从其他职能部门转到产品的员工是一个被低估的优秀选择。工程师、产品设计师,哪种重要性在AI时代增加,哪种减少?工程更重要。我会说工程重要性降低。为什么这么说呢?因为除非是在解决顶尖1%性能优化和真正复杂的技术难题,否则工程挑战会变得更加普遍化,因为会有很多工具帮助优秀的工程师达到同样的水平。我认为战略性的产品精通仍将有立足之地。而设计的重要性会更大,因为AI可以做到"足够好",很多人对此感到满意,但真正的设计专家会脱颖而出。理解。
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?
我认为你刚刚表达的方式代表了最顶尖的1%设计师和产品经理的能力,与普通工程师相比,他们能够设计出具有前瞻性并考虑周全的系统。我认为这种能力依然很重要。关于这个问题的回答,可能你的回答方式特别指出了顶尖的1%或5%的技能更加有价值,而中等水平的人则显得不那么重要。在Open Door,你认为最好的团队、产品和设计是什么?
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.
在Open Door(以及许多操作密集型公司),我们实际上把经典的三人组,即最终产品、产品优化和设计,视为一个整体,因为很难将你的数字产品与其物理表现分开。另外,这在Uber等公司也以稍微不同的形式存在。我发现作为一个对实体产品业务充满热爱的产品负责人,你面临的挑战是,即使你在Uber或Open Door等平台上提供了最漂亮的消费者软件体验,也可能会因为你无法控制的因素,比如第三方的意外情况,毁掉客户体验,让他们对你的公司评价很低。即使你已经竭尽全力做好了一切,这种情况与其他纯粹从事软件业务的公司是完全不同的。
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.
那与大多数人在硅谷的做法不同。你们作为一个群体来说变动非常频繁,现在经常从一家AI公司跳到另一家。似乎在问,为什么要相信留在一个公司会有好处呢?作为一个对这种做法有偏见的人,因为我曾在公司中有两段较长时间的工作经历,我认为事实是,时间长了你会变得更加高效,因此能更快速地完成更多工作。你会有更深厚的人际关系,对公司和客户基础有更深刻的理解,因此能更加有效率。如果你每18个月或两年跳槽一次,并假设需要六个月才能完全适应公司环境,这样会花很长时间才能真正理解并获得背景知识。在这过程中,你又开始面试和考虑下一份工作,实际上没有多少时间能做到真正高效。显然,如果工作不适合你,应该离开,但我认为不应该以每两年就跳槽作为目标,因为我相信随着时间的推移,你会变得更加高效。
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.
创始人无法实现产品市场契合的最常见原因是什么?通常是因为他们过于专注于解决方案本身,而不是深入了解问题本身和对问题的沉迷。进入产品领域后你后悔没有及时了解什么?我之前提到的招聘经验,即真正理解问题的需求,然后找到擅长处理该类问题的人。你做出的最好的产品决策是什么?为Uberport引入提前定价机制。也就是说,用户可以明确知道价格。当我们最初推出时,价格是可变的。那时候,也许你还记得,你打开Uber应用程序,说出目的地,价格是根据时间和里程计算的,直到我们建立了提前定价机制,用户可以在出发前看到确切的价格。
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.
哪个职能与产品运营之间的紧张关系最大?速度、节奏和问题解决的方式都非常不同。对于涉及产品或技术解决方案与其他领域解决方案的问题,大家用同一种语言交流确实很有挑战性。您最近在产品方面哪一次让消费者感到“哇”的瞬间?虽然有点投机取巧,但老实说,我的答案是ChatGPT。真的吗?我其实觉得Meta眼镜是一个令人惊叹的产品体验。我不知道你是否试过,你戴上它们。我倒是没有试过,不过我有一个朋友戴过。产品体验很棒,设计得非常周到,做得非常漂亮。是啊,不过很快就会有AI音乐生成器。不可思议。确实不可思议。我觉得在ChatGPT中能够上传截图、图片、视频然后进行分析和解释的多模态能力真的很惊人。
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.
这是给你的最后一个问题,你最希望如今的产品领域发生什么变化?我认为打破孤立状态,利用人工智能工具来打破各个职能部门之间的隔阂,挑战比很多人想象的更大。我希望能看到这样的改变:产品经理们可以更快速地采取行动,直接进行产品开发。Brian,我问了你很多问题,很享受这个过程。我相信你可能觉得自己被“审问”了,非常感谢你的参与。这真是一次很有趣的对话。谢谢你,Nanny。这次交流很棒,我很喜欢。祝你兄弟好运,如果你是第一次成为叔叔,也恭喜你。我迫不及待了,这是我第一次当叔叔。哇,这真是一场节奏很快的节目。如果你想观看这个节目,可以在YouTube上搜索20 V.C.,就能找到。
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.
在结束之前,我们想问您:是否在努力超越模型基准,或者在产品中实施生成式AI?如果是这样,您需要Turing。Turing是一家由杰出投资者支持的AGI基础设施公司,比如Foundation Capital和Westbridge Capital。他们主要做两件事。第一,他们帮助像Salesforce、Anthropic和Meta这样的顶尖公司和AI实验室通过高级推理、编码、多语言、多模态等技术增强他们的大型语言模型(LLM)。第二,他们结合了人类和人工智能的专业知识,为Rivian和Reddit等优秀公司部署最前沿的AI系统。目前,Turing提供一个免费的五分钟自我评估,帮助您确定在生成式AI之旅中的位置,获得优化模型策略的个性化下一步建议,最后了解Turing如何优化和实现您的模型以提升性能。不要再猜测生成式AI的过程了,访问Turing.com/20VC,开始您的免费评估,轻松实现无缝扩展。
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.
让我来告诉你关于工作操作系统的事情。工作操作系统是一个现代的B2B SaaS身份平台,帮助初创公司轻松进军更大的市场。向企业销售意味着要满足复杂的安全要求,比如SAML、单点登录(SSO)、SCIM配置和审计日志等等,很多功能都需要几个月来开发和维护。不过,工作操作系统通过灵活、易用的API简化了这一过程,使企业准备变得快速而轻松。
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.
它的亮点功能包括身份验证工具包,这是一个完整的用户管理解决方案,免费的使用量可达每月一百万用户,并内置多因素身份验证(MFA)、基于角色的访问控制(RBAC)、机器人防护和用户模拟,以及企业单点登录(SSO)。天哪,这些企业真是热衷于使用缩写,它支持任何使用SAML或OIDC的身份提供商。同时,目录同步实现了无缝的用户配置和移除。
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.
哦不,面对符合SCIM标准的目录,进行细粒度的授权管理和复杂的权限设置确实是一项挑战,但管理门户再次简化了单点登录和SCIM的接入,这对IT团队来说无疑是一大福音。这些功能已经被一些公司信赖,比如Cursor。如果Cursor都在用,那它一定很出色。想想看,他们已经从像20VC这样出色的投资者那里筹集了9500万美元的资金。今天就试试,访问workOS.com/20VC。如果你已经掌握了企业特性,我们来谈谈如何打造惊艳的产品体验,让用户按照你的愿望去使用。这就是Pendo的简单强大之处——唯一的一体化产品体验平台。
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参与的精彩节目。