内容概要
Slack 的首席产品官 (CPO) Rob Seaman 探讨了为什么传统的路线图 (roadmaps) 在充满不确定性的时代已不再有效，并倡导拥抱速度和迭代。他分享了 Slack 如何通过快速原型 (rapid prototyping)、小团队以及能够赋能各层级决策的产品原则 (product principles) 来保持创新和敏捷，并强调了为结果而非具体功能进行规划的重要性。
目录
-
引言与欢迎
-
模糊时代下，路线图的问题
-
为结果而规划与快速原型
-
利用产品原则指导日常决策
-
什么是产品原则？
-
Slack 的产品原则：规模化决策
-
原则一：别让我思考 (Don't Make Me Think)
-
原则二：成为出色的主人 (Be a Great Host)
-
原则三：通过原型探索路径 (Prototype the Path)
-
原则四：寻找效用曲线最陡峭的部分 (Seek the Steepest Part of the Utility Curve)
-
原则五：下更大、更大胆的赌注 (Take Bigger, Bolder Bets)
-
核心要点与总结
引言与欢迎
大家好，非常感谢你们的邀请。从我个人的角度来说，我大约 25 年前进军产品领域，那时完全没有像今天这样的交流平台。我们都只能靠自己摸索。我真的很羡慕在座的各位，能有这样一个论坛，可以相互学习，并向那些有经验的前辈请教。
我今天的分享在你们和酒会或回家之间，所以我会尽量快一点。我的演讲主题恰好也与速度有关：在这个充满模糊性的时代，我们应该拥抱速度，押注于速度。
模糊时代下，路线图的问题
接下来，我会和大家聊聊我们在 Slack 是如何做产品的，以及我们如何在这些充满变数的时期保持快速。
在今天一整天的会议中，大家已经听到了，我们正见证着 AI 产品、AI 公司和 AI 功能的“寒武纪大爆发”。这使得几乎每家公司，可能也包括你们的公司和你们的客户，都产生了错失恐惧症 (FOMO)。每家公司都在想：“我必须得做 AI，我需要 AI 功能。”
但与此同时，我们也正处在一个持续的经济不确定时期。客户不知道是否应该购买新产品，是否该押注于新技术。就连你自己的公司可能也不确定：“我们现在真的应该在这方面投入这么多吗？或者应该如何投入？”
这时候，人们想要的是路线图 (roadmaps)。我认为，路线图是产品经理存在的“祸根”，尤其是在当前这个时期，它几乎是最糟糕的概念之一，完全不合时宜。所以我想谈谈，为什么我认为路线图不是我们现在所需要的，以及我们可以采取什么替代方案。
我知道，如果说我们没有一个功能路线图，这会让每个人都感到极度紧张。因为作为一名产品经理 (PM)，这似乎就是你的产出物，是你老板对你的期望。但我仍然要强调，在这个时代，这绝对是错误的做法。
为结果而规划与快速原型
我认为，我们现在应该做的是为结果 (outcomes) 进行规划。
我希望在座的各位都在深入思考你们的客户以及你们想为他们实现的结果。这才是我们应该规划的，而不是规划单个功能。我们应该思考我们希望为公司和客户实现的最终结果，并把我们的计划看作是一系列需要去验证的假设。
在验证这些假设时，我们应该通过快速原型 (rapid prototyping) 来进行测试。如今的美妙之处在于，无论是 Vzero、Lovable 还是其他许多公司，原型开发工具和能力已经变得前所未有地普及。这让我们所有人都有能力比以往任何时候都更快地检验我们的假设。
但是，如果你没有路线图，很多公司和老板会问：“我们如何确保大家都在做正确的事情呢？” 他们担心员工会随心所欲地编写代码或制作原型。
利用产品原则指导日常决策
为了解决这个问题，我们采用的方法是利用产品原则 (product principles) 来指导快节奏的日常产品决策，这也是我接下来要花最多时间讨论的部分。
我认为，对于每一位产品经理来说，有一些问题至关重要，希望你们的公司也能提供答案，但实际上大多数公司并没有。当你审视功能并与工程团队合作时，你应该能够问自己这些问题：
我们公司的使命是什么？我正在做的事情是否有助于推进这一使命？它是否让我们更接近我们设定的愿景？它是否符合我们在轻量级规划过程中设定的结果？以及，它是否遵循了我们组织为自己建立的产品原则？
在我看来，以及在 Slack 的我们看来，整个体系中的核心就是产品原则。
什么是产品原则？
那么，什么是产品原则 (product principles)？
它们是构成你公司产品决策基础的根本性主张。你用它们来指导执行。这与路线图无关，与战略无关，而是关乎团队内部的日常执行。这样做的目的是为了让你能更好、更快地做出决策。
一个可能让人不太舒服的事实是，产品中绝大多数的决策并非由产品经理做出，而是由工程和设计团队的成员，甚至是客户支持部门的同事做出的。每个参与构建客户体验的人都在做产品决策。
你可以用这些原则来正式或非正式地评估团队的工作。在 Slack，我们通过在各个功能团队中每周举办研讨会 (workshops) 的方式来应用它们。
推荐大家去阅读我们前设计主管 Ethan 写的一篇文章，他阐述了为什么团队需要产品原则，我非常推荐大家去看一看。
Slack 的产品原则：规模化决策
接下来，我想谈谈我们的产品原则，但首先我想重申，产品原则最重要的作用在于规模化决策 (scaling decision-making)。
我给大家推荐一个很棒的产品——Linear。它的产品负责人 Nonu 最近在 LinkedIn 上写道：“一个不容忽视的真相是，超过 50% 的产品决策实际上是由工程师做出的。” 他认为，如果你是一位心态开放的出色工程师，欢迎加入他们。
我认为，产品原则正是给了你一种方法，将决策能力规模化地扩展到你的设计和工程组织中。这样一来，你不再需要为各种小事开会，因为每个人都能基于共同的原则，凭直觉做出好的产品决策。这是我们在这个时代能够获得的最大速度提升。
在 Slack，我们有一个由四部分组成的核心计划 (master plan)，这是很久以前由我们的创始人 Stuart 写的。其中第四部分是：“做一些神奇的 AI 玩意儿 (Do some magic AI stuff)。” 当时完全没有任何细节，那已经是六七年前的事了。但现在，显然是时候去实现它了。
我们告诉团队：“去做一些神奇的 AI 玩意儿吧。” 这对于那些掌管预算或期望看到具体功能路线图的人来说，听起来确实很吓人。因为我们没有给出具体的功能列表，只是说：“去做吧，然后回来给我们看看你们做出了什么。”
接下来，我将向大家展示我们是如何做到这一点的。我们有五条产品原则，并且每天都在实践它们：
-
别让我思考 (Don't make me think)
-
成为出色的主人 (Be a great host)
-
通过原型探索路径 (Prototype the path)
-
寻找效用曲线最陡峭的部分 (Seek the steepest part of the utility curve)
-
下更大、更大胆的赌注 (Take bigger, bolder bets)
原则一：别让我思考 (Don't Make Me Think)
第一条是“别让我思考”。软件不应该成为用户的障碍，用户不应该花时间去研究如何使用你的软件。他们有需要完成的任务。所以，你要确保用他们熟悉的模式来引导他们，并确保完成任务的路径尽可能地短。
在 Slack，我们花了很多时间思考如何优化用户的理解效率，而不是单纯地减少点击次数。很多人可能会把这条原则理解为减少点击，但我们有时会为了让用户更容易理解，宁愿增加点击次数或文字说明，从而避免他们在每一步都要去思考接下来会发生什么。
举个例子，我们最近基于“别让我思考”原则做了一个叫做 AI 搜索答案 (AI search answers) 的功能。很多产品现在都有类似的功能，比如 Google 的 AI 模式。过去搜索的一大不便是，用户心里有一个问题，但他必须思考如何把这个自然语言的问题转换成关键词，才能让搜索引擎找到相关内容。
现在，你只需直接提问。我们在搜索框顶部加入了提示文字：“问我任何事 (ask me anything)”。这样用户就知道可以直接提问。当他们提问后，得到的不再是传统的搜索结果列表，而是结合了搜索结果和自然语言回答的综合内容，就像真人在回答他们的问题一样。
这就是“别让我思考”的一个例子。在我们的产品中，这样的设计无处不在。当你进行原型设计时，也可以思考一下，在哪个环节可以为用户省去一个步骤。
原则二：成为出色的主人 (Be a Great Host)
接下来是“成为出色的主人”。这个原则的灵感来源于 Airbnb，我们 Slack 有不少同事来自那里。
当你预订一间 Airbnb 民宿时，你满怀期待。比如你在太浩湖 (Tahoe) 找到了一间看起来很棒的房子，后院绿树成荫。但当你走进房间，却发现找不到毛巾和餐具，那种体验就很糟糕。这就不是一个好主人。
我们希望我们的软件也能成为出色的主人。我们的意思是，我们希望超越用户的期望。产品不仅要能完成任务，更要在完成任务的过程中，提供超出他们预期的体验。
例如，我们几周前刚刚发布了一个名为 AI 解释 (AI explanations) 的功能。如果你使用的是支持 AI 的套餐，就可以体验到。作为产品负责人，我经常被拉进各种紧急事件处理中，但我常常看不懂那些工程师在讨论什么，比如某个缩写、某项技术，或者某个概念。
我可以去打扰正在处理事故的工程师，或者去问事件指挥官，但这效率极低。我也可以把不懂的词复制到搜索框里，但这对我来说同样低效。现在，我只需点击消息旁边的“星光”图标，它就会将整条消息和相关上下文发送给大语言模型 (LLM)，然后返回一段通俗易懂的自然语言解释。
这就是我们希望做到的：当用户遇到问题时，我们不仅要提供他们预期的解决方案，还要超越他们的期望。他们看不懂消息，只需一键点击就能获得解释，而无需打扰他人。
原-则三：通过原型探索路径 (Prototype the Path)
下一条原则是“通过原型探索路径”，这是最重要的一条，我会花最多的时间来讲。
如今，有了像 Bzero、Lovable、Bolt 或 Cursor 这样的工具，原型开发比过去容易得多。我们坚信这一点，并尽快将想法付诸代码。我们认为，当我们能亲手体验产品时，我们的速度和影响力会更大。
关于原型设计，我想分享一些可能有点争议的观点。首先，要从一个小团队开始。这个团队应该小到让你感到不舒服，感觉好像漏掉了谁，甚至觉得这个团队不完整。
我强烈建议大家去读一篇关于黏菌 (slime mold) 的文章。我们之所以希望在原型阶段保持团队规模尽可能小，是为了减少协调开销和阻力。项目中的人越多，保持所有人同步就越困难。回到我们今天讨论的核心，在这个充满不确定性的时代，我们希望尽可能地快。保证速度的最好方法就是拥有一个极小的团队。
我甚至建议，当你组建原型团队时，可以考虑从名单上再去掉一个人。在 Slack，我们有个更“刺激”的说法：你甚至可以不需要产品经理 (PM) 在这个团队里。我们常常只由一名设计师和一名工程师开始一个小型原型项目。这样可以尽可能地减少沟通环节，快速推进。当然，我们最终总会加入 PM，但在需要快速决策某个功能的手感时，设计师和工程师的直接合作通常效率最高。
其次，要从你想学习什么开始，而不是从你想构建什么功能开始。每个原型都是一次测试，一次假设检验。你的目标是通过构建原型来回答一个问题。
你需要准备好随时丢弃这些原型。我们鼓励“丢弃代码”，因为我们希望尽快亲手体验，看看能否回答我们的问题，学到我们想学的东西。一旦完成一个阶段，就立即奔向下一个“山丘”。你的最终目标可能是登上珠穆朗玛峰，但你不可能一步登顶，必须先翻越一个又一个的小山丘。每个山丘都代表一个你要回答的问题，而且问题的难度会随着进程递增。
一旦你发现某个想法可行，并且你真的想把它做出来，那时再花时间用正确的方式去实现它。但在此之前，你的目标是尽快得到问题的答案。
举个例子，Slack 中新的“动态 (Activity)”功能。我们有一个优势，就是我们自己就是产品的重度用户。我们有 3000 名员工，并且作为 Salesforce 的一部分，我们可以在 75000 名员工中进行测试。
下面展示了“动态”功能在 Slack 中的演变过程，这个过程非常“混乱”，但所有这些都是在真实用户的使用中，通过代码迭代完成的。我们尝试过在顶部添加元素、移除侧边栏、引入新的按钮和筛选器、加入内容摘要、调整间距、增加紧凑视图和宽松视图、添加顶部标签页，最后还将私信 (DMs) 整合进了动态中。
整个过程持续了大约五个月，期间我们收到了很多用户的实时反馈，有时甚至是抱怨。但最终，我们打磨出了一个手感很好的产品，并且现在正开始向部分客户进行试点推广。所以，这个过程应该是混乱的，甚至让你感到不适。
原则四：寻找效用曲线最陡峭的部分 (Seek the Steepest Part of the Utility Curve)
接下来这条原则可能最学术化，请大家耐心听一下：“寻找效用曲线最陡峭的部分”。
效用曲线 (Utility curves) 无处不在，你可以用不同的坐标轴来定义它。我们希望产品人员明白的是，你投入到产品中的努力与客户或用户从中获得的价值之间，存在一种非线性关系。
我个人更喜欢这样理解效用曲线：如果你让某件事变得足够简单，人们的行为就会改变。Uber 和 Airbnb 就是很好的例子。当你让共享出行变得足够方便，出租车市场的总规模就会扩大。同理，当你让异地住宿变得更容易，旅游市场的总规模也会增加。如果你能让一件事变得足够简单，人们的行为就会发生巨大变化。
如果你投入的努力不够，可能就无法达到那个让曲线急剧上升的拐点。但如果你投入过多，用户体验的边际改善就会递减。关键在于找到效用曲线最陡峭的那个部分。
举个例子，Slack 中的“画布 (Canvas)”功能。你可以把它想象成一个灵活的内容容器，可以存放视频、文字、文档、链接等等。我们大约在两三年前推出了这个功能，虽然周活跃用户 (Weekly Active Users, WAU) 超过了百万，但相对于我们的总用户基数来说，表现并不算好。我们一度怀疑，是不是应该放弃这个功能。
但后来我们想，也许是我们做得还不够。于是在过去六个月里，我们开始尝试一些新的东西。我们把画布添加到了频道的标签页里，这样你就可以在功能频道中直接固定你的产品需求文档 (PRD)。我们还在私信中为一对一沟通话题设置了默认的画布标签。接着，我们为画布加入了 AI 功能，可以帮助你从频道内容或搜索结果中快速生成文档。我们还利用 AI 自动记录“站会 (huddle)”的笔记并输出到画布中。
这些努力证明，我们之前确实没有触及到效用曲线最陡峭的部分。如果你看数据，从去年 7 月到今年 7 月，也就是在我们开始进行这些原型迭代之后，周活跃用户数开始像曲棍球棒一样飙升。我们仅仅是通过在效用曲线上再多走了一步，就实现了周活跃用户数 100% 的增长。
原则五：下更大、更大胆的赌注 (Take Bigger, Bolder Bets)
最后一条原则是：“下更大、更大胆的赌注”。
当然，这条原则不应被滥用。如果某个模式已经被证明是有效的，就不要去重新发明轮子。但是，如果某件事存在根本性的问题，而你认为自己能将它改进 10 倍，那就应该勇敢地去尝试。
在你的产品投资组合中，这类赌注属于高风险高回报的类型，只应占一小部分，但它们至关重要。
例如，Slack 中有一个存在了近 10 年的功能——Slackbot。它会给你发通知，比如某人归档了某个频道，或者你被添加到了某个新频道。很多人在想，我们是否能将这个大家熟知的、存在于每个 Slack 实例中的 Slackbot，进化成一个更个性化、更友好、更有帮助的角色？
这正是我们目前正在积极探索的原型。它将 Slackbot 从一个只会通知频道动态的机械式机器人，转变为一个常驻在你界面右侧，随时为你提供帮助的助手。我们认为，尽管这是一个已有的模式，但我们有能力从根本上改变它，让它变得更好。
核心要点与总结
我的分享差不多到时间了，最后我给大家总结一下，然后你们就可以去享受酒会或回家了。
我再次强调：
-
为结果 (outcomes) 而规划，将你的计划视为一系列待验证的假设。
-
真正地拥抱原型 (prototyping)。它是一个极其强大的工具。坦白说，再精美的 Figma 设计稿或文档，都无法像一个可交互的原型那样，让你准确地预测用户反馈。
-
最后，尝试建立你们自己的产品原则 (product principles)。即使你不能为整个公司制定，也可以为你的团队制定。明确你们在特定产品或功能领域绝不妥协的原则，并确保你的设计和工程伙伴也理解并认同它们。因为你不可能做出所有的日常决策，但如果有一个大家共同遵循的框架和信念体系，你就能确保绝大多数决策都是正确的。
谢谢大家的时间，祝各位今天过得愉快。
