Perplexity 产品开发的新模式 [译]

Perplexity 的联合创始人兼产品负责人 Johnny Ho 分享了他如何借助 AI 技术领导团队，如同指挥黏菌一般，构建他们的 AI 公司，以及更多前沿策略

刚刚成立不满两年，Perplexity 已经变成了我日常频繁使用的工具，甚至取代了我对 Google 的依赖 —— 而我并非个案。该公司仅凭不到 50 名员工，已经吸引了数千万用户。他们目前的年收入超过 2000 万美元，并且在与 Google 与 OpenAI 竞争搜索引擎的未来中显得尤为突出。他们近期的 6300 万美元融资活动使公司估值超过了 10 亿美元，得到了 Nvidia、Jeff Bezos 等众多投资者的青睐。Nvidia 的 CEO Jensen Huang 表示他“几乎每天都会使用这款产品”。

我有幸与 Johnny Ho 深入交谈，他详细介绍了 Perplexity 如何打造产品 —— 这可能预示着许多公司未来产品开发的方向：

1. 以 AI 为先导： 从“如何推出产品？”开始，他们在每一个公司建设的步骤中都积极寻求 AI 的建议，员工在求助同事之前，首先向 AI 寻求答案。

2. 组织架构灵活高效： 他们尽量通过并行工作方式来减少各部门间的协调成本。

3. 小型团队高效运作： 典型的团队规模为两到三人。他们评价极高的播客就是由一人独立负责的。

4. 精简管理层： 他们优先考虑自我驱动的独立贡献者，避免聘请那些主要通过指导他人来发挥作用的管理者。

5. 对未来的洞察： Johnny 预见到，随着时间的推移，那些既懂技术又具备产品敏感度的项目经理或工程师，将成为公司中最具价值的资产。

要获取更多信息，请访问 Perplexity。他们目前正在招聘新员工，详情请见 招聘信息！想深入了解业界顶尖产品团队的运作方式吗？不要错过我对 Linear、Shopify、Figma、Notion、Duolingo、Ramp、Miro、Coda、Gong 和 Snowflake 的详细分析。

附言：我正与 Perplexity 合作进行一项深入研究，探讨产品经理如何运用 Perplexity 工具，我们非常期待听到您的反馈。如果您经常使用 Perplexity，请参与 这项调查，我们将联系您进行用户访谈。

---

Perplexity 如何构建产品

从左到右为：Johnny Ho, Aravind Srinivas 和 Denis Yarats，Perplexity 的联合创始人们

1. 在 Perplexity 中，我们是如何利用 AI 工具来构建 Perplexity 的？

一开始，我们面临很多不懂的领域，如产品管理、项目管理、财务和人力资源等。幸运的是，我们早期就开始使用 GPT-3。在建立公司的过程中，我们常常先询问 AI：“什么是 X？”接着是“如何正确执行 X？”例如，我们询问：“如何发布产品？发布过程应包括哪些步骤？”AI 给出的步骤虽然粗略，但对我们这样的初创公司来说已经足够有效。当然，这些答案往往并非一次就准确无误，但人也同样如此，不是吗？因此，我们只能不断尝试并逐步改进。

原本需要几天才能摸索清楚的事务，借助 AI 和恰当的引导，我们可以在五分钟内迅速开展。

我们至今仍在采用这种方式。这个星期，我就向 Perplexity 提问：“我应该如何撰写一封邀请别人加入 Perplexity Pro 的邮件？”

我们甚至尝试过利用 AI 来开发产品。然而，当事涉到编程时，现有的 AI 工具仍不够成熟。它能帮助我们撰写脚本，但若要创建一个稳定的平台，现有代码还远远不够。尽管技术不断进步，最新的模型也只是提供了一些模板，我们还不能用它来设计持久的新型抽象。

2. 你们有多少产品经理？

我们公司有 50 人，其中只有两名全职产品经理。

在我们的典型项目中，通常只有一到两人参与。而对于最具挑战性的项目，人数最多不超过四人。以我们的播客为例，整个项目由一个人负责，从策划到执行。这位员工虽然是品牌设计师，但他也擅长音频制作，并且还要进行广泛的研究，以确保我们的播客既互动又引人入胜。产品经理在整个过程中几乎没有直接参与。

我们尤其依赖产品管理，在需要做出复杂决策和深入参与的项目中发挥作用。

产品经理最关键也是最具挑战的任务是对潜在应用场景进行精准把控。在 AI 领域，潜在的应用场景数不胜数，产品经理必须基于数据和用户研究，做出关键的选择。例如，如何在提高生产力的应用和更具吸引力的聊天机器人应用之间做出权衡是一个主要问题。我们很早就决定优先考虑前者，但围绕这个决策仍有持续的讨论。

未来一年，我们计划再聘请一到两位产品经理，但我们对候选人的要求依然非常严格。

3. 我认为你们的成功很大程度上归功于优秀的招聘和保持极高的标准。在招聘时，你最看重什么（可能别人不太注重的）？

鉴于我们快速的工作节奏，我们首先看重应变能力和主动性。在资源受限的情况下能够积极建设和承担多种职责的能力，对我们至关重要。

观察产品经理的简历，很多人将帮助他人和达成共识放在首位。我认为，随着人工智能（AI）的发展，这些能力的重要性将降低。因此，管理流程或领导团队的能力并不是首要考虑的。我们更看重那些能对用户产生显著影响的优秀个体贡献者，而不是仅限于他们所在公司的影响。如果简历中出现“敏捷专家”或“Scrum 主管”，可能并不适合我们的需求。

此外，人工智能让产品经理能够进行更多的个人贡献，尤其是在数据分析和客户洞察方面。当然，基础的数学、统计学知识和编程能力依然是必需的，但成为一个真正具备技术背景的产品经理前所未有的容易。

我们依然重视文化的匹配和合作的便捷性，但我们不再那么需要那些主导他人工作的人才，因为有了人工智能，这已经不是必需的了。随着公司规模的扩大，这种情况可能会改变，但在目前的规模下，需要开发的产品远多于可以参与的人手。

我认为未来，整个行业的管理层会趋于精简。如果我要预测，具有技术背景且懂得产品美学的产品经理或工程师，将成为公司最宝贵的资产。

4. 您的团队是依据产品、用户类型、用户体验、成果，还是其他因素来组建的？这种组织方式有过变化吗？

我的目标是尽量减少团队协调上的阻碍，这个概念来源于 Alex Komoroske 在 他的黏菌组织演示文稿中的描述。基本思想是，随着规模的扩大，不确定性和意见分歧导致的协调成本会增加，而简单增加管理层并不能有效解决问题。团队成员的目标可能会出现错位，他们可能会对上级不真实汇报，而上级也可能向更高层的管理者误报。若要与组织中其他部分的人交流，往往需要通过多层级的沟通。

更理想的方式是保持团队对总体目标的一致认识，并通过共享可重用的指导手册和流程，使不同项目能并行推进。特别是在 AI 技术的帮助下，我们可以通过利用 AI 进行“橡皮鸭调试”，即用 AI 帮助梳理和验证想法，从而减少对完美一致性和全面共识的依赖，有效降低协调成本。我们还会在内部文档中持续更新团队成员的联系信息，以便在需要时可以直接联系相关人员，这依赖于高度的相互信任。

更为重要的是，有了 AI 的辅助，我们无需频繁进行人与人之间的直接沟通。在向他人提问之前，你或许可以先让 AI 花一分钟时间帮助降低沟通成本，为每个人自行解决问题提供一个合理的出发点。

5. 你们是如何做长远规划的，这种策略多年来有什么变化？

Perplexity 这家公司成立不到两年，AI 领域的迅猛变化让我们难以做出超过这个时限的承诺。我们会制定季度计划，在每个季度内，我们努力维持产品路线图的稳定性。这个路线图既包括所有人都知道的几个大项目，也包括随优先级调整而变动的小任务。在 AI 快速发展带来不可预知的影响时，保持敏捷至关重要。例如，开源模型和上下文长度的快速发展，已经对我们的产品、路线图和整体业务产生了深远的影响。最近，Meta 推出了 Llama 3，Mistral 推出了 8x22B 模型，我们正在探索如何创新地利用这些模型。

项目的灵活调整非常必要，因为新产品开发需要与技术和模型的开发同时推进。工程师们根据具体的周计划，在维护现有产品和开发新产品之间切换。随着我们不断遇到现有系统的局限和技术债务的积累，技术路线图的发展速度很快，我们努力优先解决那些能够带来产品改进的技术债务。

然而，在一周的时间里，计划基本稳定。我们会在每周的项目启动会上设定该周的高层目标。我们采取了设定 75% 的周目标的策略，即每个人确定一周的首要任务，并争取在周末之前完成这些任务的 75%。这样做只需几个关键点，确保一周内优先级明确。

在一周的开始，花时间回顾关键任务，有助于提升决策的清晰度，避免做出过于冲动或混乱的决策。随着时间的推移，我们在估算项目规模和按投资回报进行优先级排序方面的能力也得到了提升。

6. 你们是否采用 OKRs（目标与关键结果）方法？

我们在季度计划中力求严格并依赖数据驱动决策。所有的目标都能具体衡量，不管是通过量化的指标还是简单的“是否完成了 X 任务”来确定。我们设定了极具挑战性的目标，通常到季末，我们可能只完成了大约 70% 的目标。未完成的 30% 有助于我们发现在优先级设定和人员配置上的不足。例如，如果基础设施目标没有达成，那么在基础设施工程师的招聘上的不足就会迅速显现。

7. 你的产品/设计评审会议是如何进行的？

在核心目标与高层设计确定之后，我们尽可能地实行分散决策。每个项目由一个直接责任人 (DRI) 推动，步骤尽可能并行进行。

项目的首要步骤是将其细分为多个并行任务，以此减少协调上的困难。这一过程由我和团队中的产品经理（或相当职责的成员）在 Linear 上共同完成。我们力求每个任务能独立完成——你应该能够在无障碍的情况下执行它。虽然你可能需要作出一些具有争议的决策，但可以留待以后再处理争议。

每个项目开始时，我们会举行一个简短的启动会，以统一思路，之后迭代过程异步进行，不受任何约束或审查限制。当团队成员准备好就他们的设计、实施或最终产品寻求反馈时，他们会在 Slack 上进行分享，其他团队成员则提供诚实而建设性的反馈。迭代根据需求自然发生，直到产品通过内部试用得到团队的广泛认可后才会推向市场。

我鼓励团队成员尽可能并行工作，无需等待其他人排除障碍。理想情况下，设计、前端和后端应同时在同一项目上工作。如今我们有了商务团队，四人可以同时进行工作，而不是像以往那样需要等待设计或样机先行。

8. 汇报关系是怎样运作的？

我们的团队根据不同功能 (如产品、研发 (R&D)、设计、商务等) 进行组织，各团队针对公司不同层面的结构和任务有不同的思考。但所有的努力都集中于核心产品的改进。我们制定了可以转化为共同的顶层指标，全面优化用户体验的目标。例如，各团队在其所属的层级内进行 A/B 测试时，都会共享这些顶层指标。鉴于产品可能迅速变动，我们努力避免任何政治问题，尤其是避免个人与产品的任何特定部分过度绑定。

在目前的组织规模下，我们故意保持扁平化管理，这样的报告结构并不严格规定优先级，而是更多地体现在对顶级目标的承诺上。我们的两位全职产品经理——一位负责网页，一位负责移动端——直接向我汇报，我是产品部的负责人。我们发现，当团队中没有产品经理时，团队成员会自发承担起调整项目范围、做出面向用户的决策以及信任自己的判断力等产品经理职责。

9. 你们构建了极受欢迎且成功的产品，你认为贵公司的产品策略中有哪些独特或关键的因素促成了这种成功？

我们策略的核心是收集用户和内部的反馈，并将之简化为几款直观的产品，满足广泛客户的需求。我们也将反馈以一种能够激励团队并为其提供信息的方式进行提炼，我们设定了宽泛的愿景，允许团队成员根据自己的判断做出最适合实现原始目标的决策。我们的分散决策方式将责任传递给个体，支持快速迭代且无需等待批准。个体会做出紧迫且最符合当地情况的决策，任何不一致之后都能迅速调整。

10. 你们主要使用哪些工具来进行任务管理和缺陷跟踪？

我们使用 Linear。在 AI 产品开发中，任务、缺陷和项目的界限往往不甚明确。Linear 中的一些概念，比如领导 (Leads)、紧急处理 (Triage)、项目规模评估 (Sizing) 等，都显得格外重要。我特别喜欢的一个功能是自动归档：如果一个任务很久都没被提到，那么它可能真的不那么重要。

而 Notion 则是我们存放诸如路线图和里程碑计划等核心资料的主要工具。开发过程中，我们依靠 Notion 来撰写设计文档和 RFC，项目完成后则用来整理文档、进行事后分析及保留历史记录。把思考过程形式化为文档，有助于我们做出更清晰的决策，同时减少会议，提高异步工作的效率。

我们最近还引入了 Unwrap.ai 这一工具，用以整合、记录并量化定性反馈。由于 AI 的特性，许多问题不总是可以明确地定义为缺陷。Unwrap 将零散的反馈汇总成具体的改进主题和领域。

11. 你认为路线图中的想法主要是自上而下（团队被告知需要做什么）还是自下而上（团队通常自发提出想法）的？

虽然高层的目标和方向是由上而下制定的，但许多新的想法却是从基层团队中产生的。我们非常认同工程和设计团队应对其想法和细节拥有主导权，特别是在 AI 项目中，因为在具体实现前，很多约束条件都是未知的。我们的团队始终在积极地进行头脑风暴，我们在 Slack 中专门设有一个讨论频道，相关的想法会在 Linear 中记录，而且很多时候，新的改进会直接编入代码，无需过多讨论。

例如，我们公司的 Perplexity 品牌的“发现、收集和分享”体验，就是优秀的自发想法实例。就像我之前分享的，我们的品牌设计师 Phi 不仅创建了《发现日常》播客，同时还在剧本、ElevenLabs 的集成、品牌形象和音频技术上做出了决策。对于 AI 产品来说，只有在多次迭代后，我们才能开始预测可能的使用场景。就如一年前，我们无法预见到“发现体验”最终会演变为一个播客节目。

12. 当人们从外界观察贵公司时，一切似乎无懈可击，好像你们已经事事处理妥当。那么，有哪些方面存在问题或遇到重大挑战呢？

目前，我们面临的主要挑战是如何从现有规模扩大到下一个阶段，这涉及招聘和业务执行与规划的多个方面。我们不希望失去在平等和合作的工作环境中的核心特质。即便是看似简单的决策，比如如何配置 Slack 和 Linear，放大规模时也颇具挑战。我们正在努力寻求在扩大通信频道和项目的同时，保持透明度并控制通知的急剧增加。

13. 产品团队或公司里有哪些有趣的或独特的习俗或传统？

Perplexity 的许多功能和产品都是在为期一周（或更短）的黑客松中开发出来的。这些密集的开发冲刺不仅极富挑战性，也常常成为最激动人心和难忘的经历。我们的第一个交互式搜索原型“Pro Search”（原名 Copilot），虽然只用了几天就初步构建出来，但随后经过多次迭代和细致调优，性能不断提升。

感谢 Johnny Johnny 的贡献，同时也非常感谢 Phi Hoang Phi Hoang 在视觉上的大力支持。

欲了解更多信息，请访问 Perplexity，他们目前也在招聘新成员！

祝大家本周工作充实、成果丰富 🙏