Perplexity 联合创始人兼产品主管揭秘该公司借助AI形成的独特产品开发方法

Perplexity成立不到两年，用户数迅速增长至数千万，年经常性收入（ARR）超过2000万美元。作为一家AI优先的公司，Perplexity在搜索引擎领域与Google和OpenAI等巨头竞争。

Lenny’s Newsletter 作者Lenny Rachitsky与Perplexity的联合创始人兼产品主管Johnny Ho进行了深入对话，揭示了该公司独特的产品开发方法。

AI优先策略：
- AI指导决策：Perplexity的团队会向AI询问公司建设过程中各个步骤的建议。例如，他们会问AI如何发布产品以及发布过程中的具体步骤。尽管AI的回答不总是完全正确，但通过迭代，他们能够迅速找到解决方案。
- 使用AI减少协调成本：团队成员在寻求同事帮助前，先向AI询问问题，从而减少了团队内部的协调成本。
团队组织与结构：
- “粘菌”组织模式：为了最小化协调成本，Perplexity采用了一种类似于“粘菌”的组织方式，即尽可能并行化每个项目的各个部分，减少不必要的协调。
- 小团队：典型的团队由两到三人组成，一些项目甚至由一个人完成，如AI生成的高评分播客就是由一个品牌设计师独立完成的。
- 少量管理层：Perplexity倾向于雇用自驱动的独立贡献者（IC），避免雇用主要以指导他人工作为强项的人。
产品管理的未来：
- 技术产品经理的重要性：Johnny预测，具备技术背景和产品品味的产品经理或工程师将成为公司中最有价值的人才。这些人能够直接参与产品开发，而不是仅仅管理流程或领导团队。
灵活的产品开发：
- 季度计划与灵活调整：公司制定季度计划，但在季度内保持灵活，根据AI技术的发展快速调整优先事项。每周的启动会议帮助团队成员设定高层次的目标，并在周末进行反思，以确保决策的清晰性和避免过于反应性或混乱的决策。
- 并行工作：设计、前端和后端可以同时在同一项目上工作，避免等待设计或原型完成后再开始其他部分。
去中心化的决策过程：
- 独立负责的项目：每个项目由一个单一的直接负责个人（DRI）领导，尽可能将项目分解为独立任务，以减少协调问题。团队成员可以在没有阻碍的情况下执行任务，并在项目的不同阶段根据需要获得反馈。
文化与招聘标准：
- 招聘标准：Perplexity寻找具备灵活性和主动性的员工，优先考虑在有限资源环境下能做出建设性贡献的人才，而不是擅长管理流程或领导他人的候选人。公司注重文化契合和合作能力，但减少了对传统管理技能的需求。
使用工具：
- 工具使用：Perplexity使用Linear来管理任务和项目，使用Notion来存储源文件、开发设计文档、RFC和文档。Unwrap.ai被用于整合和量化定性反馈。

以下是文章翻译

Perplexity 成立还不到两年，但已经成为我每天多次使用的产品，替代了我许多次Google搜索——而且不止我一个人这样。公司员工不足50人，但用户基数已增长到数千万，年度经常性收入（Annual Recurring Revenue, ARR）超过2000万美元，并在搜索领域与Google和OpenAI展开竞争。他们最近的6300万美元融资使公司估值超过10亿美元，投资者包括Nvidia、Jeff Bezos、Andrej Karpathy、Garry Tan、Dylan Field、Elad Gil、Nat Friedman、Daniel Gross和Naval Ravikant（但可惜没有我 😭）。Nvidia CEO Jensen Huang表示，他“几乎每天”都在使用这个产品。

我与公司联合创始人兼产品负责人 Johnny Ho 坐下来聊了聊，了解Perplexity如何构建产品——在我看来，这很可能是许多公司未来产品开发的样子：

AI优先： 他们在公司建设的每一步都询问AI，包括“如何发布产品？” 员工被鼓励在打扰同事前先问AI。
像黏菌一样组织： 他们通过尽量并行处理每个项目来优化协调成本。
小团队： 他们的典型团队由两到三人组成。由AI生成并广受好评的 podcast 仅由一人构建和运行。
少量管理者： 他们雇佣自驱动的IC（独立贡献者），并主动避免雇佣那些主要擅长指导他人工作的人员。
对未来的预测： Johnny说：“如果要我猜的话，具有产品品味的技术PM或工程师将随着时间的推移成为公司中最有价值的人。”

P.S. 我正在与Perplexity合作，深入探讨产品经理如何使用Perplexity，我们希望听到你的意见。如果你经常使用Perplexity，请填写这份简短调查，他们将联系你进行用户访谈。

从左至右：Perplexity联合创始人Johnny Ho, Aravind Srinivas 和 Denis Yarats

1.如何使用 Perplexity 中的人工智能工具来构建 Perplexity？

坦白说，一开始我们不知道如何处理各种事情，包括产品管理、项目管理、财务、人力资源等。我们早期接触到了GPT-3，在我们摸索如何建立公司的过程中，我们会从询问AI“什么是X？”开始，然后“如何正确地做X？”例如，我们会问“如何发布产品？发布过程的步骤应该是什么？”你会得到一个粗略的步骤，这对于初创公司来说已经足够好了。显然，它通常不会在第一次尝试时就正确，但人类也一样，对吧？所以我们会从那里自然地迭代。

我尝试自己摸索需要几天时间，但有了AI和一些提示，我们可以在五分钟内开始。

我们仍在这样做。例如，这周我问Perplexity，“如何写一封邀请某人加入Perplexity Pro的邮件？”

我们甚至尝试用它来构建我们的产品，但发现AI工具在编码方面还远远不够好。它可以帮助我们编写脚本，但如果你想要构建一个平台的可持续代码，它并不真正起作用。即使在今天，随着进步和最新模型，它仍然只写模板。你不能真正用它设计一个新的长期存在的抽象。

2.你有多少 PM？

我们在一个有50人的组织中只有两个全职PM。

我们的两个PM

我们处理的典型项目只有一两个人。最难的项目最多有三四个人。例如，我们的播客是由一个人从头到尾构建的。他是一个品牌设计师，但他做音频工程，并进行各种研究，以弄清楚如何制作最互动和有趣的播客。我认为在这个过程中没有任何PM介入。

我们最需要产品管理的是在有许多分支方向的艰难决策和更复杂的项目中。

PM最难也是最重要的部分是对用例的品味。有了AI，你可能会有太多可能的用例可以研究。因此，PM必须根据数据、用户研究等做出分支的定性决策。例如，AI的一个大问题是如何在更多生产力用例和引人入胜的聊天机器人类型用例之间进行优先排序。很早我们就决定专注于前者，但仍在进行讨论。

我们计划在明年招聘一两个PM，但招聘标准将保持很高。

3.我想您的成功在很大程度上得益于招聘得当，并保持很高的标准。您在招聘时最看重的是什么（也许别人不看重）？

考虑到我们的工作速度，我们最看重的是灵活性和主动性。在资源有限的环境中建设性地工作（可能需要多重角色）是我们最重要的。

当你查看PM的简历时，很多人优先帮助他人和寻找对齐。我认为随着AI的出现，这变得不那么重要。因此，你不一定需要围绕管理流程或领导他人技能。我们寻找在用户而非公司内部有明确定量影响的强IC。如果我在简历中看到“敏捷专家”或“scrum master”的字样，可能就不太适合。

此外，AI允许PM做更多IC工作，特别是数据分析和客户洞察。当然，你仍然需要一些基本知识（如数学、统计、基本编程知识），但成为真正“技术型”PM从未如此容易。

我们仍然选择文化契合度和易于合作的人，但我们不太寻找那些指导他人工作的人员，因为有了AI这不是那么必要。随着我们达到一定规模，这可能会改变，但在当前规模下，产品远多于人员。

我认为未来行业管理层级会减少。如果要我猜的话，具有产品品味的技术PM或工程师将成为公司中最有价值的人。

4.你们是如何围绕产品、用户类型、用户旅程、结果或介于其中的某些方面来组织团队的？这些年来，这种方式有变化吗？

我的目标是围绕最小化“协调阻力”来构建团队，如Alex Komoroske在这个关于将组织视为黏菌的演示文稿中所述。大致意思是，随着规模增加，协调成本（由不确定性和分歧引起）增加，增加管理人员并不能改善事情。人们的激励措施变得不一致。人们往往对他们的经理撒谎，经理对他们的经理撒谎。如果你想和组织的另一部分的人交谈，你必须上升两级，然后下降两级，沿途问每个人。

相反，你要做的是保持总体目标一致，并通过共享可重用的指南和流程来并行化指向这一目标的项目。特别是随着AI的进步，可以通过使用AI来“橡皮鸭调试”你的想法来最小化协调成本，而不是依赖完美的对齐和共识。我们还会在内部文档中更新“谁是谁”列表，如果你觉得需要联系任何人，就去联系。这需要很大的信任。

但更重要的是，有了AI，你不必经常联系他人。有时在问别人之前的问题之前，你可以先花一分钟问AI，以减少协调成本，并为每个人提供合理的起点来自己完成。

5.你们的详细计划有多长，多年来是如何演变的？

Perplexity存在还不到两年，AI的发展如此迅速，难以做出超越这个时间的承诺。我们制定季度计划。在季度内，我们努力保持计划在产品路线图内稳定。路线图有几个大家都知道的大项目，以及随着优先事项变化的小任务。灵活性至关重要，因为AI的发展常常有不可预见的影响。例如，开源模型和上下文长度的快速发展对产品、路线图和整体业务产生了下游影响。就在最近，Meta发布了Llama 3和Mistral发布了8x22B；我们正在寻找创造性的方法在我们的产品中使用这些模型。

产品路线图中的项目也需要灵活，因为新产品开发与技术/模型开发路线图并行运行。工程师在维护现有产品和构建新产品之间切换，取决于每周的需要。随着我们遇到现有系统的限制并积累技术债务，技术路线图往往快速增长，但我们尝试优先处理可以解锁产品改进的技术债务。

在特定的一周内，计划相当稳定。每周我们有一个启动会议，每个人设定一周的高层次预期。我们有一个设定75%周目标的文化：每个人确定他们本周的首要任务，并尝试在周末完成75%。只是一些要点，以确保在一周内优先事项清晰。

在每周开始时花点时间反思元任务可以带来清晰度，防止过于反应性或混乱的决策。随着时间的推移，我们估算规模和基于投资回报优先级的能力也得到了改善。

6.你们是否以某种形式使用 OKRs？

我们在季度计划中尽可能严格和数据驱动。所有目标都是可衡量的，要么以量化门槛表示，要么以布尔值“X是否完成”表示。我们的目标非常激进，通常在季度末我们只完成了70%左右。剩余的30%帮助识别优先级和人员配备中的差距。例如，当基础设施目标未完成时，很快就会显现出在招聘基础设施工程师方面的投资不足。

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

在确定核心目标和高层设计之后，我们尽量在决策上去中心化。项目由单个DRI驱动，执行步骤尽可能并行完成。

任何项目的第一步是尽可能将其分解为并行任务，以减少协调问题。我们在Linear中这样做，我与团队中的PM（或处理PM职责的人）共同领导这项工作。我们努力使每个任务都是自包含的——你应该能够在没有障碍的情况下执行它。而且你可能不得不做出一些有争议的决定，但你可以稍后再解决争议。

在每个项目开始时，有一个快速的启动以对齐，之后，迭代以异步方式进行，没有限制或审查过程。当个人感觉设计、实施或最终产品准备好接受反馈时，他们会在Slack中分享，团队的其他成员会给予诚实和建设性的反馈。迭代根据需要自然发生，产品在通过内部测试获得内部牵引力之前不会发布。

我鼓励人们尽可能并行工作。他们不应该等待每个人解除阻塞。理想情况下，设计、前端和后端应该同时在同一个项目上工作。现在我们有了一个业务团队，所有四个人可以并行工作，而传统上你可能会等待设计或模型首先出现。

8.报告线如何运作的？

团队目前按职能（产品、研发、设计、业务等）分组，不同的团队考虑公司的不同层次和堆栈。但所有的能量都集中在改进核心产品上。我们设计的目标转化为共同的顶层指标，全面改善用户体验。例如，所有团队共享共同的顶层指标，同时在他们的堆栈层中进行A/B测试。由于产品可以迅速变化，我们希望避免任何人的身份与产品的任何组成部分绑定的政治问题。

在我们目前的规模下，我们故意保持扁平化，报告结构并不如对顶层目标的承诺那样决定优先事项。我们两个全职PM——一个负责网页，一个负责移动——向我汇报作为产品负责人。我们发现，当团队没有PM时，团队成员会承担PM职责，比如调整范围、做出面向用户的决策，并相信自己的品味。

9.您打造了最受喜爱的成功产品之一。您认为您的产品取得如此成功的独特之处或核心是什么？

我们的核心方法是从用户和内部获取反馈，并将其提炼为几个直观的产品，可以为许多客户工作。我们还尝试以激励和通知团队的方式提炼反馈，设定广泛的愿景，但让个人控制自己的决定，最能满足原始目标。我们的去中心化决策方法传递了责任的火炬，使快速迭代成为可能，而无需审批过程。个人做出紧急的、本地最优的决策。任何不一致的地方都很快解决。

10.你们主要使用什么工具进行任务管理和错误跟踪？

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

我们用来存储真理来源（如路线图和里程碑规划）的主要工具是Notion。我们在开发过程中使用Notion进行设计文档和RFC，之后用于文档、事后分析和历史记录。将想法记录在纸上（记录思维链）会导致决策更清晰，并且更容易异步对齐，避免会议。

Unwrap.ai是我们最近引入的一种工具，用于整合、记录和量化定性反馈。由于AI的性质，许多问题并不总是确定性的，难以分类为错误。Unwrap将单个反馈分组为更具体的主题和改进领域。

11.你认为产品路线图的想法主要是自上而下（团队被告知要构建什么）还是自下而上（团队通常提出想法）的吗？

高层目标和方向是自上而下，但大量新想法是自下而上。我们强烈相信工程和设计应该拥有想法和细节的所有权，特别是对于AI产品，约束在想法转化为代码和模型之前是未知的。随时进行大量头脑风暴。我们在Slack中有一个专门的头脑风暴频道，后续想法收集在Linear中，通常抛光直接进入代码，没有人要求。

自下而上的想法的最佳例子可以在Perplexity的发现、收集和共享体验中看到。例如，正如我上面分享的，我们的品牌设计师Phi构建了Discover Daily播客，并同时做出关于脚本、ElevenLabs集成、品牌和音频工程的决策。有了AI，直到产品迭代发布之前，无法预测用例。一年前，我们从未预料到发现体验最终会变成播客。