在昨天关于创作者经济的文章中，我提到了 Lenny's Newsletter 的作者 Lenny，他前天称其播客今年的广告位都已经全部卖完了，足见他播客的受欢迎程度。
今天我分享他最近的一篇文章《How Perplexity builds product》，这篇文章里 Perplexity 联合创始人兼产品负责人 Johnny Ho 分享了他们构建 Perplexity 这个产品的一些经历，整个过程很多地方和 Notion 构建 Notion AI 有点类似《Notion 如何构建 Notion AI》。
Perplexity 可以说是目前最火的一个 AI 创业公司，不到 50 人的团队现在已经估值 10 亿美金了，前两周刚传出正进行至少 2.5 亿美金的新一轮融资，估值在 25-30 亿美金，并且刚推出的企业版 Enterprise Pro 可能正在创造一个新的市场。
这篇文章里有几点给了我非常深刻的印象，比方说：
-
很少有产品经理，因此倾向于招聘具有自我驱动的 IC，并且刻意避免招聘那些最擅长去指导别人工作的人；
-
产品经理工作中最困难、也是最重要的部分是在应用场景中具备品味；技术项目经理或具有产品品味的工程师将成为公司中最有价值的人；
-
小团队作战，Perplexity 的典型团队是 2-3 个人，最近推出的 AI 播客就是由一个人构建并运营的；
-
像粘菌一样组织，通过尽可能多地并行化每个项目来优化以最小化协调成本；
-
路线图的构建方面，高层次的目标和方向是自上而下，但大量的新想法是自下而上；
-
Perplexity 的许多功能和产品都是在一周（或更短）的黑客马拉松中构建的；
借助 AI 的能力，我对文章做了一下简单的翻译分享：
1.如何在 Perplexity 中使用 AI 工具来构建 Perplexity？
老实说，一开始我们也不知道如何做各种事情，包括产品管理、项目管理、财务、人力资源等。我们很早就获得了GPT-3 的使用权限，当我们在摸索如何建立公司的时候，我们会通过向人工智能提问“什么是 X ？”“我们应该如何正确地做 X？”来开始所有事情。
比方说，我们会问诸如“如何推出一个产品？推出过程中应该有哪些步骤？”这样你就会得到一个大致的循序渐进的过程，这对于一家初创公司来说已经足够好了。显然，第一次尝试时通常不正，但人类也一样，对吧？因此，我们只能从那里自然地进行迭代。
试图完全自己去解决问题需要几天的时间，但有了人工智能和一些提示，我们可以在五分钟内开始工作。现在我们仍在这样做。比方说本周，我问 Perplexity：“我如何写一封邀请某人使用 Perplexity Pro 的电子邮件？”
我们甚至有时尝试使用它来构建我们的产品，但我们发现人工智能工具在编程方面还不够好。它可以帮助我们编写脚本，但如果你想要可持续的代码来构建平台，它并没有真正起作用。即使在今天，随着技术的进步和最新的模型，它仍然只编写模板。你无法真正用它来设计一个新的、长期存在的抽象。
2.你们有多少位 PM？
在我们 50 人的团队中，只有 2 名全职产品经理（如下图）。大部分项目都只有一两个人参与，最难的项目最多也只有 3-4 个人。像我们的 AI 播客是由 1 个人从头到尾制作的，他是品牌设计师，但他也做音频工程，并且进行各种研究，以找出如何打造最具互动性和趣味性的播客，我认为项目经理在这个过程中从未介入过。
当需要做出一个非常困难的决策并涉及多个方向，或者涉及到更多的项目时，这个时候才会利用产品管理。产品经理工作中最困难、也是最重要的部分是在应用场景中具备品味。
对于人工智能来说，可能有太多潜在的应用场景可以进行开发。因此，产品经理必须根据数据、用户研究等进行分支定性决策。比方说人工智能面临的一个大问题，就是如何在更加注重生产力的应用场景和更具吸引力的聊天机器人类型的应用场景之间进行优先级排序。我们在很早的时候就决定专注于前者，但仍在进行持续的讨论。
我们计划明年再招聘一到两名项目经理，但招聘的门槛会一直很高。
3.招聘时最看重的是什么（也许别人不看重）？
鉴于我们的工作节奏，我们最看重的是灵活性和主动性。对我们来说，最重要的是能够在资源有限的环境中建设性地开展工作（可能需要身兼数职）。
当你看一个 PM 的简历时，他们中的很多人都会优先考虑帮助他人和寻求共识。我认为，随着人工智能的出现，这一点变得不那么重要了。
因此，你不一定需要像以前那样具备处理流程或领导团队的技能。我们寻找对用户有明显量化影响的强大个人贡献者，而不是在公司内部的影响。如果我在简历中看到“敏捷专家”或“Scrum主管”这样的术语，可能就不太合适。
此外，人工智能允许 PM 做更多的 IC 工作，尤其是数据分析和客户洞察。当然，你仍然需要一些基础知识（数学、统计学、编程的基本掌握），但成为一名真正的“技术”项目经理从未如此简单。
我们仍然选择符合文化并且易于合作的人，但很少找那些指导其他人工作的人，因为对于人工智能来说这并不是那么必要。随着规模的扩大，这种情况可能会发生变化，但在目前的规模下，需要开发的产品远远多于可以投入其中的人。
在未来，我预计整个行业的管理层会减少。如果我不得不猜测，随着时间的推移，技术项目经理或具有产品品味的工程师将成为公司中最有价值的人。
4.您是否围绕产品、用户类型、用户旅程、结果或介于两者之间来构建团队？这些年来是否有所改变？
我的目标是围绕最小化“协调阻力”这一概念构建团队，正如 Alex Komoroske 在关于将组织视为黏菌的 PPT 中所描述的那样。大致的想法是，协调成本（由不确定性和分歧引起）随着规模的增长而增加，增加管理者并不会改善情况。
人们的动机会错位，人们倾向于向他们的经理撒谎，经理再向他们的经理撒谎。如果你想和组织里另一个部分的人交流，你必须向上两级再向下两级，一路询问每个人。
相反，你要做的是保持总体目标一致，并通过共享可重复使用的指南和流程来并行开展指向这一目标的项目。特别是随着人工智能的发展，通过使用人工智能对想法进行 "橡皮鸭调试（rubber duck debugging）"，而不是依赖于完美的一致性和共识，可以最大限度地降低协调成本。
我们还在内部文档中更新了 "谁是谁 "的列表，如果你觉得有必要联系任何人，就直接联系吧。这需要高度的信任。
但更重要的是，有了人工智能，你就不必经常与人接触。在向其他人提出问题之前，你可以先花一分钟询问人工智能，以降低协调成本，并为每个人提供一个合理的起点，让他们自己去做。
5.你们的详细规划有多长时间，这些年来是如何演变的？
Perplexity 成立还不到两年，而人工智能领域的情况变化太快，很难在两年后做出承诺。我们制定了季度计划，在季度内，我们努力在产品路线图中保持计划的稳定性。路线图上有几个大家都知道的大项目，还有一些小任务，我们会根据优先级的变化进行调整。
灵活性至关重要，因为人工智能的发展往往会产生不可预见的影响。比方说，开源模型和上下文长度的快速发展对产品、路线图和整体业务产生了影响。就在最近，Meta 发布了 Llama 3，Mistral 发布了 8x22B；我们正在寻找创造性的方式来在我们的产品中使用这些模型。
产品路线图中的项目还需要具有灵活性，因为新产品开发与技术/模型开发路线图是并行的。工程师会根据每周的情况，在维护现有产品和开发新产品之间切换。当我们遇到现有系统的局限性并积累技术债务时，技术路线图往往会快速增长，但我们会尽量优先处理能够实现产品改进的技术债务。
不过，在给定的一周时间内，计划相当稳定。每周我们都会举行一次启动会议，每个人都会为自己的一周设定高水平的期望。我们有一种设定 75% 每周目标的文化：每个人都确定本周的首要任务，并努力在周末前实现其中的 75%。只需列出几个要点，以确保在一周内优先事项清晰明了。
在每周初花点时间反思元任务可以带来清晰度，并防止过度反应或忙碌的决策。随着时间的推移，我们根据投资回报估算规模和确定优先级的能力也得到了提高。
6.你们是否有某种形式的 OKR？
我们在季度规划中尽可能做到严格和数据驱动。所有目标都是可衡量的，无论是可量化的阈值还是布尔值“X 是否完成”。我们的目标非常激进，通常在季度末我们只在一个方向或另一个方向完成 70%。
剩下的 30% 有助于确定优先级和人员配置方面的差距。比方说，当基础设施目标未实现时，在招聘基础设施工程师方面的投资不足的问题很快就会显现出来。
7.你们的产品/设计审查会议是如何进行的？
在确定了中心目标和高级设计之后，项目由单个 DRI 驱动，执行步骤尽可能并行。
任何项目的第一步都是尽可能将其分解成并行的任务，以减少协调问题。我们在线性项目中这样做，我和团队中的项目经理（或负责项目经理职责的人）一起领导这项工作。我们力求每项任务都是独立的，你应该能够在没有阻碍的情况下执行任务。你很可能需要做出一些有争议的决定，但你可以稍后再解决争议。
在每个项目开始时，都会有一个快速的协调启动，之后以异步方式进行迭代，没有约束或审查流程。当个人觉得可以对设计、实施或最终产品提出反馈意见时，他们就会在 Slack 上分享，团队的其他成员也会给予诚实和建设性的反馈。迭代会根据需要自然发生，产品只有在通过内部使用获得足够的关注后才会推出。
我鼓励大家尽量并行工作。他们不应该等待每个人的解锁。理想的情况是，设计、前端和后端在同一个项目上同时工作。现在我们有了业务团队，所有四个人都可以并行工作，而传统的做法是，你可能要等设计或模型先出现。
8.汇报关系是如何运作的？
目前，团队是按职能（产品、研发、设计、业务等）构建的，不同的团队考虑公司和堆栈的不同层面，但所有精力都集中在改进核心产品上。我们设计的目标可转化为通用的顶级指标并全面改善用户体验，比方说，所有团队在其堆栈层内进行 A/B 测试时共享通用的顶级指标。由于产品变化如此之快，我们希望避免任何人的身份与产品的任何给定组件绑定的政治问题。
以我们目前的规模，我们的设计是扁平的，汇报结构并没有像对顶层目标的承诺那样决定优先事项。我们的两个全职产品经理（一个是 Wed 端，一个是移动端）作为产品主管向我汇报。我们发现，当团队没有产品经理时，团队成员会承担产品经理的职责，例如调整范围、做出面向用户的决策以及相信自己的品味。
9.你构建了最受欢迎和最成功的产品之一，你认为你的方法有什么独特点或核心导致了它如此成功？
我们方法的核心是听取来自用户和内部的反馈，并将其提炼成一些适用于许多客户的直观产品。我们还尝试以一种激励和告知我们团队的方式提炼反馈，设定一个广阔的愿景，但让个人控制自己的决定，决定什么最能服务于最初的目标。
我们的去中心化决策方法传递了责任的火炬，无需审批流程即可实现快节奏迭代。个人做出紧急的、局部最优的决策。然后，任何错位都会很快得到解决。
10.你用于任务管理和错误跟踪的主要工具是什么？
我们用的是 Linear，对于 AI 产品，任务、错误和项目之间的界限变得模糊，但我们发现 Linear 中的许多概念（如潜在客户、分类、大小调整等）非常重要。我最喜欢的一个功能是自动存档，如果一个任务有一段时间没有被提及，那么它实际上可能并不重要。
我们用来存储路线图和里程碑计划等事实来源的主要工具是 Notion。我们在开发过程中使用 Notion 进行设计文档和 RFC，之后使用 Notion 进行文档、事后分析和历史记录。将想法写在纸上（记录思维链）可以更清晰地做出决策，并更容易调整异步并避免会议。
Unwrap.ai 是我们最近引入的一个工具，用于整合、记录和量化定性反馈。由于人工智能的本质，许多问题并不总是具有足够的确定性，无法归类为错误。将各个反馈分组为更具体的主题和改进领域。
11.你认为路线图的想法主要是自上而下的（团队被告知要构建什么）还是自下而上（团队通常会提出想法）？
高层次的目标和方向是自上而下的，但大量的新想法是自下而上的。我们坚信，工程和设计应该对想法和细节拥有所有权，特别是对于人工智能产品来说，在将想法转化为代码和模型之前，约束是未知的。大量的头脑风暴一直在进行。我们在 Slack 中有一个专门的头脑风暴频道，后续想法收集在 Linear 中，并且通常无需任何人询问即可直接进行润色。
自下而上想法的最佳案例可以在 Perplexity 的 Discovery、Collection 和分享体验中看到。比方说就像我上面分享的，我们的品牌设计师 Phi 构建了 Discover Daily 播客，并同时围绕脚本、ElevenLabs 集成、品牌和音频工程做出决策。借助 AI，在产品迭代发布之前，无法预测应用场景。一年前，我们从未预料到“Discovery”这个模块的体验最终会被内置到播客中。
12.当人们从外面看到像你这样的公司时，一切看起来都很完美，就像你已经想通了一切一样。有哪些事情是效果不佳或面临巨大挑战的？
如今，最大的挑战围绕着从我们目前的规模扩展到一个新的水平，无论是在招聘方面还是在执行和规划方面。我们不想失去在一个非常扁平和协作的环境中工作的核心身份。即使是很小的决策，比如如何组织 Slack 和 Linear，也很难扩展。我们目前正在试图弄清楚，试图保持透明并扩大频道和项目的数量，而不会导致通知爆炸式增长。
13.你在产品团队或公司中有哪些有趣/独特的仪式或传统？
Perplexity 的许多功能和产品都是在一周（或更短）的黑客马拉松中构建的（这点和 Notion 一开始构建其 AI 产品很类似）。事实证明，构建新功能的专注冲刺是最令人兴奋和难忘的时刻。我们的第一个交互式搜索原型 Pro Search（前身为 Copilot）在几天内就建成了，但它经过多次润色和微调的迭代得到了改进。
