成立不到两年的Perplexity已经成为我每天多次使用的产品，取代了我的许多谷歌搜索——我并不孤单。该公司的员工不到50人，但用户数量已增长至数千万。他们也创造了超过2000万美元的ARR，并在未来搜索领域的争夺战中与谷歌和OpenAI展开了较量。他们最近融资6300万美元，估值超过10亿美元，投资者包括Nvidia、Jeff Bezos、Andrej Karpathy、Garry Tan、Dylan Field、Elad Gil、Nat Friedman、Daniel Gross和Naval Ravikant(可惜不是我😭)。英伟达首席执行官黄仁勋表示，他“几乎每天”都在使用该产品。
我采访了该公司的联合创始人兼产品主管Johnny Ho，让他向大家介绍一下Perplexity是如何开发产品的——在我看来，这就像是许多公司未来的产品开发模式:
- AI-first AI优先:他们一直在向AI询问公司建设过程中的每一步问题，包括“我如何发布产品?”公司鼓励员工在打扰同事之前先询问人工智能。
- Organized like slime mold 像黏菌（有高效协同能力一种真核生物）一样有组织：它们通过尽可能并行化每个项目来优化，以最大限度地降低协调成本。
- Small teams 小团队:他们的典型团队是两到三个人。他们的人工智能生成(高评价)播客是由一个人建立和运营的。
- Few managers 少量管理者:他们雇佣自我驱动型的首席执行官，并积极避免雇佣最擅长指导他人工作的人。
- A prediction for the future 对未来的预测:约翰尼说:“如果让我猜的话，随着时间的推移，有产品品味的技术项目经理或工程师将成为公司最有价值的人。
1. 你们是如何在《Perplexity》中使用AI工具去创造《Perplexity》？
老实说，一开始，我们不知道如何做各种事情，包括产品管理、项目管理、财务、人力资源等。我们很早就接触到了GPT-3，当我们弄清楚如何建立公司时，我们会先问人工智能，“X是什么?”，然后是“我们如何正确地做X ?”例如，我们会问这样的问题:“你如何推出一款产品?”发行过程中应该有哪些步骤?”你会得到一个粗略的一步一步的过程，这对一个初创公司来说已经足够好了。很明显，第一次尝试通常是不正确的，但人类也不正确，对吧?所以我们从这里自然地进行迭代。
试图自己解决问题需要几天时间，但有了人工智能和一些提示，我们可以在五分钟内开始工作。
我们还在做这个。例如，本周，我问Perplexity:“我该如何写一封邀请别人使用Perplexity Pro的电子邮件?
我们甚至有时会尝试使用它来构建我们的产品，但我们发现AI工具在编码方面远远不够好。它可以帮助我们编写脚本，但如果你想要可持续的代码来构建一个平台，它就行不通了。即使在今天，使用先进的和最新的模型，它仍然只编写模板。你不能用它来设计一个新的长期存在的抽象。
2. 你们有多少pm ?
在一个50人的组织里，我们只有两个全职的项目经理。
我们从事的典型项目只有一两个人。最难的项目最多只有三到四个人。例如，我们的播客是由一个人端到端构建的。他是一名品牌设计师，但他也做音频工程，他正在做各种各样的研究，以找出如何建立最具互动性和最有趣的播客。我认为总理在任何时候都没有进入过这个过程。
当有一个非常困难的决定涉及到许多方向，以及涉及更多的项目时，我们会利用产品管理。
PM工作中最困难，也是最重要的部分是对用例进行品味。有了人工智能，你可以处理的用例太多了。因此PM必须介入并根据数据、用户研究等做出分支定性决策。例如，人工智能的一个大问题是，你如何在基于生产力的用例和引人入胜的聊天机器人用例之间进行优先排序。很早就，我们决定专注于前者，但仍在进行讨论。
我们计划明年再招聘一到两名项目经理，但招聘的门槛仍然很高。
3. 我想你们的成功很大程度上是由于招聘得当，并保持了很高的标准。你在招聘时最看重的是什么(别人可能不看重的)?
考虑到我们工作的节奏，我们首先寻求的是灵活性和主动性。在资源有限的环境中（可能需要身兼数职）建设性地开展工作的能力对我们来说是最重要的。
当你查看 PM 的简历时，你会发现他们中的许多人都优先考虑帮助他人和找到志同道合的人。我相信随着人工智能的出现，这一点变得不那么重要了。所以你不一定需要管理流程或领导他人的技能。我们寻找的是强大的 IC，他们对用户有明显的量化影响，而不是对公司内部的影响。如果我在简历中看到“敏捷专家”或“Scrum 大师”等字眼，那可能就不太合适了。
此外，人工智能让 PM 能够做更多 IC 工作，尤其是数据分析和客户洞察。当然，你仍然需要一些基础知识（例如数学、统计学、基本的编程知识），但成为一名真正的“技术型”PM 从未如此简单。
我们仍然会选择文化契合度高、容易合作的人，但我们不太会寻找能够指导他人工作的人，因为在人工智能领域，这并非必要。随着我们达到一定规模，这种情况可能会改变，但在目前的规模下，需要开发的产品数量远远多于需要开发这些产品的人手数量。
我认为，在未来，我预计整个行业的管理层次会更少。如果让我猜的话，随着时间的推移，一个有产品品味的技术项目经理或工程师将成为公司最有价值的人。
4.你们的团队架构是围绕产品、用户类型、用户旅程、结果，还是介于两者之间的因素？这些年来，这些因素有变化吗？
我的目标是围绕最小化“协调阻力”来构建团队，正如 Alex Komoroske 在这篇关于将组织视为黏菌的演讲中所描述的那样。粗略的想法是，协调成本（由不确定性和分歧引起）会随着规模的扩大而增加，而增加经理并不能改善情况。人们的激励变得不一致。人们倾向于欺骗他们的经理，而经理又欺骗他们的经理。如果你想与组织中另一个部门的某个人交谈，你必须向上和向下走两层，一路询问每个人。
相反，您要做的就是保持总体目标一致，并通过共享可重复使用的指南和流程来并行化指向此目标的项目。特别是随着人工智能的发展，可以使用人工智能对您的想法进行“橡皮鸭调试”，而不是依赖完美的协调和共识，从而最大限度地降低协调成本。我们还会在内部文档中更新“谁是谁”列表，如果您觉得需要联系任何人，请直接联系。这需要很大程度的信任。
但更重要的是，有了人工智能，你就不必经常联系人类了。有时在问别人要问的问题之前，你可以先花一分钟时间让人工智能降低协调成本，让每个人都有一个合理的起点，自己去做。
5.您计划的详细程度是怎样的？这些年来计划是如何发展的？
Perplexity 成立还不到两年，但人工智能领域的变化如此之快，很难做出超出预期的承诺。我们制定季度计划。在季度内，我们试图在产品路线图中保持计划的稳定。路线图中有一些大家都知道的大型项目，还有一些随着优先级变化而调整的小任务。保持敏捷至关重要，因为人工智能的发展往往会产生不可预见的影响。例如，开源模型和上下文长度的快速发展对产品、路线图和整体业务产生了下游影响。就在最近，Meta 发布了 Llama 3，Mistral 发布了 8x22B；我们正在研究在我们的产品中使用这些模型的创造性方法。
产品路线图中的项目也需要具有灵活性，因为新产品开发与技术/模型开发路线图同时进行。工程师会根据具体情况在维护现有产品和开发新产品之间切换。随着我们遇到现有系统的局限性并积累技术债务，技术路线图往往会快速增长，但我们会尝试优先考虑解锁产品改进的技术债务。
不过，在一周内，计划是相当稳定的。每周我们都会召开启动会议，每个人都会为本周设定高水平的期望。我们有一种设定 75% 周目标的文化：每个人都确定本周的首要任务，并努力在周末之前完成其中的 75%。只需列出几个要点，确保本周的优先事项明确。
在一周之初花点时间思考一下元任务，可以让我们理清思路，避免过度反应或忙乱的决策。随着时间的推移，我们根据投资回报估算规模和确定优先级的能力也得到了提高。
6.您是否以某种形式使用 OKR？
我们尽量在季度规划中做到严谨和以数据为导向。所有目标都是可衡量的，无论是以可量化的阈值还是布尔值“X 是否完成”来衡量。我们的目标非常激进，而且通常到季度末我们只能完成某个方向的 70%。剩下的 30% 有助于确定优先级和人员配置方面的差距。例如，当基础设施目标未实现时，在聘请基础设施工程师方面的投资不足很快就会显现出来。
7.你们的产品/设计评审会议是如何进行的？
在确定了核心目标和高层设计之后，我们尽量将决策分散化。项目由一个 DRI 驱动，执行步骤尽可能并行进行。
任何项目的第一步都是将其尽可能分解为并行任务，以减少协调问题。我们以线性方式进行这项工作，我与团队中的 PM（或负责 PM 职责的任何人）一起领导这项工作。我们努力使每项任务都独立自主 — 您应该能够毫无阻碍地执行它。而且您可能不得不做出一些有争议的决定，但您可以稍后解决争议。
每个项目开始时，都会有一个快速启动以进行协调，之后，迭代以异步方式进行，没有限制或审核流程。当个人觉得准备好就设计、实施或最终产品提出反馈时，他们会在 Slack 中分享，团队的其他成员会给出诚实和建设性的反馈。迭代会根据需要自然发生，产品只有在通过内部测试获得关注后才会发布。
我鼓励人们尽可能多地同时工作。他们不应该等待所有人来解除他们的阻碍。理想情况下，设计、前端和后端都在同一项目上同时工作。现在我们有了一个业务团队，所有四个人都可以同时工作，而传统上你可能要等到设计或模型先出现。
8.报告线路如何运作？
目前，团队按职能（产品、研发、设计、业务等）划分，不同的团队负责公司和堆栈的不同层面。但所有精力都集中在改进核心产品上。我们设计的目标可以转化为通用的顶级指标，并全面改善用户体验。例如，所有团队在堆栈的各自层面进行 A/B 测试时都共享通用的顶级指标。由于产品变化如此之快，我们希望避免将任何人的身份与产品的任何特定组件绑定在一起的政治问题。
就我们目前的规模而言，我们设计为扁平化，报告结构不会决定优先事项，而是决定对顶级目标的承诺。我们的两位全职 PM（一位是Web产品经理，另一位是移动产品经理）向我这个产品负责人汇报。我们发现，当团队没有 PM 时，团队成员会承担 PM 的职责，例如调整范围、做出面向用户的决策以及相信自己的品味。
9.您打造了最受欢迎、最成功的产品之一。您认为您的产品方法有何独特之处或核心之处，使它如此成功？
我们方法的核心是收集来自用户和内部的反馈，并将其提炼成一些可以供许多客户使用的直观产品。我们还尝试以一种激励和启发团队的方式来提炼反馈，设定一个广阔的愿景，但让每个人控制自己的决定，决定什么最能实现最初的目标。我们的分散决策方法传递了责任的火炬，实现了快速迭代，而无需审批流程。个人做出紧急的、局部最优的决策。任何不一致之处都会很快得到解决。
10. 您用于任务管理和bug跟踪的主要工具是什么?
Linear。对于 AI 产品来说，任务、错误和项目之间的界限变得模糊，但我们发现 Linear 中的许多概念（如线索、分类、规模等）都非常重要。我最喜欢的一个功能是自动存档——如果某项任务有一段时间没有被提及，那么很可能它实际上并不重要。
我们用于存储路线图和里程碑规划等事实来源的主要工具是 Notion。我们在开发过程中使用 Notion 来编写设计文档和 RFC，之后则用于文档、事后分析和历史记录。将想法写在纸上（记录思路链）可以做出更清晰的决策，并更容易协调异步并避免开会。
Unwrap.ai 是我们最近推出的一款工具，用于整合、记录和量化定性反馈。由于人工智能的性质，许多问题并不总是足够确定，无法归类为错误。Unwrap 将各个反馈分为更具体的主题和改进领域。
11.您认为路线图想法主要自上而下（团队被告知要构建什么）还是自下而上（团队通常提出想法）？
高层目标和方向自上而下，但大量新想法自下而上。我们坚信工程和设计应该对想法和细节拥有所有权，尤其是对于 AI 产品而言，在想法转化为代码和模型之前，约束条件是未知的。我们一直在进行大量的头脑风暴。我们在 Slack 中有一个专门的头脑风暴频道，后续想法收集在 Linear 中，而且通常无需任何人询问，就可以直接将完善的内容转化为代码。
Perplexity 的发现、收集和分享体验是自下而上理念的最佳范例。例如，正如我上面分享的那样，我们的品牌设计师 Phi 构建了 Discover Daily 播客，并同时围绕脚本、ElevenLabs 集成、品牌和音频工程做出决策。使用 AI，在产品迭代发布之前无法预测用例。一年前，我们从未预测到 Discover 体验最终会被融入播客中。
12.当人们从外部看待像您这样的公司时，一切都看起来很完美，好像您已经把一切都安排好了。有哪些事情进展不顺利或面临巨大挑战？
如今我们面临的最大挑战是如何从目前的规模扩大到下一个级别，无论是在招聘方面，还是在执行和规划方面。我们不想失去在扁平化和协作环境中工作的核心身份。即使是像如何组织 Slack 和 Linear 这样的小决定，也很难扩展。我们目前正在努力保持透明度，并在不导致通知激增的情况下扩大渠道和项目的数量。
13.产品团队或公司有哪些有趣/独特的仪式或传统？
Perplexity 的许多功能和产品都是在为期一周（或更短）的黑客马拉松期间开发的。专注于开发新功能的冲刺已被证明是最令人兴奋和难忘的时刻。我们的第一个交互式搜索原型 Pro Search（以前称为 Copilot）是在几天内开发的，但它经过多次迭代和微调后得到了改进。
原文链接：https://www.lennysnewsletter.com/p/how-perplexity-builds-product
