Figma如何打造卓越产品？独家对话首席产品官Yuki Yamashita

2 分钟阅读

Figma如何打造卓越产品？独家对话首席产品官Yuki Yamashita

嘉宾：Yuki Yamashita｜Figma首席产品官（CPO）｜ 领域：产品管理与设计协作

背景与引子

2010年代，Adobe在设计软件领域几乎处于垄断地位。然而，一家名为Figma的初创公司凭借一个看似不可能的想法——在浏览器中运行专业设计工具——彻底改变了游戏规则。如今，Figma已成为全球最具影响力的协作设计平台，估值超过百亿美元，彻底颠覆了设计师的工作方式。

你可能已经知道Figma的产品有多优秀——实时协作、云端存储、无缝共享。但你是否想过：是什么让这家公司的产品能够持续保持卓越？他们的产品团队是如何思考、如何运作的？那些令人惊叹的产品决策背后，隐藏着怎样的方法论？

这些问题不仅对设计师和产品经理有价值，对所有致力于打造卓越产品的人都有启发意义。本期播客，我们邀请到Figma首席产品官Yuki Yamashita，深入探讨Figma的产品哲学、团队管理、OKR实践，以及如何在高速增长中保持产品品质。

Yuki是一位有着独特职业轨迹的产品领导者。他曾在微软、YouTube、Uber等公司担任关键产品角色，从产品经理转型为设计负责人，如今又回到产品领域执掌Figma的产品方向。他和产品团队在这些年里经历了大量实验，有些成功了，有些则需要调整方向——而这些真实经历恰恰是最宝贵的学习素材。

嘉宾是谁

Yuki Yamashita现任Figma首席产品官，在公司已工作近四年。他的职业生涯颇具传奇色彩：毕业后第一份工作在微软担任Hotmail的产品经理，之后参与Windows 8项目，第一次深度接触到UI/UX设计领域。

离开微软后，Yuki被硅谷的魅力吸引，加入YouTube担任iOS应用的产品负责人。回忆当时的情景，他笑称自己在入职第一天甚至还没用过iPhone——第一天就被经理派去苹果店买了一部iPhone 4。这种快速学习的能力和拥抱变化的开放心态，成为他职业生涯的鲜明特质。

在Uber期间，Yuki的工作发生了有趣的转变：他的职位是产品负责人，但同时兼任 Mobility团队的设计负责人。这种“脚踏两只船”的经历让他深刻理解了设计与产品之间的张力，也让他意识到设计师和PM如何能够相互学习、彼此赋能。

2018年前后，Yuki在Uber负责的项目中首次接触到Figma，当时公司正在推动透明化和包容性的工作文化转型。他亲眼见证了Figma如何改变了设计师的工作方式，如何在组织内部迅速传播。这种“边界模糊化”的协作理念深深打动了他——这不只是一款工具，更是一种全新的工作哲学。

核心观点 TOP10

  1. PM必须掌控“WHY”——想法的来源可以多元，但PM必须对产品背后的“为什么”承担独特责任。

  2. 讲故事是PM的核心技能——产品经理最强大的能力是将复杂的想法提炼成清晰、有共鸣的故事。

  3. 离开上下文，讲述完整故事——想象面对一个完全不了解项目的人，你能否从零开始解释清楚？这种能力决定了你沟通的有效性。

  4. 客户原型比数据更重要——建立平衡的反馈收集机制，避免被“嗓门大的少数人”误导。

  5. 让整个公司使用自己的产品——从写文档的模板开始，让每个人都在Figma中工作，自然发现问题。

  6. OKR不是任务清单——真正有效的目标应该能激发行动，与日常工作紧密相连。

  7. 设计师比PM更难管理——设计师需要专注于技艺成长，这不一定与公司当前最紧迫的问题对齐。

  8. 社区驱动增长——不是销售团队在卖产品，而是社区内的倡导者在推动传播。

  9. 让工程师体验用户痛点——当工程师亲自遇到过bug，他们修复的动力完全不同。

  10. 拥抱“未完成”的状态——我们的产品、流程、策略都是“正在进行时”，关键是持续迭代。

关键洞察

洞察一：设计师比PM更难管理

Yuki在Uber期间从PM转岗到设计管理，他发现管理设计师比管理PM更具挑战。这是因为设计师的职业发展需要专注于“技艺”的成长——他们需要接触能提升技能的项目。然而，公司最紧迫的问题往往与设计师需要学习的技能不完全匹配。相比之下，PM更渴望影响力，可以直接被引导到公司最重要的战场上。这一洞察提醒我们：对不同角色需要不同的管理策略。

洞察二：OKR的困境——“能衡量的不重要，重要的难衡量”

Yuki对OKR有着复杂的情感。他发现团队往往面临两难：要么设定一个“技术上可以移动但实际上无关紧要”的指标，要么设定一个“真正重要但团队无法直接控制”的目标。更糟糕的是，OKR常常沦为一季度结束后的“事后诸葛亮”，而不是指导日常工作的指南。他的解决方案是：首先弄清楚团队真正想做什么（WHY），然后再讨论如何衡量（H ow），而不是反过来。

洞察三：CEO的直觉来自数千次客户接触

Figma CEO Dylan Field以直觉敏锐著称，但Yuki指出这种直觉并非凭空而来。Dylan十年来每天阅读客户反馈，这些真实的接触积累成深厚的用户理解。当Dylan在会议上凭直觉判断某个方案“行不通”时，他的结论来自多年积累的“用户感觉库”。这提醒我们：直觉不是神秘的天赋，而是大量输入的结晶。

洞察四：个人责任感是质量保障的秘诀

在Uber，工程师们会乘坐Uber上下班。当他们在司机端App上看到司机挣扎于某个功能时，他们会感到“尴尬”，并迫切想要修复。这种“个人连接”创造的责任感，远比任何指标考核都有效。Figma同样如此——设计师们在Twitter上认识他们的用户，这种社交关系让他们不愿意交付“不值得展示”的东西。创造让员工与用户建立情感连接的机会，是提升产品质量的强大杠杆。

洞察五：Branching功能失败的启示

Figma在设计系统领域的”Branching”（分支）功能是一个重要案例——这是用户明确要求的功能，但上线后使用率很低。团队反思发现：他们自己并不使用这个功能，所以无法真正理解用户的实际场景。这促使他们意识到：当产品越来越成熟，进入更多陌生领域时，传统的“内部测试”方法需要升级——你需要更主动地去理解与你团队背景不同的用户。

精彩金句

“产品经理最强大的能力，就是把复杂的想法提炼成一个清晰、有共鸣的故事。”

Yuki认为，讲故事不是“包装”，而是PM的核心竞争力。他特别强调“离开上下文”的能力——想象你在向一个完全不了解项目的人解释，你能否从零开始把这个故事讲清楚？

“如果你不能把一个想法用任何人都能理解的方式表达出来，那说明你自己也没有真正想清楚。”

这句话呼应了物理学家费曼的名言。Yuki提到，他在哈佛担任计算机科学助教时学会了这一点——当你需要向零基础的学生解释“指针”的概念时，你被迫找到最本质、最接地气的类比。

“OKR变成了任务清单——这是最大的悲哀。”

Yuki观察到，当OKR沦为“季度末需要完成的清单”时，它就失去了意义。真正有效的目标应该能够激发行动，让人每天醒来都想着如何推进。

“让Champion成为超级英雄——不是销售在卖产品，而是社区内的倡导者在推动。”

Yuki对“产品驱动增长”的理解与众不同。他认为Figma的增长核心不是销售团队，而是公司内部那些热爱产品、主动倡导的设计师。销售的作用是帮助这些Champion更有效地传播。

“那些只有一个赞的推文，有时候包含最重要的真理。”

Figma有一个特殊的Slack频道叫“令人担忧的推文”，专门收集那些几乎没人关注但Dylan认为“有问题”的反馈。这种机制帮助团队不被流量迷惑，保持对真实问题的敏感度。

实战案例

案例：从备忘录到演示文稿的转变

当Yuki加入Figma时，他注意到产品团队主要用备忘录写文档。他做了一个看似简单但影响深远的决定：要求团队改用演示文稿（Deck），而且这些Deck必须用Figma制作。

这个决定带来了连锁反应：PM们开始在日常工作中使用Figma，亲身体验产品的每个细节。他们自然地遇到各种“小问题”，这些体验反馈比任何用户调研都真实。更重要的是，当团队每天都依赖自己的产品时，“把它做得更好”变成了内在的驱动力，而不是外部的要求。

案例：Branching功能的失败与反思

Branching是Figma为大型设计系统推出的功能——允许团队在不影响主线的情况下尝试修改。然而，这个“用户强烈要求”的功能上线后使用率极低。

团队事后分析发现几个原因：性能问题、用户不熟悉这种工作流程，更重要的是——Figma团队自己几乎不用这个功能。当你不亲身使用一个功能时，你很难理解它的真实使用场景和潜在问题。

这次失败让Figma意识到：随着公司规模扩大，他们需要建立能力来理解“与自己团队背景不同的用户”的需求，而不仅仅依赖“内部测试”。

案例：CEO在洗手间遇到用户

新冠疫情期间，Figma CEO Dylan有一次在户外开会时借用了Yuki家的洗手间。他发现Yuki的伴侣正在使用Figma工作，于是立刻凑上前去询问使用体验。两人开始讨论关于Google Fonts的问题——这不是什么战略级的大功能，而是一个具体的小痛点。

这种对任何用户、任何场景都保持好奇和投入的态度，是Dylan十年来的日常。他每天阅读客户反馈，这些零散的接触最终构建成对用户需求的深层直觉。

行动建议

建议一：训练“离开上下文”的沟通能力

为什么要做：大多数产品讨论都假设参与者有相同的背景知识。但现实是，你需要向工程师、设计师、高管、客户等完全不同的受众解释同一件事。如果你无法从零开始构建叙事，说明你还没有真正想清楚。

如何开始：找一个你正在推进的项目，尝试向一个完全不了解背景的朋友解释——不使用任何专业术语，从“为什么这个问题重要”开始。记录哪里需要解释最多，那些就是你思维中的盲点。

能得到什么：你会发现自己思维中的跳跃和假设，同时获得一个可以在任何场合使用的清晰叙事框架。

建议二：创建你自己的“令人担忧的推文”渠道

为什么要做：社交媒体上的热门反馈往往不代表沉默的大多数。你需要一种机制来捕获那些“微弱但真实”的信号。

如何开始：选择任何适合团队规模的反馈渠道（Slack频道、邮件列表等），定期收集那些“看似不重要但你直觉感觉有问题”的反馈。每周花15分钟审视这些内容，问自己：“这背后是否有更大的趋势？”

能得到什么：一个早期预警系统，帮助你在问题变大之前识别和处理它们。

建议三：强制你的团队使用自己的产品

为什么要做：工程师和PM每天都在“谈论”产品，但很少真正在日常工作中使用它。当你把产品变成工作流程的一部分时，改进的动力从外部要求变成内在需求。

如何开始：找出团队日常工作中可以改用自家产品的场景（文档、演示、项目管理），强制迁移。接受初期的效率损失——这是为了长期的洞察积累。

能得到什么：真实的痛点反馈、内在的质量驱动、以及团队对产品的深层理解。

建议四：先确定WHY，再讨论HOW

为什么要做：OKR最常见的陷阱是倒过来——先设定一个“可衡量”的指标，然后找一个项目去完成它。这样你可能移动了一个数字，但没有解决真正的问题。

如何开始：在任何目标设定讨论中，首先问“这个季度我们真正想实现的是什么”——用任何你能想到的方式描述（定性描述完全可以）。只有当团队对目标达成共识后，才讨论如何衡量。

能得到什么：更具真实性和激励性的目标，以及团队对目标意义的真正理解。

建议五：建立与用户的“个人连接”

为什么要做：当工程师觉得某个bug是“别人的问题”时，修复它的动力很低。但当他自己在使用中遇到过同样的问题时，他会感到个人责任。

如何开始：创造让团队成员直接接触用户的机会——不是正式的用户调研，而是轻松的对话、影子使用、或者邀请用户参与内部活动。关键是让员工看到具体的、真实的人在使用他们的产品。

能得到什么：更快的bug修复、更高的质量标准、以及团队对产品的自豪感。

我的总结

这次与Yuki Yamashita的对话，让我们得以一窥Figma这家顶级产品公司内部的运作方式。从“PM掌控WHY”到“故事力是核心竞争力”，从“OKR不是任务清单”到“社区驱动增长”，每个洞察都折射出Figma产品文化的独特之处。

然而，最打动人的或许是Yuki的坦诚：他承认Figma仍在实验中，OKR的问题他们还没有完全解决，Branching功能的上线效果不如预期。这种“我们是work in progress”的心态，恰恰是持续进化的前提。

对于所有产品人来说，Figma的经验指向一个核心真理：卓越产品不是计划出来的，而是在与用户的深度连接中、在团队的持续实验中、在对质量的执着追求中，逐步生长出来的。

📺 播客信息

  • 发布时间：2023-01-08
  • 时长：1小时8分钟36秒
  • 播放量：31987 次观看
  • 原版视频：『YouTube』