AI搜索Perplexity的产品构建之道

2024-09-05 AIGC 0

作者｜Lenny Rachitsky

OneFlow编译
翻译｜凌小雨、张雪聃

题图由SiliconCloud平台生成

作为一家刚成立不到两年的新公司，AI搜索新星Perplexity与搜索巨头Google和AI先锋OpenAI展开竞争，争夺未来搜索领域的一席之地。

目前，Perplexity已经拥有数以千万计的用户，不过，该团队的成员还不到50人。更令人振奋的是，这个年轻团队已经实现了超过2000万美元的年度经常性收入（ARR）。

最近，他们完成了一笔6300万美元的融资，公司估值超10亿美元，其投资者包括英伟达、亚马逊创始人Jeff Bezos、OpenAI创始成员Andrej Karpathy、知名投资人Garry Tan、Dylan Field、Elad Gil、Nat Friedman、Daniel Gross和Naval Ravikant。英伟达CEO黄仁勋曾公开表示，他几乎每天都在使用Perplexity。

知名博主Lenny Rachitsky近期与Perplexity联合创始人兼产品负责人Johnny Ho进行了一次对话，后者从内部视角深入介绍了Perplexity如何构建产品。

以下是部分要点摘要：

AI优先：员工们一直都在向AI询问有关公司构建过程步骤相关的问题，包括“如何推出产品？”公司鼓励员工在打扰同事之前先向AI提问；
组织灵活高效：通过将项目分解成多个并行任务来最大限度地减少团队间的协调成本；
小而精的团队：Perplexity的标准团队通常只有两到三名成员工，其AI生成（且评价极高）的播客仅由一个人创建、运营；
扁平化管理：Perplexity倾向于雇佣自我驱动力强的独立贡献者，并尽量避免招聘在团队中喜欢指挥别人干活的员工；
既懂技术又有产品见解的优秀产品经理/工程师：Johnny的大胆猜想是，随着时间的流逝，那些既懂技术又对产品有独到见解的产品经理或工程师，将成为公司最宝贵的资产。

（本文由OneFlow编译发布，转载请联系授权原文： https://www.lennysnewsletter.com/p/how-perplexity-builds-product）

1. Perplexity内部如何使用AI工具来构建Perplexity？

其实，一开始我们也是盲人摸象，对产品管理、项目管理、财务、人力资源等没有具体的认知。

幸运的是，我们有机会提前接触GPT-3，创立之初，我们总是先向AI求助，比如“X是什么？”“那我们该如何正确地完成它？”比如，我们会问：“如何发布产品？发布过程中的步骤是什么？”等问题。

AI会给我们一个大致的步骤流程，这对初创公司来说已经足够好。当然，第一次尝试往往都不尽如人意，但谁又能一开始就做到完美？所以我们在哪里摔倒就在哪里爬起来，不断试错、学习、迭代。

我们花了好几天尝试自己解决问题。但是有了AI的一点提示，我们可以在五分钟内就开始行动。

我们还在继续使用这样的方法。例如，本周我问Perplexity：“怎么写一封邀请别人试用Perplexity Pro的邮件？”

我们有时候甚至用AI工具来构建自己的产品，但发现在编程方面，AI工具还需要迭代。它可以帮我们编写脚本，但如果想在平台上构建可持续的代码就不太行了。

即使在今天，随着技术的进步和新模型的出现，这些工具也只能写写模板，没办法真正用它来设计那些能长久使用的抽象化技术。

2. 你们有多少产品经理？

在我们这个50人的团队里，只有两名全职产品经理。这两位产品经理负责的项目通常只有一两个人参与，最棘手的项目最多也只有三四个人。

比如，我们的播客就是由一个人一手包办的。他是品牌设计师，但同时也会做音频工程，并进行各种研究，以打造一个最具互动性和趣味性的播客。我认为，到目前为止，还没有产品经理介入过这个过程。

遇到非常困难且有多种选择的决策时，以及在更复杂的项目中，产品管理最能发挥其优势。

产品经理工作中最困难也是最重要的部分是对应用场景具有很好的判断力。在AI领域，可能存在的应用场景数量太多。因此，产品经理需要根据数据、用户研究等信息，做出分支定性决策。AI领域的一个重要问题是应该优先考虑以提高生产力为主的使用场景，还是聊天机器人类的互动性使用场景。很早以前，我们就决定专注于前者，但相关讨论仍在继续。

我们计划在未来一年内再招一到两位产品经理，但招聘标准不会降低。

3. 你们的成功很大程度上是因为招聘得当，并保持了非常高的标准。在招聘时，你们最看重的（但别人可能没注意到的）特质是什么？

鉴于我们工作的速度，我们首先会要求灵活性和主动性。在资源有限的环境中能够积极建设性地工作（可能要身兼数职）对我们来说最重要。

看产品经理的简历时，很多人会强调帮助他人、寻求共识的特质。但我认为，随着AI的出现，这一点将变得不那么重要，你不一定需要擅长管理流程或领导别人。我们更看重那些在用户群体中产生明确量化影响的强大的个体贡献者，而不是只在公司内部表现出色的人。如果简历中出现“敏捷专家”或“Scrum大师”这样的描述，这个人可能不太适合我们。

此外，AI让产品经理能做更多的技术工作，尤其是数据分析和客户洞察方面。当然，还是需要一些基本知识（例如对数学、统计学、编程的基本理解），但现在成为真正“技术型”的产品经理已经比从前用容易不少。

我们也很看重候选人与我们企业文化的契合度，易于合作很重要，我们不太想要那种擅长指导他人工作的人，在AI时代，这种人并不是很必要。也许，未来公司规模扩展之后，我们的需求会有所改变，但在目前的规模下，需要构建的产品数量远远多于投入这些工作的员工数量。

我认为，未来整个行业的管理层将会减少。随着时间推移，技术产品经理或有产品敏锐度的工程师将成为公司中最宝贵的人才。

4. 你们的团队以围绕产品、用户类型、用户旅程、成果，还是介于这些之间的某种方式来构建？这些年来，这种结构有没有发生变化？

我的目标是构建团队，力求减少所谓的“协调阻力”，正如Alex Komoroske把组织比作黏菌时所描述的那样。

我们的核心观点是，随着规模扩大，由不确定性和分歧引起的协调成本会随之上升，单纯增加管理层并不能解决问题。员工的动机可能会不一致，甚至可能出现上下级之间相互隐瞒的情况。如果你想和公司里其他部门的人沟通，可能得经过一层层的上传下达，要问遍所有人。

相反，我们可以保持总体目标一致，通过共享可复用的指导和流程，让项目并行推进，共同指向这个目标。特别是在AI的帮助下，我们可以用它实现“小黄鸭调试法”（当程序员在解释他们的代码时，就像对着一个橡皮鸭（rubber duck）说话一样。通过解释问题，程序员往往能在解释过程中自己发现问题所在，或者至少能更清晰地理解问题。）从而对我们的想法进行测试，而不必依赖于完美的对齐和共识，这样就能降低协调成本。我们还在内部文档中建立了一个“人物名录”，需要联系谁，直接就能联系。这需要很高的信任度。

更重要的是，有了AI，你不用再频繁地向他人求助。有时候，在向别人提问之前，你可以先尝试花一分钟让AI回答，以减少协调成本，这也能给每个人提供一个不错的起点，让他们自己来做。

5. 你们详细规划的时间跨度有多长？这些年来有何变化？

Perplexity成立不到两年，而AI领域瞬息万变，很难给出两年之外的承诺。

我们一般会制定季度计划，在季度内，我们尽量保持计划的稳定，并设定产品路线图。路线图上有大家熟知的几个大项目，以及随优先级变化而调整的小任务。

灵活应变至关重要，因为AI的发展常常会带来不可预见的影响。例如，开源模型和上下文长度的快速发展对产品、路线图和整个业务都产生了下游影响。就在最近，Meta发布了Llama 3，Mistral发布了8x22B，我们正在探索如何将这些模型创造性地应用到我们的产品中。

产品路线图中的项目也需要灵活一些，因为新产品开发与技术/模型开发路线图是一起进行的。工程师会根据每周的情况决定是维护现有产品还是构建新产品。技术路线图通常发展很迅速，因为我们会遇到现有系统的限制并且会累积技术债务，但一般优先处理能够带来产品改进的技术债务。

尽管如此，一周之内的计划还是相对稳定的。我们每周都有一个启动会议，每个人都会设定本周的宏观期望。我们有一个“75%”的企业文化：大家都挑出本周的首要任务，并尽力达到75%的完成率。只需几个要点，就能确保本周的优先事项清晰明确。

在每周开始时花点时间思考核心任务可以让逻辑清晰，并避免出现决策仓促、决策混乱。随着时间的推移，我们根据投资回报评估项目规模和优先级的能力也有所提高。

6. 你们会以某种形式使用OKR吗？

我们尽量在季度计划中以数据驱动，并且对此很严格。所有目标都是可以衡量的，无论是定量的阈值，还是布尔值“X是否完成”。

我们的目标很激进，通常在季度结束时，我们可能只完成了70%。剩下的30%有助于我们发现优先级和人员配置上的差距。例如，当基础设施目标未达到时，对基础设施工程师招聘的投入不足便显而易见。

7. 你们的产品/设计评审会议是如何运作的？

在确定核心目标和宏观设计后，我们尽量在决策中保持去中心化。项目由一个直接责任人（DRI）驱动，执行步骤尽可能同时进行。

所有项目的第一步都是尽可能地将其分解为并行任务，以减少协调成本。我们用Linear（一个任务管理工具）来实现协调，我与团队中的产品经理（或任何负责产品管理的人）共同领导这项工作。我们力求每个任务都是独立的——能够在没有阻碍的情况下执行。你很可能不得不做出一些有争议的决定，但这些争议可以稍后再处理。

每个项目开始时，我们会开一个快速的启动会议以达成一致，随后，迭代以非共识的方式进行，没有限制，也没有审查流程。当员工准备好征求对设计、执行或最终产品的反馈时，会在Slack中分享，团队的其他成员会给予诚实的、有建设性的反馈。需要的时候，迭代自然发生，产品在通过内部测试（dogfooding）获得认可之前不会发布。