AI 搜索 Perplexity 的产品构建之道_AI阅读总结 — 包阅AI

作者｜Lenny Rachitsky

OneFlow编译
翻译｜凌小雨、张雪聃

题图由SiliconCloud平台生成

作为一家刚成立不到两年的新公司，AI搜索新星Perplexity与搜索巨头Google和AI先锋OpenAI展开竞争，争夺未来搜索领域的一席之地。

目前，Perplexity已经拥有数以千万计的用户，不过，该团队的成员还不到50人。更令人振奋的是，这个年轻团队已经实现了超过2000万美元的年度经常性收入（ARR）。

最近，他们完成了一笔6300万美元的融资，公司估值超10亿美元，其投资者包括英伟达、亚马逊创始人Jeff Bezos、OpenAI创始成员Andrej Karpathy、知名投资人Garry Tan、Dylan Field、Elad Gil、Nat Friedman、Daniel Gross和Naval Ravikant。英伟达CEO黄仁勋曾公开表示，他几乎每天都在使用Perplexity。

知名博主Lenny Rachitsky近期与Perplexity联合创始人兼产品负责人Johnny Ho进行了一次对话，后者从内部视角深入介绍了Perplexity如何构建产品。

以下是部分要点摘要：

1. AI优先：员工们一直都在向AI询问有关公司构建过程步骤相关的问题，包括“如何推出产品？”公司鼓励员工在打扰同事之前先向AI提问；

2. 组织灵活高效：通过将项目分解成多个并行任务来最大限度地减少团队间的协调成本；

3. 小而精的团队：Perplexity的标准团队通常只有两到三名成员工，其AI生成（且评价极高）的播客仅由一个人创建、运营；

4. 扁平化管理：Perplexity倾向于雇佣自我驱动力强的独立贡献者，并尽量避免招聘在团队中喜欢指挥别人干活的员工；

5. 既懂技术又有产品见解的优秀产品经理/工程师：Johnny的大胆猜想是，随着时间的流逝，那些既懂技术又对产品有独到见解的产品经理或工程师，将成为公司最宝贵的资产。

（本文由OneFlow编译发布，转载请联系授权原文：https://www.lennysnewsletter.com/p/how-perplexity-builds-product）

1.Perplexity内部如何使用AI工具来构建Perplexity？

其实，一开始我们也是盲人摸象，对产品管理、项目管理、财务、人力资源等没有具体的认知。

幸运的是，我们有机会提前接触GPT-3，创立之初，我们总是先向AI求助，比如“X是什么？”“那我们该如何正确地完成它？”比如，我们会问：“如何发布产品？发布过程中的步骤是什么？”等问题。

AI会给我们一个大致的步骤流程，这对初创公司来说已经足够好。当然，第一次尝试往往都不尽如人意，但谁又能一开始就做到完美？所以我们在哪里摔倒就在哪里爬起来，不断试错、学习、迭代。

我们花了好几天尝试自己解决问题。但是有了AI的一点提示，我们可以在五分钟内就开始行动。

我们还在继续使用这样的方法。例如，本周我问Perplexity：“怎么写一封邀请别人试用Perplexity Pro的邮件？”

我们有时候甚至用AI工具来构建自己的产品，但发现在编程方面，AI工具还需要迭代。它可以帮我们编写脚本，但如果想在平台上构建可持续的代码就不太行了。

即使在今天，随着技术的进步和新模型的出现，这些工具也只能写写模板，没办法真正用它来设计那些能长久使用的抽象化技术。

在我们这个50人的团队里，只有两名全职产品经理。这两位产品经理负责的项目通常只有一两个人参与，最棘手的项目最多也只有三四个人。

比如，我们的播客就是由一个人一手包办的。他是品牌设计师，但同时也会做音频工程，并进行各种研究，以打造一个最具互动性和趣味性的播客。我认为，到目前为止，还没有产品经理介入过这个过程。

遇到非常困难且有多种选择的决策时，以及在更复杂的项目中，产品管理最能发挥其优势。

产品经理工作中最困难也是最重要的部分是对应用场景具有很好的判断力。在AI领域，可能存在的应用场景数量太多。因此，产品经理需要根据数据、用户研究等信息，做出分支定性决策。AI领域的一个重要问题是应该优先考虑以提高生产力为主的使用场景，还是聊天机器人类的互动性使用场景。很早以前，我们就决定专注于前者，但相关讨论仍在继续。

我们计划在未来一年内再招一到两位产品经理，但招聘标准不会降低。

3.你们的成功很大程度上是因为招聘得当，并保持了非常高的标准。在招聘时，你们最看重的（但别人可能没注意到的）特质是什么？

鉴于我们工作的速度，我们首先会要求灵活性和主动性。在资源有限的环境中能够积极建设性地工作（可能要身兼数职）对我们来说最重要。

看产品经理的简历时，很多人会强调帮助他人、寻求共识的特质。但我认为，随着AI的出现，这一点将变得不那么重要，你不一定需要擅长管理流程或领导别人。我们更看重那些在用户群体中产生明确量化影响的强大的个体贡献者，而不是只在公司内部表现出色的人。如果简历中出现“敏捷专家”或“Scrum大师”这样的描述，这个人可能不太适合我们。

此外，AI让产品经理能做更多的技术工作，尤其是数据分析和客户洞察方面。当然，还是需要一些基本知识（例如对数学、统计学、编程的基本理解），但现在成为真正“技术型”的产品经理已经比从前用容易不少。

我们也很看重候选人与我们企业文化的契合度，易于合作很重要，我们不太想要那种擅长指导他人工作的人，在AI时代，这种人并不是很必要。也许，未来公司规模扩展之后，我们的需求会有所改变，但在目前的规模下，需要构建的产品数量远远多于投入这些工作的员工数量。

我认为，未来整个行业的管理层将会减少。随着时间推移，技术产品经理或有产品敏锐度的工程师将成为公司中最宝贵的人才。

4. 你们的团队以围绕产品、用户类型、用户旅程、成果，还是介于这些之间的某种方式来构建？这些年来，这种结构有没有发生变化？

我的目标是构建团队，力求减少所谓的“协调阻力”，正如Alex Komoroske把组织比作黏菌时所描述的那样。

我们的核心观点是，随着规模扩大，由不确定性和分歧引起的协调成本会随之上升，单纯增加管理层并不能解决问题。员工的动机可能会不一致，甚至可能出现上下级之间相互隐瞒的情况。如果你想和公司里其他部门的人沟通，可能得经过一层层的上传下达，要问遍所有人。

相反，我们可以保持总体目标一致，通过共享可复用的指导和流程，让项目并行推进，共同指向这个目标。特别是在AI的帮助下，我们可以用它实现“小黄鸭调试法”（当程序员在解释他们的代码时，就像对着一个橡皮鸭（rubber duck）说话一样。通过解释问题，程序员往往能在解释过程中自己发现问题所在，或者至少能更清晰地理解问题。）从而对我们的想法进行测试，而不必依赖于完美的对齐和共识，这样就能降低协调成本。我们还在内部文档中建立了一个“人物名录”，需要联系谁，直接就能联系。这需要很高的信任度。

更重要的是，有了AI，你不用再频繁地向他人求助。有时候，在向别人提问之前，你可以先尝试花一分钟让AI回答，以减少协调成本，这也能给每个人提供一个不错的起点，让他们自己来做。

5. 你们详细规划的时间跨度有多长？这些年来有何变化？

Perplexity成立不到两年，而AI领域瞬息万变，很难给出两年之外的承诺。

我们一般会制定季度计划，在季度内，我们尽量保持计划的稳定，并设定产品路线图。路线图上有大家熟知的几个大项目，以及随优先级变化而调整的小任务。

灵活应变至关重要，因为AI的发展常常会带来不可预见的影响。例如，开源模型和上下文长度的快速发展对产品、路线图和整个业务都产生了下游影响。就在最近，Meta发布了Llama 3，Mistral发布了8x22B，我们正在探索如何将这些模型创造性地应用到我们的产品中。

产品路线图中的项目也需要灵活一些，因为新产品开发与技术/模型开发路线图是一起进行的。工程师会根据每周的情况决定是维护现有产品还是构建新产品。技术路线图通常发展很迅速，因为我们会遇到现有系统的限制并且会累积技术债务，但一般优先处理能够带来产品改进的技术债务。

尽管如此，一周之内的计划还是相对稳定的。我们每周都有一个启动会议，每个人都会设定本周的宏观期望。我们有一个“75%”的企业文化：大家都挑出本周的首要任务，并尽力达到75%的完成率。只需几个要点，就能确保本周的优先事项清晰明确。

在每周开始时花点时间思考核心任务可以让逻辑清晰，并避免出现决策仓促、决策混乱。随着时间的推移，我们根据投资回报评估项目规模和优先级的能力也有所提高。

6.你们会以某种形式使用OKR吗？

我们尽量在季度计划中以数据驱动，并且对此很严格。所有目标都是可以衡量的，无论是定量的阈值，还是布尔值“X是否完成”。

我们的目标很激进，通常在季度结束时，我们可能只完成了70%。剩下的30%有助于我们发现优先级和人员配置上的差距。例如，当基础设施目标未达到时，对基础设施工程师招聘的投入不足便显而易见。

7.你们的产品/设计评审会议是如何运作的？

在确定核心目标和宏观设计后，我们尽量在决策中保持去中心化。项目由一个直接责任人（DRI）驱动，执行步骤尽可能同时进行。

所有项目的第一步都是尽可能地将其分解为并行任务，以减少协调成本。我们用Linear（一个任务管理工具）来实现协调，我与团队中的产品经理（或任何负责产品管理的人）共同领导这项工作。我们力求每个任务都是独立的——能够在没有阻碍的情况下执行。你很可能不得不做出一些有争议的决定，但这些争议可以稍后再处理。

每个项目开始时，我们会开一个快速的启动会议以达成一致，随后，迭代以非共识的方式进行，没有限制，也没有审查流程。当员工准备好征求对设计、执行或最终产品的反馈时，会在Slack中分享，团队的其他成员会给予诚实的、有建设性的反馈。需要的时候，迭代自然发生，产品在通过内部测试（dogfooding）获得认可之前不会发布。

我鼓励大家尽可能地同步工作，不应等待别人，依赖别人。理想情况下，设计、前端和后端应该同时在同一个项目上工作。现在我们有了业务团队，这四个部分可以同时工作，而不是和以前一样等着设计或模型出现。

8.你们的汇报线是如何运作的？

目前，我们的团队按职能（产品、研发、设计、业务等）划分架构，不同团队对公司和堆栈的考量也不同，但所有精力都集中在改进核心产品上。

我们设计的目标旨在转化为通用的高层次指标，并全面提升用户体验。例如，所有团队共享同一个核心指标，同时在各自堆栈层进行A/B测试。由于产品变化迅速，我们希望避免因个人身份与产品任何特定组件紧密绑定而产生的政治问题。

在目前的规模下，我们是有意保持扁平化的，但是优先级更多是由对顶层目标的承诺决定的，而不是由汇报结构决定的。我们有两位全职PM——一位负责网页端，一位负责移动端——他们作为产品负责人向我汇报。我们发现，当团队没有PM时，团队成员会承担PM的责任，比如调整范围，做出面向用户的决定，并相信自己的决策。

9.你们做出了最受欢迎和成功的产品之一，有没有什么独特或核心的地方使得你们取得了这样的成功？

关键在于吸收来自用户和内部的反馈，并将其提炼为可以为其他客户服务的直观产品。

我们也努力用一种激励团队的方式来提炼反馈，设定宏观的愿景，但让个人掌控自己的决策，这样才能最大程度地服务于最初目标。我们在决策中采取去中心化的方法，将责任传递出去，无需审批流程即可快速迭代。个体负责做紧急的、局部最优的决策。一旦发现有不协调的地方，之后会迅速采取措施予以解决。

10.你们主要的任务管理和错误追踪工具是什么？

我们主要用Linear。对于AI产品，任务、错误和项目之间的界限很模糊，但我们发现Linear中的许多概念，如Leads、Triage、Sizing等非常重要。我最喜欢的功能是自动归档——如果一个任务很久没被提及，那它可能并不重要。

我们用来存储像路线图和里程碑计划这样的真实来源的主要工具是Notion。我们在开发过程中使用Notion进行设计文档和RFC（变更请求），之后用于文档、事后分析和历史记录。将想法写在纸上（记录思维链）可以带来更清晰的决策，并使异步对齐更容易，避免不必要的会议。

Unwrap.ai是我们最近引入的一个工具，用于整合、记录和量化定性反馈。由于AI的特性，许多问题并不能绝对地归为bug 。Unwrap将个别反馈汇集成更具体的主题和改进方向。

11.路线图的想法主要是自上而下（通知团队）还是自下而上（团队提出想法）？

高层次的目标和方向是自上而下的，但大量的新想法是自下而上的。

我们坚信工程和设计应该对想法和细节拥有决定权，尤其是对于AI产品，因为很多限制条件在想法变成代码和原型图之前是无法预知的。头脑风暴一直都在上演，我们在Slack上有一个专门的头脑风暴频道，在Linear上收集跟进想法，通常这些改进会直接转化为代码，不需要征求任何意见 。

自下而上的想法的最佳例子可以在Perplexity的发现、收藏和共享体验中看到。例如，正如我前面提到的，我们的品牌设计师Phi构建了“每日发现”播客，并且同时在剧本、ElevenLabs集成、品牌和音频工程等多个业务上有决策权。

对于AI来说，只有在产品迭代发布后才能预测使用案例。一年前，我们没想过“发现体验”最终能做成一个播客。

12.在外界看来，你们这样的公司一切看起来都很完美。你们有遇到什么挫折或大的挑战吗？

当下的挑战与规模扩展有关，无论是招聘还是执行和计划方面，我们不想失去扁平化和协作化的核心特性。即使是像如何组织Slack和Linear这样的小决定，也可能很难扩展。我们目前正在尝试在不导致消息量激增的前提下，保持透明并扩展频道和项目数量。

13.你们的产品团队或公司里有哪些有趣/独特的仪式或传统？

在Perplexity，许多功能和产品是在一周（或更短）时间内的黑客马拉松中构建的。专注冲刺以搭建新功能是最令人兴奋和难忘的时刻。

我们的第一个互动搜索原型Pro Search（前称Copilot）是在几天内构建的，同时，这个产品也在多次迭代和微调中不断得到完善。

其他人都在看

SiliconCloud，让超级产品开发者实现“Token自由”

现在，每成功邀请一位SiliconCloud新用户，你就能获得2000 万Token/人。

Token奖励上不封顶，传送门：
siliconflow.cn/zh-cn/siliconcloud