一种更好的规划、构建和交付产品的方式 | Ryan Singer（"Shape Up" 作者）

Ryan Singer 2025-03-30

一种更好的规划、构建和交付产品的方式 | Ryan Singer（“Shape Up” 作者）

Ryan Singer： 我经常用家装翻新来打比方——你可以有一张最漂亮的新卧室效果图，床的两侧有从墙壁延伸出来的壁灯。但如果你没检查过那面墙里有没有电路，这会彻底改变成本、工期和一切。

我们在塑形会议（shaping session）中要做的是产出一套示意图，让工程师、产品和设计都能说”我们看懂了”。所以第一件事是：除非我们从头就能看到尾，否则不会启动任何项目。我们不会拿着一个大概念然后问”估算一下这东西要多久？”

我们要反过来——我们要问的是，在真正完成一件事情之前，我们愿意投入的最长时间是多少？如何想出一个在业务愿意投入的时间范围内可行的方案？

Lenny Rachitsky： 今天的嘉宾是 Ryan Singer。Ryan 是 37signals 最早的一批员工之一，凭借在 37signals 构建 Basecamp 以及 17 年产品构建的经验，他写了一本书叫 Shape Up，分享了一种截然不同的软件开发方法——用胃口（appetite）代替截止日期，高度重视让设计、工程和产品坐在一起塑形方案，而不是写冗长的 PRD 或在开发前敲定所有设计。

我注意到越来越多的团队开始采用 Shape Up 方法，尤其是在 AI 开始改变我们工作和构建产品方式的当下，产品团队的运作方式正在迎来转变，所以我觉得现在是深入探讨 Shape Up 方法的绝佳时机。

这一期基本上会给你提供所有需要的东西，让你的团队或公司尝试 Shape Up，看看它是否能解决你在交付优秀产品时遇到的问题。

感谢 Des Trainer、Bob Moesta 和 Chris Speck 为这次对话提供的问题和话题建议。如果你喜欢这个播客，别忘了在你喜欢的播客应用或 YouTube 上订阅关注。

好了，下面请出 Ryan Singer。

Ryan Singer： 非常高兴来到这里，谢谢。

Lenny Rachitsky： 我觉得这会是一期传奇的节目。如今人们对不同的工作方式越来越感兴趣，尤其是 Agile、SAFe、Scrum 这些人们耳熟能详的方法论。特别是在 AI 时代，一切都在变化，探索不同工作方式的兴趣似乎与日俱增，尤其是 Shape Up——你所谈论的这套方法——的关注度明显在上升。

所以我很兴奋能帮助大家理解这套工作方式到底是什么、是否适合自己、有哪些入手实施的方法，以及可能会踩到哪些坑。同时尽量多聊一些产品团队实际运作中的真实情况——那些人们通常不太愿意公开谈的话题。

首先，你也注意到了 Shape Up 关注度的上升吗？

Shape Up 的关注热度

Ryan Singer： 是的，我觉得我们现在做这期对话很有意思。书是 2019 年出版的，我越来越多地听到”哦，我们认识有人在试这个”，或者”我们去其他公司交流时听说了”。所以我觉得这是一股正在慢慢积蓄力量的浪潮。

有意思的是，书刚出版的时候，我还试着建过一个在线论坛，让所有感兴趣的人一起讨论。但我很早就发现，人们不太愿意公开谈论自己在交付上的困境。

尤其是 CPO 和 CTO 不太愿意在一个公开论坛上说”我们公司交付不了东西”，或者”我们的工程团队卡住了”，或者”我们的团队总在细节中迷失”。这不是一个适合在在线论坛上讨论的轻松话题。

所以我认为这也是它一直靠口碑缓慢积累势头的另一个原因。

交付困境为何难以启齿

Lenny Rachitsky： 这也是我在做播客时遇到的困难。正如你所说，做产品的人、产品团队不愿意分享进展不顺的时候。所以我在播客里设置了”失败角落”——“好吧，那你告诉我一次不太顺利的经历。”

Ryan Singer： 哦，这太好了。确实，要聊到那一层太难了，对吧？因为现实并不全是那条金光大道、一片坦途，我们每天都在交付漂亮而有意义的东西。这是一个艰难的行业，也没有一所完美的学校能培养出专业产品经理、CPO、CTO 之类的角色。我们都在摸索前行，而可以参考的资源又很少，所以挣扎无处不在。

Shape Up 作为一种稀缺的替代方案

Lenny Rachitsky： 关于如何做产品，其实没有多少选择。人们真正读到的，随着规模扩大，不外乎 Scrum/Agile/SAFe；然后就是瀑布模型，而瀑布模型呢——“不，我从来不用瀑布模型。“再就是创业公司的方式，直接发布，可能一两个星期一个周期；然后就是 Shape Up。所以它感觉像是为数不多的另一种选择。所以——

Ryan Singer： 这也正是我一直以来听到的反馈。比如：“哦，我们原以为只有 Scrum 和看板，后来听说了这个 Shape Up，那是什么？”

Lenny Rachitsky： 而且我觉得它一直以来都和 Basecamp 绑定在一起。这个我们待会儿会聊到。不过要说的是，它对那些和 Basecamp 完全不同的公司也适用。也许可以简单谈谈这一点。

Shape Up 走出 Basecamp

Ryan Singer： 嗯，说实话，这对我来说也是个意外。写那本书的时候，我在 Basecamp 已经待了大概 15 年，说实话我根本不了解外面的世界。其实写书这个主意都是 Jason 提出来的。他说：“你看，很多人会想知道这些东西。很多人正在挣扎。“我就说：“好吧，行吧。”

我了解的是我们的内部经历——我们也经历过成长的阵痛，需要把我们工作和交付的方式规范化，这样新人进来后能参与其中，而我们也能保持速度。所以我知道我们内部的挣扎，但坦白讲，我对外的世界一无所知。

直到书出版之后，我才有了借口去和各种不同公司的人交流，这真的很有意思。有些案例非常精彩，那些公司和 Basecamp 的特征截然不同——有 VC 融资的，规模大得多的，面临的压力完全不同，团队结构不同，技能组合也不同——但他们都在用 Shape Up。

与此同时，也有很多问题涌向我，因为坦白说，很少有团队的构成和 Basecamp 一样，所以书里存在很多空白——“那这个呢？那个呢？在我们的情况下该怎么做？”

所以我现在很大一部分精力就是在填补这些空白，帮助大家弄清楚：我怎样才能让这套方法对我自己或我的团队有效？

Lenny Rachitsky： 你还特别跟我提到过，你现在不再只是叫它 Shape Up，而是叫 Shape Up In Real Life，或者说 Shape Up For Real Life。

Ryan Singer： 对。我太太听到我在每一通电话里都在重复同样的话。她在旁边听到了，就说：“你得做个课程，你得搞点什么。你每次说的都是一样的东西。”

于是就催生了我们做的这个课程，叫 Shaping in Real Life。嗯，对，核心就是”real life”那部分——如果我的设计师不会写代码，我该怎么让它运作起来？争取工程时间非常困难。你懂的，就是那些 Basecamp 不曾面临的各种压力。

Shape Up 与其他方法的根本区别

Lenny Rachitsky： 我们接下来会深入聊它具体怎么运作以及关键要素，但你能不能先简要概括一下，Shape Up 和其他产品方法论的核心区别是什么？

Ryan Singer： 我觉得区别的起点在于我们工作的方式本身就有点不同。我是 2003 年开始和 Jason 还有 David 一起做 Basecamp 第一版的，那是 37signals 的旗舰产品。当时我们只有三个人。

我觉得对任何真正小的团队来说，刚起步的时候不需要流程，不需要一套工作方式。它会自然而然地发生，因为你们在一起，不需要向别人解释，它自然而然就成了。

但 Jason 和 David 始终有一种极其强烈的紧迫感——“我们得搞出一个能发布的东西。我们得完成这个然后继续前进。我们得达到一个完成的状态。“对于那种变得模糊、开始拖延的大块工作，他们完全不能容忍。始终有一种不断打磨的劲头：这东西到底是什么？我们什么时候能尽快走到终点？

而且，即便在构建 V1 的时候，David 其实并不是全职的——他是我们唯一的技术人员。他每周只写十个小时的程序。所以我们面临着极大的压力：怎么才能最充分地利用 David 的时间？

我们绝不想给出一个”这就是我们要做的东西”，结果后来发现不是我们想要的，只能扔掉重来——你懂吧？就是那种浪费的恶性循环。

DHH 每周十小时的约束

Lenny Rachitsky： 我正好想问这一点，因为这确实很有意思。这里说的是 DHH，他创办 37signals 的时候是兼职做的。

Ryan Singer： 每周十个小时。对。

Lenny Rachitsky： 他当时是不是主要在做 Ruby 和那整套东西？

Ryan Singer： 嗯，Rails 就是从第一个版本中诞生的……他跟 Jason 说：“我想试试用 Ruby 来构建这个。“因为之前他们有过一些合作，David 之前用 PHP 做过东西，然后他有了新的想法，想试试 Ruby——这个他爱上的语言。

然后那个框架，Ruby on Rails，是在 Basecamp 跑起来之后他才发布的。因为它是从支撑 Basecamp V1 所需的东西中抽取出来的。

Lenny Rachitsky： 所以他其余的时间就在做那个，而不是——

Ryan Singer： 我不清楚。我不知道他其余时间在做什么。

Lenny Rachitsky： 大概在做什么了不起的事吧。什么——

Ryan Singer： 但他一直都是那样。他总是在做什么有趣的事。要么在赛车，要么天知道在干什么，你懂吧？我只知道我们能分到那十个小时。

Lenny Rachitsky： 对，我很喜欢这一点——这个约束催生了一种工作方式的设计，让工程时间得到了最有效的利用。

Ryan Singer： 对，把这些放在一起看就明白了。David 每周十个小时的约束，再加上 Jason 有这种——我觉得很多真正成功的创始人，尤其是 CEO，都有这种特质——他们只想看到推进。你懂吧？向前、向前、向前。

什么时候能看到？什么时候能试试？什么时候能把它交到别人手上？这两者叠加在一起，即便没有任何外部压力，紧迫感也依然极其强烈。你懂吧？那完全是文化层面的驱动力——我们怎么持续到达某个阶段，到达某个我们可以为之庆祝、为之兴奋的成果。

Lenny Rachitsky： 我很喜欢这个。我觉得这是很多成功创始人的一个共性。所以听到这一点很合理。

Ryan Singer： 完全同意，完全同意。这也正是我想回过头来说的——这个故事中有一部分，我想很多公司都会说：“嗯，我懂那种感觉。“因为我觉得那大概就是你说的成功公司的种子。

那种紧迫感的组合，再加上那些人本身才华横溢，对要做的事情有清晰的愿景，所有这一切。早期的那种日子，其实真的是一段很棒的时光。

Lenny Rachitsky： 背景故事还有没有什么是重要的或者特别有趣的要分享？

塑形会议的起源

Ryan Singer： 还有一个很重要的部分——Jason 和我当时算是产品端的，怎么说呢，占了三分之二。那时我在做 UX，同时也亲自写代码。所以大家非常非常融合，每个人什么都做一点，所有人都在写代码。Jason 也在实际的应用模板里写 HTML 和 CSS 来做视图，他也亲自动手做设计。我们所有人都紧密围绕着一个核心问题：我们为什么要做这个？这个东西到底是什么？David 负责大部分编程工作，而 Jason 和我会进行一些小型的讨论会。

这些小型讨论会就是我们真正弄清想法的地方。会有那样的时刻——用 Sharpie 马克笔在大本子上画几笔，突然间你就会觉得：“对了，就是这个。这就是我们要去尝试构建的东西。”

对我来说，和 Jason 的那些讨论会时间短、强度极高——大家在一起绞尽脑汁破解难题。想法在哪？概念是什么？我们能不能找到这样一个东西——十个小时后 David 回来了，我们可以跟他说：“这个太棒了，它跑通了，而且做了让我们兴奋的事情。”

那其实是真正的种子。实际上那些讨论会持续了好多年、好多年。那也就是书中”塑形”（shaping）这个词的种子。塑形意味着什么？它不是一个人坐在那里写文档，不是列一堆需求，也不是做一个漂亮的 Figma 文件来呈现一个可能成为功能的概念。它是一种超高强度、非常令人兴奋的协作——“这个怎么样？""那个呢？""哦，也许可以这样。“所以那种工作方式也是我们日常中非常重要的一部分。

通过极高强度的协作讨论来确定想法，把它打磨得足够锋利、足够清晰，让我们能非常有信心地从 David 那里得到一个”好”。他会完全清楚这个东西是什么、意味着什么，然后回来实现它，最终交付的东西会是我们所设想的，运作方式也如我们所期望的那样，这样我们就能继续推进，而不必返工或推倒重来。

保持创业公司的工作方式

Lenny Rachitsky： 听起来，你们本质上是在试图随着公司成长仍保持创业公司的工作方式。你描述的一切就是创业公司的感觉，而这是一套用来维持这种感觉的方法。这么说对吗？

Ryan Singer： 完全正确，Shape Up 的由来就是：我们如何尽可能长久地保住那种感觉？其中有一个重要因素——我们也有一个优势——就是 Jason 和 David 招人极其谨慎、极其缓慢。这也是他们没有拿投资的一个幸运的副产品。所以从来不存在那种”现在是我们扩张的时刻”的节点。永远都是加一个人，然后整个有机体去适应；再加一个人。于是这种自然而然的工作方式就在有机地扩散。大概过了十年，我们才第一次出现那种——“等等，刚才发生了什么？那个项目不太对劲，这不像我们平时的运作方式。”

当然一直都有起起落落，但大约十年后，我们才遇到了第一个出了问题的项目。我还记得那个项目。我记得当时已经到了……那时候大概已经六七周了。我们还没有完全锁定后来写进 Shape Up 里的那个六周的节奏。

我记得我们做了一次评审会，团队里有一个比较新的人承担了那个团队一半的工作。我们做了评审，结果不是”哦，看，这个差不多可以发布了”，而是”这里有太多悬而未决的问题”。而且”不仅仅是有很多悬而未决的问题，我们在提问时也得不到快速的回答”。我们开始意识到：“哦，这不仅发不了版，我们甚至看不到它的尽头在哪里。”

那就是那种让你恍然大悟的时刻——“哦，这不会随着我们继续招人而自动地、有机地一直扩散下去。“你明白我的意思吗？我们确实到达了一个节点，意识到：“哦，我们得搞清楚——当事情顺利的时候，为什么顺利？我们做了什么不同的事？如何把这些形式化，使其在我们持续引入新人的时候可以复现？”

那其实就是 Shape Up 作为一个框架真正开始的时刻。那也是我真正开始深入介入、承担起这个责任的时刻——“好，我来把这个系统化。“

Shape Up 方法的核心要素

Lenny Rachitsky： 这个过渡太好了，那我们就来聊聊 Shape Up 方法具体是怎么运作的。也许先从高层概括一下，Shape Up 方法的核心要素有哪些？

Ryan Singer： 基本上有三个大的方面。第一个，就是这个理念：除非我们从一开始就能看到结尾，否则我们不会启动任何事情。所以我们不会拿一个大概念，然后问”这个东西的估算是多少？“我们不会说”哦，我们需要做一个日历，然后做一大堆 Figma 文件，或者写一大堆需求，再来要一个估算。”

我们要反过来——我们要说”我们对此的胃口是什么？我们愿意投入的最大时间是多少，在这个时间到达之前我们一定要做出一个完成的东西？“我们拥有之前谈到的那种创业时刻——就是那种”啊，你懂的，它跑通了，我们到达了某个地方”的时刻。至少这一块——如果不是整个项目的话——这一块有意义的成果，我们可以真正地放手了。

然后我们通过大量实验发现，六周是我们能展望未来的最大时长——在这个范围内我们可以说，“如何从终点倒推，找出一个能在六周内构建出来并且真正交付的东西？”

这就是第一块：从我们实际愿意花的时间倒推，然后说”我们能做什么？我们能塑形出什么东西，使得在那个时间结束后我们到达了一个我们想去的地方？”

这就像你要买车、买房、租新房，你得先有个预算，对吧？有了预算，你才能在各种备选方案之间做出选择，做出各种艰难的取舍——“好吧，我想要更强劲的发动机，但就得放弃这个；我希望它驾驶体验好，但我们也需要长途自驾的空间。“你一直在做这些权衡。

第二块就是我们称之为”塑形”的工作。塑形工作就是：我们如何在给定自己的这段固定时间内，通过调整范围来找到合适的方案？如何想出一个能在企业愿意花费的时间内完成的想法——某个可以奏效的版本？

这就是我之前说的那些创造性讨论会——我们在白板前跳来跳去，最终抵达一个想法。而那里的关键在于，我们得到的是一个我们能”看见”的想法。我们理解为什么要做这件事。我们在跟问题搏斗，也在跟解决方案搏斗，直到我们有了一个能真正说出口的想法——“这就是我们要去构建的东西。“所以它不仅仅是”日历”或”仪表盘”或”邮件构造器”，而是”我们打算如何解决关于日历请求的这个问题”这样的想法。这就是塑形。

第三块：把完整想法交给团队

Ryan Singer： 第三块就是，当我们真正切出了一块固定的时间，当我们塑形出了一个方案——从体验角度、功能角度、技术角度来看都是可行的、值得做的，是我们在那段时间内能够实现的东西——这时候我们就可以把它交给一个团队。

我们不必去做 Scrum 里有时候被称为”碎纸机”的那种事。就是那种把一个想法拆成一百张工单，然后指望拆完之后所有东西还能粘在一起。我们不想那样做。

相反，我们想要一个完整的想法，把它交给一个团队，让他们看到全貌，真正理解它，对吧？然后他们自己来决定任务，自己想办法追踪进度、拆分工作，这样他们才能真正承担起更多责任。

于是我们看到的是参与度大幅提升，尤其是技术团队。因为不再是”这是你的工单”或者”这是你的用户故事”，而是”这是你能理解的东西，它说得通，现在你要自由地去想办法让它变成现实”。

实现细节中会有一百万个问题等着解决，现在你有了一堆有趣的问题，而且你不需要不停地问别人”这个到底是什么”或者”我该怎么做这个取舍”之类的问题。

Lenny Rachitsky： 其中的一个核心要点，我想确认一下——你可以从中挑选适合你团队的部分来用，不需要全盘照搬，对吗？

不必全盘照搬

Ryan Singer： 你完全可以一点都不用。所以这时候回头看看哪里出了问题、我们想解决什么，会很有帮助。然后才是：我想从中引入什么？

通常我注意到，人们有时候喜欢从这开始——“我想给团队，比如说六周的时间，给团队更大的自由度，或者说更多的创作自由，让他们在这六周内自己负责想出怎么把事情做成。”

通常这背后的驱动力是——“我已经厌倦了那么多会议、仪式和那些不是在真正解决问题、做实事的事情。“尤其是 Scrum 团队，他们经常这样抱怨。

所以他们有时候会在这里面看到——“哦，我太喜欢这个想法了，团队就埋头干六周，不需要——我们按需碰头，按需开工作坊，但不用一直被这些仪式占满时间。”

但棘手的地方在于，如果你想要团队在六周里像快乐的蜂群一样嗡嗡运转这个美好图景，他们就需要对”我们要解决的问题到底是什么”有非常清晰的认识。

所以当我们从那个目标往回推导的时候，就会发现——“哦，如果我们不在塑形上做得更好，团队就没有足够的清晰度去接过那份责任，去做选择、做决策、做取舍，最终把这个东西交付出来。“最糟糕的是，有时候你会看到这样的案例——“好，我们现在用 Shape Up 了。所以你们来构建 newsletter 构造器，好吧？但你们只有六周时间。用你们的固定时间，调整你们的范围，享受你们的责任。“你懂我的意思吧？这简直是残忍的。

因为我想引用 Bob Moesta 的一句话——他上过你好几次节目——“你不可能把十磅的东西塞进五磅的袋子里。“这话说得很学术，但道理就是我们不能随便拿一个项目，不管它有多大，然后扔给一个团队说：“自己想办法，六周内通过砍范围交付出有意义的东西。”

所以这开始引发一些问题——我们如何共同决定这个项目到底是什么？我们真的清楚这个想法是什么、我们要构建什么吗？

胃口与估算的对比

Lenny Rachitsky： 让我跟进其中几个要点。关于胃口，我想任何产品经理、工程师、设计师，只要经历过”我们估算这个落地页大概要两周，好的，开始做吧”，结果最后做了六周的人，都能理解为什么这个方法说得通。

就是——“这个落地页对我们来说没那么重要。我们直接说，投入两周时间，在两周内尽量多做，然后往前走。范围不允许超出。“完全说得通。听上去太说得通了，尤其是对那些深陷估算不准之苦的人来说——

太说得通了，尤其是对那些深陷估算不准之苦的人来说。

六周周期的由来

然后还有一个六周的要素，关键在于——这个可能跟 Scrum 的两周冲刺刚好相反，这是不是这个时间周期的来源？

Ryan Singer： 实际上，六周只是一个上限，这才是这个数字真正发挥作用的地方。如果我们把六周理解为一个上限，它就会迫使我们问自己一些非常好的问题——其中哪一块是我们真正认为自己能落地的？因为如果你说”六个月后我们要发布这个东西”，你根本无法把六个月的工作量中所有需要解决的问题都揽在手里。未知数太多了，有太多我们没有理解或无法预见的定时炸弹。但如果我们把上限设在六周，我们就有了好得多的机会——我认为六周是这样一个尺度：在这个尺度下，我们能够真正去塑形它，把足够的未知数暴露出来，在深陷其中之前揭示出那些复杂性。

这不意味着我们不能用这个技术做一个两周的项目。尤其是如果你在增长团队，你不会想等六周——你不可能为了做六周而人为地把东西硬凑在一起。就像，看，我有一个想在下周发布的东西，然后接下来可能有个要花两周的东西，之后又是一个一周的。所以更多是关于我们想承担什么。六周真正是那个上限。

Lenny Rachitsky： 好的。所以也可以是一个两周的周期，然后胃口就是——

Ryan Singer： 可以是一个两周的东西。

Lenny Rachitsky： 好。所以就像——我们要构建这个新落地页，给两周时间，然后对它做一次塑形会议。

Ryan Singer： 但另一方面，当涉及到功能开发，或者构建一个足够有分量、能卖得出去的东西时，很少有能在两周内完成、同时又对产品有实质性增值的事情。所以你就进入了一种局面——我们只是在冲刺，一口一口地啃。然后就陷入了那种”我永远看不到终点，我只是一直回去说，再来一个冲刺，再来一个冲刺，再来一个冲刺”的状态。而六周是一个足够大的时间块——有时候四周也行——关键在于，多大规模的事情才是我们用这段时间真正能做出进展的？

Lenny Rachitsky： 这里面有一个隐含的要素，我觉得值得强调。整个理念就是你对胃口做出承诺，如果你没有按计划赶上进度，不是延长日期，而是削减范围，以确保仍然按时交付。

Ryan Singer： 这个确实比较棘手。

Ryan Singer： 你说得对，这确实是隐含在其中的。但问题是，在现实中，如果你做出了一个承诺，大家达成了共识——我们要花六周的工程时间来构建这个东西——如果到了六周结束时出了问题，比如没有被很好地塑形，看不到尽头，比我们想象的更复杂，诸如此类。顺便说一下，我们也可以讨论为什么这些事情会发生，但当我们陷入那种情况时，如果到了六周末尾情况不妙，我们不能简单地把当初约定好的、让这个东西有价值的东西砍掉。我们不能就这样削减范围，然后说，“哦好吧，我们总算在六周内发布了。“这会严重打击所有人的士气。每个人都会感到失望，觉得这一切不值得。

然后进入下一个周期时，带着一种亏欠感——我们实际上没有完成本该完成的事情，现在好像欠了债一样。这没有一点好处。如果我们走到另一个极端，直接说——我们在书里写过，Basecamp 有一个原则，叫断路器（circuit breaker）的概念：如果一个项目在六周后明显无法完成，我们就直接取消它，重新思考。几乎没有团队能下得了这个决心。但一个更容易接受的版本是这样的——我们不能直接取消项目然后说”看看接下来会怎样”，但我们可以说，“我们不会再继续投入到一个我们不理解的东西里面去了。”

所以，让我们把这个东西从构建模式中拿出来，带回塑形模式。这可能意味着不同的人，不同的对话，提出不同的问题，做不同类型的工作——去弄清楚到底哪里是模糊的？哪些是我们看不清的？什么是我们不了解的？我们怎样才能获得所需的清晰度，以便在再次动手时能真正确信这件事情能做成。

Lenny Rachitsky： 我很喜欢这个方法的务实感，不是那种理论上的——“好的，六周到了，削减范围就行了，多简单啊。”

Ryan Singer： 对，“削减范围嘛。”

Lenny Rachitsky： 对。

Ryan Singer： “没问题。”

Lenny Rachitsky： “塑形你的直觉，相信你的直觉。”

Ryan Singer： 顺便说一下，我确实见过一些 Shape Up 的实践看起来就是这样的，那不是正确的方式。塑形这一步是至关重要的。你刚才提到的着陆页的例子，确实很诱人，因为我们可以想象——帕金森定律嘛，对吧？如果你给我六周做一个着陆页，我会想办法用满六周；但如果给我两周，我两周就停了。但当涉及到真正的产品工作，需要弄清楚某个功能怎样才能实现时，我们不能因为时间不够就直接削减范围。所以这意味着塑形工作非常重要——大家一起努力弄清楚这个东西的主要活动部件是什么。我们如何缩小对问题的理解范围，如何识别解决方案中的活动部件，以及这个功能到底怎么才能连贯运作起来。

当我们真正达到能够说出”我们需要做这个、这个，然后引擎就能转起来”的程度时，那就是我们可以说”这个东西塑形得很好”的地方。这是一种不同类型的工作。在现实中，我们称之为实况塑形会议，我也是这样教大家的。这实际上是我和 Jason 多年来的工作方式。我们走进会议室，我同时具备技术和用户体验两方面的视角，所以在那种情况下两个方面都由一个人代表了。但对今天的很多团队来说，我们实际上教他们如何把资深工程师带进房间——不是徒有头衔的资深，而是那个真正知道旧系统里哪里埋着雷、旧东西怎么运作、在我们的基础设施里什么是真正可行的、什么是难的、什么是容易的人，那个真正门儿清的人。

把这个人和产品人员放在一起——后者深刻理解这件事为什么是一个机会、我们想解决什么问题。然后再加上一个设计师，三个人在白板前碰撞、争论，最终得出一个我们真正相信的、真实的、在那段时间内确实能完成的版本。

塑形会议的具体细节

Lenny Rachitsky： 太好了。让我们在塑形会议上再深入一层。有几个战术层面的问题。这些会议多长时间？听起来参与的人是一个设计师、一个工程师和一个产品经理。还有什么需要补充的吗？另外，这些会议在什么时候举行——是在一个周期结束的时候吗？顺便问一下，你们管那个六周左右的周期叫什么？周期还是冲刺？

Ryan Singer： 我其实更倾向于用时间盒这个说法。因为有些团队需要固定的周期，因为他们有并行团队，需要那种节奏来降低管理开销。但如果你规模小，只有一两个团队，你可能不需要固定的节奏或周期计划。你可以一个接一个地设定时间盒。所以关键在于，那个时间在向你施加压力，而你有意识地思考——我的时间预算是多少，我需要塑形到什么程度？

Lenny Rachitsky： 让我稍微岔开一下，因为你说的这点很有意思——时间盒可以是完全不同的长度。想象一下在一家大公司里，这会变得很复杂，因为其他团队有依赖关系、有时间线、有发布日期、有上市时间，所有这些东西。这个方法在多大的公司里运作成功过？Shape Up 适合的公司阶段是什么？

Ryan Singer： 它可以在非常大的公司里运作。比如说，我有一些朋友在一家做临床试验的公司，是制药行业的，公司有几千人。并不是每个团队都在用这个方法，但有几个团队在重要领域工作，他们就是这么做的，在那个环境下完全可行。只要你在工程方面有一位资深的人，能够做出正确的架构选择，同时也能做一些协调工作，作为后盾确保有人不会被拉去做别的事情——如果你能划分出”这个系统可以独立于那个系统来开发”——这其实是 David 在 Basecamp 一直以来的超能力，就是这种依赖关系的……

其实并不是那样的。不是的。很多人已经习惯了，觉得事情就是这样的，但其实不是。好的工程领导力是可以把东西解耦的，这样我们就可以在这个系统上工作，而不需要一直想着远处的另一个系统。所以当你在基础设施和架构方面从工程角度做了一些解耦，你就获得了一些自由度。然后如果你还能在容量管理方面想清楚——我要保护这个团队，让他们在接下来几周内不受其他工作的干扰——你就能真正做出很多事情。

Lenny Rachitsky： 你可以在大公司里以这种方式运作，而且不需要整个公司都这样做——我觉得这个洞见对很多人来说是一种解脱。那适配器是什么？我还想回到塑形流程的具体细节，但我忍不住想问这个。假设公司按季度或六个月的节奏运作，然后有一个团队按两周、有时六周、有时四周的节奏在运作——你有什么建议？连接这两种节奏的适配器是什么？

周期对齐的两种方式

Ryan Singer： 这其实有两种不同的做法。一种是我见过一些公司决定采用四周加两周，或者五周加一周冷却期的安排，然后把它和季度对齐，加起来刚好是一个季度。这种做法我确实见过。另一种情况是，当团队在持续交付有意义的成果时，其实不需要刻意对齐，因为从管理层的角度来看——不管你是 CPO、CTO，还是在大型公司里某个业务线的 VP——你都需要汇报你这个团队在做什么。而当你每次都能说：“我们说要做什么，它就做完了”，下次又说：“我们说要做什么，它也做完了”，没有借口，没有”再给我们几个月”、“我们还在努力”这种话——大家真正想看到的就是这种推进力。

Lenny Rachitsky： 对，如果你做得够好，大家就不会来打扰你。这个道理说得通。

Ryan Singer： 绝对的，绝对的。

Lenny Rachitsky： 我很喜欢这一点。好，回到塑形的话题。也许有一种方式能让大家更容易理解——塑形会议的产出是什么？

塑形不是什么

Ryan Singer： 塑形会议的产出是——不过说到塑形会议，也许我们可以先聊聊塑形不是什么，因为有时候我们需要这个对比。

很多时候，当人们尝试 Shape Up 时，我看到的是产品团队要么产出大量的 Figma 文件，要么写大量的文档，比如一份包含一堆需求、一堆背景故事和充分理由的 PRD。而你观察到的是，当你把这些当作”我们塑形的成果”交给团队时，事情就会爆掉。你大概也知道 Figma 文件和工程团队第一次”亲密接触”时会发生什么——那是一场现实的检验，而且很多时候就是要回到画图板重新来过。所以，当有大量解决方案一直细化到细节层面，却完全没有工程团队参与时，通常这就是一个痛苦的模式。然后就会出现”不行，我们做不了那个”，或者”实际上逻辑不是那样的”。

除此之外，另一个大挑战是，UI 表面之下有太多你看不到的东西。从这里到那里的流程是什么？有哪些不同的逻辑分支？在什么情况下，流程是从这里到这里再到这里？幕后在发生什么？工程团队简直得戴上 X 光透视眼镜去研究这个东西，试图理解底下到底在发生什么。我经常用一个装修房子的类比：你可以有最漂亮的效果图——这是新卧室，床边会有从墙壁伸出来的灯——你可以有完美的效果图、完美的灯具、完美的颜色，但如果你没有检查那面墙里有没有电线，那一切的成本和时间都会彻底改变，因为你可能得把墙砸开，把线引上去给那些灯供电。

塑形会议的真正产出

所以，当塑形会议进行得顺利时，我们需要产出的成果是某种图纸或示意图，让工程师、产品和设计三方都能看着它说：“我们理解了，我清楚地知道要去构建什么。”

我用书里的日历功能来举例。日历是什么？首先，在能够塑形之前，我们有一些工作要做，就是能不能把这个问题描述清楚。在真实的塑形工作中，我们称之为 framing（框定）。书里有一章叫”Setting the Boundaries”（设定边界），专门讲这个。就是说，我们不是要做一个日历——那是 Google 日历——天知道边界在哪里。我们把范围缩小到：我们理解我们的特定客户反复提出的这个需求，核心是”我需要看到空闲时段”，而现有的日程视图中，我只能看到已经安排好的事项，看不到可以预约的空档。

所以我们就抓住了我们要解决的问题——空闲时段。这就是一个好的框架。那我们到底要构建什么？我们总结出一条好的经验法则：如果塑形做得好，你通常可以用不到 10 个要素来描述它。如果我能够说：“它会有这个、这个、这个、这个、这个和这个”，这就是我们让人们看到空闲时段的方式——那就是一个很好的指标，说明它足够清晰，塑形做得好。

日历功能的塑形实例

在这个例子中，当你去航空公司订票时，你会看到一个双月的网格。所以就是两个月并排显示，上面只有圆点来标示某天是否有空、是否有安排——就像 iPhone 日历现在仍然有的那种，月视图上只有小圆点。

然后你点击一个有圆点或没有圆点的日期，下面会滑出一个日程视图，显示你那天安排了什么。还有在月份之间前进和后退的导航，还有一个创建活动的按钮，基本就是这些。你可以看到，这不是”什么是一个日历”的问题——它不是一个日历。它是一个双月圆点网格，下面有可滚动的日程视图，加上一个在查看空闲时段时可以按”新建”来创建活动的按钮。这种东西就是经过塑形的，我们可以讨论它意味着什么、包含什么，我们可以有一个非常务实、现实的对话——这件事六周能不能做完？

这才是真正的对话，而不是看着一堆设计稿试图用 X 光透视去搞清楚意图到底是什么，什么是真的什么是假的，什么是可行的什么是不可行的。

Lenny Rachitsky： 这个例子太好了，真的很有帮助。如果让我来描述的话，塑形会议带出来的东西本质上是用户体验——就是线框图/屏幕草图加上关键按钮和流程。它就像带有关键组件的架构，而不是一份规格文档，也不是最终设计，同时也不只是一个用户故事——“作为用户，我需要能够看到空闲时段”。

Ryan Singer： 没错。因为事情出错的地方就在这里——如果我们准备投入工程时间，而我们只是相信有某种方式能看到空闲时段，但具体方式是个问号，那用这种方式去花时间是非常冒险的。

Lenny Rachitsky： 因为你们在做承诺，对吧？

Ryan Singer： 对，我们在做承诺，而那个时间非常宝贵。那是工程师六周的时间，而且那些时间本来就不容易争取到，因为公司里当然还有其他各种力量想把工程师拉去做别的事情。所以如果我们希望那个团队真正高效地利用时间——他们在推进，他们理解自己在解决什么问题，而且他们有创造性地投入，因为他们知道目标是什么——他们就需要在问题端有清晰度（这是关于空闲时段的），在方案端也要有清晰度（它是一个双月圆点网格加可滚动日程视图加一个按钮）。在真正的高保真设计和代码层面，仍然有无数有趣的创造性任务等着他们。有太多东西需要解决，但那是一个他们所有人都能装在脑子里、理解并着手去做的东西。

细节程度的调节

Lenny Rachitsky： 你刚才提到的，我觉得很多听众会有这样的反应——“噢，我不敢这样做”——就是如果你做得太细致，团队里的工程师和设计师会说，“搞什么？你就是在告诉我该做什么。这也太糟糕了。我可不想干这种活。” 那么解决方案是不是——让工程负责人深度参与细节，设计负责人也深度参与，这样你就能相信自己不是那种只会照指令干活的代码猴子？

Ryan Singer： 这个问题很有意思。我得告诉你，我在真实世界中看到的主要失败案例，一次又一次，始终是细节不够。这也是最常见的失败模式——工程师跑回来找产品的人说，“你给我的东西不够。” 真的就是这样。但我能理解为什么想到这件事会让人后背发凉，因为当然，如果你给一个资深工程师说，“这个模型的数据库变更，我想让你这样来实现 schema”，他会说，“你以为你是谁？你算什么？” 你懂我的意思吧？但真正有趣的是，这不是一个放之四海皆准的事情。团队觉得有帮助的细节量是一个可以调节的旋钮，取决于团队里有谁。

如果构建团队里有一个相对初级的人，而塑形阶段有一位资深工程师参与，那位资深工程师就可以通过提供更多细节来帮助这个初级工程师更成功地完成任务。比如，“我们要做这件事，我建议这样、这样、这样和这样来处理。” 那个初级工程师——当他不知道怎么做的时候，他是不会开口问的，因为他不想暴露自己不会，他会把迷路这件事藏起来，然后在项目后期爆雷。而反过来，如果给了他更多指引，他就能成功。他能从那位很懂行的人那里学到人家是怎么处理这个问题的。然后在下一轮或者几个项目之后，你就可以把旋钮往回调，说，“好吧，我们少给一些细节，看看他能不能应对。”

所以你真的可以给人们更大的成长空间，帮助他们成功。当然，反过来也行——如果团队里有一些真正出色的人才，你们有长期的合作历史，你有充分的信心他们能够理解并解决问题，那当然可以把一些东西省略掉。

但我经常看到的一种情况是：如果构建团队里有人觉得自己应该参与方案的根本决策，那更好的解决方案其实是把他拉进塑形阶段，让他在塑形会议中扮演那个技术角色。如果他具备合适的技能、视角和知识来胜任这个角色，那就直接把他拉进塑形。所以核心就是：我们如何把人安排到能发挥他们优势的位置，然后给他们一个输入，使得无论他们处于哪个工作环节，都能施展最大的创造力，同时又拥有最大的清晰度，从而真正高效地利用时间，也对自己的工作感觉良好。

Lenny Rachitsky： 感觉这其中的核心就是——先把最大的风险排除掉，把最大的未知尽可能解决掉。大概是那 80% 的风险——让我们在承诺这个胃口之前，先深入地理解它们。

塑形阶段的风险排查

Ryan Singer： 完全正确。有这些东西——我们可以叫它们兔子洞，也可以叫它们定时炸弹——就是我们说”没事，能搞定”的那些地方。举个简单的例子，我跟一个团队合作过，他们的产品是一个 FinTech（金融科技）产品的注册流程，其中有一个注册步骤，在这一步他们会在漏斗中流失很多人，因为用户需要填写一大堆信息。后来他们发现其实可以从合作的银行那里把数据直接导入。他们就想，“我们根本不需要问用户这些。所以我们能提升转化率，能从用户体验中去掉一个步骤，太棒了。”

但他们没有去看的是：如果你去看那个注册步骤的代码，它其实不是一个步骤。根据客户对接的是哪家银行，这个步骤有三条不同的分支。这就是那种听起来美好又简单，但等你真正深入细节才发现——“哦，等等。“你懂我的意思吧？现在我们要做决策了。如果你已经在一个项目的中期，资源已经分配了，大家已经承诺要做这件事，工程时间的安排已经对齐了，而你在第四周才发现这个问题。你懂吧？你画了那么多漂亮的设计稿，结果第四周才发现这个，那可不是个好位置。

但如果我们在塑形阶段，项目还没启动，我们甚至还没有批准这个项目，而且我们有一位工程师在场——不仅仅是产品的人，不仅仅是设计师，还有那位工程师，他有时候会坚持——我喜欢把他想象成一个什么都见过的脾气暴躁的老水管工，他坚持要在报价之前先撬开墙壁看看管子。所以当你在那个房间里有这么一个人，他会说，“听起来都很好。让我们先看一下代码，搞清楚你说的到底是哪个页面。就让我们快速看一下。“打开代码、找到我们正在讨论的那个东西、真正审视一下它，只需要一小会儿——然后说，“哦，比我们想的复杂。“

发现问题后的权衡对话

Ryan Singer： 这时候，就不是”完了，我们完蛋了，项目要变大了”。现在，我们可以就权衡展开一场非常有价值的对话。比如，我们这里有三种不同的集成方式，对接不同银行的三条分支。从我们签下的合作来看，或者从客户流经这三条不同路径的比例来看，它们之间的体量对比如何？如果我们只在其中一条分支上做这件事，算不算一个成果？如果三条都做，我们需要多争取多少时间，值不值得？你看，我们进入了一种讨价还价的模式——什么是重要的，什么值得做，我们需要从中获得什么？这非常高效。当你在项目启动之前做这件事，感觉就是——“我们在讨论真正重要的事情。我们现在不是在失败，我们正在直面那些艰难的问题，这些问题正是让我们之后能真正交付一个成功产品的基础。“

塑形会议的实操细节

Lenny Rachitsky： 我们再深入聊聊这个塑形会议，因为显然它是整个方法能够运转的核心，我知道你有一整本书讲具体怎么操作，所以我们不会——我不会试图覆盖所有问题，里面有很多细节和微妙之处。但有几个问题：这些会议通常多长时间？听起来像是一整天的事情。然后听起来你邀请的人要尽可能少，但又不能太少。关于谁应该参加，你有什么指导原则？

Ryan Singer： 在”塑形与真实项目”课程中，我们办了一些工作坊，帮助人们体验塑形会议是什么样的。我一直觉得很有意思的一点是——我和 Kathy 主持这些会议的时候，人们不习惯这么快节奏地工作。“我们现在到底在做什么？""这个决定是什么？""现在有什么想法？“我们不会说”先回去画个东西，然后我在文档上留个评论，明天再聚”。而是——从零开始，我们现在有什么想法？想象一下，我们已经把日历问题收窄了：是关于空白区域的问题。从业务角度来说，我们愿意花一个周期，也就是六周时间，来尝试解决这个问题。我们相信存在可行的方案，那我们能想出什么来？

Lenny Rachitsky： 这就是塑形会议的输入——或者说，是框定阶段的产出？

Ryan Singer： 没错。通过框定工作把问题收窄——这又是一个很大的话题，很多时候 PM 只是照单全收，没有真正去谈判、去把问题收窄到”这到底是什么，价值在哪里”。但我们假设这一步已经完成了，问题已经收窄了。接下来我们要做的就是尝试不同的方案，而关键在于——我们要努力打破它们。我想画一个方案出来，然后让技术人员发现问题——“这个行不通，因为这个原因”。或者产品人员看了会说，“我理解这在技术上是简单的做法，但如果我把客户场景走一遍，我觉得我们实际上并没有交付价值。“你明白吧？

方案可以从不同角度失败。我们在会议中还会指导大家一件事：不要只走一条路，然后卡在一个方案上围着细节绕三小时。要真正退后一步说——“这里有一个方案，如果我们做一个滚动的日程视图，怎么样？这是方案 A。那有没有一种截然不同的做法？“如果我们不想要那个日程视图，有没有办法只用月视图来实现？让我们画出来看看。这就是会议中发生的事情。你问了时间的问题，我从人们不习惯直接面对空白页、当场尝试方案这一点说起。

确实需要一点学习成本，学会直面那张空白页，大家一起开始尝试。我们发现，一个三小时的会议可以非常高效，帮你理清我们现有的可行方案有哪些，以及还缺什么大的部分。比如，“好，我有了日历点阵的方案，有了日程视图的想法，但多日事件怎么办？“就会出现这种”那什么什么怎么办”的问题。那我们可能先暂停一下，各自想一想，有人就那些遗留问题画一些草图，做一两个技术试探（spike），然后我们再回来开另一个三小时，或者第二天再聚。我的经验是——如果你要做的项目使用的是现有技术，你不是在发明新算法，不是在发明什么新数据库，不是在训练新 AI 模型，而更多是”我怎么用我们现有的 API、框架和技术栈把它们组装起来、构建一个东西”——那么只要问题是清晰的、时机是对的了，你大约三次会议就能得出结论：什么是可行的。关键在于全身心投入这些会议，真正地互相碰撞。如果你只有产品和设计师在场，然后说”回头再给技术人员看”，那一切都可能崩盘。然后你发现比预想的复杂得多，只能回到原点重新来过。我们需要所有必要的信息都在同一个房间里，这些会议才能快速推进。

Lenny Rachitsky： 这个方法里嵌入了太多精妙的设计，而且它顺应了人的天性。一方面是，你需要真正深入那些边缘案例和细微之处，而不是仅仅——

Ryan Singer： 对，更多的具体性。

Lenny Rachitsky： 非常具体、非常深入，然后胃口的概念也是——这里面有太多元素都契合了人类实际工作的方式，而不是那种理论式的”嗯，看看这要花多长时间，会是个很棒的项目……我们在做的过程中再搞清楚，不需要现在真的想清楚，我们没时间做那个。”

Ryan Singer： 而且我们是在一起解一道谜题——它必须在这个时间内可行，同时又要命中我们要解决的问题的那些关键点。它要做到这些事，但在这么短的时间内。还有一件事我想提——我们不能画 Figma 文件。顺便说一句，这次对话中我一直对 Figma 很不客气，但确实有需要 Figma 文件的正确时机。我们想要做的是先就那些关键布局达成清晰共识——就好比我们已经知道厨房的水槽放哪里了，现在可以就瓷砖和具体的水龙头款式做最终决定了——

Lenny Rachitsky： 填缝剂的颜色。

Ryan Singer： ……之类的东西。对，填缝剂的颜色。我们不想每次有什么变动就把所有东西推翻重来。所以 Figma 有它自己的用武之地，在那个阶段用起来很棒、感觉很好——哦，现在变漂亮了，现在太棒了。但在塑形会议中，你没办法在高保真的东西上协作。所以我们也需要一些协作的方式，这就是你在书中看到的那些技巧，比如 breadboarding（面包板草图）和 fat marker sketching（粗标记笔草图）。这些工具帮助我们把一个想法非常、非常清晰地表达出来，而且是有细节的——我们要按这个按钮，从这个按钮跳到这里；这个计算运行，然后我们得到这个结果，然后我们可以选择去这里或那里。这才是我们需要看到的东西，在这个细节层面上我们可以一起快速推进，同时还能看到一些真实的东西——更多是在面包板草图这个层面上。

Lenny Rachitsky： “粗标记笔会议”这个说法很能让人联想到整个塑形过程的精髓——非常高层级的草图。这个词用得很好。

Ryan Singer： 我经常看到的一个危险是，我们不想说”哦，Figma 在这个阶段不太合适，所以我们改用粗标记笔草图”——结果你得到的只是一个模糊版的 Figma。你明白我的意思吗？就是细节更少了而已。一张粗标记笔草图要对我们这些构建者有价值，它必须真正把想法传达清楚。当我看到那张图的时候，我的反应是”哦，现在我明白了”。但如果它更像是一个笼统的线框图——仪表盘放在这里，下面有四个报告——那我仍然不知道该构建什么，对吧？

Lenny Rachitsky： 嗯嗯。

Ryan Singer： 如果它没有告诉我该构建什么——所以也许这可以回到你之前的问题，塑形会议的输出是什么——就是：如果我们能把这个交给一个技术人员，他说”好，我现在知道该去构建什么了”，那就是塑形完成了。

如何开始实践 Shape Up

Lenny Rachitsky： 我对我们这次流程概览非常满意。我觉得我们很好地给了大家一个要点。当然，如果他们想要真正实施的话，可以去读那本书深入钻研，或者跟你合作——我们稍后会告诉大家怎么找到你。假设有人说”这太棒了，我想试试”，对于一个目前……比如说在创业公司，每两周发一次版，甚至每周发一次版的团队，你会建议他们怎么迈出第一步？然后对于大公司来说——比如那些在用 Agile、Scrum、SAFe 的团队——他们说”哦，我们想试试不同的东西”，又该怎么开始？

Ryan Singer： 有时候开发团队喜欢不用 Scrum 仪式的想法，所以他们想采用六周周期，但如果工程和产品没有一起想办法如何协作塑形——就像我们之前谈的那样——那个时间盒不会顺利的。所以我——

Lenny Rachitsky： 他们以为不用再开站会了，结果现在变成了一整天的苦思冥想。

Ryan Singer： 实际上会变成更多的会议，因为我们不知道该做什么。

Lenny Rachitsky： 而那些更多的会议就是塑形会议本身。对吧？

Ryan Singer： 不是，我的意思是如果我们没有——

Lenny Rachitsky： 哦对，我理解了。

Ryan Singer： 如果我们只采用了六周周期，说”我们边做边想”，但没有采用塑形环节，那我们就是不知道该做什么。然后到了周期末尾，我们基本上是一边做一边仓促地塑形。然后时间用完了，然后我们觉得这不像……虽然暂时逃离 Scrum 仪式确实不错，但我们没法说自己一次次地在用香槟敲船头来庆祝发布，对吧？

Shape Up 的 kickoff 与 Scrum 的 sprint kickoff

Lenny Rachitsky： 这其实是个好时机，可以聊聊——Scrum 里显然有 sprint kickoff。对大家来说主要区别是什么？因为他们可能会想”哦，这不就是 sprint kickoff 吗。”

Ryan Singer： 这个问题好。在 Scrum 团队中你经常看到的是，有一个人创建这些工单——这些就是 sprint 里要完成的事情。在很多情况下——在我个人看来是太多情况下——创建那些工单的人并不是真正动手构建的人。

Lenny Rachitsky： 就是你的 product owner。

Ryan Singer： 所以这里有一个巨大的鸿沟。我们可以深入聊这个，但核心是上下文的脱节——写工单的人并不真正理解其中涉及的工作量。你明白我的意思吗？所以那些工单里埋着大量的未知数和定时炸弹——它们听起来合理，但实际上不是由真正理解需要做什么工作的人创建的。关键区别有两点。在 Scrum 中，是一个不是构建者的人在创建工单，这就是那张残酷图景中的”碎纸机”。在 Shape Up 的世界里，你有一个已经塑形好的单一想法——就是我们塑形好的那个东西，议程视图里的两个月等等。你们自己去拆解任务吧，因为你们是专业人士。你明白我的意思吗？就像承包商——如果你在盖房子——他们需要了解设计图纸，但你不需要告诉他们”现在拿上锤子走到那边去”。那是他们的事，对吧？所以在 Shape Up 的世界里，kickoff 就是：这是一个已经塑形成熟的想法，现在时间盒开始了。

在 Basecamp，这个过程非常、非常松散，因为他们那里全是资深人员。他们有大量非常资深的工程师，而且所有设计师都会写代码。他们技术功底很深，是真正非常、非常熟练的人。我发现当团队组成更复杂一些——如果他们不全是超级资深的话——有一个简单的方法很有用：在 kickoff 的时候，把塑形好的内容拿来，画一个九宫格，给我九个格子，分别列出你认为从实现角度看需要完成的九个主要模块。也就是把这个翻译成九个主要的实现范围，这些需要在时间盒内完成。这是一个启动项目时非常有用的练习，我们现在有很多团队在用这个方法。六周是 30 个工作日，除以九，每个格子大概四天。所以通过一个快速的练习，你就能获得很大的清晰度。再次强调，这是由构建者来做的。这对他们来说也是一个很好的练习，可以让他们注意到：“哦等等，我们觉得这里的范围太大了。“即使之前看起来合理，但当我们把它放进九个格子里的时候——我觉得我们做不完所有这些。或者这也是一个很好的时机，一个比较初级的人可能会描述他们的实现方案，然后一个资深的人可以审查一下说：“其实我们之前做过类似的，如果不采用这个其他方案的话会碰到这个麻烦。“所以那些很好的指导时刻就会自然而然地出现。

Lenny Rachitsky： 如果你要尝试这个方法并举行塑形会议，一个你方向正确的信号是——输出的结果，也就是构建团队能不能列出九个……必须是九个吗？六个行不行，十个行不行？

Ryan Singer： 我发现如果超过 10 个，你就又掉进了工单地狱——这有一百万件事等着我去做。你明白我的意思吗？如果你有 100 件事，那什么都说明不了。但上限就是九个或更少。

Lenny Rachitsky： 九个或更少。好的，好的，很酷。

七加减二法则

Ryan Singer： 我其实觉得……我在这里推测一下，不过你观众中的 UX 设计师应该都知道这个七加减二法则（rule of seven, plus or minus two）。这是认知科学中发现的一个原则，关于一个人同一时间能在脑子里装下多少东西。所以这个九就是七加减二的上限，它基本上就是在说——我们脑子里是不是真的有一幅关于”构建这个东西意味着什么”的全景图？我们能不能看到整座城堡的全貌？

如何开始尝试 Shape Up

Lenny Rachitsky： 所以我听到的是，如果你现在在一个敏捷 Scrum 团队中，想要开始尝试这个方法的话，就是安排一次塑形会议，先假设周期为六周，带着一个”我们要解决的问题是什么”的框定进入会议。这样理解对吗——就是我们想要解决的那个问题？

Ryan Singer： 对，当然。问题在于我们要解决什么问题，因为塑形工作更多是在探索——我们的解决方案有哪些选择？而如果问题太模糊、太大，如果问题只是”日历”两个字，那塑形就会变成一个不断膨胀、永无止境的事情，我们根本没法推进。

Lenny Rachitsky： 嗯，好的。那你花三个小时，也许第一次会议花六个小时。你会建议刚开始尝试的时候尽量控制在这么多时间以内吗？

Ryan Singer： 不，我不会这样做。我觉得关键其实在于——如果你已经到了想要举办塑形会议、并且成功把产品和工程拉到同一个房间里来做这件事的地步，你就已经很了不起了。如果你到了那个阶段，你已经做得很好了。哦，太多的挑战其实在于能不能让产品和工程达成共识——我们不能让项目一直拖、一直拖、一直拖。我们不能每次到了一个冲刺结束或一个周期结束的时候还看不到尽头，或者不得不在最后一刻做大量的削减和妥协，导致质量不行……或者跟最初设想的完全不是一回事。当这些问题正在发生的时候，或者……另外顺便说一下，这些问题恰好就暴露在最关键的层面上。

想象一下，你是 CPO，你是 CTO，你应该能回答”那个项目进展如何？”

而回答是，“呃，其实，我们还在做。“我能想起好几次我需要向 Jason 汇报，他期望我在某件事上有了进展，而我什么都没做出来。那种感觉——当你和最高领导层坐在一起，却对项目进展没有好的回答时……哦，那真是太煎熬了，对吧？然后从 CEO 的角度来说就是，“进展在哪？我们在做生意啊。真的，还是什么都没上线？”

这种情况不能一直持续下去。所以无论在高层还是在团队内部，总会出现某种共识——我们不想继续拖下去了，我们不想继续迷失在细节里，然后这就成为了激活能。你聚拢起力量说，“好吧，我们真的要尝试一些不同的东西了。“

试点项目

在这种情况下，我会说通常最有效的做法是——好，我们要做一个试点项目，我们要做的是，正如你说的，选一个对我们所有人都足够重要的问题，我们觉得它有意义，值得用心去做。它不一定是六周。它可以稍微小一点，也许第一次你更愿意接一个三周的项目。重要的是把这些事情匹配起来。

这是一个我们真正关心的问题。它很及时，是我们希望能尽快上线的东西。它不是那么小以至于我们练不出这个新肌肉，但又足够大，让我们觉得真的做成了一件事。所以也许四周，也许六周，也许三周，我说不好。然后到达一个阶段——我们跟问题较量一番，把它收窄。我们进入塑形会议，然后尽力而为。你明白我的意思吗？而且通常还会发生的是——如果我们有一个工程团队即将有空来做这几周的工作，那就是我们能花在塑形上的时间上限，这又是一个现实中的情况。有时候我们会讨论——

一方面，有这种永无止境的文档来回传递以获取反馈和评论的世界；另一方面，团队即将就绪。我们是真的要动手做了，所以实际上，我们只有一周时间来做塑形，因为工程团队下周就要 kickoff。你明白我的意思吗？当你真正处于那种”我们现在就要交付东西”的共识状态中，这才是更真实的场景。

Lenny Rachitsky： 对，现实中的约束。这确实是一个非常有用的方式来判断你有多少时间来做这件事。有些人会说，“我不知道，身边没什么朋友在用这个。这种工作方式有点奇怪，我不是经常听到。“你会对他们说什么来帮助他们下决心——“好吧，我真的应该试一试。有多少人在用这个，你见过什么效果。“有什么你能分享的、能帮他们迈过那道坎的东西吗？

等到疼得受不了再改变

Ryan Singer： 我会说，等到疼得受不了了再说。如果不熟悉是最大的障碍，那也许现在的事情还行。因为这不是唯一的方法。更像是——改变真的很困难，而如果有一个充分的理由去做，比如，你看，我们用老方法做过了，我们尝试了不同的实验，我们甚至已经换了一任新的产品负责人，或者换了一个不同的 CTO，但我们还是遇到同样的问题。那到了某个时刻就会觉得，我知道这让人不舒服，我也不认识谁做过这事，但我觉得我们需要尝试一些不同的东西了，因为我们不能再这样继续下去了。

Lenny Rachitsky： 这个回答很好。沿着这条线继续问——有哪些信号表明是时候尝试新方法了？你经常看到什么样的痛点，让人觉得，好吧，你应该认真了解一下这个？

痛点贯穿整个旅程

Ryan Singer： 痛点贯穿整个旅程。所以我觉得最明显的地方是在最后阶段——当我们以为要完成了，结果这东西一直拖、一直拖、一直拖。团队交不出东西，我们在原地踏步，不停地兜圈子，看不到尽头。当然，这是最终的爆发点，但一路上也有很多痛点。

如果我们一直追溯到上游，追溯到项目的源头——销售跟客户谈了……你明白我的意思吗？或者销售跟潜在客户谈了，然后他们有一个关于我们需要构建什么的想法，或者 CEO 某天洗澡时突然冒出了一个想法，或者产品团队做了大量的研究，有一整套理由说明为什么这是下一个应该构建的东西。不管是什么，从业务角度来看，都有一个”这是我们应该做的下一件事”的源头。

从模糊需求到无尽的追问

Ryan Singer： 如果我们只说”仪表盘”却不讨论它到底意味着什么，如果我们只说”日历”却不界定它具体是什么，那我们会经历什么？就是那种模糊的感觉——很难得出一个明确的结论说：对，这就是我们需要去做的事。它就像一个不断膨胀的 blob。如果你曾经感受过这种情况，那这已经是第一个痛点了。

然后当然，它会往哪里发展？我们说了”日历”，但不知道它意味着什么，然后把它交给产品团队。我们要么拿到一大堆 Figma 文件，要么拿到一份列出百万条需求的 PRD，描述一个”优秀的日历”应该是什么样子。当然，我不是要刻薄那些在这上面倾注心血的人——Figma 文件确实很漂亮，只是出现得有点太早了。PRD 里也确实写了很多真实的内容，可能对项目中的决策真的很重要，但它被打包的方式在那一刻并不能被真正吸收。你写了一份文档，抱歉，到底谁真的会去读它？你懂我的意思吧？我知道这很残酷，但现实就是这样。而且即使我们试图去读，因为东西没有被塑形过，我们没有把它归结为”就是这个、这个、这个，它的工作方式是这样的”，所以读完之后你脑子里也很难形成”这就是我们要去构建的东西”的清晰概念。它就像一百万块拼图碎片，需要你自己去拼。

所以我们看到的局面是：要么有 Figma 文件，然后工程师那边开始反弹；要么有 PRD，但大家看完后说：“好吧，但我们还是不知道具体要建什么。” 所有这些情况，不是在向前推进，而是问题越来越多，反弹越来越多，一次又一次回到起跑线。这是另一个很大的信号，说明出了问题。

然后到了构建阶段，我们以为自己已经达成了共识，以为大家都在说”对，这就是我们要做的”，但冒出来的问题却越来越多。越来越多的意料之外的复杂性，我们没预料到的东西，而且完全没有”我们在逐渐接近答案”的感觉，只觉得事情越来越难。所有这些都是信号，不管你用什么流程，都说明缺乏清晰的塑形，缺乏清晰的框定，因为我们对自己到底在做什么缺乏清晰的认识。

功能工厂的批评与反论

Lenny Rachitsky： 在我们开始录音之前，你提出了一个很有意思的观点——人们总是在谈论 feature factory（功能工厂），但实际上这些工厂很少是高效运转的。它们其实并不真的管用。能谈谈这个吗？

Ryan Singer： 对，我理解 feature factory 这个批评想说什么。它实际上恰恰指向了框定的问题——我们没有就去协商一件东西的价值和我们想要获得的成果。我们只是拿来就建。然后当然，按照 feature factory 批评的说法，我们只是因为有人说应该建所以就建了，结果用户不用它，不觉得它有价值，产品只是在不断膨胀。

但问题是，我想说的是，如果你有一个 feature factory——意思是你在持续不断地产出功能——那你的状况其实相当健康。你只需要往这个工厂的入口喂不同的输入就行了。

大多数团队真正在挣扎的是：他们没有可预测的、可重复的交付节奏。至少根据我的经验，更普遍、更大范围的挣扎是——东西不动了，在拖。我看不到尽头。我失去了……我开始感到倦怠。你懂我的意思吧？做这件事已经不让人兴奋了，诸如此类的感觉。

Shape Up 的适用阶段

Lenny Rachitsky： 也许这部分的最后一个问题：一家公司在什么阶段开始使用 Shape Up 最合适？你们基本上从最初三个人开始就这样工作了。你觉得刚起步的创业公司应该一开始就采用这种方式吗，还是你觉得到了后来才更有用？

Ryan Singer： 我们并不是一开始就把它形式化的，而是直到不得不做的时候才做。很长一段时间里，项目并没有固定的时间长度，只是对紧迫性有一种理解，对”太长了”有一种感觉。它真正变成”哦，这是一个周期长度，是六周，然后我们暂停，然后这些人聚在一起决定下一个项目是什么，然后主要由这个人来做塑形”——你懂我的意思吧？所有这些东西，都是在我们达到一定规模之后才被梳理清楚的。

通常来说，如果从小到大来看，主要的转折点是：有一个阶段创始人还参与所有事情，所以你用什么流程都无所谓，一切都会运转得不错。

但接着你开始招聘第一批其他人，然后你第一次尝试把一些事情委托出去，创始人试着减少参与，这时候往往很多问题就开始浮现了。创始人开始问自己：“我们以前很快的，现在因为需要扩展规模招了人，结果变慢了。我们怎么才能重新快起来？因为我们知道——”

Ryan Singer： “——怎么做是对的。所以，‘我们怎么才能重新快起来？‘因为我们知道那是什么感觉。如果我们创始人重新亲自下场、卷起袖子，我们就能让这事推下去。但我怎么让我们招进来的人做出这些取舍和决策？我怎么让工作重新流转起来？” 这些是我们确实在那个阶段看到的情况。所以那是一个非常关键的时机——我在引入新人，我不知道该告诉他们怎么工作。我不想引入一堆 Scrum 仪式，单纯凭感觉用看板也不管用，因为他们对到底该做什么缺乏足够的清晰度，所以我得一直当保姆一样盯着他们。你懂我的意思吧？就这类问题。

还有另一个极端，就是——我们已经过了那个阶段了。我们做 Scrum 或者别的什么已经好多年了。公司一直在增长，收入在进来，销售在做他们的工作，一切都在运转。但是，东西就是出不了门。我们已经做了好多年，有一支根深蒂固的开发团队。一支根深蒂固的工程团队，跟一墙之隔的根深蒂固的产品团队彼此割裂，所有人各自为政。整个事情就像——我们卡住了。

这个阶段更多的是在高管层面开始出现一些紧张关系。会有一些互相指责。会有一些：“为什么这个不动了？为什么这个没发生？我们在所有这些工程师身上花了这么多钱，却拿不出什么可以展示的成果？” 到了这个节点，就需要进行一些艰难的对话了——“我们到底怎么开始围绕如何分配时间来协商？” 我们不能只有无休止的重构和基础设施项目，我们需要真正去构建能再次卖出去的东西。

Lenny Rachitsky： 真是一针见血。

Ryan Singer： 对，你懂的。但确实……有很多工程组织已经存在了很长一段时间，整天都是重构、技术债务之类的东西。这些情况之所以出现都有它们的原因，但总有一个时刻，我们必须想办法穿透这一切，做出一些艰难的选择，这样我们才能腾出时间来去构建那些真正能推动业务前进的东西，而不是仅仅维持现状、在原地踏步。

Lenny Rachitsky： 我猜后者就是你主要合作的对象——那些把你请进去的公司。

还记得”快”是什么感觉的公司

Ryan Singer： 很多找我的人，是那些还记得”快”是什么感觉的公司。他们刚变得太大，不喜欢自己变慢了。这种情况我遇到很多。我觉得你的直觉是对的——最后那个类别的市场最大，但很难触达他们。谈这些事情并不容易，这些都是敏感话题。你懂我的意思吗？比如”我们的工程团队迟迟不能交付”——这种事发生在领导层。组织深处有大量抱怨，但底层的人谁也改变不了什么。归根结底，真正需要改变的接口其实在高管层面——他们得能说出”我们的时间到底花在哪里了？我们必须做出改变。”

Lenny Rachitsky： 让第一个类别更具体一点，你觉得什么样的组织规模最需要这些？比如说多少工程师？还是说从他们招第一个 PM 开始？大概是什么——

Ryan Singer： 有时候我会和人聊”我到底该怎么招第一个 PM，他们该干什么”这类话题。但通常比那更晚。是已经招了第一个 PM、第二个 PM，甚至可能第三个之后。产品和工程加起来大概三五十人，然后他们发现：“我们以为把每个人都放到了合适的位置上，我们基本上做了该做的事，但一切就是在磨蹭。我们为什么这么慢？”

Lenny Rachitsky： 明白了。所以三十到五十人左右似乎是一个合适的……基本上你发现就是在那个规模，事情开始真正出问题。

Ryan Singer： 那就是问题暴露的时候。我想说的是，如果有人听到这些觉得都说得通，而他们还处在那波浪潮更早的阶段，那当然越早预见越好，对吧？

Lenny Rachitsky： 对，这说得好。

Ryan Singer： 所以如果你——

Lenny Rachitsky： 等到太晚了他们才找上门来——

Ryan Singer： 我主要是在太晚的时候才听到这些事。所以他们才会主动联系——

Lenny Rachitsky： 明白了。所以可能更接近三十人的时候。好。

Ryan Singer： 说实话，我觉得从第一个项目就开始了——比如创始工程师不再亲力亲为，新招的人接手了责任。或者那个既是创始人又是 CEO 的人第一次把事情交给一个 PM，以为对方能把它推进到底。然后结果没有达到他们的预期。我觉得那些脱节就是从那时开始的。是从第一次远离实际工作的那一步开始，所有这些问题的种子就埋下了。

Shape Up 中 PM 的角色

Lenny Rachitsky： 我想谈谈 Basecamp，以及是不是每家公司都能像 Basecamp 那样运作。不过在此之前，关于 Shape Up 还有什么想补充或分享的吗？

Ryan Singer： 有一个关键点，就是 PM 的角色。我觉得现在很多团队中，出于无奈，PM 把大量时间花在构建阶段、在时间盒之内到处追踪，确保大家没有卡住、没有迷失在细节里，试图推动事情前进。这有时候太接近项目管理，而不是产品管理。

而在 Shape Up 团队中，当他们进入佳境时，PM 会向上游移动。PM 不再忙于”我怎么才能让这个项目在构建过程中不出岔子”，而是更多地在思考”我怎么理解业务上下文？我怎么缩小问题的范围？我怎么和可能把这个需求带给我的 CPO 反复协商，找到问题的核心？“——真正深入理解业务、问题、客户领域，搞清楚什么问题值得解决，以及那个问题的哪个切面才是有价值的切面，值得我们去论证应该花几周时间来做。这才是 PM 在 Shape Up 世界中真正能做出大量贡献的地方。这才是他们该做的事，而不是当流程的牧羊人，或者做什么仪式的主持人。

Lenny Rachitsky： 听起来非常棒。我最近在思考一个面向 AI 的世界会对 PM 的角色产生什么影响，感觉其实非常类似——构建工作现在会由 AI 工具替你完成。这意味着更大的问题变成了”我到底该构建什么？我构建出来的东西对不对、行不行得通？“感觉这和你说的情况很像——PM 在前期花更多时间思考该构建什么，然后构建过程就放手多了。放手到什么程度呢，五分钟就搞定了——“帮我构建这个东西”，“好了，在这了”。

Ryan Singer： 对，拭目以待吧。拭目以待。

Lenny Rachitsky： 拭目以待。

Ryan Singer： 我也非常好奇。

Lenny Rachitsky： 天哪，真是疯狂的时代。好，我们来谈谈 Basecamp。我记得我们在播客录制前聊过这个——你希望人们知道 Basecamp 是非常独特的，不是所有人都能像 Basecamp 那样工作。来谈谈你在这方面的洞察和建议吧，尤其是当人们看到从 Basecamp 出来的所有这些建议的时候。

Basecamp 有多独特

Ryan Singer： 我得告诉你，我完全不知道我们有多独特，直到我离开了那里。有太多事情了。比如，很多人问我的那些书中没有写的东西，反而开始向我揭示了这一点。有太多我习以为常的东西。我的意思是，每个设计师都会写代码。

想象一下，如果每个设计师都会写代码——我不是说只会 HTML。我是说能在本地运行应用，进入渲染那个视图的地方，把那个东西调成自己想要的样子。我是说真的写代码，每个设计师都会。如果每个设计师都会写代码，那设计和工程之间的墙在哪里？那个你拿着 Figma 文件走过去、然后满心期待被工程师一句”不行”全部打碎的时刻在哪里？那些时刻在那个世界里根本不存在。

而且，我认为还有一个特点：业务目标——我们可能要做某个项目的原因——与创始人的认可之间没有距离。不存在那种”高管远在天边盯着大目标、中间隔着一层 PM、再往下才是构建”的情况。创始人始终在那里，直接参与问题定义。

我是说到 2021 年我离开之前都是这样。这意味着我们在解决什么、为什么解决、为什么为此腾出时间——这些问题始终非常清晰。然后当然，在工程方面也是如此。想象一下，没有销售团队，没有市场团队，所有的销售和市场都由那几位传奇创始人自己做了。这意味着工程时间不会有争抢，不会有各种不同来源的需求让你去搏斗。

David 在这方面做得太出色了——我越看到真实世界，就越惊叹于每六周工程团队都有一条清晰的跑道：“我们有时间做任何我们共同认定最重要的事情。“每六周就是整整六周。不是空头支票，但你懂我的意思——一整块空白的六周。

Lenny Rachitsky： 嗯。

反复实践 Shape Up 的挑战

Ryan Singer： 一遍又一遍，年复一年。让工程产能始终聚焦于产品的准备状态，全身心投入到为产品构建令人兴奋的事情中去，而不是迷失在重构、新基础设施、技术债务之类的泥潭里。我的意思是，这些差异确实令人惊叹。所以这些是一些非常大的不同。但这并不意味着你必须是 Basecamp 才能用 Shape Up。它真正意味着的是，当我们说”哦，只要开一个塑形会议，如果你有时间盒的压力，你们就能一起做取舍”——问题是，“如果我们习惯于在工程和设计之间竖起一道高墙，那我们就得学习……”想要开始塑形的人就得学习：“好吧，我需要弄清楚该把谁召集到一起，怎么开这个会，我们之间该怎么互动。这样我们才能把所有那些知识整合起来——而在 Basecamp，很多情况下这些知识本来就在同一个人脑子里。”

Lenny Rachitsky： 这一点太重要了，真的需要让更多人听到。因为有太多人上这样的播客，根据自己的经验分享”应该这样做”。但其中有多少关于他们资源的假设、他们雇佣的人、创始人运作方式的前提条件。比如没有销售团队——我觉得那简直……我甚至都没想过这一点。

Ryan Singer： 对。想象一下，从来不存在来自销售的需求，对吧？从来不存在”我们需要这个功能才能追加销售或签下这个客户”的压力。从来没有。

Lenny Rachitsky： 听起来你在这个 Basecamp……顺便问一下，它之前叫 37signals 吗？有意思的是你叫它 Basecamp 而不是 37signals。

Ryan Singer： 对。这跟我离开的时间点有关。我们最初叫 37signals，后来 Basecamp 做得太大，我们就把公司改名为 Basecamp 了。

Lenny Rachitsky： 我不知道这个。

Ryan Singer： 对。所以比如在书的封面上，Shape Up 下面是 Basecamp 的 logo，不是 37signals 的。但后来我又回去了，现在又是 37signals。所以我有时候也很纠结不知道该怎么叫，但两个都是。大家能认出哪个就用哪个，反正是同一个团队。

Lenny Rachitsky： 好，很高兴不是只有我一个人搞混。37signals 是现在的名字，明白。

离开 Basecamp 后的文化冲击

Lenny Rachitsky： 你之前说你离开之后感觉像是走出了一个泡泡。有没有那么一个时刻，你写了这本书，所有人——你告诉大家”你们应该这样工作”，然后你说”哦，等等，这对很多人来说在现实中其实行不通”？有没有这样一个瞬间？

Ryan Singer： 不是说行不通，我只是身处异国他乡。更像是我们试了但没有奏效。我常听到的一个情况是项目不断超期。“我们在周期结束时完不成项目，一直超期、超期、超期。“然后我就说：“嗯，那能给我看看你们的塑形工作吗？“他们就给我看一份 PRD，我就说：“这跟书里写的不是一回事。“再问一遍：“能给我看看你们的塑形工作吗？“他们给我看一堆 Figma 文件。

我逐渐理解到的是，有些角色的人习惯于在某个步骤产出某种制品，然后他们就一直在做那件事。我之前没有意识到——我花了一段时间才明白：“这里根本没有工程师的身影。“等到我们真正开始做课程的时候，我说……实际上我做了好几个项目，手把手地帮助团队，我发现他们……

实际上我做的第一个咨询项目就是帮助一个卡住的团队。我们做的选择是把最合适的工程师拉到产品那边，让他参与到塑形中来。那一刻的感觉就是：“啊，现在我又回到了我熟悉的世界。“当所有这些知识再次汇聚在同一个房间里的时候。所以那确实是一个……对我来说完全是全新的学习曲线，有很多类似的经历。但那是一个非常大的发现——“哦，我们必须把工程师拉进来。“

Jason 的 Shape Up 续作计划

Lenny Rachitsky： 你正是我最喜欢邀请到这个播客上的那种嘉宾，因为你跟很多很多公司合作，研究什么有效、什么无效。你不是在云端高谈阔论，而是在跟团队一起把事情做得更好。然后你把所有这些学到的经验整理成一本书，跟我们所有人分享。所以对我们来说回报率简直太高了，因为你花了那么多时间做这件事，而且你真正做了实际的工作，不是只停留在理论上。太棒了。但我们还没结束。我想问的一个问题是，Jason 发推说他在写一本 Shape Up 的续作。那边是什么情况？你参与了吗？是怎么回事？

Ryan Singer： 我也看到了那条推文。我承认看到的时候有点惊讶，但一年前我确实跟 Jason 聊过。他联系我说：“嘿，我们在考虑做这本书的第二版。“我的第一反应——想象一下，我当时正处在深入学习所有这些团队需要掌握的东西的过程中，这些是为了赶上 Basecamp 习以为常的做法所必需的。所以对我来说，“有意思。我有很多新的东西，有很多新的想法。也许合作做第二版是合理的。”

但我理解到的是，他想做的是更新他们的工作方式的版本，因为一直以来——我应该用正确的名字，37signals——他们做市场和引领行业的一个核心理念就是展示一个清晰的范例。不是”你可以这样做，有些人这样做”，而是”我们就是这样做的”。

我觉得这是他们的优势所在，非常非常明确：“我们就是这样做的，爱要不要。“我所理解的是，如果我再做一版只是讲 Basecamp 怎么做的书，我觉得会浪费太多机会。因为有太多人，他们需要学习的是更像这样的东西：“怎么让它更接近我目前的处境？如果我今天在产品和工程之间确实有一堵墙，我怎么把对的人拉进塑形会议？我们实际上该怎么操作？我怎么克服所有这些小小的障碍，因为这跟我们目前的工作方式差距太大了？”

所以比如我在”shaping in real life”中做的工作，全都是围绕这些差距的。至于第二版会有什么内容，我不清楚，因为他们——我猜那边会有人在写。但我的猜测是，它会是一种更新，“在山顶那边，Basecamp 正在这样做。“所以希望它会是一个很酷的东西，作为”这是他们的做法模型”来参考。然后问题就是，“我能从中拿走什么，我又需要什么才能真正在我所处的现实情况中让它运转起来？“这大概就是……嗯，这就是我的关注点。

Lenny Rachitsky： 太有意思了。谢谢你的分享。听起来像是一个分叉——你 fork 了它，这两个方向可能会走向不同的地方，但又彼此启发。

Ryan Singer： 嗯。完全是这样。

Lenny Rachitsky： 太有意思了。Ryan，在我们结束之前还有什么想分享的吗？

项目无法交付的根源

Ryan Singer： 我可以提的一点是，有时候人们来找我，是因为他们的项目迟迟无法交付，团队很挣扎，很多事情都不清晰。但根本原因其实是流程最开始的输入太模糊了——比如我们其实并不清楚客户真正在意什么，或者我们不确定价值到底在哪里。所以我们之前讨论的那个框定步骤——“真正的问题是什么？“——在进入塑形之前，这个环节非常关键。这一步也和产品战略紧密相连。在这个阶段，Bob Moesta 的那套 Jobs-to-be-Done 和需求侧研究的方法就非常有用，可以帮助厘清那些大的问题。所以那是我在那个阶段会去使用的工具。

你可以这样理解——在问题定义之前，还有一个问题是：“需求在哪里？人们在哪里感到挣扎？他们真正想挠的那个痒处到底在哪里？“然后，Shape Up 的很多内容，其实是当我发现了一个机会，或者通过客户反馈、Jobs-to-be-Done 研究或者其他方式了解到某些东西是有意义的——现在，我如何把它变成一件我们真正可以在合理时间内完成并交付的事情？这是供给侧。Shape Up 这部分就是在这里发挥作用的。所以也许让大家看到这个关联会很有意思。

Lenny Rachitsky： 这正好是 Bob Moesta 那期节目的好推介。我们深入聊了 Jobs-to-be-Done 框架以及如何实际应用它。你会推荐他的哪本书？听起来基本上是 Shape Up 加上这本书就能覆盖很多了。

Ryan Singer： 其实我最推荐的是《Demand-Side Sales 101》。有趣的是，书名里带”销售”。尤其是对产品人来说，你会觉得”我是做产品的，不是做销售的”。但这本书对”人们真正想解决什么问题”的深入探讨非常好，能帮你进入那种”痛点在哪里？问题是什么？“的思维模式。我觉得这是一个很好的入门点。

Lenny Rachitsky： 对。我不太喜欢那个书名。感觉他们可以起一个更好的名字——

Ryan Singer： 它——

Lenny Rachitsky： 对。

Ryan Singer： 有意思的是，如果你的目标是推动销售进展，那它确实非常精准，因为它讲的是另一种销售——需求侧销售。所以也许对我们这些把它用于其他目的的人来说——我们是产品人，想从中提取一些东西——书名就没那么贴切了，但内容仍然很有用。

Lenny Rachitsky： 对。但基本上它就是一本 Jobs-to-be-Done 的书——

Ryan Singer： 对。它有点像一本更具实操性的 Jobs-to-be-Done 书籍。如果你对 Jobs-to-be-Done 的整体精神感兴趣，那《Competing Against Luck》是一本很好的入门书，那是 Clay Christensen 写的，里面有很多……我觉得 Bob 也参与了很多内容。但如果你想要更实操一些的，比如”访谈具体怎么做？如何思考人们挣扎的时刻？“这类问题，那这本《Demand-Side Sales》在策略层面很合适。

Lenny Rachitsky： 太棒了。我们也会链接到那期节目，花一个小时就能掌握要点。

Ryan Singer： 哦对。那期节目很棒。是的——

Lenny Rachitsky： 谢谢，Ryan。好的，我们完成了。这期太精彩了。我觉得这会帮助到很多人——

Ryan Singer： 我们讲完了。

Lenny Rachitsky： 还没完。最后两个问题。大家可以在哪里找到这本书，想和你合作的话怎么找到你？还有什么想分享的？以及听众可以怎么帮到你？

咨询工作方式

Ryan Singer： 大家可以在我的网站上找到我，网址是 ryansinger.co。我也在 X 上，账号是 RJS，还有 LinkedIn。至于大家怎么帮到我？我很喜欢听到正在经历这些问题的人的声音。如果你正在经历这些问题——比如”事情一直在拖延”，或者”我们看不到终点，也得不到我们需要的质量”——说真的，我所有的经验就是通过和深陷其中的人交流得来的。所以即使下一步该做什么还不清楚，只要这个问题是真实存在的，我都想了解。我很乐意聊聊。

Lenny Rachitsky： 小心你的愿望——Bob Moesta 刚上过这个播客，他告诉我他收到了超过一百条 LinkedIn 私信，都是人们分享自己在求职中的挣扎。所以你等着吧。

Ryan Singer： 哈哈，对。工作变动，那确实是个大话题。受众面很广。

Lenny Rachitsky： 确实。我想请你聊聊你做的咨询工作，具体是怎么运作的？面向什么样的人？因为我知道这也是你做的事情之一。

Ryan Singer： 基本上通常是这样开始的——往往是 CPO 或 CTO 先联系我。效果最好的情况是我们把双方拉到一起，然后他们意识到需要做出改变；或者我们有一位产品负责人和一位工程负责人，类似这样的组合。如果这两个人都达成共识，认为存在问题，那我们就可以开始讨论：“好，那谁是合适的试点团队成员？业务上正在发生哪些事情可以作为好的试点项目？“然后我可以帮助梳理——“我们到底怎么……”几乎像是引导他们完成对试点项目的框定和聚焦，这样他们在塑形阶段就能得到足够的支持，确保成功。接着，辅导团队让他们真正掌握塑形技能，这样他们就能完成一次塑形会议，并带着清晰得多的成果走出来。比如他们实际该怎么组织这些会议。

所以基本上是先和领导层合作——“我们需要谁来做这件事？谁是合适的人选？如何把他们纳入试点项目？“然后聚焦试点项目，做一些框定工作，让塑形阶段更清晰。再然后，在塑形过程中提供一些带反馈的指导。这通常是一个比较好的方式。

Lenny Rachitsky： 太好了。如果想了解这些，可以在你的网站上找到对吗？

Ryan Singer： 是的。

Lenny Rachitsky： 太好了。Ryan，非常感谢你来。

Ryan Singer： 谢谢。你的提问非常精彩。这个话题可以往很多方向展开，而你一直把我们拉回到某个主线上，所以我很满意。真的很棒。非常感谢。

Lenny Rachitsky： 我尽力了。

Ryan Singer： 是的。

Lenny Rachitsky： 谢谢 Ryan，大家再见。

非常感谢收听。如果你觉得这期节目有价值，可以在 Apple Podcasts、Spotify 或你喜欢的播客应用上订阅。也请考虑给我们评分或留言，这真的能帮助其他听众发现这个播客。你可以在 lennyspodcast.com 找到所有往期节目或了解更多关于这个节目的信息。下期见。

术语表

原文中文
37signals37signals（公司名，保留原文）
appetite胃口（指团队愿意在某项工作上投入的时间/精力上限）
BasecampBasecamp（公司名/产品名，保留原文）
Bob MoestaBob Moesta（Jobs-to-be-Done 理论的核心实践者，保留原文）
breadboarding面包板草图（Shape Up 中用于描述交互流程的低保真建模方法）
build mode构建模式
circuit breaker断路器（项目取消机制）
Clay Christensen克里斯坦森（哈佛商学院教授，“颠覆式创新”理论之父）
Competing Against Luck《Competing Against Luck》（Clay Christensen 所著关于 Jobs-to-be-Done 的书，保留原文）
cool down冷却期（周期之间的缓冲时间）
CPOCPO（Chief Product Officer，首席产品官，保留原文）
CTOCTO（Chief Technology Officer，首席技术官，保留原文）
cycle周期
David / DHHDavid / DHH（David Heinemeier Hansson，Ruby on Rails 创造者）
demand-side需求侧
Demand-Side Sales 101《Demand-Side Sales 101》（Bob Moesta 所著，保留原文）
fat marker sketching粗标记笔草图（Shape Up 中用粗笔触快速勾勒界面布局的方法）
feature factory功能工厂（指持续不断地产出功能但缺乏价值判断的团队运作模式）
FigmaFigma（设计工具，保留原文）
FinTech金融科技（Financial Technology 的缩写）
framing框定（在塑形过程中明确问题边界和范围的步骤）
green light批准/放行（指项目正式启动）
JasonJason（Jason Fried，Basecamp 联合创始人）
Jobs-to-be-DoneJobs-to-be-Done（用户需求分析框架，保留原文）
Kanban看板（项目管理方法）
KathyKathy（Ryan Singer 的同事/合作者，保留原文）
kickoffkickoff（项目或周期的启动会议）
mock-ups设计稿
needle moving产生实质性推动（指对业务有显著影响）
Parkinson’s law帕金森定律
pilot project试点项目
PRDPRD（Product Requirements Document，产品需求文档，保留原文）
product ownerproduct owner（Scrum 中的角色，负责管理产品待办列表）
rabbit hole兔子洞（指项目中容易让人深陷其中的复杂问题）
refactoring重构
ritual master仪式主持人（指只负责流程仪式而不参与实质产品决策的角色）
Ruby on RailsRuby on Rails（Web 开发框架，保留原文）
rule of seven, plus or minus two七加减二法则（认知科学中关于工作记忆容量的原理，也称 Miller’s Law）
SAFeSAFe（Scaled Agile Framework，保留原文）
ScrumScrum（敏捷框架，保留原文）
Shape UpShape Up（Basecamp 的产品开发方法论，保留原文）
shaping mode塑形模式
shaping session塑形会议
spike技术试探（快速验证技术可行性的小实验）
struggling moment挣扎时刻（Jobs-to-be-Done 框架中描述用户遇到痛点的关键概念）
supply side供给侧
tech debt技术债务
ticket工单
time bomb定时炸弹（指项目中隐藏的、将来会爆发的风险）
time box时间盒
unicorn founders传奇创始人（指兼具稀缺能力的创始人）
VCVC（Venture Capital，风险投资，保留原文）
Waterfall瀑布模型（传统软件开发方法论）
wire frames线框图

此文档由 AI 分片翻译（translate_long_document）