How Perplexity builds product by Lenny Rachitsky

APR 30, 2024

摘要:

Perplexity，一家不断增长的 AI 产品，强调以 AI 为先的方法，通过小团队减少协调成本，并在产品开发中重视技术产品经理，在展示去中心化决策过程和敏捷季度规划方面表现出色。

1. Perplexity 在产品开发中专注于以 GenAI 为先的方法。

2. 公司通过并行化任务和小团队来降低协调成本。

3. 技术产品经理在去中心化环境中做出决定以推动公司，备受重视。

4. 敏捷季度规划和灵活的产品路线图对于适应 GenAI 进展至关重要。

5. 鼓励去中心化决策和对想法的所有权。

6. 公司强调扁平化的组织结构和透明度与协作文化。

7. 专注的冲刺和黑客马拉松对于快速功能开发和创新至关重要。

被采访者: 

约翰尼·何（Johnny Ho），联合创办人兼产品负责人，解释了他如何像黏菌一样组织自己的团队，利用人工智能来建立他们的人工智能公司，以及更多其他内容

Perplexity产品介绍: 

成立不到两年，Perplexity 已成为我每天使用多次的产品，取代了我很多次的谷歌搜索 - 我并不是唯一一个这样做的人。

虽然公司只有不到50名员工，但他们的用户基础已经达到了上千万。他们的年收入超过了2000万美元，并与谷歌和OpenAI展开了一场关于搜索未来的较量。他们最近筹集了6300万美元的资金，使公司估值超过了10亿美元，投资者包括Nvidia、Jeff Bezos、Andrej Karpathy、Garry Tan、Dylan Field、Elad Gil、Nat Friedman、Daniel Gross和Naval Ravikant 。Nvidia首席执行官Jensen Huang表示他几乎每天都使用这个产品。

我与该公司的联合创始人兼产品负责人Johnny Ho坐下来，为您展示Perplexity是如何开发产品的——对我来说，这就像是许多公司未来产品开发的样子：

1. AI第一：他们一直向AI提问公司建设过程中的每一步，包括“如何发布产品？”鼓励员工在烦扰同事之前先询问AI。

2. 高效的组织架构：通过尽量并行化每个项目，他们优化以最小化协调成本。

3. 小团队：他们的典型团队由两到三个人组成。他们的AI生成的（评价很高的）播客是由一个人建立并管理的。

4. 减少管理层：他们雇佣自我驱动的个人贡献者，并积极避免雇佣那些擅长指导他人工作的人。

5. 对未来的预测：Johnny说：“如果让我猜的话，技术项目经理或具有产品眼光的工程师将会成为公司中最有价值的人。”

How Perplexity builds product

1. 如何在Perplexity中使用AI工具来构建Perplexity?

说实话，在最开始的时候，我们并不知道如何做各种事情，包括产品管理、项目管理、财务、人力资源等等。我们早期就得到了GPT-3的使用权限，然后在我们逐步搭建公司的过程中，我们会向AI提问：“X是什么？”然后是“我们应该如何正确地做X？”例如，我们会问诸如“如何推出一个产品？”、“在推出过程中应当有哪些步骤？”之类的问题。你会得到一个初步的逐步过程，对于一家初创公司来说已经足够好了。当然了，它的第一次尝试通常都不正确，但是人也一样，对吧？所以我们只是从这个起点自然地进行迭代。

我们自己尝试解决问题花了好几天，但有了人工智能和一些提示，我们只需要五分钟就能开始推动进展。

我们还在继续尝试。例如这个星期，我问了“Perplexity”：“如何写一封邀请别人加入Perplexity Pro的电子邮件？”

我们甚至尝试过在制作产品时使用它，但我们发现当涉及到编码时，人工智能工具的质量还远远不够。虽然它可以帮助我们编写脚本，但如果你想要构建一个可持续的平台代码，它就不太适用了。即使在今天，尽管有了更先进的模型，它仍然只能写出模板。你无法真正用它来设计一个新的长期抽象。

2. 你们有多少产品经理

我们在一个拥有50人的组织中只有两名全职产品经理。

我们工作的典型项目通常只有一两个人。最困难的项目有三到四个人，最多不超过四个人。例如，我们的播客是由一人独立完成的。他是品牌设计师，但他也负责音频工程，并进行各种研究以找出如何构建最具互动性和最有趣的播客。我认为在这个过程中从未有项目经理介入。

我们在产品管理中的最大杠杆作用体现在当面对一个分支很多、并且涉及更多参与的项目的非常难的决策时。产品经理工作中最难且最重要的部分是在使用案例上有鉴赏力。对于AI来说，可能的使用案例太多了，因此产品经理必须介入，基于数据、用户研究等做出分支性的定性决策。例如，AI的一个大问题是如何在更多以提高生产力为基础的使用案例与吸引人的聊天机器人类型的使用案例之间进行优先排序。相当早的时候，我们决定专注于前者，但仍有持续的讨论。

我们计划在明年再聘请一到两名产品经理，但招聘的标准将保持非常高。

3.我认为你们的成功很大程度上是因为招聘得当，且始终保持很高的标准。在招聘时，你最看重什么（可能是别人没太注意的）？

鉴于我们目前的工作节奏，我们最看重的是灵活性和主动性。在资源有限的环境中（可能需要身兼数职）能够建设性地建造是对我们来说最重要的。

当你查看项目经理的简历时，他们中的许多人都将帮助他人和寻找一致性放在优先位置。我认为，随着人工智能的出现，这一点变得不那么重要。因此，你不一定需要围绕管理流程或领导人员的技能。我们寻找的是对用户产生明确量化影响而非仅在其公司内部产生影响的强大个人贡献者。如果我在简历中看到“敏捷专家”或“Scrum主管”的字眼，它可能并不是非常合适。

同样的，AI让产品经理能够做更多的个人贡献工作，特别是在数据分析和客户洞察方面。当然，你仍然需要一些基础知识（比如数学、统计学、基本的编程知识），但成为一个真正的“技术型”产品经理从未如此简单。

我们仍然选择那些适合企业文化且易于合作的人，但我们较少寻找那些指导其他人工作的人，因为有了AI，这不再那么必要。随着我们达到一定规模，这种情况可能会改变，但在当前规模下，要构建的产品远远多于可供工作的人手。我认为，未来，我预计行业内的管理层次会更少。如果我必须猜测的话，一个具有产品敏感度的技术型产品经理或工程师，将随着时间的推移成为公司中最有价值的人。

4. 您是围绕产品、用户类型、用户旅程、成果，还是介于这些之间的某种因素来构建团队的？这些年来，这种做法有变化吗？

我的目标是围绕最小化“协调阻力”来构建团队，正如Alex Komoroske在这个关于将组织视为黏菌的演示文稿中所描述的那样, 协调成本（由不确定性和分歧引起的）随规模增加而增加，增加管理者并不会改善情况 人们的利益变得不一致 人们倾向于对他们的经理说谎，而经理也对他们的经理说谎 如果你想和组织中另一个部分的某人交谈，你必须上升两级再下降两级，沿途询问每一个人

相反，你想要做的是保持整体目标一致，并通过共享可复用的指南和流程，使朝向这一目标的项目并行发展 特别是在人工智能的推进下，通过使用人工智能进行“橡皮鸭调试”你的想法而不是依赖于完美的一致和共识，可以最小化协调成本 我们还在内部文档中更新了一个“谁是谁”的列表，如果你觉得需要联系任何人，就直接这么做 这需要很大程度的信任

但更重要的是，有了人工智能，你就不必那么频繁地联系别人了。有时，在向别人提问之前，你可以先尝试花一分钟向人工智能提问，以减少协调成本，给大家一个合理的起点，让他们自己去做。

5. 您通常会详细规划到多远的将来？这一习惯随着时间的推移有何变化？

困惑存在的时间还不到两年，而人工智能领域的变化是如此之快，以至于很难承诺超过这个时间范围。我们制定了季度计划。在季度内，我们尝试保持产品路线图内的计划稳定。路线图上有一些大项目，是大家都知道的，还有一些小任务，我们会根据优先级的变化进行调整。灵活应变是至关重要的，因为人工智能的发展往往会带来无法预见的影响。例如，开源模型和上下文长度的快速发展对产品、路线图以及整体业务产生了下游影响。就在最近，Meta发布了Llama 3，Mistral发布了8x22B；我们正在寻找创造性的方法，将这些模型应用于我们的产品中。

产品路线图中的项目也需要具有灵活性，因为新产品开发与技术/模型开发路线图并行进行。工程师根据周而定，可能在维护现有产品和构建新产品之间转换。技术路线图往往会随着我们遇到现有系统的限制和积累技术债务而迅速增长，但我们试图优先解决那些能够解锁产品改进的技术债务。

在给定的一周内，计划相当稳定。我们每周都有一个启动会议，在那里每个人都会设定他们一周的高级期望。我们有设定75％周目标的文化：每个人确定他们一周的最高优先级，并尝试在周末前达到75％。只需列出几个要点，以确保在一周内优先事项明确。

在一周开始的时候花一点时间去思考元任务能够带来清晰度，并防止过度反应或决策混乱。随着时间的推移，我们估计任务规模和根据投资回报进行优先排序的能力也得到了提升。

6. 你们使用OKRs吗？

我们在季度计划中尽量保持严谨和数据驱动。所有目标都是可衡量的，要么以可量化的阈值来衡量，要么用布尔值“X是否完成”来判断。我们的目标非常具有挑战性，通常到了季度末，我们只能完成大约70%的目标，不管是哪个方向。剩下的30%帮助我们识别在优先级设定和人员配置方面的缺口。例如，如果基础设施目标没有达成，就能迅速发现在基础架构工程师的招聘上的投资不足。

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

在确定了中心目标和高层设计之后，我们在决策过程中尽可能实现分散化。项目由单个 DRI 推动，尽可能并行执行步骤。

任何项目的第一步是尽可能将其分解为并行任务，以减少协调问题。我们在 Linear 中进行此操作，我与团队中的项目经理（或负责项目经理职责的人员）一起领导这项工作。我们致力于使每个任务都是独立的—您应该能够在没有阻碍的情况下执行它。您可能需要做出一些有争议的决定，但可以稍后再解决争议。

在每个项目开始时，都会进行一次快速的启动会议以确保对齐，之后，则以异步的方式进行迭代，没有约束或审查流程。当个人认为自己的设计、实现或最终产品准备好接受反馈时，他们会在Slack中分享，并且团队的其他成员会提供真诚和建设性的反馈。迭代根据需要自然发生，只有在通过内部实践获得内部支持时，产品才会被发布。

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

8. 团队汇报线是如何运作的？

团队目前按功能（产品、研发、设计、商业等）进行结构化，不同的团队关注公司和堆栈的不同层面。但所有的精力都指向提升核心产品。我们设计了目标，这些目标转化为共同的顶级指标，并全面改善用户体验。例如，所有团队在他们的堆栈层面进行A/B测试时，共享共同的顶级指标。由于产品可能会迅速变化，我们希望避免任何人的身份与产品的任何特定组件绑定产生的政治问题。

在我们目前的规模下，我们的设计是扁平化的，报告结构并不像对顶级目标的承诺那样决定优先级。我们的两位全职产品经理——一位负责网页，一位负责移动端——向我这位产品负责人汇报。我们发现，当团队没有产品经理时，团队成员会承担产品经理的职责，如调整范围、作出面向用户的决策以及信任他们自己的品味。

9. 您打造了市场上最受欢迎和成功的产品之一。您认为是什么独特或核心的产品方法论导致了这样的成就呢？

我们的方法的核心是接受用户和内部的反馈，并将其提炼成几种直观的产品，这些产品能够满足许多客户的需求。我们还试图以一种能够激励和告知我们团队的方式来提炼反馈，设定一个宽广的视野，但让每个人控制他们自己的决定，关于什么最能服务于原始目标。我们的去中心化决策方法传递了责任的火炬，使得快节奏的迭代成为可能，而无需审批流程。个体做出紧急的、局部最优的决定。任何不一致之后都会迅速得到解决。

10. 您主要使用什么工具来进行任务管理和bug跟踪？

Linear。对于人工智能产品而言，任务、漏洞和项目之间的界限变得模糊，但我们发现Linear中的许多概念，如Leads、Triage、Sizing等，极其重要。我最喜欢的一个功能是自动归档——如果一个任务已经有一段时间没被提及了，那很可能是因为它实际上并不重要

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

Unwrap.ai 是我们最近也引入的一个工具，用于整合、记录和量化定性反馈。由于人工智能的特性，很多问题并不总是足够确定性的，以至于可以被归类为漏洞。Unwrap 将单个反馈聚集成更具体的主题和改进领域。

11. 您会说路线图思路主要是自上而下（团队被告知要构建什么）还是自下而上（团队通常提出想法）吗？

高级目标和方向是自上而下的，但大量新想法是自下而上的。我们坚信工程和设计应该拥有对想法和细节的所有权，尤其是对于AI产品，其限制直到想法被转化为代码和模型时才为人所知。在所有时间里，都有大量的头脑风暴活动。我们在Slack中设有专门的头脑风暴频道，后续想法被收集在Linear中，往往抛磨直接上代码，无需任何人询问。

最佳的自下而上的想法例子可以在Perplexity的发现、收集和分享体验中看到。例如，正如我上面分享的，我们的品牌设计师Phi构建了Discover Daily播客，并同时决定剧本、ElevenLabs集成、品牌和音频工程方面的事宜。有了AI，直到产品的迭代版本发布之前，不可能预测使用案例。一年前，我们永远不会预测到Discover体验最终会被构建成一个播客。

12. 当人们从外部看到像你们这样的公司时，一切看起来都很完美，就像你们已经解决了所有问题。有哪些事情是进行得不顺利或者一直是大挑战呢？

如今我们面临的巨大挑战主要围绕着如何从当前规模扩大到下一个层面，这不仅涉及招聘方面，也包括执行和规划方面。我们不希望失去我们核心的身份——在一个非常扁平和协作的环境中工作。即便是像如何组织Slack和Linear这样的小决策，放到扩展的情况下也很难处理。我们目前正尝试弄明白的是，如何在透明度提高的同时，增加频道和项目的数量而不让通知数量激增。

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

Perplexity的许多功能和产品都是在为期一周（或更短）的黑客松期间构建的。专注的冲刺构建新功能被证明是最令人兴奋和难忘的时刻。我们的第一个交互式搜索原型，Pro Search（以前称为Copilot），是在几天内构建的，但经过多次迭代的打磨和微调，它已经得到了改善。