最近越来越喜欢使用 Perplexity，觉得他们的产品做得很有灵气。然后找了他们的两个访谈，读来很有收获，做些摘录和意译。
--
第一个是 Lex Fridman 访谈其 CEO Aravind Srinivas，内容在：https://lexfridman.com/aravind-srinivas-transcript。
在这篇访谈的前半部分，我看到不少产品比较本质的思考，颇为推荐。
Google 的“漏洞”——也就是 Google 给 Perplexity 留下的市场空间
> 我们雇佣的第一个员工来问健康保险。去 Google 搜索时，Google 没有动力给你明确的答案，他们希望你点击所有这些链接并自己阅读，因为这能带来广告收入。
> 任何比链接利润低的广告单元，或者任何会降低链接点击率的广告单元，都不符合他们的利益，因为这会减少高利润项目的收入——广告收入太惊人，没办法“戒掉”展示链接的广告模式。
> 我们从未尝试在 Google 擅长的领域与其竞争。如果你只是试图通过构建另一个搜索引擎来挑战 Google，并且有一些其他的差异化，比如隐私或无广告之类的，这是不够的。
> 颠覆来自于重新思考整个用户界面本身。为什么我们需要链接占据搜索引擎用户界面的显著位置？
阻止幻觉
> 在论文中阻止自己说胡话的一种方法是：确保每句话都有恰当的引用。要么引用其他经过同行评审的学术论文，要么引用自己论文中的实验结果。除此之外，论文中的其他内容都应该是我们个人的观点评述。
> 这其实就是维基百科的方式：在维基百科进行内容编辑时，会被要求提供真实可信的来源，且他们有自己的标准来判断可靠性。
知识发现引擎而非搜索引擎
> 在我看来，旅程在你得到答案后才刚刚开始。你会在底部看到相关问题，建议提出的问题。为什么？因为也许答案不够好，或者答案足够好，但你可能想深入挖掘并提出更多问题。
答用户还没问的问题
> 在产品层面上仍有很多工作要做，比如如何最好地向用户呈现信息，以及如何从用户真正想要的和可能想要的下一步倒推，并在他们提出要求之前就提供给他们。
盈利
> 也许 Perplexity 的长期商业模式可以让我们盈利，但永远不会像谷歌那样成为摇钱树。你必须记住，这仍然不错，大多数公司在其生命周期内甚至都没有盈利。
速度
> Chrome 发布时，Larry 会故意在非常旧版本的 Windows 和非常旧的笔记本电脑上测试 Chrome，并抱怨延迟很糟糕。Larry 要求它必须在破旧的笔记本电脑上也能工作，这样在好的笔记本电脑上，即使是最差的网络也能工作。每当我在飞行中，我总是在飞机上的 WiFi 测试 Perplexity，因为网络通常很糟糕，我想确保应用程序即使在这种情况下也能快速运行，并且我会将其与 ChatGPT 或 Gemini 或任何其他应用程序进行基准测试，尽量确保延迟相当不错。
> Spotify 早期的故事——弄清楚如何以非常低的延迟流式传输音乐(其实 QQ 和微信也有类似的故事)。
细节
> 每个细节都很重要，比如在搜索栏上，你可以让用户去点击搜索栏开始输入查询，或者你可以已经准备好光标，这样他们就可以直接开始输入。每一个细节都很重要，比如自动滚动到答案的底部，而不是强迫他们自己滚动。或者在移动应用中，当你点击搜索栏时，键盘出现的速度。我们关注所有这些细节，我们跟踪所有这些延迟，这是因为我们非常钦佩 Google 而养成的习惯。我想在这里强调的是，我从拉里那里学到的最终理念是，有一种理念叫做用户永远不会错。
用户永远对
> 这只是一个简单的哲学问题。你只需反过来说，“无论用户输入什么，你都应该提供高质量的答案。”然后你为此构建一个产品。你在幕后做所有的魔法，这样即使用户懒惰，即使有拼写错误，即使语音转录错误，他们仍然能得到答案并且喜欢这个产品。这迫使你做很多目前专注于用户的事情。即使用户没有要求什么，但你知道他们想要什么，并且在他们没有要求的情况下就给他们。
最大的敌人
> 我甚至不需要你输入查询。你只需输入一堆词就可以了。你必须设计产品到这种程度。因为人们很懒惰，一个更好的产品应该是让你更懒惰，而不是更勤奋。当然，另一种观点是说，“如果你要求人们输入更清晰的句子，这会迫使他们思考。”这也是一件好事。但最终，产品需要有一些魔力，而这种魔力来自于让你更懒惰。
> 我们的设计师和联合创始人在讨论，然后我们说，“嘿，我们最大的敌人不是谷歌，而是人们天生不擅长提问。”
> 世界上的每个人都有好奇心，但并不是所有人都能将这种好奇心转化为一个表达清晰的问题。将你的好奇心提炼成一个问题需要大量的思考，然后确保问题足够明确以便这些 AI 理解也需要很大的技巧。
> 帮助人们提出问题，并建议一些有趣的问题——这是一个受 Google 启发的想法。就像在 Google 中，你会看到“人们也会问”或建议一个问题，基本上都在尽可能减少提问的时间，并真正预测用户意图。
平衡
> 当你在增长的时候，当你试图增加新用户但也要保留现有用户时，如何平衡？有个案例研究：某个笔记产品不断为他们的高级用户构建功能，结果是新用户根本无法理解这个产品。Facebook 有一个早期的数据科学人员负责他们的增长，他说他们为新用户推出的功能比现有用户的更多，这对他们的增长更为关键。你可以整天争论这个问题，这就是为什么产品设计和增长并不容易。
让用户留下来的 magic number
> 对 Facebook 来说，magic nbumber 是你加入时在 Facebook 上已经有的初始朋友数量，这意味着你更有可能留下来。而对 Uber 来说，这是你成功乘坐的次数。
> 对 Perplexity 来说，它是让你感到满意的查询次数。你要确保产品快速、准确，并且答案可读，这样用户更有可能回来。
--
第二个是 Lenny 与其联合创始人兼产品负责人 Johnny Ho 的对谈，内容在：https://www.lennysnewsletter.com/p/how-perplexity-builds-product，内容是 Perplexity 如何构建产品，有 13 个问题：
1. 怎么用 AI 创建 Perplexity
- 问 AI，然后迭代、升级。
2. 产品经理
- 我们有 50 人，其中两位是产品经理。
- 常规项目只 1-2 人，最难也就 3-4 人。例如，播客是一个品牌设计师完成的，没有产品经理介入。
- 产品工作中，最困难和重要的部分是“taste around use cases”（我理解这里的 taste，是产品经理的直觉、洞察和判断力，能从众多场景中识别出最有价值、最重要的场景）。对 AI，有太多潜在场景，决策很难。例如，AI 的一个大问题是如何在更多基于生产力的场景（如 perplexity）与引人入胜的聊天机器人（如 c.ai）场景间排优先级。我们早就决定专注前者，但仍有持续讨论。
3. 招聘
- 我们看重灵活性和主动性，能资源有限的环境中建设性地工作（可能需要身兼数职）。
- 更重视个人能力，不那么关注管理流程或领导人的技能，当然仍然必须适合公司文化且容易合作。
- AI 使产品经理能够做更多的个人贡献，特别是在数据分析和客户洞察方面。当然，你仍然需要一些基础知识（即数学、统计学、编程的基本掌握），但成为一个真正“技术型”的产品经理从未如此容易。
- 我认为将来，行业的管理层级会减少，有产品品味的技术项目经理或工程师将随着时间的推移成为公司中最有价值的人。
4. 团队与组织
- 最小化“协调阻力”。毕竟协调成本（由不确定性和分歧引起）随规模增长而增加，增加管理者不会改善。
- 保持总体目标一致，共享可重复使用的指南和流程，并行追逐目标。
- 内部文档中更新了"谁是谁"列表，如果你觉得有必要联系任何人，直接联系。
- 在向其他人提出问题之前，先问 AI，降低协调成本。
5. 计划
- 季度计划，在季度内，我们努力在产品路线图中保持计划的稳定性。过程中保持灵活，毕竟 AI 发展太快。
- 每周举行一次启动会，每个人都为自己设定高水平期望（75% 每周目标）：每个人都确定本周的首要任务，并努力在周末前实现其中 75%，只需列出几个要点，以确保优先事项清晰明了。
6. OKR
- 所有目标可衡量的（可量化的阈值还是“是否完成”）。目标非常激进，只能完成 70%。
7. 执行
- 确定了目标、设计之后，项目有一个直接负责人全权负责。
- 尽可能将其分解成并行的任务，以减少协调问题。在每个项目开始时，都会有一个快速的协调启动，之后以异步方式进行迭代，理想的情况是，设计、前端和后端在同一个项目上同时工作。在 Slack 上讨论。
- 产品只有在通过内部使用获得足够的关注后才会推出。
8. 汇报关系
- 团队按职能（产品、研发、设计、业务等）构建，所有精力都集中在改进核心产品上。
- 当团队没有产品经理时，团队成员会承担产品经理的职责，例如调整范围、做出面向用户的决策以及相信自己的品味。
9. 什么独特点带来了成功
- 听取来自用户和内部的反馈，并提炼为适用的产品
- 为团队设定愿景，给大的自由度，他们自行决策。去中心化决策方法传递了责任的火炬，无需审批流程即可实现快节奏迭代。个人做出紧急的、局部最优的决策。任何错位都会很快得到解决。
10. 工具
- 用 Linear 管理任务。
- 用 Notion 存储文档（路线图、计划、设计文档、RFC、事后分析、历史记录），用文档更容易调整异步并避免会议。
- 用 Unwrap.ai 整合、记录和量化定性反馈。
11. 产品路线图
- 高层次的目标和方向是自上而下的，但大量的新想法是自下而上的。我们坚信，工程和设计应该对想法和细节拥有所有权。
- 头脑风暴随时都在进行。我们在 Slack 中有一个专门的头脑风暴频道，后续的想法会收集在 Linear 中，通常改进会直接进入代码而无需任何人要求。
12. 挑战
- 规模扩展，但不损失扁平。比如：如何在保持透明的同时扩展频道和项目的数量，而不会导致通知爆炸。
13. 黑客马拉松
- Perplexity 的许多功能和产品都是在一周（或更短）黑客马拉松期间构建的。专注于构建新功能的冲刺已被证明是最令人兴奋和难忘的时刻。
--
欢迎你加入我的知识星球，我们一起聊聊创业、产品、运营、阅读。微信识别二维码，付费即可加入，如不满意，72 小时内可在 App 内无条件自助退款。——>星球创业笔记传送门。
