How Perplexity builds product
Perplexity 如何构建产品
Johnny Ho, co-founder and head of product, explains how he organizes his teams like slime mold, uses AI to build their AI company, and much more
何強尼，联合创始人兼产品负责人，阐述了他如何像黏菌一样组织团队，利用人工智能构建他们的人工智能公司，以及更多内容
👋 Hey, Lenny here! Welcome to this month’s ✨ free edition ✨ of Lenny’s Newsletter. Each week I tackle reader questions about building product, driving growth, and accelerating your career.
👋 嗨，我是 Lenny！欢迎阅读本月✨免费版✨Lenny 的通讯。每周我都会解答读者关于构建产品、推动增长和加速职业发展的疑问。
If you’re not a subscriber, here’s what you missed this month:
如果您尚未订阅，以下是您本月错过的内容：
The secret to Duolingo’s exponential growth
Duolingo 指数级增长的秘诀How to accelerate growth by focusing on the features you already have
如何通过聚焦现有功能加速增长
For $150 a year, get access to these posts and every prior post, along with an invite to a private Slack community with global meetups, a mentor matching program, interview prep support, live AMAs, and more. I guarantee you’ll get 100x the value of a subscription or your money back.
每年仅需 150 美元，即可访问这些文章及所有过往文章，并获得加入私人 Slack 社区的邀请，该社区定期举办全球聚会、提供导师匹配计划、面试准备支持、实时问答环节等丰富资源。我保证您将获得订阅费用百倍的价值，否则全额退款。
Founded less than two years ago, Perplexity has become a many-times-a-day-use product for me, replacing many of my Google searches—and I’m not alone. With fewer than 50 employees, the company has a user base that’s grown to tens of millions. They’re also generating over $20 million ARR and taking on both Google and OpenAI in the battle for the future of search. Their recent fundraise of $63m values the company at more than $1 billion, and their investors include Nvidia, Jeff Bezos, Andrej Karpathy, Garry Tan, Dylan Field, Elad Gil, Nat Friedman, Daniel Gross, and Naval Ravikant (but sadly not me 😭). Nvidia CEO Jensen Huang said he uses the product “almost every day.”
成立不到两年，Perplexity 已成为我每日多次使用的产品，取代了我许多原本的谷歌搜索——而且我并非个例。这家员工不足 50 人的公司，用户基数已增长至数千万。他们还实现了超过 2000 万美元的年度经常性收入，并在未来搜索之争中同时挑战谷歌和 OpenAI。其最新一轮 6300 万美元的融资使公司估值超过 10 亿美元，投资者包括英伟达、杰夫·贝索斯、安德烈·卡帕西、加里·谭、迪伦·菲尔德、埃拉德·吉尔、纳特·弗里德曼、丹尼尔·格罗斯以及纳瓦尔·拉维康特（可惜没有我😭）。英伟达 CEO 黄仁勋表示，他“几乎每天”都在使用该产品。
I sat down with Johnny Ho, the company’s co-founder and head of product, to give you an inside look at how Perplexity builds product—which to me feels like what the future of product development will look like for many companies:
我与公司的联合创始人兼产品负责人 Johnny Ho 坐下来，带您深入了解 Perplexity 如何构建产品——在我看来，这仿佛预示着众多企业未来产品开发的面貌：
AI-first: They’ve been asking AI questions about every step of the company-building process, including “How do I launch a product?” Employees are encouraged to ask AI before bothering colleagues.
以 AI 为先：他们在公司建设的每一步都向 AI 提问，包括“如何发布产品？”鼓励员工在打扰同事之前先咨询 AI。Organized like slime mold: They optimize for minimizing coordination costs by parallelizing as much of each project as possible.
组织如黏菌：他们通过尽可能并行化每个项目的大部分工作，来优化以最小化协调成本。Small teams: Their typical team is two to three people. Their AI-generated (highly rated) podcast was built and is run by just one person.
小团队：他们典型的团队规模是两到三人。他们由人工智能生成（评价极高）的播客，从构建到运营仅由一人完成。Few managers: They hire self-driven ICs and actively avoid hiring people who are strongest at guiding other people’s work.
少数管理者：他们聘用自我驱动的独立贡献者，并积极避免招聘那些最擅长指导他人工作的人。A prediction for the future: Johnny said, “If I had to guess, technical PMs or engineers with product taste will become the most valuable people at a company over time.”
未来预测：Johnny 表示：“如果要我猜测，随着时间的推移，具备产品感觉的技术项目经理或工程师将成为公司中最有价值的人才。”
For more, check out Perplexity. And they’re hiring! For more stories of how the best product teams operate, don’t miss my deep dives into Linear, Shopify, Figma, Notion, Duolingo, Ramp, Miro, Coda, Gong, and Snowflake.
了解更多，请查看 Perplexity。他们正在招聘！想要深入了解顶尖产品团队如何运作，千万不要错过我对 Linear、Shopify、Figma、Notion、Duolingo、Ramp、Miro、Coda、Gong 以及 Snowflake 的深度剖析。
P.S. I’m collaborating with Perplexity on a deep dive into how product managers use Perplexity, and we’d love to hear from you. Fill out this short survey if you use Perplexity regularly, and they’ll reach out to conduct a user interview.
附言：我正与 Perplexity 合作深入探讨产品经理如何使用 Perplexity，我们非常希望听到您的声音。如果您经常使用 Perplexity，请填写这份简短的调查问卷，他们将联系您进行用户访谈。
How Perplexity builds product
Perplexity 如何构建产品
从左至右：Johnny Ho、Aravind Srinivas 和 Denis Yarats，Perplexity 联合创始人
1. How do you use AI tools within Perplexity to build Perplexity?
1. 在 Perplexity 中，您如何运用 AI 工具来构建 Perplexity？
Honestly, at the very beginning, we didn’t know how to do all kinds of things, including product management, project management, finances, HR, etc. We had early access to GPT-3, and as we were figuring out how to build the company, we’d start everything by asking AI, “What is X?” and then “How do we do X properly?” For example, we asked questions like “How do you launch a product? What should be the steps in the launch process?” You get a rough step-by-step process, which for a startup was good enough. Obviously, it’s often not correct on the first try, but neither is a human, right? So we’d just iterate naturally from there.
老实说，在最开始的时候，我们并不知道如何处理各种事务，包括产品管理、项目管理、财务、人力资源等等。我们较早地接触到了 GPT-3，在摸索如何构建公司的过程中，我们总是先向 AI 提问：“X 是什么？”接着再问：“我们该如何正确地做 X？”例如，我们会询问“如何发布产品？发布过程中应该有哪些步骤？”AI 会提供一个大致的步骤流程，对于初创公司来说，这已经足够好了。显然，它给出的答案往往不是一次就完全正确，但人类也未必能做到一次就对，对吧？因此，我们会自然而然地从那里开始迭代改进。
Trying to figure things out by ourselves took days, but with AI and some prompting, we could get rolling in five minutes.
试图自行理清问题耗时数日，但借助人工智能并稍加提示，我们便能在五分钟内启动。
We’re still doing this. This week, for example, I asked Perplexity, “How do I write an email inviting someone to Perplexity Pro?”
我们仍在进行这项工作。例如，本周我向 Perplexity 提问：“如何撰写一封邀请某人加入 Perplexity Pro 的电子邮件？”
We even tried to use it at times to build our product, but we found AI tooling wasn’t anywhere near good enough when it comes to coding. It could help us write scripts, but if you wanted sustainable code to build a platform on, it didn’t really work. Even today, with the advances and latest models, it still only writes templates. You can’t really design a new long-lived abstraction with it.
我们甚至尝试在某些时候利用它来构建产品，但发现就编码而言，AI 工具的性能远未达标。它虽能协助编写脚本，但若要打造一个基于可持续代码的平台，它实际上并不奏效。即便在今日，随着技术的进步与最新模型的推出，它也仅限于编写模板。你无法真正借助它设计出全新的、长寿命的抽象架构。
2. How many PMs do you have?
2. 您有多少个项目经理？
We have only two full-time PMs, in an organization of 50.
我们整个机构 50 人中，只有两名全职产品经理。
Typical projects we work on only have one or two people on it. The hardest projects have three or four people, max. For example, our podcast is built by one person end to end. He’s a brand designer, but he does audio engineering and he’s doing all kinds of research to figure out how to build the most interactive and interesting podcast. I don’t think a PM has stepped into that process at any point.
我们通常参与的项目只有一两个人负责。最复杂的项目最多也就三到四人。比如，我们的播客从制作到发布全由一人包揽。他本是品牌设计师，却同时兼做音频工程，还进行各种研究以打造最具互动性和趣味性的播客内容。我不认为有项目经理介入过这一流程。
We leverage product management most when there’s a really difficult decision that branches into many directions, and for more involved projects.
我们在面临极其复杂的决策，且该决策涉及多个方向时，以及在更为深入的项目中，会充分利用产品管理。
The hardest, and most important, part of the PM’s job is having taste around use cases. With AI, there are way too many possible use cases that you could work on. So the PM has to step in and make a branching qualitative decision based on the data, user research, and so on. For example, a big problem with AI is how you prioritize between more productivity-based use cases versus the engaging chatbot-type use cases. Pretty early on, we decided to focus on the former, but there are still ongoing discussions.
产品经理工作中最具挑战性、也最关键的部分，在于对使用场景的品味把握。面对人工智能领域层出不穷的可能应用场景，产品经理必须介入，依据数据、用户研究等信息，做出分流的定性决策。例如，人工智能面临的一大难题是如何在提升生产力的应用场景与引人入胜的聊天机器人型应用场景之间进行优先级排序。很早之前，我们就决定侧重于前者，但相关讨论仍在持续进行中。
We plan to hire one or two more PMs over the next year, but the bar for hiring is going to stay very high.
我们计划在未来一年内再招聘一至两名项目经理，但招聘标准将保持极高。
3. I assume much of your success has been due to hiring well, and keeping a very high bar. What do you most look for when hiring (that maybe others don’t)?
3. 我猜想你的许多成功很大程度上归功于出色的招聘策略和保持极高的标准。在招聘时，你最看重的是什么（可能是别人不太关注的）？
Given the pace we are working at, we look foremost for flexibility and initiative. The ability to build constructively in a limited-resource environment (potentially having to wear several hats) is the most important to us.
鉴于我们目前的工作节奏，我们首先寻求的是灵活性和主动性。在资源有限的环境中（可能需要身兼数职），能够建设性地开展工作对我们来说至关重要。
When you take a look at resumes of PMs, a lot of them prioritize helping other people and finding alignment. I believe this becomes less important with the advent of AI. So you don’t necessarily need skills around managing processes or leading people as much. We look for strong ICs with clear quantitative impacts on users rather than within their company. If I see the terms “Agile expert” or “scrum master” in the resume, it’s probably not going to be a great fit.
当审视产品经理的简历时，许多人将帮助他人和寻求共识放在首位。我认为随着人工智能的兴起，这一点的重要性正在降低。因此，你未必需要那么多的流程管理或人员领导技能。我们更倾向于寻找那些对用户产生明确量化影响的优秀独立贡献者，而非仅在公司内部有所建树的人才。如果在简历中看到“敏捷专家”或“Scrum 大师”这样的字眼，很可能并不符合我们的要求。
Also, AI allows PMs to do a lot more IC work, especially for data analysis and customer insights. You still need some fundamental knowledge, of course (i.e. math, statistics, a basic grasp of programming), but it’s never been easier to be a truly “technical” PM.
此外，人工智能使产品经理能够承担更多集成电路方面的工作，尤其是在数据分析和客户洞察方面。当然，你仍需掌握一些基础知识（如数学、统计学、编程基础），但成为一名真正意义上的“技术型”产品经理从未如此简单。
We still select for culture fit and being easy to work with, but we’re less looking for people who guide other people’s efforts, because it’s not as necessary with AI. This might change as we get to a certain scale, but at the current scale, there are way more products to build than there are people to work on them.
我们依然注重文化契合度和易于共事的能力，但不再那么看重指导他人工作的人才，因为在人工智能的辅助下，这种需求已不那么迫切。这一情况可能会随着规模扩大而改变，但在当前规模下，待开发的产品远比能投入其中的人手要多得多。
I think in the future, I expect fewer layers of management in the industry in general. And if I had to guess, a technical PM or an engineer with product taste will become the most valuable people at a company over time.
我认为在未来，整个行业普遍会减少管理层级。如果让我猜测，具备技术背景的项目经理或拥有产品感觉的工程师将随着时间的推移成为公司中最有价值的人才。
4. Do you structure your teams around products, user types, user journeys, outcomes, or something in between? Has this changed over the years?
4. 您的团队是围绕产品、用户类型、用户旅程、成果，还是介于这些之间的某个点来构建的？这种结构多年来是否有所变化？
My goal is to structure teams around minimizing “coordination headwind,” as described by Alex Komoroske in this deck on seeing organizations as slime mold. The rough idea is that coordination costs (caused by uncertainty and disagreements) increase with scale, and adding managers doesn’t improve things. People’s incentives become misaligned. People tend to lie to their manager, who lies to their manager. And if you want to talk to someone in another part of the org, you have to go up two levels and down two levels, asking everyone along the way.
我的目标是围绕减少“协调阻力”来构建团队，正如 Alex Komoroske 在这份关于将组织视为黏菌的演示中所述。大致思路是，随着规模的扩大，协调成本（由不确定性和分歧引起）会增加，而增加管理层并不能改善这一状况。人们的激励机制变得不一致，员工倾向于向其上级隐瞒真相，上级再向上级隐瞒。如果你想与组织另一部分的人交流，必须向上跨越两级再向下跨越两级，沿途还要征得每个人的同意。
Instead, what you want to do is keep the overall goals aligned, and parallelize projects that point toward this goal by sharing reusable guides and processes. Especially with the advance of AI, it’s possible to minimize coordination costs by using AI for “rubber duck debugging” your ideas instead of relying on perfect alignment and consensus. We also keep a “who’s who” list updated in our internal docs, and if you feel the need to reach out to anyone, just do it. This requires a large degree of trust.
相反，你应确保整体目标一致，并通过共享可复用的指南和流程来并行推进指向这些目标的项目。特别是在人工智能技术进步的背景下，可以利用 AI 进行“橡皮鸭调试”来优化创意，而非单纯依赖完美对齐和共识，从而降低协调成本。我们在内部文档中还维护了一份“人员名录”，若你感到需要联系某人，尽管行动。这需要高度的信任基础。
But even more importantly, with AI, you don’t have to reach out to people as often. Sometimes before asking the question you were going to ask someone else, you could first try spending one minute asking AI to reduce coordination costs and give everyone a reasonable jumping-off point to do it themselves.
但更为重要的是，借助人工智能，你不必频繁地向他人求助。有时，在准备向他人提问之前，你可以先尝试花一分钟时间向 AI 求助，以降低协调成本，并为每个人提供一个合理的起点，让他们自行解决问题。
5. How far out do you plan in detail, and how has that evolved over the years?
5. 你们在多远的未来进行详细规划，这些年这一规划范围有何演变？
Perplexity has existed for less than two years, and things are changing so quickly in AI that it’s hard to commit beyond that. We create quarterly plans. Within quarters, we try to keep plans stable within a product roadmap. The roadmap has a few large projects that everyone is aware of, along with small tasks that we shift around as priorities change. Being nimble is critical as developments in AI often have unforeseeable impact. For example, the rapid developments in open-source models and context length have had downstream impact on the product, roadmap, and overall business. Just recently, Meta released Llama 3 and Mistral released 8x22B; we’re looking into creative ways to use those models in our product.
Perplexity 成立至今不足两年，人工智能领域的变化极为迅速，以至于难以做出超出此时间范围的承诺。我们制定季度计划，在季度内，我们努力在产品路线图中保持计划的稳定性。路线图包含几个大型项目，所有人都有所了解，同时还有一些根据优先级变化而调整的小任务。保持灵活性至关重要，因为人工智能的发展常常带来不可预见的影响。例如，开源模型和上下文长度的快速发展已对产品、路线图及整体业务产生了连锁反应。就在最近，Meta 发布了 Llama 3，Mistral 发布了 8x22B；我们正在探索创新方式，将这些模型融入我们的产品中。
The projects in the product roadmap also need to be flexible because new product development runs in parallel with a technical/model development roadmap. Engineers shift between maintaining existing products and building new products, depending on the week. The technical roadmap tends to grow quickly as we run into limitations of existing systems and accumulate tech debt, but we try to prioritize tech debt that unlocks product improvements.
产品路线图中的项目同样需要保持灵活性，因为新产品开发与技术/模型开发路线图并行推进。工程师们根据周次在维护现有产品和构建新产品之间切换。随着我们在现有系统局限性中摸索并累积技术债务，技术路线图往往会迅速扩展，但我们努力优先处理那些能解锁产品改进的技术债务。
Within a given week, though, plans are fairly stable. Each week we have a kickoff meeting where everyone sets high-level expectations for their week. We have a culture of setting 75% weekly goals: everyone identifies their top priority for the week and tries to hit 75% of that by the end of the week. Just a few bullet points to make sure priorities are clear during the week.
尽管在特定的一周内，计划相对稳定。每周我们都会召开启动会议，每个人在会上设定自己本周的高层次期望。我们有一种设定 75%周目标的文化：每个人都明确自己本周的头等大事，并努力在周末前达成该目标的 75%。只需列出几个要点，确保一周内的优先事项清晰明了。
Taking a moment at the beginning of the week to reflect on meta tasks brings clarity and prevents overly reactive or hectic decision-making. Over time, our ability to estimate size and prioritize based on return on investment has also improved.
在周初抽出片刻时间反思元任务，能带来清晰思路并避免过度反应或仓促决策。随着时间推移，我们根据投资回报率估算规模和优先级的能力也得到了提升。
6. Do you use OKRs in some form?
6. 你们是否以某种形式使用 OKR？
We try to be as rigorous and data-driven as possible in quarterly planning. All objectives are measurable, either in terms of quantifiable thresholds or Boolean “was X completed or not.” Our objectives are very aggressive, and often at the end of the quarter we only end up completing 70% in one direction or another. The remaining 30% helps identify gaps in prioritization and staffing. Underinvestments, for example, in hiring infra engineers become quickly apparent when infrastructural goals aren’t met.
我们在季度规划中力求尽可能严谨和数据驱动。所有目标都是可衡量的，无论是通过可量化的阈值还是布尔型的“X 是否已完成”。我们的目标设定非常激进，通常在季度末，我们只能完成某个方向上的 70%。剩余的 30%有助于识别优先级和人员配置上的差距。例如，当基础设施目标未达成时，对基础设施工程师招聘的投入不足会迅速显现。
7. How do your product/design review meetings work?
7. 贵公司的产品/设计评审会议是如何进行的？
After the central objectives and high-level designs are determined, we try to be fairly decentralized in our decision-making. Projects are driven by a single DRI, and execution steps are done in parallel as much as possible.
在确定了核心目标和高层次设计后，我们在决策过程中力求保持相当的分散性。项目由单一的直接责任人（DRI）推动，执行步骤尽可能并行进行。
The first step for any project is to break it down into parallel tasks as much as possible to reduce coordination issues. We do this in Linear, and I lead this work along with the PM on the team (or whoever is handling the PM duties). We strive for each task to be self-contained—you should be able to execute on it without blockers. And you will likely have to make some controversial decisions, but you can just work through the controversy later.
任何项目的初始步骤都是尽可能将其分解为并行任务，以减少协调问题。我们在 Linear 中执行此操作，我与团队中的项目经理（或负责项目管理职责的人员）共同领导这项工作。我们力求每个任务都自成一体——你应该能够在没有阻碍的情况下执行它。而且你很可能会面临一些有争议的决定，但你可以稍后解决这些争议。
At the beginning of each project, there is a quick kickoff for alignment, and afterward, iteration occurs in an asynchronous fashion, without constraints or review processes. When individuals feel ready for feedback on designs, implementation, or final product, they share it in Slack, and other members of the team give honest and constructive feedback. Iteration happens organically as needed, and the product doesn’t get launched until it gains internal traction via dogfooding.
在每个项目伊始，会迅速启动一次对齐会议，随后迭代以异步方式进行，不受约束或审查流程限制。当个人准备好对设计、实现或最终产品进行反馈时，他们会在 Slack 上分享，团队其他成员则提供真诚且建设性的反馈。迭代根据需要自然发生，产品在通过内部试用获得认可前不会发布。
I encourage people to try to work in parallel as much as they can. They should not be waiting for everyone to unblock them. Ideally, you have design, front end, and back end all working at the same time on the same project. And now that we have a business team, all four people could work in parallel, whereas conventionally you might wait for designs or mock-ups to show up first.
我鼓励大家尽可能尝试并行工作，不应坐等他人解封。理想情况下，设计、前端和后端应同时在同一项目上协同作业。如今我们有了业务团队，四人可以并行工作，而传统做法可能是先等待设计稿或样稿出炉。
8. How do reporting lines work?
8. 汇报线是如何运作的？
The teams are currently structured by function (product, R&D, design, business, etc.), and different teams think about different layers of the company and stack. But all energy is directed toward improving the core product. We design objectives that translate to common top-level metrics and improve the user experience holistically. For example, all teams share common top-level metrics while A/B testing within their layer of the stack. Because the product can shift so quickly, we want to avoid political issues where anyone’s identity is bound to any given component of the product.
团队目前按职能划分（产品、研发、设计、业务等），不同团队思考公司和产品堆栈的不同层面。但所有精力都集中于提升核心产品。我们设计目标，转化为共同的顶级指标，全面提升用户体验。例如，各团队在各自堆栈层级内进行 A/B 测试时，共享相同的顶级指标。由于产品变化迅速，我们希望避免任何人的身份与产品特定组件绑定可能引发的政治问题。
At our current size, we are flat by design, and the reporting structure does not dictate priorities as much as commitments to top-level goals. Our two full-time PMs—one web and one mobile—report to me as head of product. We’ve found that when teams don’t have a PM, team members take on the PM responsibilities, like adjusting scope, making user-facing decisions, and trusting their own taste.
在我们目前的规模下，组织结构扁平化是设计使然，报告关系并不像对顶级目标的承诺那样决定优先级。我们的两位全职产品经理——一位负责网页端，一位负责移动端——直接向我这位产品负责人汇报。我们发现，当团队没有专职产品经理时，团队成员会承担起产品管理职责，比如调整范围、做出面向用户的决策，并相信自己的品味。
9. You build one of the most beloved and successful products out there. What would you say is unique or central to your approach to product that leads to such success?
9. 您打造了市面上最受欢迎且最成功的产品之一。您认为在产品开发过程中，有哪些独特或核心的方法促成了这样的成功？
Central to our approach is to take feedback, both from users and internally, and distill it into a few intuitive products that can work for many customers. We also try to distill the feedback in a way that motivates and informs our team, setting a broad vision but letting individuals control their own decisions about what would best serve the original goal. Our decentralized approach for decisions passes the torch of responsibility, enabling fast-paced iteration without the need for approval processes. Individuals make urgent, locally optimal decisions. Any misalignments are then ironed out quickly afterward.
我们方法的核心在于收集用户及内部的反馈，并将其提炼成几款直观的产品，以满足众多客户的需求。同时，我们力求以一种激励团队、传递信息的方式来处理这些反馈，确立宏大的愿景，同时让团队成员自主决定如何最有效地实现既定目标。我们采取的去中心化决策方式，传递了责任之炬，使得快速迭代成为可能，无需繁琐的审批流程。个人可做出紧急且局部最优的决策，任何偏差随后都能迅速得到纠正。
10. What’s your primary tool for task management, and bug tracking?
10. 您主要使用什么工具进行任务管理和缺陷跟踪？
Linear. For AI products, the line between tasks, bugs, and projects becomes blurred, but we’ve found many concepts in Linear, like Leads, Triage, Sizing, etc., to be extremely important. A favorite feature of mine is auto-archiving—if a task hasn’t been mentioned in a while, chances are it’s not actually important.
线性。对于人工智能产品而言，任务、缺陷与项目之间的界限变得模糊，但我们发现 Linear 中的许多概念，如负责人、分类、规模评估等，极为关键。我个人特别喜欢的一个功能是自动归档——若某项任务长时间未被提及，很可能它并不那么重要。
The primary tool we use to store sources of truth like roadmaps and milestone planning is Notion. We use Notion during development for design docs and RFCs, and afterward for documentation, postmortems, and historical records. Putting thoughts on paper (documenting chain-of-thought) leads to much clearer decision-making, and makes it easier to align async and avoid meetings.
我们用于存储诸如路线图和里程碑规划等真实来源的主要工具是 Notion。在开发过程中，我们利用 Notion 来撰写设计文档和 RFC，之后则用于编写文档、事后分析及历史记录。将思路落实到纸面上（即记录思考过程）能极大提升决策的清晰度，并有助于异步协作，减少会议需求。
Unwrap.ai is a tool we’ve also recently introduced to consolidate, document, and quantify qualitative feedback. Because of the nature of AI, many issues are not always deterministic enough to classify as bugs. Unwrap groups individual pieces of feedback into more concrete themes and areas of improvement.
Unwrap.ai 是我们近期推出的一款工具，用于整合、记录和量化定性反馈。由于 AI 的本质特性，许多问题并不总是具有足够的确定性而被归类为漏洞。Unwrap 能将零散的反馈归纳为更具体的主题和改进领域。
11. Would you say roadmap ideas primarily come top-down (teams are told what to build) or bottom-up (teams generally come up with the ideas)?
11. 您认为路线图构想主要是自上而下（团队被告知要构建什么）还是自下而上（团队通常提出构想）？
High-level objectives and directions come top-down, but a large amount of new ideas are floated bottom-up. We believe strongly that engineering and design should have ownership over ideas and details, especially for an AI product where the constraints are not known until ideas are turned into code and mock-ups. Plenty of brainstorming is going on at all times. We have a dedicated brainstorm channel in Slack, follow-up ideas are collected in Linear, and often polishes go straight to code without anyone asking.
高层目标与方向自上而下传达，但大量新创意却自下而上涌现。我们坚信，工程与设计团队应拥有对创意及细节的掌控权，尤其是在 AI 产品领域，其约束条件往往要等到创意转化为代码和原型后才能明确。随时都有大量的头脑风暴在进行中。我们在 Slack 设有专门的头脑风暴频道，跟进的想法会被收集到 Linear 中，而许多打磨甚至直接转化为代码，无需任何人催促。
The best examples of bottom-up ideas can be seen in Perplexity’s Discovery, Collection, and Sharing experiences. For example, as I shared above, our brand designer Phi builds the Discover Daily podcast and simultaneously makes decisions around the script, ElevenLabs integration, brand, and audio engineering. With AI, it’s impossible to predict use cases until iterations of the product are released. A year ago, we would never have predicted that the Discover experience would eventually be built into a podcast.
自下而上的最佳实践案例在 Perplexity 的发现、收藏和分享体验中可见一斑。例如，正如前文所述，我们的品牌设计师 Phi 负责构建“每日发现”播客，同时对剧本、ElevenLabs 集成、品牌形象及音频工程等方面做出决策。借助人工智能，在产品迭代发布之前，我们无法预见具体的应用场景。一年前，我们绝不会预料到“发现”体验最终会演变成一档播客节目。
12. When people see a company like yours from the outside, it all looks perfect and like you have everything figured out. What are some things that aren’t working well or have been big challenges?
12. 当人们从外部看待像贵公司这样的企业时，一切看起来都完美无缺，仿佛你们已经把所有事情都安排得井井有条。那么，有哪些方面运作得不尽如人意，或者曾经面临过巨大的挑战呢？
Big challenges today revolve around scaling from our current size to the next level, both on the hiring side and in execution and planning. We don’t want to lose our core identity of working in a very flat and collaborative environment. Even small decisions, like how to organize Slack and Linear, can be tough to scale. Trying to stay transparent and scale the number of channels and projects without causing notifications to explode is something we’re currently trying to figure out.
当今面临的主要挑战在于如何从现有规模扩展到下一阶段，无论是在招聘方面，还是在执行与规划上。我们不希望失去核心特质——在一个极为扁平且协作的环境中工作。即便是微小的决策，比如如何组织 Slack 和 Linear，都可能难以扩大规模。我们正努力解决的问题是，如何在保持透明度的同时，扩展频道和项目的数量，而不至于让通知泛滥成灾。
13. What are some fun/unique rituals or traditions you have on the product team or at the company?
13. 你们产品团队或公司有哪些有趣的/独特的仪式或传统？
A lot of features and products at Perplexity were built during one-week (or less) hackathons. Focused sprints to build new features have proved to be the most exciting and memorable times. Our first interactive search prototype, Pro Search (formerly Copilot), was built in a few days, but it has improved over many iterations of polish and fine-tuning.
Perplexity 的许多功能和产品都是在为期一周（或更短）的黑客马拉松期间构建的。专注于打造新功能的冲刺阶段已被证明是最令人兴奋和难忘的时刻。我们的首个交互式搜索原型——Pro Search（原名 Copilot），仅用几天时间便搭建完成，但经过多次打磨和精细调整，它已不断改进。
Thank you, Johnny! Also, a big thank-you to Phi Hoang for helping with visuals.
谢谢你，Johnny！同时，也非常感谢 Phi Hoang 在视觉设计方面的协助。
For more, check out Perplexity, and they’re hiring!
了解更多，请查看 Perplexity，他们正在招聘！
Have a fulfilling and productive week 🙏
愿你拥有一个充实且富有成效的一周 🙏
👀 Hiring? Or looking for a new job?
👀 招聘中？还是寻找新工作？
I run a white-glove recruiting service specializing in product roles, working with a few select companies at a time. If you’re hiring for senior product roles, apply to work with us:
我运营着一家专注于产品岗位的高端招聘服务，每次仅与少数精选公司合作。若贵司正在招聘高级产品职位，欢迎申请与我们合作：
If you’re exploring new opportunities yourself, use the same button above to sign up. We’ll send over personalized opportunities from hand-selected companies if we think there’s a fit. Nobody gets your info until you allow them to, and you can leave anytime.
若您正在寻找新的机遇，请使用上方同一按钮进行注册。若我们认为有合适的匹配，我们将为您发送来自精心挑选公司的个性化机会。未经您允许，无人能获取您的信息，且您可随时退出。
If you’re finding this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already. There are group discounts, gift options, and referral bonuses available.
如果您觉得这份通讯有价值，不妨与朋友分享，如果尚未订阅，也请考虑加入。我们提供团体折扣、礼品选项及推荐奖励。
Sincerely, 敬上，
Lenny 👋 莱尼👋
Love perplexity, use it every day, and Glad to read more about the behind-the-scenes.
I like these articles, I got things that helped me in my career, thanks a lot.
I didn't know Perplexity but I would like to test it