本文来自于莱尼时事通讯的的一次对于国外红透半边天的AI独角兽perplexity创始人的采访内容的英文翻译。主旨内容在于探讨perplexity这样的一家AI驱动的创业公司在构建产品时如何真正将AI纳入生产关系。
为了方便阅读，我们尽量遵循原作者撰文中的第一人称阐述视角。同时为了保障中文环境的阅读顺畅，我们基于AI翻译工具做了一些转译。
1.如何使用 Perplexity 中的 AI 工具来构建 Perplexity？
老实说，一开始，我们不知道如何做各种事情，包括产品管理、项目管理、财务、人力资源等。我们很早就接触到了GPT-3，当我们在想如何做的时候，建立公司时，我们会通过询问 AI“X 是什么？”来开始一切。然后“我们如何正确地做某事？”例如，我们提出了诸如“您如何推出产品？启动过程应该采取哪些步骤？”你会得到一个粗略的逐步过程，这对于初创公司来说已经足够好了。显然，第一次尝试通常是不正确的，但人类也不是，对吧？所以我们就从那里自然地迭代。
尝试自己解决问题需要几天的时间，但有了人工智能和一些提示，我们可以在五分钟内开始工作。我们我们一直坚持这样的方式。例如在本周，我问 Perplexity：“我如何写一封邀请某人使用 Perplexity Pro 的电子邮件？”
我们甚至有时尝试使用它来构建我们的产品，但我们发现人工智能工具在编码方面还不够好。它可以帮助我们编写脚本，但如果你想要可持续的代码来构建平台，它依旧无法真正意义上投入使用。即使在今天，随着技术的进步和最新的模型，它仍然只能编写模板化内容。你无法真正用它设计一个新的、长期存在的抽象工程。
2.在Perplexity团队中，一共有多少位PM？
在我们 50 名员工的组织中，只有两名全职产品经理。
我们从事的传统产品经理的典型项目只有一两个人。最困难的项目最多需要三到四个人。例如，我们的官方播客是由一个人端到端构建的。他本身是一名品牌设计师，但他可以从事音频工程，并且正在进行各种研究，以找出如何构建最具互动性和最有趣的播客。我认为我们的PM在任何时候、甚至可以说从头到尾都没有介入过这个过程。
当有一个非常困难的决策，涉及多个方向，并且对于涉及更多的项目时，我们最充分地利用产品管理。
PM 工作中最困难也是最重要的部分是对用例进行品味（自我判断）。借助人工智能，您可以处理太多可能的用例。因此，PM 必须介入并根据数据、用户研究等做出分支定性决策。例如，人工智能的一个大问题是如何在基于生产力的用例与引人入胜的聊天机器人类型用例之间进行优先排序。在很早期的时候，我们决定重点关注前者，但直到现在仍在进行讨论（这个问题）。
我们计划在明年再雇佣一到两名产品经理，但招聘的门槛仍然很高。
3.Perplexity的成功很大程度上依赖于优质的招聘和较高的选拔标准，招聘时最看重什么特质？
鉴于我们的工作节奏，我们首先寻求灵活性和主动性。在资源有限的环境中进行建设性建设的能力（可能需要身兼数职）对我们来说是最重要的。
当你查看产品经理的简历时，你会发现很多人都会优先考虑帮助其他人并找到一致性（往期经验的可复用性）。我相信随着人工智能的出现，这一点变得不那么重要了。因此，作为PM您不一定需要那么多管理流程或领导人员的技能。我们寻找对用户（而不是对公司内部）有明显定量影响的强大 IC（原文称为集中电路，这里应该代指高复合型人才）。如果我在简历中看到“敏捷专家”或“Scrum Master”等术语，那么候选人可能不太合适我们。
此外，人工智能还允许产品经理做更多的IC 工作，特别是数据分析和客户洞察。当然，您仍然需要一些基础知识（即数学、统计、编程的基本掌握），但成为真正的“技术”PM 从未如此简单。
我们仍然会选择适合团队文化且易于合作的人，但我们不再寻找喜欢指导与管理他人工作的员工，因为这对于人工智能来说并不那么必要。当我们达到一定规模时，这种情况可能会发生变化，但在目前的规模下，需要构建的产品远多于开发这些产品的人员。
我认为未来，整个行业的管理层级会减少。如果我不得不猜测的话，随着时间的推移，技术 PM 或具有产品品味的工程师将成为公司中最有价值的人员。
4.是否围绕产品、用户类型、用户旅程、结果或介于两者之间的其他因素来构建团队？这些年来这种情况有变化吗？
我的目标是围绕最小化“协调阻力”原则来构建团队，正如Alex Komoroske在关于将组织视为粘菌的演示文稿中所描述的那样——大致的想法是，随着规模的增加，协调成本（由不确定性和分歧引起）也会增加，增加管理者并不能改善这种客观情况。同时人们的激励措施会变得不一致。人们倾向于对他们的经理撒谎，而经理则对他们的上级撒谎。如果你想与组织中另一个部分的人交谈，你必须上升两个层级再下降两个层级，沿途询问所有人。
相反，您想要做的是保持总体目标一致，并通过共享可重用的指南和流程来并行化指向该目标的项目。特别是随着人工智能的进步，通过使用人工智能“橡皮鸭调试”你的想法，而不是依赖完美的一致性和共识，可以最大限度地降低协调成本。我们还在内部文档中更新了“名人录”列表，如果您觉得需要联系任何人，就直接联系即可。当然，这需要彼此有高度的信任。
但更重要的是，有了人工智能，你不必经常与人接触。有时，在问你要问别人的问题之前，你可以先尝试花一分钟要求人工智能降低协调成本，并给每个人一个合理的起点，让他们自己做这件事。
5.Perplexity的详细规划有多远？这些年来进展如何？
Perplexity已经存在了不到两年的时间，而人工智能领域的变化如此之快，以至于很难再做出超出这一范围的承诺。我们制定季度计划。在几个季度内，我们尝试在产品路线图中保持计划稳定。该路线图有一些每个人都知道的大型项目，以及我们随着优先级变化而转移的小任务。灵活性至关重要，因为人工智能的发展往往会产生不可预见的影响。例如，开源模型和上下文长度的快速发展对产品、路线图和整体业务产生了下游影响。就在最近，Meta发布了Llama 3，Mistral发布了8x22B；我们正在寻找在我们的产品中使用这些模型的创造性方法。
产品路线图中的项目也需要灵活，因为新产品开发与技术/模型开发路线图并行运行。工程师根据周的情况在维护现有产品和开发新产品之间切换。当我们遇到现有系统的局限性并积累技术债务时，技术路线图往往会快速增长，但我们会尝试优先考虑能够解锁产品改进的技术债务。
不过，在一周内，计划相当稳定。每周我们都会举行一次启动会议，每个人都会为自己的一周设定高水平的期望。我们有一种设定 75% 每周目标的文化：每个人都确定本周的首要任务，并努力在周末前实现其中的 75%。只需几个要点即可确保本周的优先事项明确。
在本周初花点时间反思元任务可以带来清晰度，并防止过度反应或忙碌的决策。随着时间的推移，我们根据投资回报估算规模和确定优先级的能力也得到了提高。
6.在Perplexity内部是否使用OKR？
我们在季度规划中尽可能做到严格和数据驱动。所有目标都是可衡量的，无论是可量化的阈值还是布尔值“X 是否完成”。我们的目标非常激进，通常在季度末我们只在一个方向或另一个方向完成 70%。剩下的 30% 有助于确定优先级和人员配置方面的差距。例如，当基础设施目标未能实现时，在雇用基础设施工程师方面的投资不足很快就会显现出来。
7.在Perplexity中产品/设计评审会议如何进行？
在确定了中心目标和高层设计之后，我们会尝试在决策过程中实现相当分散的权力。项目由单个 DRI （Directly Responsible Individual-直接责任人）驱动，并且执行步骤尽可能并行完成。
任何项目的第一步都是尽可能将其分解为并行任务，以减少协调问题。我们在 Linear 中完成这项工作，我与团队中的 PM（或任何负责 PM 职责的人）一起领导这项工作。我们努力使每项任务都是独立的——您应该能够在没有障碍的情况下执行它。你可能不得不做出一些有争议的决定，但你可以稍后解决这些争议。
在每个项目开始时，都会快速启动协调，然后以异步方式进行迭代，没有任何限制或审查过程。当个人准备好接受有关设计、实施或最终产品的反馈时，他们会在 Slack 中分享，并且团队的其他成员会提供诚实和建设性的反馈。迭代会根据需要有机地进行，并且产品只有在通过内部测试获得内部吸引力后才会发布。
我鼓励人们尽可能多地尝试并行工作。他们不应该等待每个人都解锁他们。理想情况下，设计、前端和后端都在同一个项目上同时工作。现在我们有了一个业务团队，所有四个人都可以并行工作，而按照惯例，您可能会等待设计或模型首先出现。
8. 汇报关系如何运作？
目前，团队是按职能（产品、研发、设计、业务等）构建的，不同的团队考虑公司和堆栈的不同层面。但所有精力都集中在改进核心产品上。我们设计的目标可转化为通用的顶级指标并全面改善用户体验。例如，所有团队在其堆栈层内进行 A/B 测试时共享通用的顶级指标。由于产品变化如此之快，我们希望避免任何人的身份与产品的任何给定组件绑定的政治问题。
就我们目前的规模而言，我们的设计是扁平化的，报告结构并不像对顶层目标的承诺那样规定优先事项。我们的两名全职产品经理（一名网络产品经理和一名移动产品经理）向我汇报，担任产品主管。我们发现，当团队没有 PM 时，团队成员就会承担 PM 的职责，例如调整范围、做出面向用户的决策以及相信自己的品味。
9.Perplexity打造了最受欢迎、最成功的产品之一。您取得如此成功的独特之处或核心是什么？
我们方法的核心是收集用户和内部的反馈，并将其提炼成一些可以为许多客户服务的直观产品。我们还尝试以一种激励和告知我们团队的方式提炼反馈，设定广阔的愿景，但让个人控制自己的决定，决定什么最能服务于最初的目标。我们的去中心化决策方法传递了责任的火炬，无需审批流程即可实现快节奏的迭代。个人会做出紧急的、局部最优的决策。任何错位都会很快得到解决。
10. 您用于任务管理和错误跟踪的主要工具是什么？
Linear。对于人工智能产品来说，任务、错误和项目之间的界限变得模糊，但我们发现 Linear 中的许多概念非常重要，例如线索、分类、规模调整等。我最喜欢的一个功能是自动存档——如果某项任务有一段时间没有被提及，那么很可能它实际上并不重要。
我们用来存储路线图和里程碑规划等事实来源的主要工具是Notion 。我们在设计文档和 RFC 的开发过程中使用 Notion，然后用于文档、事后分析和历史记录。将想法写在纸上（记录思路链）可以使决策更加清晰，并且可以更轻松地协调异步并避免会议。
Unwrap.ai是我们最近推出的一款工具，用于整合、记录和量化定性反馈。由于人工智能的性质，许多问题并不总是具有足够的确定性来归类为错误。 Unwrap 将各个反馈分组为更具体的主题和改进领域。
11. 产品路线图想法主要是自上而下（团队被告知要构建什么）还是自下而上（团队通常提出想法）？
高层目标和方向是自上而下的，但大量新想法是自下而上提出的。我们坚信，工程和设计应该对想法和细节拥有所有权，特别是对于人工智能产品来说，在想法转化为代码和模型之前，限制是不知道的。大量的头脑风暴一直在进行。我们在 Slack 中有一个专门的头脑风暴频道，在 Linear 中收集后续想法，并且通常无需任何人询问就可以直接编写代码。
自下而上的想法的最佳例子可以在 Perplexity 的发现、收集和共享体验中看到。例如，正如我上面分享的，我们的品牌设计师 Phi 构建了Discover Daily 播客，同时围绕脚本、ElevenLabs 集成、品牌和音频工程做出决策。对于人工智能，在产品迭代发布之前不可能预测用例。一年前，我们绝不会预料到 Discover 体验最终会被内置到播客中。
12. 当人们从外面看到像Perplexity这样的公司时，一切看起来都很完美，就像已经把一切都搞清楚了。有哪些事情进展不顺利或遇到了巨大的挑战？
今天的重大挑战围绕着将我们当前的规模扩大到新的水平，无论是在招聘方面还是在执行和规划方面。我们不想失去在非常扁平和协作的环境中工作的核心特征。即使是很小的决定，比如如何组织 Slack 和 Linear，也可能很难扩展。我们目前正在努力解决的问题是，在不导致通知激增的情况下，尝试保持透明度并扩大渠道和项目的数量。
13.在产品团队或公司有哪些有趣/独特的仪式或传统？
Perplexity 的许多功能和产品都是在为期一周（或更短）的黑客马拉松中构建的。事实证明，集中冲刺来构建新功能是最令人兴奋和难忘的时刻。我们的第一个交互式搜索原型 Pro Search（以前称为 Copilot）在几天内就构建完成，但经过多次打磨和微调，它已经得到了改进。
本文原文链接如下：
