Transcription
大家好，我在 Meta、Amazon、Reddit 和 Roblox 等公司担任产品负责人已超过十年。以下是我相信的 25 条构建优秀产品的原则。有趣的是，我所相信的往往与像大公司这样工作的方式截然相反。好了，我们开始吧。首先，速度是唯一的护城河。第一条，建立快速反馈循环。你与真实用户迭代的速度越快，你的产品很可能就越好。你应该能在早上构建一个原型，并在午餐时获得用户反馈。在与真实用户交流之前，你应该绝对拒绝进行三轮内部评审。第二条，分层级发布。你知道，一次性将新产品发布给所有用户几乎总是一个坏主意。相反，先进行内部员工测试和客户 Beta 测试，以便在正式发布前发现问题并提升质量。我实际上不知道如何在没有一个可以每天交流以获取反馈的 Beta 用户社区的情况下构建优秀的产品。第三条，小团队发布更快。一个由四到六名全栈构建者组成的团队，他们被赋权与用户共同创造并从失败中学习，他们将在任何一天都比一个 50 人的组织执行得更好。这里的关键词是“赋权”。如果你雇佣了一群顶尖人才，你必须给予他们与真实用户无休止迭代的自主权。第四条，优先与 AI 迭代。现在每个人都有一个 24/7 可用的 AI 队友。所以，在与团队会面之前，与 AI 合作来总结反馈、起草计划并改进你的原型。在这个阶段，提前完成基础的 AI 工作是基本要求。第五条，成为用户。我简直不敢相信我需要说这个，但你必须不断地“吃自己的狗粮”。像第一次使用的用户一样使用你的产品，并记录下体验有多么令人沮丧。我估计，每周真正“吃自己狗粮”的产品经理不到 10%。你知道，没有人会因为测试自己的产品而显得太资深。好了，为了让这五项原则生动起来，我想分享一个简短的例子。Boris 是 clock code 的创建者，他最近在 X 上征求用户反馈，收到了数百条回复。最令人瞩目的是，他不仅回复了每一条，而且还与 AI 合作，在同一天发布了数十个修复。Boris 是一个完美的小团队（在这种情况下是一个人）与真实用户快速迭代的例子。速度就是一切。好了，下一部分是专注是一种超能力。让我们继续列表。第六条，少做，做好。我不相信每个季度追求超过一到三个 P0 高优先级项目。专注于解决最大的用户痛点，从而发展你的业务，而不是试图一次构建所有东西。你知道，说“我们可以两者兼顾”或为你的团队甚至公司列出五到十个优先级，对我来说是一个危险信号。第七条，先做简单的事情。始终发布最简单的可行方案，以避免解决尚未存在的问题。例如，如果你的产品还没有达到产品市场契合度，你可能不应该优化产品的扩展性。对吧？说到这里，第八条，先验证你最冒险的假设。每个产品都有一些假设，如果错了，就会毁掉整个产品。所以，在构建任何其他东西之前，先用简单的原型或 A/B 测试与真实用户一起验证这些假设。当你的核心假设仍未得到证实时，不要去处理次要或外围的功能。第九条，保护你的日历。如果你无法控制自己的时间和精力，你就无法构建优秀的产品，也无法专注。我喜欢在早晨进行深度工作，那时我头脑清晰，并且我坚决拒绝那些消耗我精力的会议。第十条，说“不”的次数要比说“是”多十倍。习惯于对不符合你想要解决的最重要问题的功能、会议甚至用户请求说“不”。只要确保表现出同情心并清楚地解释你的理由。如果你这样做，对方通常会理解。好了，举个例子，我曾经在一家公司工作，那里的 CPO 公布了九个年度优先事项。他甚至有一个很棒的首字母缩略词来帮助人们记住所有这九个优先事项。在一年中几乎没有在任何优先事项上取得进展后，他将列表缩减到只有三个。这是理查德·鲁蒙特（一位战略专家）关于优秀战略的引述。核心在于，战略就是关于专注。而大多数复杂的组织并没有专注于他们的资源。相反，它们同时追求多个目标，而没有集中足够的资源来实现任何一个目标的突破。所以，专注于你的优先事项，专注于你的时间。专注是实现突破性产品的关键。好了，继续。下一部分是产品优先于流程。让我们从第 11 条开始，即拒绝产品经理的表演。你知道，我曾谈过与真实用户建立反馈循环的重要性，但大多数产品经理都专注于内部表演，比如打磨文档，并在实际评审前进行无休止的预备会议。你必须专注于用户实际使用的产品，而不是你的内部文件。我知道这很难，但请尽力做到这一点。第 12 条，构建最小可行计划。你知道，停止假装你知道一年后确切要构建什么。相反，创建一个最小可行计划，涵盖用户问题、愿景、目标、原则、解决方案以及你**不**做什么。将其保持在一页纸上，并随着你的学习进行更新。拒绝年度规划和 OKR 表演。第 13 条，实践原型而非开发。你知道，原型比任何幻灯片或文档都能让人们更好地了解你的解决方案。它们也更有趣，并且更容易与真实用户进行测试。你可以使用 Google AI Studio、Replet、Cursor 等各种工具来首先构建你的产品原型，最重要的是，向利益相关者和真实用户展示它以获取反馈。因此，在创建 PRD 和设计以涵盖大量边缘情况之前，先用原型验证兴趣。好了，说到边缘情况，第 14 条是专注于细节、默认状态、边缘情况和撰写好的文案。这些细节是区分优秀产品和粗制滥造的关键。无论你有多资深，你都必须关心最微小的细节，才能发布让你引以为豪的东西。第 15 条，简化产品评审。你知道，没有什么比等待几周才能获得高管的日历来评审你的工作才能发布更慢的了。所以，如果你是领导者或高管，请赋权你的团队自由地向他们的 Beta 社区发布，并异步评审原型，而不是因为你的繁忙日程而阻碍他们。例如，RAMP 在创纪录的时间内增长到 320 亿美元，这得益于赋权他们的团队快速发布。正如 Jeff Ramp 的 CPO 在这篇帖子中所解释的，RAM 团队可以随时向 Beta 用户发布，无需获得精确的许可。而且他们在发布到普遍可用之前还有一个最小的评审流程。我特别喜欢这则推文中的一句话是“领导者有 48 小时的时间来评审产品，否则产品就会发布”。这使得领导者和高管有责任不减慢产品发布速度。下一部分非常重要。你必须无情地追求真相。第 16 条。你知道，傲慢是最令人反感的。我无法忍受那些认为自己比其他人更优秀的产品领导者和创作者。我遇到的最优秀的领导者也最谦虚，因为他们之前曾反复失败，并且见过一些真实的情况。如果你不谦虚，你就没有在倾听，你就不会构建出优秀的产品。第 17 条，禁止委员会式决策。我不相信跨职能的协调是一个目标，因为试图让所有利益相关者满意将不可避免地损害产品体验。所以，一定要从利益相关者和真实客户那里寻求不同的意见，然后由一个人来做决定并承担结果。不要试图进行委员会式决策。它从来不起作用。第 18 条，不要被“应声虫”包围。当领导者被那些不会挑战他们想法的“应声虫”包围时，优秀的公司就会衰败。寻找并奖励那些愿意提出尖锐问题的人，只要他们保持建设性。你知道，如果你有一个产品评审，而每个人都沉默地点头，那实际上是一个坏迹象。你应该鼓励辩论。好了，第 19 条。假设对方是善意的。当你不同意某人时，倾听以理解他们所说的话，而不是试图构建反驳。很可能他们实际上提出了一个你没有考虑到的绝佳观点。最好的辩论是协作式的求真练习，而不是要赢得的战斗。第 20 条，愿意承认自己是错的。大多数决定都是可逆转的“双向门”。正确的做法通常是直接决定并学习，而不是等待完美的信息。我从与 Jana 的访谈中学到了这句话。在我辩论两个想法的时候，我已经发布了 10 个。不要等待完美的信息。直接发布，并愿意承认自己是错的。所以，举个例子，最近在工作中，一些利益相关者推动了一个我抗拒了几周的功能。但我一直在与用户交谈，并向他们展示原型。最终，来自用户和利益相关者的反馈改变了我的想法。我承认我错了。我展示了证据。现在我们正在构建一个我们更有信心的东西。关键是你的目标应该是找到真相，而不是证明自己永远是对的。好了，最后一节我感受尤其强烈，那就是构建者而非官僚。寻找那些真正关心打造优秀产品的人，而不是那些仅仅为了职业发展而这样做的人。也要尽量招聘那些具有“搞定一切”精神的人。他们愿意身兼数职，解决问题，而不是等待许可。第 22 条，工作成果比资历更重要。你知道，在这个时代，人们不在乎你的名校背景或 AI 产品证书。我想招聘那些构建过优秀的副业项目或以某种方式展示过高能动性的人。唯一重要的资历是他们发布了什么。他们产生了什么影响，以及他们对改进你的产品有什么想法。第 23 条，要么“绝对是”，要么“否”。如果你对一个候选人不感到兴奋，就不要雇用他们，希望他们能有所作为。一个优秀的招聘胜过三个平庸的。而且永远不要因为急于填补职位空缺而降低标准。第 24 条，你的职位头衔实际上并不重要。最好的团队模糊了产品经理、设计和工程之间的界限。我喜欢工程师更新我的规格，也喜欢设计师让我用 Figma 编辑文案。构建一个相互信任和尊重彼此技艺的全栈构建者团队。最后但同样重要的是，目标是取代自己。作为产品负责人，你的工作最终是让自己变得不那么必要。如果你的团队没有你一周就无法运转，那实际上是一种失败，而不是一种炫耀。最优秀的领导者会赋权他人，以便他们能够处理更高级别的问题。所以，举个例子，我目前正在招聘一名高级产品经理，我在职位描述中明确写道，请在申请顶部链接你最好的副业项目或已发布的产品。现在，我真正不喜欢看到模糊的行话或流行语，比如“敏捷专家”或“战略产品领导者”。对我来说，这些东西毫无意义。直接从你发布的东西和你产生的影响开始。好了，这就是全部内容。在我为一些顶尖公司工作了十多年后，我所相信的 25 条构建优秀产品的原则。如果你喜欢这个列表，我鼓励你写下你自己的列表，并寻找并为那些与你拥有相同价值观和原则的公司工作。这会让你的生活轻松得多。我保证。好了。所以，如果你喜欢这个简短的视频，请点赞并订阅我的频道，我将在此过程中分享更多个人产品见解和 AI 教程。谢谢。