Figma 如何做产品：什么有效、什么无效，以及设计、工程与产品的未来 (Yuhki Yamashita)

▍嘉宾：尤基·山下（Yuhki Yamashita）

尤基·山下是 Figma 的首席产品官（CPO），主导这个全球最受欢迎的设计平台之一的产品开发：

• 微软起步：产品经理生涯始于微软，入行第一课是「把自己当成高级秘书」——帮工程师扫清障碍，这门哲学贯穿其职业生涯；
• Uber 时代：任乘客端产品负责人，主导了 Uber 体验的彻底改造——预先输入目的地、直接显示价格与时间，把「看到收据才知道多少钱」的旧体验送进历史；
• Figma 时代：掌管从 Figma Design 到 FigJam、Figma Slides、Figma Buzz、Figma Make 的多产品矩阵扩张。

▍关于 Figma

Figma 是总部位于旧金山的协作设计软件公司，2012 年由迪伦·菲尔德（Dylan Field）与埃文·华莱士（Evan Wallace）创立，以浏览器端实时多人协作颠覆了设计工具行业。

• 核心模式：免费增值（freemium）加自下而上的社区传播——先俘获设计师个体，再向企业销售团队席位；产品从 Figma Design 扩展为覆盖头脑风暴、开发交付、幻灯片、营销素材与 AI 生成的八大产品线；
• 关键节点：2022 年 9 月 Adobe 宣布以约 200 亿美元收购 Figma，2023 年 12 月因欧美反垄断审查告吹（Adobe 支付 10 亿美元分手费）；2025 年 7 月 31 日 Figma 在纽交所上市（代码 FIG），首日收盘大涨 250%，完全稀释市值一度近 680 亿美元。

Harry： 这里是 20Product，我是哈里·斯特宾斯（Harry Stebbings）。这档节目带你走进当今最杰出的产品领导者，看看他们如何带领那些最顶尖的产品团队。今天坐上嘉宾席的是 Figma 首席产品官（CPO）尤基·山下（Yuhki Yamashita），他主导着全球最受欢迎的设计平台之一的产品开发。此前他是 Uber 的产品负责人，掌管全球数百万用户使用的核心乘客端体验。尤基是产品叙事和团队建设的大师，重新定义了世界级数字产品的打造与规模化方式。今天他能来到伦敦的演播室，我兴奋极了。

尤基，我太期待这期了，兄弟。我们第一次见面是在新冠疫情期间 Linktree 的一场圆桌活动上，这期节目我盼了很久。谢谢你亲自到场。

Yuhki： 谢谢邀请。

开场：搬家搬出来的用户同理心

Harry： 别客气。刚才我们聊到了你的成长经历，你说你小时候经常搬家，提到了东京，还有其他一些你童年生活过的地方。我想从这里开始：频繁搬家对你今天思考产品和设计的方式有什么影响？

Yuhki： 回头看，小时候频繁搬家这件事，对一个小孩来说，你只想融入环境。你交了很多朋友，却不得不抛下他们，搬到一个新地方，学习一种新文化。在这个过程中，我觉得我必须抛掉自己关于"事情该怎么运转"的所有预设。比如一些很基础的事：在新加坡，你拿勺子和叉子的方式就跟菲律宾不一样。正是这些小事，会让你在某种程度上质疑自己的每一个预设。

我觉得这帮我学会了换位思考，建立了最基本的用户同理心。而这些都是设计的核心信条。

Harry： 接下来我会不断问一些不太厚道的问题，你要是不喜欢，我们可以剪掉。

Yuhki： 没事，尽管问。

「简单永远更好」？先质疑这条教条

Harry： 有没有哪个设计上的预设，是我们本不该质疑、却在质疑的？

Yuhki： 我认为一切都应该永远被质疑。设计师的工作就是永远问一句"如果……会怎样"。比如对我来说，"简单永远更好"——真的吗？我们就该质疑这个预设。

Harry： 那么，"简单永远更好"到什么程度会变成偷懒，而不是防止功能蔓延？

Yuhki： 问得好。迪伦·菲尔德（Dylan Field）总说简单更好，这话有它的道理。但简单是一种感知，不一定是现实。如果把"简单永远更好"推到极端，你可能就不再添加新功能、不再增加新能力了，而我不认为那总是对的。

Harry： 顺着这个思路想——简单更好，但又要加新功能。我觉得对一个做产品的局外人来说，最难的是：如何既满足只想要最先进功能的超级用户，又照顾好那些只需要基础功能、需要很多手把手引导的用户，同时不疏远任何一方？

Yuhki： 确实非常难。某种程度上，极少有产品能以那种方式演进。在 Figma，我们的思路是给人们提供不同的使用形态，让他们待在同一个作品里，却用不同的视角去看它。比如我们刚发布的产品 Figma Buzz，里面有设计模式（design mode），类似专家模式、困难模式，里面有设计师熟悉的一切：布局、变量、设计系统——这些对非设计师来说有点陌生。

但我们也有常规模式，大家进来就是一个非常简单的编辑器，可以用他们预期的方式编辑内容。这种双重性——给不同的人提供看同一个界面的不同视角——就是我们为一侧保留简单、为另一侧保留强大能力的一种方式。

Harry： 你刚才提到了新产品里的设计模式。

Yuhki： 对，设计模式是我们产品里的一个功能。Figma Buzz 是我们面向营销人员的新产品之一，Figma Slides 也有设计模式。它平时看起来和其他任何幻灯片产品一样，但你可以打开设计模式，获得你期望从 Figma Design 得到的所有功能。

新产品的诞生：用户 hack、Maker Week 与产品评审

Harry： 你们怎么决定进入哪些新品类？我很喜欢这个节奏，很妙，但管他呢——你们怎么判断哪些新品类要进、哪些不碰？你大可以看着 Figma Slides 说，Pitch、Canva 之类已经做得很好了，这不是我们的主战场；也可以说我们就是要去做。这个产品决策你是怎么想的？

Yuhki： 我的一位产品导师叫希瓦·拉贾拉曼（Shiva Rajaraman），他曾是我在 YouTube 时的经理，后来做了很多了不起的事。他常说，要观察人们怎么"hack"你的产品，把这当作灵感，因为那是真实的信号——他们不惜绕路也要向你证明自己有这个需求，尽管你并没有满足它。

所以对我们来说，很多新产品都来自这种观察。疫情期间，人们把 Figma Design 当成隔离期间聚在一起的空间，这促使我们考虑为他们造一个专门的空间，也就是我们的头脑风暴工具 FigJam。Slides 也一样：在我们做 Slides 产品之前，已经有 350 万份演示文稿是在 Figma Design 里做出来的，尽管它本来不是干这个的。这对我们就是动力。这类方向我们很容易排定优先级，因为需求已经摆在那儿了。

Harry： 能不能带我走进 Figma 这台神奇的产品机器内部，看看接下来会发生什么？我们看到有人在"hack"产品，做出了 350 万份幻灯片，然后有人把它带到会上说：我觉得我们该做这个产品。接下来的产品流程是什么样的？

Yuhki： 就刚才聊到的这些产品来说，通常 Figma 内部会有一群人——我们叫他们 figmate——对某件事特别上头。他们可能会等到我们的 Maker Week（创客周），那基本相当于黑客周，然后做出一个概念验证（POC）来提案。至少在我们的文化里，造出一个大家能实际上手用的东西，更能说服人们相信这个想法站得住脚，甚至比想象中更简单。通常正是这一点，把这个项目推上路线图，或者至少让它进入被认真考虑的行列。

Harry： Maker Week 多久办一次？

Yuhki： 一年一次。有时候一年办两次。

Harry： 在这个变化比以往任何时候都快的世界里，你们是不是也比以往任何时候都更鼓励人们鼓捣业余项目？

Yuhki： 我认为现在每个产品团队都必须思考如何做原型、如何把玩新能力，因为一切都变化太快了。Maker Week 这类项目有帮助，但我认为这是我们所有人都需要习得的核心能力。

Harry： 完全同意。比起听人讲，人们更容易被一个能摸到的实体打动。那然后呢？三个 figmate 被某个想法点燃了，做出了早期版本。接下来会发生什么？

Yuhki： 通常会有一个提案时刻，算是一种产品评审（product review）。往往最好能同时讲清楚：它的差异化在哪？配套的信息传达是什么？我们怎么围绕它讲故事？因为，它到底是个平平无奇的幻灯片产品，还是有什么特别之处？"为什么它独属于 Figma"是其中很大的一部分。

第二点是对齐我们的目标。我们这行是帮团队打造产品的，哪怕是幻灯片这种东西，也有很多围绕产品团队的用例。我们怎么把这些用例做出来？为什么它比别的幻灯片产品更好？

PRD 之死与北极星指标树

Harry： 作为播客主播，我经常放一些暴论，然后等着你来打圆场。产品需求文档（PRD）死了吗？现在有人说，在如此敏捷的时代，已经不需要 PRD 了。PRD 死了吗？它的用法又发生了什么变化？

Yuhki： 你想象的那种形态可能确实死了——那种密密麻麻、等着被照着实现的规格说明书。我记得我刚大学毕业进微软的时候，我们的 PRD 长达 20 页，里面全是边界用例的表格。如果 PRD 里出了错，你得走一整套叫"设计变更申请"的流程，算是一种惩罚。

Harry： 我感觉自己像在给 Grammarly 打广告。

Yuhki： 那种形式的东西，我觉得大概已经过时了，即便在微软，现在也是如此。但一个集中的地方——写明"这是目标"或"我们想做成什么"——一个大家能随时回去查阅的事实源，比如"我现在正要做个决策，我想知道这个决策对不对"，这样一个能阐明北极星（North Star）的东西，对锚定所有人仍然重要。

Harry： 同一家公司里，不同产品能有不同的北极星吗？还是必须统一？

Yuhki： 拿我们产品团队的做法来说，我们定目标时喜欢做一种叫 KPI 树（KPI tree）的东西。这其实是我在 Uber 学到的：你有一个指标，但它向上汇聚到什么？有时它通过数学关系向上汇聚，有时靠假设。比如你的团队专注客户满意度，其中有个假设是：它最终会汇聚到用户参与度，进而汇聚到周活跃用户。

而在 Uber，一切的最顶端是行程量，所有指标都从那里层层分解。所以我认为，虽然每个人都可以盯住树上不同的部分，但总得有人负责通盘思考，确保这一切确实在向上汇聚。

截图测试：让产品自己讲故事

Harry： 你刚才把故事和信息传达也列为其中一环。在 Figma 或 Uber，你最骄傲的产品故事或信息传达是哪一个？你们在其中做对了什么？

Yuhki： 最好的故事是，你看着一个东西，它自己就把故事讲了。比如我喜欢的"截图测试"（screenshot test）：你只有一张截图——最多放宽到一个 GIF——但在没有任何文字说明的情况下，人们立刻就能明白它的价值。

在 Uber 时，我负责乘客端 App 的重新设计，我们推出了预先定价（upfront pricing）——首页上直接显示时间和真实价格。整个改版要讲什么，一目了然。而太多时候，人们最后不得不带着用户过一遍教程：让我给你解释为什么这个产品更好。在我看来，这不只是故事的问题，也是对设计的一种约束——你可能逼得还不够狠，没做到让"怎么用、为什么有价值"不言自明。

Harry： 我已经能想象很多创始人在听的时候说：可是我的产品太复杂了。

Yuhki： 嗯。

Harry： 我永远做不到那样。

Yuhki： 嗯。

Harry： 这是因为有些产品确实复杂到做不到，还是说那是设计没做好的表现？

Yuhki： 我认为对你的受众来说，总该有某个时刻，你看着它就会说：哇，太棒了。就像我说的，可以是一个 GIF，如果需要几步，就把几步浓缩进去。但如果出现某个时刻，你不得不说"等等，让我解释一下"，或者要连放三个提示气泡来说明，那就有点可疑了。

Harry： 好，我们有了那张漂亮的图——截图，或者 GIF——也有了提案时刻。那个提案时刻是什么样的？在"做还是不做"的决策上，你是怎么思考的？

Yuhki： 每个产品都有它的魔力，对吧？每家公司都会以某种方式谈论魔力。当你看到一个特别、独一无二的东西时，会有一种发自本能的反应，这通常是很强的信号，说明这里有些对的东西。如果这种感觉不存在，就继续打磨，直到它出现；或者告诉自己：现在还不行。这是我非常看重的东西。

Code Layers 与「唯一事实来源是代码」

Harry： 在 Figma 内部，哪个新产品提案让大家觉得最特别？当时是全票一致吗？还是说提案过程中，大家对什么的喜好也出现过巨大分歧？

Yuhki： 我想到最近的一个。我们推出了一个叫 Code Layers 的功能，当时内部的产品名叫 Living Designs。想法是：你刚画好一张静态设计，按下一个按钮，它就变成了代码，然后你可以通过提示词（prompt）用代码继续增强它。

我记得那是个 Maker Week 项目，所有人都惊叹——突然之间，那些原本在 Figma Design 里做不到的事，借助代码的力量全都变得可能了，而且还是基于你刚画的那张设计。就好像设计活了过来。那种 Zoom 聊天区全场沸腾的时刻，所有人都在说——

Harry： 作为投资人，我经常思考切入点的问题。很多时候你输就输在切入点错了——想法对、方案也对，但切入点错了。谈到未来做产品的切入点，你刚才提到把设计变成活的代码；此外还有另一路，就是实时构建，比如 Bolt、Lovable 那类产品——不一定从纯设计开始，而是边做边建。你怎么看未来切入点的格局？

Yuhki： 未来一定是一个有无数切入点的世界，因为打造产品本来就是一件极其复杂、涉及方方面面的事。我们喜欢谈我们的北极星：怎么把一个想法以最快速度变成用户手里的成品。有些情况下，人们只把想法构思成了一句话，那完全可以从那里开始。

但对很多人来说，他们已经开始用某种方式画草图了，因为语言不足以传达概念，或者设计里有某种本质的东西，他们想先传达出来。设计师是非常视觉化的人，是那种先冲到白板前开始画、一个字都还没写的人。还有一些开发者，他们可能已有现成的代码库，想法也由此产生，你也要允许他们从那里开始设计概念。

Harry： 你觉得世界会分化成专业和业余两拨吗？专业人士用 Figma、以设计为先，业余用户用 Lovable 或 Bolt 这类工具边做边建？

Yuhki： 确实，Figma 传统上更偏专业用户，但我们的愿景是任何人来到 Figma 都能立刻上手。比如我们做 Figma Make 的一个动机，就是让只有一个文字概念的人也能开始动手，然后在产出的基础上迭代——可以靠队友帮忙，也可以自己来。

Harry： 说到决策，你记忆中 Figma 内部最具争议的新产品决策是什么？为什么有争议？你现在回头看怎么想？

Yuhki： 我觉得最大的一个就是 Figma Make 里的设定：唯一事实来源（source of truth）是代码。我们要想办法把你的设计翻译成代码，然后让你通过代码来迭代，因为代码的表达力极强，而大语言模型（LLM）又特别擅长写代码。

这对我们来说某种程度上是个很大的转变，因为在此之前，事实来源一直是设计本身的某种表征。当然这两者并非截然不同，它们关联很紧密。但把锚点定在代码上——尤其是对 Figma Make 这个产品——对我们而言感觉确实不一样。

Harry： 团队内部在看待这件事的方式上有过分歧吗？

Yuhki： 倒谈不上分歧，但确实感觉很新鲜。换作两三年前，我们不会这么想。

Harry： 当出现不同意见、或者有人说"我对这个没把握"的时候，你们怎么处理？绿灯和红灯之间怎么权衡？

Yuhki： 我觉得归根结底要看用户想要什么。就我们而言，客户想要的是不受所用工具的束缚，拥有用任何媒介来表达自己的能力。

这也是为什么我认为我们对设计的定义在过去一两年里几乎扩展了。你可能以为设计就是在画布上做视觉操作、画几张稿，但实际上，通过提示词反复迭代同样成立，写代码也同样成立——因为通过写代码来设计可能更快。

一旦接受这种世界观——应该允许你在产品开发流程的任何环节、用任何媒介、任何输入方式来做设计——那我们平台就必须引入这些能力，这就顺理成章了。

角色的坍缩：设计、工程与产品的未来

Harry： 你刚才提到设计的外延在扩大，还有产品和设计的融合。从很多方面看，这些不同职能似乎正在坍缩成一个"超级个体"。展望未来，考虑到这种融合与边界模糊，你认为产品团队的结构会是什么样？

Yuhki： 这种边界模糊在 AI 出现之前就在发生了，比如设计师学写代码、产品经理（PM）学一点设计。我加入 Figma 的原因之一，恰恰就是边界正在被抹平。我一直对设计师和 PM 之间那条人为划出的线感到沮丧——这两个角色我都干过。

很大程度上，这是因为人们被推到了技术栈的更上层。工程师不再需要理解底层发生的一切，他们调用一堆强大的库和 API，照样高效产出。设计师也很少再逐个像素地抠像素了，他们是在把设计系统里现成的组件拼起来。

于是所有人都在越来越高的抽象层级上工作，也都被推向同一个地带：专注在最具战略性的事情上，也就是解决问题、解决用户的问题。所以我认为这些学科确实在——不知道是不是该叫"收敛"——但肯定都在抽象层级上一起往上走。

Harry： 你们今天的团队结构是什么样？pod 小组长什么样？五年后又会是什么样？

Yuhki： 好问题。由于边界在模糊，很容易想象它们会进一步坍缩成某种通才型的产品构建角色，再配上少数几个专家，在各自领域里钻得更深、把手艺做到更高。

但话说回来，一群人各自往不同极端去推，这种状态其实非常健康。我记得 Figma 有过一个设计实习生，想试试做 PM。我们就说，好啊，这个项目你既当 PM 又当设计。结果他很挣扎——一戴上 PM 的帽子，他就开始自我设限，变得极度务实，某种程度上扼杀了自己做梦的能力。

而有时候设计师就是一心扑在终端用户身上，把做对用户有利的事摆在一切之上，他们会去推动改变甚至移除业务约束、技术约束。正是这种张力在推动产品前进。所以我认为必须有人去顶这些位置：为业务代言、为用户代言、为技术可行性代言。未来这些未必还由我们今天熟知的传统角色来承担，但这些极端立场对于做出最好的产品几乎是必需的。

Harry： 那回到 pod 小组，今天的 pod 是什么样？五年后呢？

Yuhki： 每个人都应该以某种方式参与设计。无论今天还是未来，都是如此。

Harry： 那反过来，每个人都应该以某种方式参与构建吗？如果人人都该设计，人人是不是也该构建？

Yuhki： 也有可能。我们越来越发现，一张静态稿已经不足以说服别人了，你需要一个足够真实的原型，需要用这种方式去检验、去验证你的想法。所以没错，某种形式的构建对每个人都会变得重要。

Harry： 恕我问得基础。这就是和伦尼（Lenny）这样真正懂产品的人聊天、和与我这种努力理解产品的风险投资人聊天的区别——差别很大。如果一个团队有 10 个人，今天工程、设计、PM 的比例怎么分？五年或十年后又是什么样？

Yuhki： 今天典型的情况是 8 到 10 个工程师，配一个 PM 和一个设计师——大概就是一个典型 pod 小组的样子，当然取决于产品的性质。

Harry： 那五年后呢，你觉得会变成什么样？

Yuhki： 你看，猜测未来可是你们的本行。我会说比例可能会收窄一点——每种职能、每种考量会被更均衡地代表。因为真正的杠杆点在于想清楚我们要构建什么、想清楚用户体验是什么，人类注意力的重心会集中在那里。

Harry： 所以工程师会变少。

Yuhki： 这很难说。五年后工程师是多是少，我不认为会比今天少。但我们会比今天做得更多。随着我们扩展更多产品，我不指望工程师人数会同比例增长。

Harry： 内部的技术栈有什么变化？你们强制要求用 Cursor、Windsurf 吗？怎么推动工程团队站在最前沿？

Yuhki： 他们确实在大量探索各种 AI 辅助的代码编辑器。

Harry： 有没有强制指定某一款？或者主推一两个？我们前阵子请了多邻国（Duolingo），他们说全公司都用 Cursor。

Yuhki： 没有强制。我们一向只想确保大家用上最好的工具。大家发现工具之间的差异时，自然会有讨论。

Harry： 你觉得这些工具是让普通工程师变成 10 倍工程师，还是让 10 倍工程师变成千倍工程师？必须选一个的话？

Yuhki： 我还是想回到我们自己的框架：AI 对设计的作用是既降低地板、又抬高天花板。放在我们的场景是设计，放在这里是写代码——它让这件事对每个人都更可及、更容易上手，从这个意义上欢迎了更多人进来；同时也抬高了天花板，让最好的设计师、最好的工程师产出更高。两端都在兑现，我认为这就是我们正在看到的现实。

约束的爱与恨

Harry： 你刚才用了一个很妙的词：约束。我一直在纠结什么是好约束、什么是坏约束。你今天带产品团队时怎么想这个问题？

Yuhki： 我觉得每个人对约束都是爱恨交加。身处创意行业，约束催生创意。没有约束，几乎……就没意思了。

Harry： 对。

Yuhki： 或者说，约束在某种程度上给你灵感。而现实是，有些约束是拍脑袋定的——我们说要在某个时间节点前发布，这就是个人为约束。但看到人们在这种约束下做出的东西，往往很惊人。

所以我认为有约束是重要的，但错误的约束也很危险。比如一个团队默认产品的某个运作方式不能动，只能在现有基础上往上搭——这可能就是个坏约束，因为它会带来平庸的体验。能识别出这类约束，是产品思维里非常重要的一环。

Harry： 有没有哪个约束你原以为是好的、结果证明是坏的？我举个自己的例子：我曾经坚决不做视频——不上 YouTube，只做音频，因为我们节目量大、音频做得也很好，而且嘉宾面对镜头没那么自在。我当时觉得"只做音频"这个渠道约束非常好。结果大错特错。我误解了用户，他们想要的是更有视觉感的呈现。这就是我看走眼的一个"好约束"。

Yuhki： 我想到一个：Figma 早期产品哲学的核心之一是无限画布的力量。Figma 的美妙之处在于你进入的是一个某种意义上毫无约束的空间——你可以把东西越建越大，朝两个方向无限延展画布。

这对协作来说棒极了，因为大家可以在彼此的基础上不断搭建而互不干扰。相比之下，文档是一维的，你往里加内容就得把别的东西往下挤，要跟空间较劲。这是 Figma 设计和 FigJam 美妙之处的重要部分。

但当我们开始为其他受众构建其他产品时，我们意识到：不对，有人会被二维画布搞糊涂，他们更喜欢一次只看一件事的工作流。所以当我们考虑开发者、产品经理等其他类型的用户时，发现某些场景下把维度降下来反而更好。

翻车复盘：Make Design 的教训

Harry： 多快能判断一个新产品方向错了——它不是你想的那样？

Yuhki： 要判断它"跑不通"是很快的：把它放到一些用户面前，看能不能立住。我们常做 Beta 测试，把产品交给一个团队，一周后回访看他们还在不在用。这个信号很明显。

但"好"和"卓越"之间的差别就微妙多了，有时你得让它跑一阵子，或者放到真实世界里观察，再或者拿各种不同类型的用户去测，才能分辨。所以我的结论是：完全行不通的东西一眼就能看出来；但要区分"好"和"惊艳"，需要更多时间。

Harry： 最惨的一次翻车是什么——发布之后就是不行、而且显而易见的那种？你从中学到了什么？

Yuhki： 至少从反响的角度看，我们前年做过一些 AI 功能，当时叫 Make Design——输入一段提示词，它就在画布上生成一些设计。

功能本身很简单：你写提示词，它用一些模板和基础变量，让模板看起来更贴合你的使用场景，或者填充一些更有动态感的内容。说到底，它就是把提示词和模板做匹配。

但因为它叫 Make Design，又因为大家并不清楚它的工作原理，我们的社区完全摸不透我们的意图：你们到底想用这功能干什么？它到底拿什么数据训练的？招来了一大堆反对声。

而实际上，我们的本意——后来也改了名——是让它充当"第一稿"，帮你起个头，而不是要取代设计这件事本身，之后还得靠你迭代。我们还想把底层机制讲得更清楚，于是专门写了一整篇博客解释它是怎么工作的。在最近的产品里，我们也更透明了：用了什么模型、具体怎么运作，都讲明白。

Harry： 这是否有违我们先前说的"截图测试"精神？就是需要把沟通做到水晶般透彻这件事？

Yuhki： 是的。我们当时是事后补救，才不得不做这一堆解释。本来有机会在产品里就把名字起得更清楚、把话讲明白。

到今天，你截一张 Figma Make 的图就能看到它是由 Claude 驱动的。好，没有任何疑问——你清楚地知道代码是从哪生成的。这些是我们本可以更早用上的教训。但当时我们的想法是"替你搞定一切，不拿细节烦你"，这个出发点让我们一开始选择了更隐晦的做法。

PM 是产品的 CEO 吗

Harry： 说到这个流程，通常是由 PM 来主导的。我在节目里常听到一种说法：PM 是产品的 CEO。这话对吗——PM 真的是产品的 CEO 吗？未来几年，做 PM 这件事又会怎么变？

Yuhki： 我的产品经理（PM）生涯是在微软起步的。当时我的经理跟我说的第一句话就是：你就把自己当成一个高级秘书。你的工作是帮工程师扫清障碍，这就是你的职责。这个观念在我心里扎了很久——它背后是一种世界观：你没有任何硬技能，你的存在就是去补位填缝。所以这一直是我的职业哲学。

设计师和工程师里有很多才华横溢的人，他们对自己手艺的掌控力是我永远达不到的。所以我从来就对那套"CEO 式"的话语没什么共鸣。

Harry： 现在岗位边界越来越模糊，原本由你来填的缝隙，可以说正在被抹平。很多人跟我说，几年后根本就不会有 PM 这个岗位了。

Yuhki： 我不排斥这种可能。但我认为这项工作的本质依然非常重要。我听过对 PM 最简洁的一种解释是：他们对"为什么"负责。我们为什么要做这件事？为什么它现在是优先级最高的？为什么是这个用例、这个用户群？把这些问题讲清楚，其他每个人才能做出真正好的决策。

我认为总得有人来扮演这个角色。这个人不一定非得顶着"产品经理"的头衔，但可以肯定的是，最优秀的产品经理都能创造出这种清晰度。

Harry： 可这难道不应该是创始人的事吗？"为什么"不该由创始人来定吗？

Yuhki： 在我看来，"为什么"是层层递进的。最深处那个关乎存在意义的"为什么"，确实归创始人所有。在小公司里，创始人就是那个包揽一切的人——我甚至认为小公司根本不该设 PM，因为创始人自己就在扮演这个角色。但当公司到了一定规模，你就需要……

Harry： Figma 可以没有 PM 吗？

Yuhki： 这个问题我显然有立场偏见。我认为可以——前提是其他职能的人能站出来承担这个角色。工程和设计团队里确实有很多人能胜任。但你不可能一夜之间就做到，因为我们整个职能体系就是围绕"深挖为什么"、围绕与客户深度协作搭建起来的，这些时间和技能是需要……

听起来我好像在反对 PM，但完全不是。PM 是很棒的。

Harry： 可 PM 的存在，难道不恰恰让割裂状态得以延续吗？如果你在所有职能之间放了这么一层"胶水"，各职能就不必像没有这层胶水时那样直接互动了——一旦把 PM 抽走，跨职能沟通会突然变得至关重要，因为他们必须自己去回答那个"为什么"。

Yuhki： 对。但这就回到我一开始说的那点：一个人很难同时替两边使劲。PM 最独特的地方在于，他们是不同观点之间权衡取舍的协调者——工程这边说什么可行、什么不可行，设计师那边说什么对用户才是对的，PM 要在中间调停。

当然，两边理论上可以自己协调。但在一家复杂的公司里，来自不同职能的观点太多了，都得有人统筹考虑。让设计师和工程师各自全力为自己的立场辩护，反而更简单——因为那正是他们浸淫最深的东西。而产品经理的独特价值，就是能客观地审视所有这些信息，想清楚目标和"为什么"，再决定怎样才是最佳平衡。这种领导力，我认为很重要。

讲故事、趣味与细节

Harry： 最优秀的产品人身上，最不显而易见的特质是什么？我们之前聊到，我说过，加入过一个游戏公会、甚至当过公会会长，是预测一个人能否成为成功创始人最准的信号之一。那么，有没有哪些特质、行为模式或背景上的共性，能造就最好的产品人？

Yuhki： 对我来说，答案还是讲故事的能力。举个具体的例子：我认为一个厉害的 PM，能把一件枯燥到极点的事讲得像生死攸关一样。所以我面试 PM 时总会问：说说你牵头做过哪些项目？如果无论哪个领域，他都没法把这件事讲得让我提起兴趣，我就会怀疑他凝聚团队的能力。

因为这份工作的一部分，就是要论证为什么这件事现在非做不可——否则值得做的事多了去了。团队必须围绕这件事被点燃。哪怕是个无比枯燥的合规项目，好的产品经理也能把它讲得极具存亡感、极具战略意义，让所有人都为之兴奋。这就是我看重的本事。

Harry： 有件事我觉得特别重要。我听过乔尼·艾夫（Johnny Ive）一场很精彩的演讲，他谈到设计中快乐与趣味的重要性。在用户注意力空前短暂的今天，你怎么看待趣味性和实用性之间的关系？产品做得好玩，重要吗？

Yuhki： 趣味能让人看到产品背后的人，某种程度上也能让人看到用心。回顾我的职业生涯，最让我激动的时刻，都是有人决定把某件事做到极致——不是因为有哪个 OKR 要完成，而是因为他们光是想到用户发现那个小细节时的反应就兴奋不已，想到人们会开始谈论它——哪怕它并不服务于漏斗里的任何一个指标。

那种自豪感，那种对匠艺的自豪，首先是让做产品这件事变得有趣的东西。说到底，我们在这里是因为这是份工作，但也因为我们是设计师、是匠人，这才是我们的快乐所在。如果你在自己的产品里找不到这样的时刻，那挺可悲的。

Harry： 说起来有意思，Spotify 的古斯塔夫·索德斯特伦（Gustav Söderström）——我觉得他非常出色——总说：细节不是细节，细节就是产品。我觉得这句话太重要了。既然细节如此重要，你怎么权衡什么时候该先发布上线，什么时候该把每一个微小的地方打磨到完美？

Yuhki： 这是个永恒的问题。我觉得这也取决于公司文化。比如在 Figma，我们的文化就是每个人都想把细节做对，所以有时候我们反而要鼓励大家：放轻松，先把东西发出去。

Harry： 当细节处于这么核心的位置时，你很难给团队制造紧迫感吗？

Yuhki： 这里有一个非常具体的取舍，围绕"学习"展开：打磨细节是为了搞清楚哪些细节值得打磨，还是纯粹为了打磨而打磨？如果你打磨的是关键环节——它能帮你判断这个产品在市场上到底行不行——那当然值得。

但如果你开始打磨的是那些更偏臆测的部分，或者你不确定会不会有人用的功能，那我宁愿先弄清楚我们有没有总体上的产品市场契合（PMF），或者先搞清楚用户到底被产品的哪些部分吸引，然后再把注意力加码到那里。

Harry： 在衡量"用户喜爱"这件事上，你们产品团队的北极星指标是什么？

Yuhki： 我们的主力产品是一个用户每周用五天、每天深度使用好几个小时的产品。我们的第一款产品 Figma Design，一直定义着"让人深度依赖的工具"该是什么样。这就是我们的黄金标准。

Harry： 但"深度依赖"怎么量化？

Yuhki： 我们用一个叫 ND7 的指标，比如用户一周里有几天在用你的产品。

Harry： 对你们来说是五天。

Yuhki： 对，因为对设计师来说，这就是他们的核心工作。

分发就是一切

Harry： 你提到了打造漂亮产品这件事，以及你们对打磨颗粒度的讲究。我一直在纠结一个问题："只要造出来，用户自然来"这话到底成不成立。你说过，人们更愿意分享自己喜爱的产品。那么，只要把产品做漂亮，用户就会来吗？还是根本不是这么回事？

Yuhki： 分发就是一切，在今天尤其如此。你可以做出最漂亮的东西，但如果没人发现，一切归零。Figma 是让我对这一点体会最深的地方。我们的创始人迪伦从一开始就非常重视设计师社区，一心让他们谈论 Figma。

他做的最早的几件事之一，就是把设计圈 Twitter（Design Twitter）可视化成一张关系图谱，找出设计师关注最多的是哪些人，然后直接去找这些设计师，请他们给 Figma 提反馈，让他们为 Figma 兴奋起来。这就是他的策略，而且奏效了。当时的设计圈 Twitter 就是这么运转的——他们以极深的方式互相影响彼此的选择。

如果他没做这件事，我不确定我们还能不能看到那样的加速增长，能不能赢得社区的认同。这通常不是我的思维方式——我更专注于内部，想着怎么把东西做好——但我确实认为分发极其重要。当然，我也不是说它就是唯一重要的事。

Harry： 产品和分发，重要性占比怎么分？70：30？60：40？

Yuhki： 如今确实有很多东西演示效果惊艳，大家都在谈论，所有人都去试用，结果却没有兑现承诺。而一旦发生这种情况，想把那些用户赢回来、让他们再回来，就难太多了。

我认为最重要的，是先找到一小群疯狂热爱你产品的人，然后——

Harry： 一千个铁杆粉丝。

Yuhki： 我不知道如今一千个还够不够，但差不多是那个量级。这就是我的产品打造之道。

Harry： 你刚才提到迪伦很早就专注于社区。你也见过很多新产品来了又走。在你看来，周围的人在社区建设上犯的最大错误是什么？

Yuhki： 和社区的关系极其重要，但你也得学会怎么跟他们对话。我们总是被用户提出的需求牵引着走，但我们必须问出更深层的问题。一味地照单全收、用户要什么就做什么，这很容易。但我们想追问的是：你为什么要这个功能？他们会说：因为我遇到了这个问题。那你一开始为什么会遇到这个问题？

在 Figma，工程师有个"五个为什么"（five whys）的仪式，用来刨根问底：这个错误为什么会发生？一层层挖下去，直到找到根本原因。我认为同样的方法也必须用在社区身上。

这不是说社区是错的。用户并不总是以"问题"的方式表达需求，他们可能只是随口说出一个想到的功能。所以重要的是和他们建立更深的关系，让你能问出：这个主意很棒，但能不能帮我理解一下，你为什么想要它？也许我们能一起想出更好的方案。

多产品组合：整合、学习与砍掉的时机

Harry： 你最想改变 Figma 设计上的哪一点？可以是横向的整体层面，也可以是某个具体产品，但因为某些原因你改不了——可能是迪伦，可能是产品团队，可能什么都是。

Yuhki： 我希望我们各个产品之间的整合能比今天更紧密。我们最近刚从四个产品扩到八个，这很令人兴奋，但在体验的一体感上还有很大空间——你可以从一个产品开始，然后无缝地流转到另一个。

Harry： 你觉得这么快铺开这么多产品是正确的决定吗？发布节奏非常快，可以说是一次性全放出来了。有时候你得一点一点喂给用户，他们才能消化这种扩张。

Yuhki： 我觉得时间会给出答案。这是我们第一次尝试这种做法，会从中学习到很多。但这也反映了我们用户群此刻的多样性：很多人只对其中一部分产品感兴趣，我们也正在触达不同的人群。

所以对普通用户来说，他们未必会觉得是"要学四个新产品"——因为其中两三个正好打中了他们，他们会先去探索那几个。

Harry： 说到这四个新产品，它们都能成吗？如果放到三年后看，这四个产品还会都在吗？还是说更可能砍掉两个？

Yuhki： 我们发布任何产品时，当然不会抱着"以后砍掉它"的预设。但与此同时，很多产品还在 beta 阶段，我们本来就打算从中学习，如果机会合适就去——产品会在 beta 待多久？——我们认为需要多久就待多久，直到产品达到我们引以为傲的状态。其中有些是相当复杂的产品。

做工具跟做典型的消费品很不一样——消费品有个漏斗，你盯着指标做优化；而工具是造出来让别人拿它去创造别的东西的。所以你很难一开始就预想到，别人会拿着你的工具做出什么来。你当然会带着一些预设的用例起步，但用户永远会给你惊喜。

所以我认为，做工具的人得保有一份谦卑：让用户的创作告诉你该把工具带向哪里、该在哪里加倍投入、哪些行得通哪些行不通。正因如此，我们需要给用户足够的时间，让他们在工具上创作。

Harry： 我在想这会不会有点像裁员——你总是早早就心知肚明，却拖了太久才动手。我的问题是：你会不会明知一个产品不行了，却让它拖得太久？

Yuhki： 在我的职业生涯里，我确实见过一些本该更早收缩、更早关停的产品。

Harry： 你最先想到的是哪个？你从中学到了什么？

Yuhki： 这个我恐怕不方便评论。

Harry： 你脸上就写着"我清清楚楚知道是哪个产品，但我不想太得罪人"——顺便说，这回答完全合理，太有意思了。那么，有什么产品是你在 Figma 还没做、但最想做的？为什么？

Yuhki： 尽管我们总爱以"产品"为单位来谈论成绩，但说到底，我们要帮用户做的事只有一件：构建软件、构建数字产品。所以对我来说，问题不是"我还需要再做一个什么产品来帮助团队"，而是"今天还有哪些空白，让这件事依然很难做"。

对我们来说，答案可能是给现有产品加功能，也可能是让产品之间的连接更紧密，诸如此类。如果你随便问一个人：今天做产品难在哪儿？他能列出一千件让它困难、耗时的事情。而那些，就是我们要去做的东西。

设计与实现的鸿沟

Harry： 对你来说，答案是什么？

Yuhki： 人们设计出来的东西，和最终交到用户手里的东西之间，仍然存在严重的脱节。我常做一个思想实验：下次设计师向你展示作品集时，他们展示的是漂亮的 mock 稿，还是线上产品的真实截图？大概率是前者——在完美环境里、用完美数据做出来的设计。

我的目标是，希望他们能自信到随便在街上拦下一个人，掏出手机调出对方屏幕上的真实界面，然后说：这就是我的设计，我为此感到骄傲。

Harry： 设计与实现之间的鸿沟，是特性还是缺陷？

Yuhki： 问得好。我认为今天它主要是个缺陷，只是偶尔伪装成特性。设计师总是在超前设计，脑子里想的是 V1、V2、下一代版本，所以设计稿自然总是显得更好一点——他们想得远，位置又在流程上游。

但问题在于，设计师常常超前得太远，没有立足于产品今天的真实状态。这么说你能理解吧。

重新点燃团队：质量周与「小更新，大惊喜」

Harry： 你的团队有没有陷入过"产品低谷"？我指的是缺乏创造力、缺乏干劲的状态。当团队变得有点套路化时，你怎么重新点燃一支产品团队，让他们重新变得有创造力、有野心、有饥渴感、有热情？

Yuhki： 当然遇到过。有时候是因为一个难题卡了太久，团队一直在撞墙。解法有很多种——可以调整团队构成，也可以重新审视某些约束条件，因为可能是其中某个东西让大家觉得自己的方案空间被限制死了。

而 Maker Week（创客周）这类机制，恰恰就是用来打破日常节奏的那种律动。

Harry： 一年一次够吗？

Yuhki： 可能不够。有些团队会自己办黑客周。我个人最喜欢的其实是"质量周"（quality week）——大家暂时放下路线图，回头去打磨那些当初没时间做的东西，或者修掉某个存在已久的 bug。这类安排同样能把你从手头的项目里拉出来。

事实上，我们最受欢迎的一些发布，就是这类小东西，我们给它们起了个品牌名叫"小更新，大惊喜"（little big updates）。用户特别喜欢。

Harry： 小更新，大惊喜。

Yuhki： 对。

Harry： 这个说法太妙了，等于给一个可能成、也可能不成的东西提前留了退路。不成的话，它只是个小更新；成了，它就是个大更新。你懂我意思吧？

Yuhki： 确实。很多时候是一些小小的 bug，或者我叫它们"微型悲剧"（micro tragedies）的东西，终于被解决了。所以用户会真心为此欢呼。

无限资源、发现难题与匠心

Harry： 如果我今天给你无限的资源——最显而易见的恐怕是资金——你会如何改变你现在做事和打造产品的方式？

Yuhki： 好问题。先打个预防针：往一个问题上堆更多人、更多资源，并不总能让事情推进得更快。我之所以这么说，是因为我们刚发布了一批新产品，眼下最难的问题仍然是如何让它们更好地连接在一起。

而要让它们连接得更好，需要的是系统性思维，是看清全局的能力。这靠堆人是解决不了的。你得把对的人放到这个问题上，或者给自己留出足够的时间。这是我先要说清楚的前提。

另外补充一点，我个人最大的期望——说起来有点宏观——就是让各产品之间连接得更好。这是我想再多花力气解决的问题。

Harry： 连接不畅，最大的原因是什么？

Yuhki： 从理念上讲，我们这一轮的取舍是：不急于过早地宣布所有产品都必须深度打通。当然它们现在也很互通——可以互相复制粘贴，都在同一个平台上，这很好。

但我们这么做的原因是：我们还在尝试新的使用场景，需要从中学习。与其过早地把所有东西揉到一起，不如先弄清楚哪些成立、哪些不成立，把每个产品各自做扎实。到那时候，它们之间该如何拼接，自然会变得清晰。某种程度上，这是有意为之的。

不过我也承认，对终端用户来说，如果一下子面对一大堆产品、不知从何下手，确实可能会感到无所适从。

Harry： 在产品世界里，AI 是否让"被发现"变得更难了？如今人人都有能力创造任何想要的东西，新产品供给侧几乎是无限的，"发现"反而成了更大的问题。你怎么看？

Yuhki： 确实有"发现"的问题，但我们更愿意把它看作"匠心"（craft）的问题。软件已经多如牛毛，人人都能做出产品。真正的命题是：靠什么把一个产品和下一个产品区分开？我们深信，答案是出色的设计和出色的打磨。

这不是扔给 AI 它自己就能想明白的事。你需要人的引导，逼着它更深入地思考体验，或者做出真正独特的东西。这才是第一个要解决的问题——如果你只是帮人们去发现平庸的软件，那对世界毫无帮助。

Uber 往事：预先定价的硬仗

Harry： 完全同意。进入快问快答之前，我想先聊聊你在优步（Uber）的经历，那段太精彩了。回想一下，你参与过的最大的产品胜利是什么？从产品角度你又学到了什么？

Yuhki： 我认为是那场对 Uber 体验的彻底改造。说出来你可能不信，现在已经很难回忆起来了，但当年的 Uber 完全是另一个样子：你按车型选车，上车，行程结束后收到一张收据——直到看到收据那一刻，你才知道自己要付多少钱。

Harry： 惊喜。

Yuhki： 对，就是这样。跨年夜我们没少因此被骂。不过当年的出租车也是这么运作的。毫无疑问，对这场体验最大的改造，就是让你提前输入目的地，直接看到价格和时间。

对我们平台来说，在你上车之前就知道目的地，是一个巨大的胜利，因为我们因此可以优化一切：优化路线，基于目的地定价，诸如此类。所以我认为那是脱胎换骨的改变。

Harry： 人们想要可靠性，想要透明度，想要——

Yuhki： 其实我学到的教训是：当时公司内部对这件事的阻力非常大。那时最赚钱的业务是 Uber Black（高端专车）。人们担心，一旦把它和更便宜的 UberX、UberPool 的价格摆在一起对比，这块业务会受到冲击，对公司来说就不是利润最大化的选择了。

而且行业里也没有先例，所以大家的心态是：我们为什么要自己逼自己做这件事？但当时的 CEO 特拉维斯（Travis）态度很鲜明：这关乎原则。他非常坚持——透明度正是魔力的一部分，我们要去改变整个行业，其他人迟早都会跟上。既然如此，不如我们做第一个，先学先受益。事实证明他完全正确。但那真的是一件非常难做的事。

快问快答：Adobe 分手、自我评审与最爱产品

Harry： 我想围绕你的经历做一轮快问快答。我说一个简短的提问。到目前为止，你在 Figma 经历过的最难的时刻是什么？

Yuhki： 说实话，应该是与 Adobe 并购告吹之后。我们要确保社区明白：一切照旧，我们还在，我们还是那个你们熟悉和喜爱的 Figma，我们会继续专注于用户。

那段时期我们确实在埋头做事，这一点不假。但对我们而言，那仍是一个需要向社区证明自己的时刻——证明我们的势头丝毫不减当年，证明我们对前路充满干劲。那是一个大时刻。

Harry： 迪伦说了什么来鼓舞团队？那确实是最艰难、最具挑战性的时刻。

Yuhki： 听着，Figma 从此要成为一家了不起的独立公司了。所以结局是好的，但那个时刻真的非常难。

Harry： 他当时具体做了什么、说了什么来凝聚团队？

Yuhki： 他就是回到使命本身，回到这个使命有多大。他一贯喜欢在公司内部引用他对 Figma 的最初愿景——从想象到现实（from imagination to reality）。这是他的起点，尽管旁人都劝他：你是不是该说得更具体一点？

但他就是不断提醒大家这个创立之初的愿景，以及它有多宏大。我认为这非常重要，它让大家看到还有多少事等着我们去做。这基本上是他传递的第一层信息。

第二层信息则全部聚焦在我们的社区上。风波发生时，有那么多人、那么多用户对我们的未来无比期待。他把大家的注意力引向那里，仿佛在说：看看这些相信我们的人，看看这些期待我们未来动作的人。他把所有人团结在社区和这份热情周围。

Harry： 假设我们现在做一场反馈会，由你以产品领导者的身份给自己做一次评审。如果你要对自己说：这是你的弱点，你得改。你会对自己说什么？

Yuhki： 我这个人不太情绪化。我经常收到的反馈是：你应该多把情绪当作一种杠杆来用；或者：很难知道你在想什么。因为有时候我只是在消化信息，不会立刻给出本能的激烈反应。

每种优势都有它的阴影面，我想这就是一个例子。但作为领导者，我确实可以做得更好——不仅靠打造产品在智识上的吸引力来凝聚人心，也要更多调动情感的那一面。

Harry： 说起来好笑，我觉得我最大的弱点是我太意大利人了。别人跟我说个想法，我会直接说：我讨厌它，太烂了。

Yuhki： 哈哈。

Harry： 然后五分钟后我又改口：其实不错嘛，我喜欢。但伤害已经造成了——我一上来就太情绪化、太直白。说到伟大的产品领导者，你最尊敬和钦佩的是哪一位？为什么？

Yuhki： 其中一位是我的导师，他现在是 Grammarly 的 CEO，之前曾领导 YouTube 的产品团队，叫希希尔·梅赫罗特拉（Shishir Mehrotra）。他是一位极其出色的系统性思考者，深谙如何运转一个组织。他痴迷于设计各种仪式和机制。

很多时候，大家只想着打造产品、设计产品，但他还会有意地去设计文化——通过设计独特而有趣的流程、会议节奏，一切都结构精妙、意图明确。身处其中真的很有意思，也让人佩服。

Harry： Figma 的产品文化里，有什么遗留至今的、你想改变的毛病？

Yuhki： 它仍然很依赖"部落知识"（tribal knowledge）——那些口口相传的隐性知识。你得恰好知道某个犄角旮旯的细节，知道某段来龙去脉，才知道为什么这件事不能做。这有时会阻碍新人更快找到更好的方案，或者搞不清自己的产品会如何影响其他产品。

我真心希望我们能把这些知识更好地沉淀下来，让每个人都能看懂；或者干脆把它简化掉，省得存在这么多奇怪的依赖关系。

Harry： 最后一个问题。最近有没有哪个产品策略或产品让你印象特别深刻？为什么是它？拿我来说，答案是多邻国（Duolingo）——这也是我请他们上节目的原因。让我佩服的是他们对细节的打磨，比如用触觉反馈（haptics）来配合关卡进阶。这种颗粒度的用户愉悦感，实在太显眼了。在消费级产品里，你最喜欢哪一个？哪个在你眼里是美的？

Yuhki： 我现在喜欢的消费级产品是 Waymo，不过我喜欢的更多是它的实体体验。它当然足够令人惊叹——让你坐在一件原本看似不可能的东西里，却感到无比安全。

产品里处处是小提示，让你觉得一切尽在掌控。细节打磨到什么程度呢：你开门前，它会提醒你旁边有骑行者经过；你下车走远了忘了拿包，它也会提醒你。这些事其实真人司机也能做，但在这里它们是默认配置。正是这种对细节的执着，让平均水平近乎变成最佳体验，实在了不起。

Harry： 我们开头说过，最好的对话，就是真正的对话。

Yuhki： 没错。

Harry： 非常感谢这场对话。说实话，我其实都不知道自己有没有问到准备好的问题——我不喜欢看提纲，那会有损对话的质量。你表现得棒极了，真的太感谢了。

Yuhki： 哪里，你是一位很棒的主持人。也谢谢你。

Harry： 我和尤基的这场对话，我太享受了。如果你想回看这一期节目，可以在 Spotify 上搜索 20VC。没错，Spotify，搜索 20VC。一如既往，感谢大家的大力支持，周一请锁定我们与多邻国（Duolingo）创始人的精彩对谈。