在 Figma 操盘了 5 年的人，把"产品"拆成了 7 道光 他用 craft × taste × storytelling，重新定义了 PM 这个职业

在三种文化之间长大的人，最后做了"翻译"这件事

Yuhki 出生在日本，后来在美国长大、在 Harvard 学 CS——他这一辈子都在不同语境之间做翻译。这件事对他后来在 Figma 的工作非常重要。

很多产品经理的成长故事都是"从小痴迷代码 → CS 学位 → 大厂 PM → 创业 → CPO"。Yuhki 的故事看起来也像，但他多了一个隐藏 buff：跨文化翻译。

在 Harvard CS 读本科时，他不只学技术——他还做了 Head Teaching Fellow（首席助教），需要把抽象的算法、数据结构讲给完全不同背景的本科生听。"如何把一件复杂的事讲清楚"——这是他从 18 岁就开始练的肌肉。

很多 PM 把"会讲故事"当成软技能、当成 nice-to-have。Yuhki 把它当成核心硬技能——和编程、和数据分析、和用户研究并列，甚至更核心。在 Figma 内部，每一份产品需求文档（spec）都必须以一段"为什么这个 problem 重要"的 narrative 开头，不允许直接跳到方案。

从 Microsoft 到 YouTube 到 Uber：一份把 PM 和 Designer 双轨打通的简历

Yuhki 的履历有一个非常少见的特点——他既做过 PM，也做过 Designer，且是大厂里真正掌过权的那种。这种"双轨"经历，在硅谷 PM 里凤毛麟角。

这份"双轨"履历给了 Yuhki 一个非常稀缺的视角——他不会神化 PM 也不会神化 Designer。在大多数公司里，PM 觉得自己更懂业务、Designer 觉得自己更懂用户，两边互相轻视。Yuhki 在 Figma 内部反复说同一件事："PM 是 Designer 的副驾驶，反过来也是。两个角色没有谁更高级。"

Outcome over Output：他把 PM 这件事重新定义了一次

这是 Yuhki 最有名的一句话，也是 Figma 内部贴在每个会议室墙上的一句话——不要看你"做了多少"，要看你"改变了什么"。

2010 年代后期，硅谷 PM 圈最大的病灶是 output 通胀——大家比的是发了多少 feature、发了多少 OKR、跑了多少 A/B 实验。但用户体验没有变得更好，公司的核心指标也没有变得更好。Yuhki 在 Lenny's Podcast 上把这件事讲得很直接：

Yuhki 在 Figma 推动的最重要变化之一，就是把 OKR 的写法从"发 X 个 feature"改成"用户行为发生 Y 改变"。这听起来是小事，但在一个有几十个 squad 的大公司，会从根本上重写人的激励：

Figma 内部的"三阶段产品流程"，第一次被完整公开

在 First Round Review 的长访谈里，Yuhki 第一次系统讲了 Figma 怎么做新产品——三个阶段，每个阶段问一个不同的问题。这套方法在硅谷 PM 圈被疯传。

① Concept 阶段：Yuhki 要求每个产品负责人在写任何 spec 之前，先写一份 narrative——不超过 1 页 A4，回答三个问题：

• // Q1
  这个 problem 真的存在吗？ 不能是"我觉得用户需要"，必须是"我看见 X 个用户在干 Y 这件事，Y 在用现有工具完成时有 Z 痛点"。
• // Q2
  为什么是 Figma 来解决？ 不是"我们能做"，而是"没有别人能像我们这样做"——Figma 已有的画布 / 协作 / 用户网络是不是这件事的天然底座？
• // Q3
  不做会怎么样？ 如果不做这件事，Figma 在 3 年后会损失什么？如果答案是"什么也不会损失"，这件事就不值得做。

② Build 阶段：Yuhki 强调一件事——craft 必须在 build 阶段就 hold 住，不能等到 scale 阶段才加 polish。Figma 内部有一个原则叫"quality bar starts at day one"。

③ Scale 阶段：到了 scale 才是真正考验产品组织成熟度的时候——你能不能让一个 100 用户的产品长成 1000 万用户的产品而不掉品质？这一阶段 Yuhki 会要求每个 squad 重新写一次 narrative，因为放大本身会改变问题的本质。

Storytelling 不是软技能：它是 PM 最核心的硬技能

在 First Round Review 那期长访谈里，Yuhki 把"讲故事"这件事拔到了和"写代码"一样的核心位置——这是 Figma 内部最被反复强调的一条文化。

大多数 PM 训练里，"storytelling"被归类为软技能（soft skill），意思是"有当然好，没有也能凑合"。Yuhki 反对这个分类——他认为 storytelling 是 PM 的底层操作系统，没有它，所有其他技能都跑不起来。

Yuhki 在 Figma 内部推行了一个非常独特的做法——每一份产品 spec 必须以一段"narrative"开头，而不是直接进入需求描述。这一段必须能让任何一个不在场的人（CEO、新来的工程师、合作伙伴）在 60 秒内理解：这件事是什么、为什么重要、为什么现在做。

这条原则在 AI 时代更重要——当 AI 让"做出一个产品"变得越来越容易的时候，"说清楚为什么这个产品值得存在"反而成了最稀缺的能力。

Craft × Taste：Figma 为什么"看起来就比别人好"

从外部看 Figma，最容易感受到的是它的"质感"——动效顺、组件干净、字体讲究、文档周到。这不是偶然，是 Yuhki 在内部用很多年硬磕出来的两个词：craft 和 taste。

Yuhki 在 First Round Review 上把它们拆得很清楚：

Yuhki 反复强调一件事——craft 和 taste 不是天生的，是可以训练的，但训练的方式不是开课程，是"持续暴露在高质量样本里"。Figma 内部有一个传统：每周会有一次"craft review"，把全公司本周做的产品截图全部贴出来，团队互相点评细节。这件事看起来很 nerdy，但坚持 5 年之后，整个公司的"对好东西的判断力"在被持续校准。

Yuhki 留给中国产品人的 5 条"光谱式"启示

把 Yuhki 在 Lenny / First Round / Harvard in Tech / Config 上反复说的话拆成 5 道光，每一道光都对应中国 PM 一个常被忽略的维度。

• // 01
  看 Outcome，不看 Output——并且要敢于 ship 完了承认"没动指标"。 最难的不是"看 outcome"这件事本身，而是"ship 完了承认没动指标"。中国 PM 在这件事上压力最大——但 Yuhki 在 Lenny 那期反复说："没动指标是 information，不是 failure。"
• // 02
  每份 spec 先写 narrative，再写需求——讲不清楚就不要 ship。 "讲不清楚"通常意味着自己没想清楚。在 spec 里强迫自己写一段"narrative"，是逼自己回答："这件事到底为什么值得做？"
• // 03
  Concept → Build → Scale 三阶段，每阶段问不同的问题。 国内大部分团队跳过 Concept 直接进 Build；ship 完了又跳过 Scale 直接做下一个。三个阶段都不能省，每个阶段都有它特有的失败方式。
• // 04
  把 craft 和 taste 当成可训练的硬技能，不是天赋。 每周做一次"craft review"，把团队这周 ship 的所有东西贴出来一起点评。这件事坚持 6 个月，整个团队的判断力会肉眼可见地变强。
• // 05
  PM 是 Designer 的副驾驶，反过来也是——别神化任何一边。 PM 觉得自己更懂业务、Designer 觉得自己更懂用户——两边其实都不够懂。Yuhki 在 Figma 推动的是"同一个房间里一起决策"，而不是"先 PM 写完再 Designer 接力"。

这 5 条像 7 道光一样独立，但把它们叠起来，就是一束完整的白光——那个白光的名字，叫"能持续做出好产品的产品组织"。这件事不是靠某个天才 PM 的灵感堆起来的，是靠 Yuhki 这种"把每个动作都拆出来、然后把每个动作都做到位" 的人一点一点搭起来的。