Perplexity 牛逼!50 人团队年入 1.5 亿,这家 AI 独角兽如何在2年内撼动谷歌地位?...

原文链接:https://www.lennysnewsletter.com/p/how-perplexity-builds-product

作者:Lenny Rachitsky

AI 新秀 Perplexity[1] 异军突起,成立仅两年就成为搜索界的 “黑马”。这家仅有 50 人的小公司已吸引数千万用户,年收入突破 2000 万美元,估值更是一举超过 10 亿美元。Perplexity 不仅吸引了英伟达、亚马逊创始人贝索斯等科技大佬投资,还在搜索领域向谷歌和 OpenAI 发起挑战。作为用户,我每天都会多次使用 Perplexity,它已经取代了我的大部分谷歌搜索——显然,我不是唯一一个这样的 “铁粉”。就连英伟达 CEO 黄仁勋都表示他 “几乎每天[2]” 都在用这款产品。Perplexity 最近一轮融资额达 6300 万美元[3],投资者阵容豪华,包括 Andrej Karpathy、Garry Tan、Dylan Field、Elad Gil、Nat Friedman、Daniel Gross 和 Naval Ravikant 等知名人士。可惜的是,我没能成为其中一员——着实令人遗憾啊!

我采访了 Perplexity 公司的联合创始人兼产品负责人 Johnny Ho[4],为大家深入剖析 Perplexity 是如何打造产品的——在我看来,他们的做法很可能预示了许多公司未来产品开发的模式:

  1. 1. AI 优先:从 “如何推出产品” 到公司运营的方方面面,他们事事都先问 AI。公司还鼓励员工遇到问题先找 AI 解答,而不是一直打扰同事。

  2. 2. 仿生组织结构:为了提高效率,他们尽可能地将每个项目的任务并行处理,以最小化协调成本。

  3. 3. 小而精的团队:他们的典型团队由两到三人组成。他们那个广受好评的 AI 生成播客[5],背后居然是由一个人独立开发和运营的。

  4. 4. 扁平化管理:他们偏好招聘自驱力强的独立贡献者,有意识地避免雇佣那些喜欢且擅长指挥他人工作的人才

  5. 5. 未来展望:Johnny 预测说,“如果让我来猜,随着时间推移,懂技术又有产品品味的产品经理或工程师,很可能会成为公司里最炙手可热的人才。”

以下是完整的访谈记录:


4738a190ebaf09a3427b555b71025c2d.jpeg
图中三人从左至右依次为 Johnny Ho、Aravind Srinivas 和 Denis Yarats,他们是 Perplexity 公司的联合创始人

Perplexity 是如何借助 AI 工具来打造自己的产品的?

说实话,我们刚起步时对很多事情都一窍不通,产品管理、项目管理、财务、人力资源,你能想到的我们都不太懂。幸运的是,我们很早就接触到了 GPT-3。在摸索如何创建公司的过程中,我们的第一步就是问 AI:“X 是什么?”,然后再问 “怎样正确地做 X?”。比如,我们会问 “怎么发布一个产品?产品发布流程应该包括哪些步骤?”。AI 会给出一个大致的步骤流程,对于创业公司来说已经够用了。当然,第一次尝试往往不够完美,但人类不也是这样嘛?所以我们就这样摸着石头过河,不断完善

ad2ded4a98e08b60530e6e1f5d350528.jpeg

如果完全靠我们自己摸索,那可能要磨蹭好几天。但有了 AI 的帮助,只需几分钟就能上手干活了。

我们现在还在这么干呢。就在本周,我还问 Perplexity:“怎么写一封邀请别人使用 Perplexity Pro 的邮件?”

我们甚至尝试过用 AI 来构建产品,但发现在编码方面,AI 工具还不够给力。它可以帮我们写一些简单的脚本,但如果你想要可靠的代码来搭建平台,就不太行了。即使到了今天,尽管 AI 模型有了很大进步,它也只能写出一些模板代码。你无法真正用 AI 设计出一个长期存在的新抽象概念。

你们有多少产品经理?

我们公司总共 50 人,只有两名全职产品经理

d7964b2e775cdcb25b0ec538d0137151.jpeg

我们的项目通常只需一到两人参与。即便是最复杂的项目,也最多只需三到四人。举个例子,我们的播客项目[6]是由一位品牌设计师一手包办的。这位同事不仅负责音频工程,还在研究如何打造最具互动性和吸引力的播客,可以说是从策划到制作全程一条龙服务。在整个过程中,产品经理基本上没有插手。

e887727afb56fb1a14355c9a28dc3cd6.jpeg

我们主要在面临复杂决策或处理较为繁琐的项目时,才会充分发挥产品管理的作用。

产品经理最具挑战性且最关键的任务是对使用场景有敏锐的判断力。在人工智能领域,可能的应用场景简直是多如牛毛。因此,产品经理需要挺身而出,根据数据分析和用户研究等因素,做出分支式的定性决策。比如,在人工智能应用中,如何在提高工作效率的应用和有趣的聊天机器人应用之间权衡是一个棘手问题。我们很早就决定主攻前者,但相关讨论仍在继续。

我们计划在来年增加一到两名产品经理,但会继续保持较高的招聘标准。

我猜你们的成功很大程度上得益于出色的人才招聘和严格的选拔标准。那么,在招聘过程中,你们最看重哪些可能被他人忽视的特质呢?

考虑到我们当前的工作节奏,我们首要考虑的是应聘者的灵活性和主动性。在资源有限的环境中,能够建设性地工作,甚至能够一人身兼数职,这对我们来说至关重要。

在查看产品经理简历时,我们发现许多人都强调自己在协助他人和寻求共识方面的能力。然而,我认为随着 AI 的发展,这些能力的重要性已经有所降低。因此,管理流程或领导团队的技能不再是必需的。我们更倾向于寻找能够对用户产生明确量化影响的硬核独立贡献者,而不是那些仅在公司内部有影响力的人。如果简历中出现 “敏捷专家” 或 “Scrum Master” 等词汇,可能就不太符合我们的需求。

此外,AI 使产品经理能够承担更多的个人贡献工作,尤其是在数据分析和客户洞察方面。当然,一些基础知识仍然必不可少,如数学、统计学和基本的编程技能。但是,成为一名真正的 “技术型” 产品经理从未如此容易。

我们仍然重视文化契合度和良好的团队协作能力,但不再过分看重指导他人工作的能力,因为有了 AI,这种需求已经大大减少。随着公司规模的扩大,这种情况可能会有所改变,但就目前而言,需要开发的产品数量远远超过了可用的 “打工人”。

我预计,未来整个行业的管理层级可能会减少。如果要我做出预测的话,我认为具备技术背景的产品经理或具有产品品味的工程师,将随着时间的推移成为公司最炙手可热的人才。

贵公司是怎么组建团队的?按产品、用户群、用户体验还是目标效果?或者是综合考虑这些因素?这些年来有变化吗?

我的目标是围绕最小化 “协调阻力” (coordination headwind) 来构建团队,这一概念源自 Alex Komoroske[7] 将组织比作粘菌的理论[8]。其核心思想是,随着组织规模的扩大,由不确定性和分歧引发的协调成本也会相应增加。仅仅增加管理层并不能有效解决问题,反而可能导致激励机制失调,造成下级对上级、上级对更高层级的虚假汇报。跨部门沟通更是需要层层上报再层层下达,效率低下。

相反,我们的做法是确保总体目标一致,然后通过共享 “操作指南” 和 “标准流程”,让各个项目都能并行跑起来。最近 AI 这么火,我们可以利用 AI 进行 “小黄鸭调试[9]”,而非追求完美的意见一致。啥意思?就是你有想法时,先跟 AI 聊聊,不用非得所有人点头才敢干。我们内部还有个 “人肉通讯录”,谁负责啥一目了然,有事直接找人,不用层层汇报。当然,这需要团队有够硬的信任基础。

更妙的是,有了 AI 当助手,很多时候都不用麻烦别人了。想问谁问题,不如先花一分钟问问 AI,没准就解决了。这样既能减少沟通成本,还能给大家一个不错的起点自己解决问题。简直是一箭双雕,何乐而不为?

5d28f66bf656f1b4d27f76de0e209fbf.jpeg

贵公司在制定详细计划时会提前多长时间,这种做法是如何随着时间推移而发生变化的?

作为一家成立不到两年的 AI 公司,Perplexity 深知行业变化之快,难以对远期未来做出承诺。我们采用季度规划的方式,并努力在每个季度内保持产品路线图的稳定性。

我们的产品路线图包含几个公司上下皆知的重大项目,以及一些可根据优先级灵活调整的小型任务。在瞬息万变的 AI 领域,保持灵活性至关重要。例如,开源模型和上下文长度的迅速进步就对我们的产品、路线图和整体业务产生了深远影响。最近,Meta 推出了 Llama 3,Mistral 则发布了 8x22B 模型,我们正在探索如何创新性地将这些新技术整合到产品中。

我们 Roadmap 中的项目也需要保持灵活性,因为新产品开发与技术及模型开发是同步进行的。工程师们会根据每周实际情况,在维护现有产品和开发新产品之间灵活切换。随着我们不断发现系统局限并积累技术债务,技术路线图往往会快速扩展。但我们会优先处理那些能够推动产品改进的技术问题。

尽管整体规划需要灵活应对,但在每周的范围内,我们的计划是相当稳定的。每周开始时,我们都会召开启动会议,员工们会为本周设定目标。我们推崇 “75%周目标” 的理念:每个人都明确自己本周的首要任务,并努力在周末前完成其中的 75%。这种做法既保证了工作重点明确,又给予了一定的灵活性,以应对可能出现的突发状况。

be5a40c2adc51a9e72c449b655899121.jpeg

在每周开始时花点时间思考宏观任务,能让我们头脑更加清晰,避免做出过于仓促或手忙脚乱的决策。随着时间推移,我们在评估任务规模和根据投资回报率排定优先级方面的能力也有了显著提升。

你们是不是也在用 OKR 或类似的管理工具?

在制定季度计划时,我们一直力求做到严谨且数据驱动。所有目标都是可衡量的:要么有具体的数字指标,要么就是能明确判断 “完成了没有”。我们设定的目标都很有挑战性,通常到季度结束时,完成度也就七成左右。不过那剩下的三成其实挺有用,能帮我们发现工作重点和人员配置上的问题。举个例子,如果基础设施方面的目标总是达不成,那就能很快暴露出我们在招聘基础设施工程师上投入不够这个问题。

f92312de8776536682765b2c7874423e.jpeg

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

在确定核心目标和总体设计后,我们采取相对分散的决策模式。每个项目由一位直接责任人 (DRI) 主导,各执行环节尽可能并行推进。

每个项目的第一步是尽量将其拆分成多个可并行的子任务,以减少协调成本。我和产品经理 (或负责相关工作的同事) 在 Linear 平台上主导这项工作。我们力求让每个任务都能独立完成,不受其他环节影响。这个过程中可能需要做出一些有争议的决定,但我们可以边做边解决这些争议。

f2396f856feb4bb07ed6a95d10f1a1bb.jpeg

每个项目启动时会召开一个简短的同步会议,之后团队以异步方式进行迭代,没有严格的限制或审查流程。当团队成员需要就设计、实施或最终成果获取反馈时,他们会在 Slack 上分享,其他成员则提供坦诚而有建设性的意见。迭代过程会根据需要自然展开,产品在通过内部试用获得认可前不会正式发布。

bbcbe3813952119742e8c0972b668262.jpeg

我鼓励团队成员尽可能并行工作,不要总是等待他人来解决障碍。理想情况下,设计、前端和后端应同时在同一个项目上同步工作。现在我们还有了业务团队,这样四个角色都可以并行工作,而不是像传统做法那样需要等待设计或原型完成才能开始。

贵公司的汇报体系是如何运作的?

目前我们的团队是按照职能划分的,包括产品、研发、设计和业务等部门。虽然各团队关注公司和技术架构的不同层面,但所有精力都集中在改进核心产品上。我们制定的目标会转化为共同的高层指标,全面提升用户体验。比如,所有团队在进行 A/B 测试时,都会参照相同的高层指标,同时在各自负责的技术层面进行优化。考虑到产品可能会快速迭代,我们希望避免出现人员身份与特定产品组件绑定的政治问题。

就目前的公司规模而言,我们采用扁平化的组织结构。汇报关系并不主导工作重点的确定,更多的是对高层目标的承诺。我们有两名全职产品经理,分别负责网页端和移动端,他们直接向我 (产品负责人) 汇报。有趣的是,我们发现,当团队没有产品经理时,团队成员会自发承担产品经理的职责。他们会调整项目范围,做出面向用户的决策,并相信自己的判断力,这种方式也运作得很好。

你们打造了一个备受喜爱且非常成功的产品。你觉得是什么独特或核心的产品方法造就了这样的成功?

我们的核心在于充分吸收用户和内部的反馈,并将其提炼为几个直观的产品功能,以满足多数客户的需求。我们还会以激励团队的方式传达这些反馈,制定宏观愿景的同时,让个人能够自主决策如何最好地实现最初的目标。我们采用分散式决策方法,将责任下放,实现快速迭代,无需繁琐的审批流程。这使得团队成员能够针对紧急情况做出快速、局部最优的决策。即便出现任何不一致之处,我们也能在事后迅速协调和调整。

你们主要使用什么工具来进行任务管理和 bug 追踪?

我们主要使用 Linear[10]。对于 AI 产品来说,任务、问题和项目之间的界限常常不太明确,但我们发现 Linear 中的许多概念,比如负责人、分类、规模评估等,都特别有用。我个人最喜欢的功能是自动归档——如果一个任务长时间没人提起,多半就不是什么要紧事了。

至于存储路线图和里程碑计划等核心信息,我们主要用 Notion[11]。在开发过程中,我们用 Notion 来写设计文档和需求征求意见书 (RFC),之后还用它来整理文档、做项目复盘和保存历史记录。把想法写下来 (也就是记录思考过程) 能让决策更清晰,也方便团队异步沟通,少开些会。

最近我们还引入了反馈分析工具 Unwrap.ai[12],主要用来整合、记录和量化那些定性反馈。AI 嘛,很多问题你还真说不准是不是 bug。Unwrap 就能把零散的反馈归类,总结出具体的改进方向。

说到制定产品路线图,你觉得是领导说了算,还是基层员工们自己决定?

大方向确实是老大们定的,但大量的新想法大多来自一线员工。在我们公司,工程师和设计师才是主角儿。毕竟做 AI 产品,你也不知道有啥坑,得写出代码、画出草图才知道。因此,我们鼓励全员持续不断地进行头脑风暴。我们在 Slack 平台上设立了专门的头脑风暴频道,在 Linear 系统中收集后续想法,有时甚至直接对代码进行优化,无需额外授权。

Perplexity 的 “发现”、“收藏” 和 “分享” 功能是自下而上创新的典范。例如,正如我之前所述,我们的品牌设计师 Phi 独立开发了 Discover Daily 播客[13],全权负责脚本编写、ElevenLabs 集成、品牌塑造和音频工程等各个环节。在 AI 领域,只有通过不断迭代和发布,才能发现产品的真正应用场景。一年前,我们绝对想不到 “发现” 功能最终会演变成一档播客节目。

外人看你们公司,总觉得一切都很完美,好像你们已经把所有问题都搞定了。那么,有没有什么地方还不太顺,或者遇到了什么大挑战呢?

现在我们面临的最大挑战,就是如何实现公司规模的进一步扩张。无论是在招聘人才,还是在业务执行和规划方面,我们都需要更上一层楼。但在这个过程中,我们不想丢掉公司一直引以为傲的扁平化管理和协作文化。

说来你可能不信,就连一些看起来很小的决定,比如如何管理 Slack (一个团队协作工具) 和 Linear (一个项目管理软件),在公司变大后也变得棘手起来。我们现在正在绞尽脑汁,想找到一个两全其美的办法:既能保持信息的透明度,又能增加沟通渠道和项目的数量,还要避免员工被各种通知轰炸到崩溃。这个平衡,说实话,真不太好把握。

贵公司或产品团队有哪些独特有趣的惯例或传统?

在 Perplexity,我们有不少 “拳头产品” 都是在一周甚至更短的编程马拉松中诞生的。这种集中火力、快速开发新功能的模式,往往是最激动人心和难忘的经历。比如我们的交互式搜索功能 “Pro Search” (原名 “Copilot”),它的雏形就是在短短几天内完成的。当然,之后经过多轮优化和调整,才有了现在的模样。

ad314f91f865bcc04cba8704071bb1aa.jpeg
引用链接

[1] Perplexity: https://www.perplexity.ai/
[2] 几乎每天: https://arc.net/l/quote/uglckdse
[3] 最近一轮融资额达 6300 万美元: https://x.com/AravSrinivas/status/1782784338238873769
[4] Johnny Ho: https://www.linkedin.com/in/hjohnny/
[5] 播客: https://www.perplexity.ai/podcast
[6] 我们的播客项目: https://www.perplexity.ai/podcast
[7] Alex Komoroske: https://www.linkedin.com/in/alex-komoroske-6597336/
[8] 将组织比作粘菌的理论: https://komoroske.com/slime-mold/
[9] 小黄鸭调试: https://en.wikipedia.org/wiki/Rubber_duck_debugging
[10] Linear: https://linear.app/
[11] Notion: https://www.notion.so/
[12] Unwrap.ai: https://www.unwrap.ai/
[13] Discover Daily 播客: https://www.perplexity.ai/podcast

14de7a66ef28fff0277c9622089f761d.png

独立开发最好的出路是出海,而出海的第一步就是学好英语!

如何学好英语?当然是看英文视频啦!英语基础薄弱的同学可以先从动画片看起,这里推荐一部超级好看的动画片叫《神奇校车》。神奇校车 (The Magic School Bus) 是一部美国学龄儿童教育动画片,故事围绕一位名叫瓦莱莎·芙里兹尔 (Valerie Frizzle) 的三年级老师和她的学生们展开。芙里兹尔老师开着一辆会变形的神奇校车,带领学生们进行一系列的科学探险。

1df199d3d9ed9533c626702c4fb333cf.jpeg

这辆神奇校车会变成潜水艇、宇宙飞船、时光穿梭机等等,小朋友们也可能变大变小、变成各种动物,用各种科学、物理知识去探险。以新颖活泼、好玩易懂的形式,带领孩子们进入浩瀚的科学领域,畅游在地球科学、生物科学、太空科学、气象学、古生物学等学科中。

a682124347b337eaf0936eb179f6769a.png 5c1a715b0475e150a5aaf83c9009ac09.png

关注【云原生实验室】公众号

回复「123」,限时免费领取!

↓ ↓ ↓ ↓ ↓

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值