Press "Enter" to skip to content

Perplexity 如何构建 AI 产品开发新模式

成立不到两年的 Perplexity 已成为我每天使用多次的产品,取代了我许多的谷歌搜索,而我并非孤例。公司不到50名员工,用户基数已增长到数千万。他们的年收入超过2000万美元,正在与谷歌和 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 如何构建产品——对我来说,这感觉就像许多公司未来产品开发的样子:

  1. 以 AI 为先导: 他们在公司建设过程的每个步骤都在向 AI 提问,包括“如何推出产品?”员工被鼓励在打扰同事之前先向 AI 提问。
  2. 像粘菌一样有组织: 他们优化以最小化协调成本,通过尽可能并行化每个项目。
  3. 小团队: 他们典型的团队是两到三人。他们的人工智能生成的(评价很高)播客是由一个人构建和运行的。
  4. 少管理者: 他们雇佣自我驱动的个体贡献者,并积极避免雇佣最擅长指导他人工作的人。
  5. 对未来的预测: Johnny 表示:“如果我要猜测,技术产品经理或具有产品品味的工程师将随着时间的推移成为公司中最有价值的人。”
从左至右:Johnny Ho、Aravind Srinivas和Denis Yarats,Perplexity的联合创始人

1、您如何在 Perplexity 内部使用 AI 工具来构建 Perplexity?

老实说,一开始我们并不知道如何做各种事情,包括产品管理、项目管理、财务、人力资源等。我们早期就获得了对 GPT-3 的使用权限,当我们摸索如何建立公司时,我们会通过询问 AI 开始所有事情,“X是什么?”然后“我们如何正确地做X?”例如,我们会问诸如“如何推出一个产品?推出过程中应该有哪些步骤?”之类的问题。您会得到一个大致的逐步过程,对于初创公司来说已经足够好了。显然,第一次往往不正确,但人类也一样,对吧?所以我们就从那里自然地进行迭代。

图片

靠自己摸索需要花费数天,但借助 AI 和一些提示,我们可以在五分钟内开始进行。

我们仍在继续这样做。例如,本周我问 Perplexity,“如何撰写一封邀请某人加入 Perplexity Pro 的电子邮件?”

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

2、你们有多少产品经理?

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

我们的两名产品经理

我们通常参与的项目只有一两个人。最困难的项目最多有三到四个人。例如,我们的播客由一个人从头到尾构建。他是品牌设计师,但他也做音频工程,他正在进行各种研究,以找出如何构建最具互动性和趣味性的播客。我认为产品经理在这个过程中从未介入。

图片

我们在面临一个真正困难的决策,分支到许多方向,并且对更复杂的项目时,会更多地利用产品管理。产品经理工作中最困难、也是最重要的部分是在使用案例周围具备品味。在 AI 领域,可能有太多潜在的使用案例可以进行工作。因此,产品经理必须介入,并基于数据、用户研究等进行分支定性决策。例如,AI 面临的一个重大问题是如何在更多基于生产力的使用案例和吸引人的聊天机器人类型使用案例之间进行优先排序。我们很早就决定专注于前者,但仍在进行持续讨论。

我们计划在未来一年内雇佣一到两名产品经理,但招聘标准将保持非常高。

3、我猜想你们的成功很大程度上归功于良好的招聘和保持高标准。您在招聘时最看重什么(可能是其他人不看重的)?

考虑到我们的工作节奏,我们首先寻找的是灵活性和主动性。在资源有限的环境中建设性地构建(可能需要扮演多重角色)对我们来说最为重要。

当你查看产品经理的简历时,很多人都优先考虑帮助他人和寻找共识。我认为随着 AI 的出现,这些变得不那么重要了。因此,你不一定需要像管理流程或领导团队那样的技能。我们寻找对用户产生明显量化影响而不仅限于公司内部的强大个人贡献者。如果简历中出现“敏捷专家”或“Scrum大师”,可能不太适合。

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

我们仍然注重文化匹配和易于合作,但我们更少寻找引导他人努力的人,因为在 AI 领域这并不那么必要。随着我们达到一定规模,这种情况可能会改变,但在当前规模下,需要开发的产品远远多于可以投入其中的人员。

我认为未来,整个行业中管理层级将减少。如果我要猜测,技术型产品经理或具有产品品味的工程师将随着时间的推移成为公司中最有价值的人才。

4、你们的团队是围绕产品、用户类型、用户旅程、结果还是介于两者之间进行组织的?这些年来有什么变化吗?

我的目标是围绕最小化“协调阻力”来构建团队,正如Alex Komoroske这篇关于将组织视为粘菌的演示文稿中所描述的。大致想法是,协调成本(由不确定性和分歧引起)随着规模增加而增加,增加管理者并不能改善情况。人们的激励变得不协调。人们倾向于向他们的经理撒谎,而经理则向他们的经理撒谎。如果你想与组织中的其他人交谈,你必须向上两级再向下两级,一路询问每个人。

相反,你要做的是保持整体目标的一致,并通过共享可重复使用的指南和流程来并行指向这一目标的项目。特别是随着 AI 的进步,通过使用 AI 进行“橡皮鸭调试”你的想法,可以最大程度地减少协调成本,而不是依赖于完美的一致和共识。我们还在内部文档中更新“who’s who”列表,如果你觉得有必要联系任何人,就去做吧。这需要相当程度的信任。

但更重要的是,有了 AI,你不必那么经常联系他人。有时,在向别人提问之前,你可以先尝试花一分钟询问 AI,以减少协调成本,并为每个人提供一个合理的起点来自行解决问题。

5、你们的详细计划有多远?这些年来有什么变化?

Perplexity 成立不到两年,AI 领域变化迅速,很难做出长期承诺。我们制定季度计划。在季度内,我们努力保持产品路线图的稳定。路线图中有几个大型项目,每个人都知晓,还有一些小任务,随着优先级的变化而调整。灵活应对至关重要,因为 AI 领域的发展往往具有不可预见的影响。例如,开源模型和上下文长度的快速发展对产品、路线图和整体业务产生了影响。就在最近,Meta 发布了 Llama 3,Mistral 发布了 8x22B;我们正在探索如何在产品中创造性地应用这些模型。

产品路线图中的项目也需要灵活,因为新产品开发与技术/模型开发路线图是并行进行的。工程师根据每周的情况在维护现有产品和开发新产品之间切换。技术路线图往往会迅速增长,因为我们遇到现有系统的限制并积累技术债务,但我们努力优先处理能带来产品改进的技术债务。

然而,在给定的一周内,计划是相当稳定的。每周我们都会举行启动会议,每个人都会设定本周的高层期望。我们有一个设定75%周目标的文化:每个人确定本周的首要任务,并努力在周末前完成其中的75%。只需几个要点,确保本周的重点清晰。

在周初花点时间反思元任务,可以带来清晰度,避免过度反应或忙乱的决策。随着时间的推移,我们估算规模和基于投资回报优先级的能力也得到了提高。

6、你们是否以某种形式使用 OKR?

我们在季度计划中尽可能严谨和数据驱动。所有目标都是可衡量的,要么是以可量化的阈值,要么是布尔值“X是否完成”。我们的目标非常激进,通常在季末我们只能完成70%左右。剩下的30%有助于识别优先级和人员配置上的差距。例如,如果在招聘基础设施工程师方面投入不足,当基础设施目标未能实现时,问题很快就会显现。

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

确定中心目标和高层设计后,我们在决策上尽量分散。项目由单一负责人推动,执行步骤尽可能并行进行。

任何项目的第一步都是尽可能将其拆分为并行任务,以减少协调问题。我们在 Linear 中这样做,我与团队的项目经理(或者负责项目经理职责的人)一起领导这项工作。我们努力让每个任务都是自包含的——你应该能够在没有阻碍的情况下执行它。你可能需要做出一些有争议的决定,但可以稍后解决争议。

在每个项目开始时,会有一个快速的启动会议以确保一致性,之后,迭代以异步方式进行,没有约束或审查流程。当个人准备好接受关于设计、实施或最终产品的反馈时,他们会在 Slack 中分享,团队其他成员会给出诚实和建设性的反馈。迭代会根据需要自然发生,产品在通过内部使用获得内部动力之前不会推出。

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

8、汇报线是如何运作的?

团队目前按功能(产品、研发、设计、业务等)进行组织,不同团队考虑公司和技术堆栈的不同层面。但所有精力都致力于改进核心产品。我们设计的目标转化为共同的顶层指标,并全面提升用户体验。例如,所有团队在技术堆栈的各层进行A/B测试时共享共同的顶层指标。由于产品变化如此迅速,我们希望避免任何人的身份与产品的任何组件绑定的政治问题。

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

9、你们打造了最受欢迎和最成功的产品之一。您认为是什么独特或核心的产品方法导致了这样的成功?

我们方法的核心是接受来自用户和内部的反馈,并将其提炼成几款直观的产品,适用于许多客户。我们还尝试以一种激励和启发团队的方式提炼反馈,设定一个广泛的愿景,但让个人自行决定如何最好地服务最初的目标。我们的去中心化决策方法传递了责任的火炬,实现了快节奏的迭代,无需批准流程。个人做出紧急的、局部最优的决策。任何不一致之处随后会迅速解决。

10、你们的主要任务管理和错误跟踪工具是什么?

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

我们用来存储路线图和里程碑规划等真实信息的主要工具是 Notion。我们在开发过程中使用 Notion 来进行设计文档和 RFC,之后用于文档、事后分析和历史记录。把想法记录下来(记录思维链)有助于更清晰地做决策,使异步对齐更容易,避免开会。

Unwrap.ai 是我们最近引入的工具,用于整合、记录和量化定性反馈。由于人工智能的性质,许多问题并不总是足够确定以分类为错误。Unwrap 将个别反馈整合成更具体的主题和改进领域。

11、您认为路线图的想法主要是自上而下(团队被告知要构建什么)还是自下而上(团队通常提出想法)?

高层目标和方向自上而下确定,但大量新想法是自下而上提出的。我们坚信工程和设计应该对想法和细节负责,特别是对于一个人工智能产品,直到想法转化为代码和模型之后才知道约束条件。我们随时进行大量头脑风暴。我们在 Slack 中有一个专门的头脑风暴频道,跟进的想法在 Linear 中收集,而且经常进行的润色直接转化为代码,无需他人要求。

自下而上想法的最佳例子可以在 Perplexity 的发现、收集和分享体验中看到。例如,正如我之前分享的,我们的品牌设计师Phi创建了Discover Daily podcast,同时在脚本、ElevenLabs集成、品牌和音频工程方面做出决策。对于人工智能来说,直到产品的迭代发布,才能预测使用案例。一年前,我们绝对无法预测 Discover 体验最终会发展成一个播客。

12、当人们从外部看到像你们这样的公司时,一切看起来都很完美,就像你们已经搞定了一切。有哪些事情进展不顺利或遇到了重大挑战?

今天面临的主要挑战是从当前规模扩展到下一个水平,无论是在招聘方面还是在执行和规划方面。我们不想失去在一个非常扁平和协作的环境中工作的核心身份。即使是小决策,比如如何组织 Slack 和Linear,也可能难以扩展。我们目前正努力保持透明,并尝试扩展频道和项目数量,而不会导致通知爆炸。

13、你们在产品团队或公司中有哪些有趣/独特的仪式或传统?

在 Perplexity,许多功能和产品都是在一周(或更短)的黑客马拉松中构建的。专注于构建新功能的冲刺被证明是最激动人心和难忘的时刻。我们的第一个交互式搜索原型 Pro Search(前身为 Copilot)是在几天内构建的,但经过多次润色和微调的迭代后得到改进。

内容由GeekAI网页翻译服务自动翻译完成。
原文地址:https://www.lennysnewsletter.com/p/how-perplexity-builds-product

发表回复