5 min read
译文：如何像 Perplexity 一样打造产品
在AI时代，已经涌现出许多传奇人物和公司。例如，只有两名员工的Magnific AI，以及今天的主角，Perplexity。在“套壳”的争议声中，Perplexity凭借不到50名员工，在短短两年内达到了10亿美元的估值，这不禁让人对其背后的产品思考充满好奇。今天，我们将跳出设计师的视角，从产品、运营和商业的角度，深入探讨这家传奇公司。
Perplexity 成立于不到两年前，现已成为我每天使用多次的产品，取代了我许多 Google 搜索——而且我并不是唯一一个。这家公司拥有不到 50 名员工，但用户群已增长到数千万。他们还创造了超过 2000 万美元的年度经常性收入 (ARR)，并在搜索引擎的未来之战中挑战着 Google 和 OpenAI。他们 最近筹集了 6300 万美元，公司估值超过 10 亿美元，投资者包括英伟达、杰夫·贝佐斯、Andrej Karpathy、Garry Tan、Dylan Field、Elad Gil、Nat Friedman、Daniel Gross 和 Naval Ravikant（但遗憾的是没有我 😭）。英伟达首席执行官黄仁勋表示，他 “几乎每天” 都在使用这款产品。
我与该公司联合创始人兼产品负责人 Johnny Ho 进行了交流，为你深入了解 Perplexity 如何打造产品——在我看来，这感觉就像许多公司未来产品开发的样子：
译者：这里敲重点啦~AI时代，对于公司组织和人才的标准，值得参考👍。
- 以人工智能为先： 他们一直在向人工智能询问有关公司建设过程每一步的问题，包括“我如何推出产品？” 鼓励员工在打扰同事之前先咨询人工智能。
- 像黏菌一样组织： 他们通过尽可能并行化每个项目的各个部分来优化并最大程度地降低协调成本。
- 小团队： 他们的典型团队由两到三人组成。他们由人工智能生成（并获得高度评价）的 播客 仅由一人构建和运营。
- 少管理者： 他们聘用自主驱动的个人贡献者，并积极避免聘用那些最擅长指导他人工作的人。
- 对未来的预测： Johnny 说：“如果让我猜，随着时间的推移，技术型产品经理或具有产品品味的工程师将成为公司中最有价值的人。”
如需了解更多信息，请查看 Perplexity。而且 他们正在招聘！如需了解更多关于最佳产品团队如何运作的故事，请不要错过我对 Linear、Shopify、Figma、Notion、Duolingo、Ramp、Miro、Coda、Gong 和 Snowflake 的深度分析。
附：我正在与 Perplexity 合作，深入研究产品经理如何使用 Perplexity，我们很想听听你的意见。如果你经常使用 Perplexity，请填写 这份简短的调查，他们会联系你进行用户访谈。
从左至右：Perplexity 联合创始人 Johnny Ho、Aravind Srinivas 和 Denis Yarats
坦白说，一开始我们不知道如何做各种事情，包括产品管理、项目 管理、财务、人力资源等等。我们很早就接触到了 GPT-3，在我们摸索如何创建公司的过程中，我们从询问人工智能开始，“什么是 X？” 然后是“我们如何正确地做 X？” 例如，我们会问“如何推出产品？产品发布过程应该有哪些步骤？” 你会得到一个粗略的步骤流程，对于一家初创公司来说，这已经足够好了。显然，它在第一次尝试时通常不会是正确的，但人类也是如此，对吧？所以我们只会在此基础上自然而然地进行迭代。
自己摸索需要几天时间，但借助人工智能和一些提示，我们可以在五分钟内开始行动。
我们仍在这样做。例如，本周我问 Perplexity，“我该如何写一封电子邮件邀请某人加入 Perplexity Pro？”
我们甚至尝试过用它来构建产品，但我们发现人工智能工具在编码方面还远远不够好。它可以帮助我们编写脚本，但如果你想要可持续的代码来构建平台，它就无法真正发挥作用。即使在今天，随着技术的进步和最新模型的出现，它仍然只能编写模板。你无法真正用它来设计一个新的、长期存在的抽象概念。
在一个 50 人的组织中，我们只有两名全职产品经理。
我们的两位产品经理
我们参与的典型项目只有一两个人。最难的项目也只有三到四个人。例如，我们的播客 从头到尾都由一个人制作。他是一名品牌设计师，但他同时也做音频工程，并且正在进行各种研究，以确定如何制作出最具互动性和趣味性的播客。我认为在整个过程中，没有产品经理参与过。
只有当遇到一个非常困难的决定，需要从多个方向进行分支，以及在更复杂的项目中，我们才会最大限度地利用产品管理。
产品经理工作中最难也是最重要的部分是对用例的品味。对于人工智能来说，你可以处理的用例太多了。因此，产品经理必须介入，根据数据、用户研究等做出定性的分支决策。例如，人工智能面临的一个大问题是如何在更注重效率的用例与更具吸引力的聊天机器人型用例之间进行优先级排序。很早的时候，我们就决定专注于前者，但目前仍在进行讨论。
我们计划在明年再招聘一到两名产品经理，但招聘门槛将 tetap 非常高。
鉴于我们目前的工作节奏，我们最看重的是灵活性和主动性。在资源有限的环境中（可能需要身兼数职）进行建设性工作的能力对我们来说是最重要的。
当你查看产品经理的简历时，你会发现，他们中的很多人都会优先考虑帮助他人和达成一致。我认为，随着人工智能的出现，这一点变得不那么重要了。因此，你不需要像以前那样，过多地具备流程管理或人员领导方面的技能。我们寻找的是对用户有明确量化影响的个人贡献者，而不是在公司内部有影响力的人。如果我在简历中看到“敏捷专家”或“Scrum 大师”这样的字眼，那可能就不太合适了。
此外，人工智能可以让产品经理做_更多_ 的个人贡献工作，尤其是在数据分析和客户洞察方面。当然，你仍然需要一些基础知识（即数学、统计学、编程基础知识），但成为一名真正的“技术型”产品经理从未像现在这样容易。
我们仍然会选择文化契合度高且容易共事的人，但我们不太会寻找那些指导他人工作的人，因为这对人工智能来说已经没有必要了。随着我们规模的扩大，这种情况可能会发生变化，但在目前的规模下，需要构建的产品远远多于可以参与的人。
我认为，在未来，我预计整个行业管理层级会减少。如果让我猜，随着时间的推移，技术型产品经理或具有产品品味的工程师将成为公司中最有价值的人。
我的目标是围绕最小化“协调阻力”来构建团队，正如 Alex Komoroske 在 这份关于将组织视为黏菌的演示文稿 中所描述的那样。大致的意思是，协调成本（由不确定性和分歧造成）会随着规模的扩大而增加，而增加管理者并不能改善这种情况。人们的动机变得不一致。人们倾向于对他们的经理撒谎，而经理又对_他们的_ 经理撒谎。如果你想和另一个部门的人交谈，你必须向上两级，然后向下两级，一路询问每个人。
相反，你要做的是保持总体目标一致，并通过共享可重复使用的指南和流程，将指向该目标的项目并行化。尤其是在人工智能的推动下，可以通过使用人工智能对你的想法进行“橡皮鸭调试”，而不是依赖完美的一致和共识，从而最大程度地降低协调成本。我们还会在内部文档中更新“谁是谁”列表，如果你觉得需要联系任何人，直接联系即可。这需要高度的信任。
但更重要的是，有了人工智能，你就不必像以前那样频繁地联系他人了。有时，在你向别人提出问题之前，你可以先试着用一分钟的时间问问人工智能，以减少协调成本，并为每个人提供一个合理的起点，让他们自己去解决问题。
Perplexity 成立还不到两年，人工智能领域的发展日新月异，很难做出更长远的承诺。我们会制定季度计划。在一个季度内，我们会尽量在产品路线图中保持计划的稳定性。路线图中有一些每个人都知道的大项目，还有一些我们会根据优先级的变化而调整的小任务。由于人工智能的发展往往会产生不可预见的影响，因此保持敏捷至关重要。例如，开源模型和上下文长度的快速发展对产品、路线图和整体业务都产生了下游影响。就在最近，Meta 发布了 Llama 3，Mistral 发布了 8x22B；我们正在探索在产品中使用这些模型的创造性方法。
产品路线图中的项目也需要保持灵活性，因为新产品的开发与技术/模型开发路线图是并行进行的。工程师们会在维护现有产品和构建新产品之间转换，具体取决于每周的情况。随着我们遇到现有系统的局限性并积累技术债务，技术路线图往往会迅速增长，但我们会尝试优先考虑能够解锁产品改进的技术债务。
不过，在给定的一周内，计划相当稳定。每周我们都会召开一次启动会议，每个人都会在会上设定自己本周的高级别预期。我们有一种设定 75% 周目标的文化：每个人都要确定自己本周的首要任务，并努力在本周末之前完成 75%。只需要几个要点，就能确保一周内的优先事项清晰明了。
在每周开始时花点时间反思元任务，可以让你思路清晰，避免过度反应或做出慌乱的决策。随着时间的推移，我们估计规模和根据投资回报率确定优先级的能力也有所提高。
在季度计划中，我们力求做到严谨和数据驱动。所有目标都是可衡量的，要么以可量化的阈值为准，要么以布尔值“X 是否完成”为准。我们的目标非常激进，通常在一个季度结束时，我们只会在一个方向上完成 70%。剩下的 30% 有助于识别优先级和人员配备方面的差距。例如，当基础设施目标无法实现时，基础设施工程师招聘方面的投资不足就会很快显现出来。
在确定了中心目标和高级设计之后，我们会尽量在决策过程中进行分权。项目由一名直接责任人 (DRI) 负责，执行步骤尽可能并行进行。
任何项目的第一步都是将其尽可能分解成并行任务，以减少协调问题。我们使用 Linear 来完成这项工作，由我和团队中的产品经理（或任何负责产品经理职责的人）共同领导。我们力求每个任务都是独立的——你应该能够在不受阻碍的情况下执行任务。你可能需要做出一些有争议的决定，但你可以稍后再解决这些争议。
在每个项目的开始阶段，都会进行一次快速的启动会议以达成一致，之后，迭代将以异步的方式进行，不受约束或审查流程的限制。当个人认为已准备好就设计、实施或最终产品征求反馈意见时，他们会在 Slack 上分享，团队中的其他成员会给出诚实和建设性的反馈意见。迭代会根据需要自然而然地进行，只有当产品通过内部试用获得认可后才会发布。
我鼓励人们尽量并行工作。他们不应该等待每个人都为他们扫清障碍。理想情况下，设计、前端和后端应该同时进行同一个项目。现在我们有了一个业务团队，这四个人可以并行工作，而在传统模式下，你可能要先等待设计稿或模型出现。
团队目前按职能划分（产品、研发、设计、业务等），不同的团队考虑公司和堆栈的不同层次。但所有的精力都集中在改进核心产品上。我们设计的目标可以转化为通用的顶级指标，并全面提升用户体验。例如，所有团队都共享通用的顶级指标，同时在其堆栈层内进行 A/B 测试。由于产品可能会发生快速变化，因此我们要避免出现任何人的身份与产品的任何特定组件绑定在一起的政治问题。
在我们目前的规模下，我们有意保持扁平化，报告结构并不像对顶级目标的承诺那样决定优先级。我们的两名全职产品经理（一名负责网络，一名负责移动设备）向我（产品负责人）汇报工作。我们发现，当团队中没有产品经理时，团队成员会承担起产品经理的职责，比如调整范围、做出面向用户的决策以及相信自己的品味。
我们方法的核心是收集用户和内部的反馈，并将其提炼成几个直观的产品，这些产品可以适用于许多客户。我们还尝试以一种激励和告知团队的方式提炼反馈，设定一个宏伟的目标，但让个人控制他们自己关于什么最能服务于最初目标的决定。我们分散化的决策方法传递了责任，使快速迭代成为可能，而不需要审批流程。个人做出紧急的、局部最优的决定。任何不一致之处都会在事后迅速得到解决。
Linear。对于人工智能产品来说，任务、错误和项目之间的界限变得模糊，但我们发现 Linear 中的许多概念，比如 Leads、Triage、Sizing 等，都非常重要。我最喜欢的一个功能是自动归档——如果一个任务已经有一段时间没有被提及了，那么它很可能并不重要。
我们用来存储路线图和里程碑计划等真相来源的主要工具是 Notion。我们在开发过程中使用 Notion 来编写设计文档和 RFC，并在开发结束后使用它来编写文档、事后分析和历史记录。将想法写在纸上（记录思维链）可以使决策更加清晰，并且更容易异步协调和避免会议。
Unwrap.ai 是我们最近引入的一个工具，用于整合、记录和量化定性反馈。由于人工智能的性质，许多问题并不总是具有确定性，不足以归类为错误。Unwrap 将各个反馈意见归纳成更具体的主题和需要改进的领域。
高级目标和方向是自上而下的，但大量的新想法是自下而上的。我们坚信，工程和设计应该对想法和细节拥有所有权，尤其是对于人工智能产品而言，因为在想法变成代码和模型之前，约束是未知的。我们一直在进行大量的头脑风暴。我们在 Slack 上有一个专门的头脑风暴频道，后续想法会收集到 Linear 中，而且通常情况下，经过润色的想法会直接进入代码编写阶段，而无需任何人过问。
Perplexity 的发现、收集和分享体验是自下而上想法的最佳例证。例如，正如我上面分享的那样，我们的品牌设计师 Phi 制作了 Discover Daily 播客，同时还负责剧本、ElevenLabs 集成、品牌和音频工程方面的决策。对于人工智能来说，在产品迭代发布之前，不可能预测用例。一年前，我们绝对不会想到，发现体验最终会以播客的形式呈现出来。
今天面临的重大挑战是如何从目前的规模扩展到下一个级别，包括招聘方面以及执行和计划方面。我们不想失去在非常扁平化和协作的环境中工作的核心身份。即使是很小的决定，比如如何组织 Slack 和 Linear，也可能难以扩展。在不造成通知爆炸的情况下，努力保持透明度并扩展频道和项目的数量，是我们目前正在努力解决的问题。
Perplexity 的许多功能和产品都是在为期一周（或更短时间）的黑客马拉松中开发出来的。事实证明，专注于构建新功能的冲刺是最令人兴奋和难忘的时刻。我们的第一个交互式搜索原型 Pro Search（以前称为 Copilot）是在几天内构建出来的，但它在经过多次迭代的改进和微调后才得以完善。
本文翻译自：https://www.lennysnewsletter.com/p/how-perplexity-builds-product
今天的分享就到这里，有什么疑问或者问题，可以留言交流哦~ 关注我公众号（设计小站）：sjxz00，获取更多AI辅助设计和设计灵感趋势。