A better way to plan, build, and ship products | Ryan Singer (creator of “Shape Up")

发布时间 2025-03-30 11:00:16 来源

摘要

Ryan Singer is one of the earliest employees and the former Head of Strategy at 37signals (the makers of Basecamp), where he ...

GPT-4正在为你翻译摘要中......

中英文字稿

I often use this analogy of like if you're doing a home renovation, you can have like the most beautiful rendering of the new bedroom and we're going to have these lamps on the side of the bed that are coming out from the wall. But if you have in check if there's electricity in that wall there or not, it's going to drastically change the cost and the time and everything. What we need to do in a shaping session is we come out with some kind of diagram where engineers, product and design, they're saying we understand that.

我经常用这样的比喻：就像进行家庭装修一样，你可能会有一个新卧室的绝美设计效果图，并计划在床边墙上安装壁灯。但如果你没有检查那面墙里是否有电源，这会极大地影响整体的成本、时间和其他方面。在一次策划会议中，我们需要制定出某种方案，确保工程师、产品和设计团队都能理解并同意这一点。

So the first thing is we are not going to start something unless we can see the end from the beginning. We're not going to take a big concept and then say what's the estimate for this thing. We're going to go the other way around and we're going to say what is the maximum amount of time we're willing to go before we actually finish something? How do we come up with a idea that's going to work in the amount of time that the business is interested in spending?

首先，我们不会开始一件事情，除非我们能从一开始就看到结束的样子。我们不会先抛出一个大概念，然后再去估算这个东西的工期。我们打算反过来操作，即先确定我们愿意在这个项目上花费的最大时间，然后想办法在这个时间范围内完成任务。我们要考虑如何提出一个在企业愿意投入的时间内可行的方案。

Today, my guest is Ryan Singer. Ryan was one of the first few hires at 37 signals and through his experience of building base camp and a 17 years of building products at 37 signals, he wrote a book called Shape Up, which shares a very different approach to building software. Apotypes, instead of deadlines, a big focus on bringing design engine product together into a room to shape the plan versus writing long PRDs or trying to finalize designs before you start building.

今天，我的嘉宾是瑞安·辛格。瑞安是37 Signals公司最早的几名员工之一。在他参与开发Basecamp以及在37 Signals公司参与产品开发的17年工作经验中，他写了一本书，叫做《Shape Up》。这本书提出了一种截然不同的软件开发方法。它强调使用“模型期”而非“截止日期”，并着重于让设计、引擎和产品团队聚在一起共同制定计划，而不是在开始构建之前编写冗长的产品需求文档（PRD）或是试图最终确定设计。

I've noticed more and more teams adopting the Shape Up method and especially with AI starting to change how we work and build product. There's a shift coming and how product teams will operate. And so I thought this was the perfect time to do a deep dive into the Shape Up method. This episode is basically going to give you everything you need to give Shape Up a shot on your team or at your company to see if fixes the problems that you're having shipping grade products.

我注意到越来越多的团队开始采用 Shape Up 方法，特别是在人工智能开始改变我们的工作方式和产品开发方式的背景下。产品团队的运作方式即将发生变化。所以我认为现在是深入了解 Shape Up 方法的最佳时机。这个节目将为你提供所有必要的信息，让你可以在团队或公司中尝试使用 Shape Up 方法，看看它是否能解决你们在推出高质量产品时遇到的问题。

A big thank you to Des trainer Bob Mesta and Chris Speck for suggesting questions and topics for this conversation. If you enjoy this podcast, don't forget to subscribe and follow it in your favorite podcasting app or YouTube. Also, if you become a paid subscriber of my newsletter, you get an entire year free of perplexity pro, notion, superhuman, linear, and granola. Check it out at Lenny's newsletter.com. With that, I bring you Ryan Singer.

非常感谢Des培训师Bob Mesta和Chris Speck为本次对话提供问题和话题建议。如果你喜欢这个播客，别忘了在你喜欢的播客应用或YouTube上订阅和关注。此外，如果你成为我新闻通讯的付费订阅者，你将免费获得一整年的Perplexity Pro、Notion、Superhuman、Linear和Granola服务。请访问Lenny's newsletter.com了解详情。现在，我为你带来Ryan Singer的分享。

This episode is brought to you by Work OS. If you're building a SaaS app, at some point your customers will start asking for enterprise features like Samo authentication and skim provisioning. That's where Work OS comes in, making a fast and painless to add enterprise features to your app. Their APIs are easy to understand so that you can ship quickly and get back to building other features.

本集节目由 Work OS 赞助。如果你正在开发一款 SaaS 应用，总有一天你的客户会要求增加企业级功能，比如 Saml 身份验证和 Skim 配置。这时，Work OS 就派上用场了，它能让你快速且轻松地为你的应用添加企业功能。他们的 API 简单易懂，让你能快速交付产品，并专注于开发其他功能。

Today, hundreds of companies are already powered by Work OS, including ones you probably know, like Versel, Webflow, and Loom. Work OS also recently acquired Warned, the Fine grain authorization service. Warned's product is based on a groundbreaking authorization system called Zanzibar, which was originally designed for Google to power Google Docs and YouTube. This enables fast authorization checks at enormous scale, while maintaining a flexible model that can be adapted to even the most complex use cases.

如今，已经有数百家公司在使用 Work OS，其中包括你可能熟悉的公司，如 Versel、Webflow 和 Loom。Work OS 最近还收购了名为 Warned 的精细化授权服务。Warned 的产品基于一个名为 Zanzibar 的突破性授权系统，该系统最初是为谷歌设计的，用于支持 Google Docs 和 YouTube。Zanzibar 系统可以在大规模使用中进行快速授权检查，同时保持灵活的模型，能够适应即使是最复杂的使用场景。

If you're currently looking to build roll-based access control or other enterprise features like single sign-on, skim, or user management, you should consider Work OS. It's a drop-in replacement for Auth0 and supports up to 1 million monthly active users for free. Check it out at WorkOS.com to learn more. That's WorkOS.com.

如果您正在寻找构建基于角色的访问控制或其他企业功能，例如单点登录、权限精简或用户管理，那么您应该考虑使用 Work OS。它可以直接替代 Auth0，并且支持每月多达 100 万活跃用户的免费使用。您可以访问 WorkOS.com 了解更多信息。网址是 WorkOS.com。

This episode is brought to you by Merge. Product leaders, yes, like you. Courage when they hear the word integration. They're not fun for you to scope, build, launch, or maintain. And integrations probably aren't what led you to product work in the first place. Lucky for you, the folks at Merge are obsessed with integrations. Their single API helps SaaS companies launch over 200 product integrations in weeks, not quarters.

本节目由 Merge 公司赞助。产品负责人们，比如你，当听到“集成”这个词时，都会感到头疼。你不喜欢去规划、构建、发布或维护这些集成。而且集成工作可能并不是吸引你进入产品领域的原因。幸运的是，Merge 公司的人对集成充满热情。他们的单一 API 可以帮助 SaaS 公司在短短几周内推出超过 200 个产品集成，而不是以季度来计算。

Think of Merge like PLAD, but for everything B2B SaaS. Organizations like RAMP, DRADA, and Electric use Merge to access their customers' accounting data to reconcile bill payments, file storage data to create searchable databases in their product, or HRIS data to auto-provision and deeper vision access for the customer's employees. And yes, if you need AI-ready data for your SaaS product, then Merge is the fastest way to get it.

可以将 Merge 想象成一个针对所有B2B软件服务的PLAD。像 RAMP、DRADA 和 Electric 这样的组织使用 Merge 来访问客户的会计数据，以便对账单支付进行核对，或访问文件存储数据以创建他们产品中的可搜索数据库，或者访问HRIS数据以实现自动配置和为客户员工提供更深入的访问权限。而且，如果你需要为你的SaaS产品准备AI数据，Merge 是最快捷的获取方式。

So, want to solve your organization's integration dilemma once and for all? Book an attend a meeting at Merge.dev slash Lenny and receive a $50 Amazon gift card. That's Merge.dev slash Lenny. Ryan, thank you so much for being here and welcome to the podcast. Man, I'm really happy to be here. Thanks a lot. I think this is going to be a legendary episode.

想要彻底解决你们组织的整合难题吗？访问 Merge.dev/Lenny 预订并参加会议，即可获得一张 $50 的亚马逊礼品卡。网址是 Merge.dev/Lenny。Ryan，非常感谢你来到这里，欢迎参加我们的播客节目。伙计，我真的很高兴能来。非常感谢。我觉得这会是一集非常棒的节目。

There's a lot of interest these days in different ways of working, especially ways that aren't agile and safe and scrim and all these ways that people kind of hear about. Working, especially in this world of AI where everything's just changing. Feels like there's just an increased interest in exploring different ways of working. And specifically, feels like there's been a rise in interest and shape up the stuff that you talk about. So, I am really excited to basically help people understand what is this way of working. Is it right for them? What are ways to start implementing it? What are maybe some pitfalls you may run into? And as much as possible, get into a lot of real talk about how things are actually going on product teams that people often don't like to hear.

近来，人们对各种不同的工作方式兴趣浓厚，尤其是那些与敏捷、SAFE、Scrum等传统方式不同的新方法。在这个人工智能不断变化的时代，人们似乎对探索不同的工作方式更加感兴趣。尤其是，关于你提到的Shape Up方法，兴趣似乎在增加。因此，我很高兴能够帮助大家理解这种工作方式，它是否适合他们，以及如何开始实施它。我们还会讨论一些可能遇到的陷阱，同时尽量进行真实的对话，谈论产品团队中常常被忽略的实际情况。

So, first of all, just do you have you also seen this increased interest in shape up? Yeah, I think it's interesting that we're talking now. You know, I mean, the book came out in 2019. And it's just, I've been hearing more and more. Like, oh, we know somebody who's trying it or we're hearing it when we go talk to other companies, you know, like, so I think it's a wave that's slowly building. And it's funny, you know, like when it came out, I even tried to have like an online forum to get everyone who's interested to talk together.

首先，你有没有注意到对 "Shape Up" 这种方法的兴趣增加了？是的，我觉得我们现在讨论这个话题很有趣。书是2019年出版的，但近年来我越来越多地听到关于它的讨论。比如，我们认识的一些人在尝试这个方法，或者我们去其他公司交流时会听到他们谈论这个。所以，我觉得这股潮流正在慢慢兴起。这很有意思，当书刚出来的时候，我甚至尝试过创建一个在线论坛，让所有感兴趣的人一起讨论。

And what I started to learn pretty early on is that people don't like to talk about their struggles shipping, especially, you know, CPO's and CTO's don't like to go in a public forum and say our company isn't shipping or our engineering team is stuck or our team is always lost in the weeds. You know, that's not a, it's not an easy community topic on an online forum, you know? So I think there's also some reasons why it's been word of mouth kind of slowly gathering steam. That's something I struggle with on this podcast, you know, it's, as you said, it's a product and product teams don't want to be sharing the things aren't going great. That's why I introduced failure corner on the podcast where it's like, okay, but tell me it's time things didn't go well.

我很早就开始了解到，人们并不喜欢谈论他们在产品交付上的困难，尤其是首席产品官（CPO）和首席技术官（CTO）往往不愿意在公开的论坛上承认他们的公司没有按时交付产品，他们的工程团队陷入困境，或者他们的团队总是被细节困扰。这不是一个适合在网络论坛上轻松讨论的话题。所以，我认为这也是为什么这种问题是通过口口相传逐渐传播开的原因之一。这也是我在这个播客中遇到的挑战之一。正如你所说的，这就像是一个产品，而产品团队不想分享他们的失败经验。这就是为什么我在播客中引入了“失败角”这一环节，请嘉宾讲述那些事情进展得不顺利的时刻。

Oh, yeah, that's great. Yeah, because it's so hard to get to that, right? And it's not all just this golden path rosy where we're all, you know, shipping, beautiful, meaningful things all day, you know, it's a, it's a hard business and there's no like perfect school either that kind of produces expert product managers and, and CPO's and CTO's and stuff like that. So we're all like trying to figure this out and we don't have a lot of sources, you know? So it's, there is a lot of struggle.

哦，是的，那太好了。是啊，因为要达到这个目标真的很难，不是吗？而且这条路也不全是充满美好和希望的，我们并不是整天都在推出漂亮又有意义的东西。这是一项艰难的事业，也没有什么完美的学校能培养出优秀的产品经理、首席产品官和技术总监之类的人才。所以我们都在尽力摸索，没有太多的资源可供参考。这其中充满了挑战和艰辛。

And there aren't like many options for how to build product. Like all people really read about is scrum slash agile slash safe as they scale and then there's like waterfall, which I'll never do waterfall. And then there's like the startup way of just like ship and maybe one or two week cycles and then their shape up. So it feels like it's one of the rare other options that exists. And so that's one of the things I've been hearing. It's like I hear like, oh, we thought there was only scrum or con bon and then we heard there was this shape up thing. Like what's that?

翻译：构建产品的方法选择并不多。人们通常只知道Scrum、Agile、SAFe这些方法，以及它们的规模化应用，还有一种就是瀑布模型（我绝不会用瀑布模型）。还有一种是初创公司的方式，就是快速发布产品，可能是一两周的周期，然后就是Shape Up方法。所以，感觉Shape Up是为数不多的其他选择之一。我听到有人说，他们以为只有Scrum或看板（Kanban），然后才发现还有Shape Up这个方法，他们会问：“那是什么？”

And I think it's always been connected to base camp. We're going to talk about that just like it's like it works for companies that are nothing like base camp. Maybe maybe just touch on that briefly. Well, I mean that came as a surprise to me. You know, I mean, when I wrote the book, I had been in base camp at that time, I think 15 years. And I actually didn't even know the outside world, you know?

我觉得这一直以来都和 Basecamp 有关。我们要谈论的是，虽然有些公司与 Basecamp 完全不同，但这些方法对它们也同样有效。也许我们可以简单提一下这个。实际上，这让我感到很惊讶。写这本书的时候，我在 Basecamp 已经待了大约 15 年，我其实对外面的世界一无所知。

I mean, it was Jason's idea to even write the book because he said, look like a lot of people are going to want to know about this. A lot of people are struggling and I'm kind of like, well, okay, like I knew our inside story of we had some growing pains and we had to be able to formalize the way that we were working and shipping so that as we brought new people in that they could participate in that and we could stay fast, you know, so I knew our like internal struggles, but I honestly didn't know anything about the outside world.

我的意思是，其实是杰森提议写这本书的，因为他说，看吧，会有很多人想知道这些事情。很多人都在苦苦挣扎，我有点像，好吧，我知道我们内部的一些问题，我们经历了一些成长的阵痛，我们必须规范我们的工作和交付方式，以便当我们迎来新成员时，他们可以参与其中，而我们也能保持高效。我了解我们内部的挑战，但坦率地说，我对外部世界的情况一无所知。

And it was only after the book came out that it gave me this kind of excuse to start talking to people from all kinds of different companies. And it's been really interesting. There are some really amazing cases of companies of very different characteristics from base camp like VC funded, you know, significantly bigger, very different pressures, different team structure, different skills who were doing it. And at the same time, there's also a lot of questions that are coming my way because honestly, there are so few teams that are structured just like base camp that there are a lot of gaps in the book of like, well, what about this and what about that?

这本书出版后，它成了我与各种公司的人交流的一个契机，这真是非常有趣。有些公司与 Basecamp 非常不同，比如那些通过风投融资的、规模大得多的公司，它们面临着不同的压力，拥有不同的团队结构和技能，这些公司做的事情也很出色。同时，也有很多问题向我涌来，因为说实话，像 Basecamp 这样结构的团队实在是太少了，因此书中存在很多空白，比如“那样的情况怎么办”，或者“这个问题怎么处理”等等。

And how do we do that in our situation? So like a lot of my focus today is actually kind of closing those gaps and helping people figure out how can I make this work for me or for our team? And you specifically told me he's now called instead of shape up, it's shape up in real life or shape up for real life. Yeah, well, you know, my wife heard me saying the same thing over and over again on every phone call. And she's over here and me and she's like, you have to make a course, you have to do something because you're just, you are saying the same thing.

在我们的情况下，我们该怎么做呢？今天我的重点实际上是缩小这些差距，帮助人们找出怎样才能让这对我或我们的团队有效。你特别告诉我，现在不叫“shape up”，而是“现实中的shape up”或者“为现实生活而shape up”。是的，我的妻子听我在每个电话中反复说同样的话。她在旁边听到了，就对我说：“你得开个课程，做点什么，因为你总是在重复同样的话。”

So then this led to this course that we made, which is called shaping in real life. And well, yeah, the idea is the real life part, right? How do I make this work if my designers don't code? If you know, if I have actually, it's very contentious to get engineering time, you know, to mean like when there's all these different pressures that base camp didn't have. We're going to get into the need of greedy of how this actually works and the key elements.

于是，这就促成了我们创建这门课程，名为“现实生活中的塑造”。嗯，重点就是“现实生活”这个部分，对吧？如果我的设计师不会编程，我该如何让这一切运转呢？你知道，有时候要争取工程师的时间是很有争议的，因为会有各种不同的压力，这是 Basecamp 不曾有的。我们将深入探讨这个过程实际如何运作的细节和关键要素。

But do you just give like a very short overall overarching summary of how shape up is different from how other product approaches are? I think the way it's different starts with kind of how the way we were working was a little bit different. So I started working with Jason and David on the first version of base camp, you know, that which was like the flagship product of 37 signals back in 2003. And we were a team of three.

能否用简短的方式概述一下“Shape Up”与其他产品方法有何不同？我认为这种不同之处源自于我们工作方式上的一些差异。我最初与Jason和David一起开发了第一个版本的Basecamp，也就是2003年时37signals的旗舰产品。当时我们团队只有三个人。

And we were, I mean, I think it's for any really small team when you're just starting out, you don't need a process, you don't need a way of working. It just kind of happens organically because you're together, you don't have to explain it to other people, you know, it just kind of happens on its own, right? But there was always this really intense urgency from both Jason and David, like, we've got to get to something we can ship. We have to finish this and move on. We have to get to something that's done.

当我们刚开始的时候，我的意思是，对于任何一个刚刚起步的小团队来说，其实不需要特定的工作流程或者工作方式。这些事情就像自然而然地发生了，因为大家在一起工作，不需要向其他人解释，自然而然地就成了。但Jason和David总是有非常强烈的紧迫感。他们总是在强调，我们必须做出可以发布的产品。我们必须完成这个阶段并继续前进，我们需要做出一个完成的产品。

There was just no tolerance for kind of big things that got fuzzy and started to drag. There was always this sharpening to get to what is this thing really? And when are we going to get to the end soon? And on top of that, even when we were building V1, David wasn't actually full time as the, as our only technical person. He was programming 10 hours a week.

没有人能容忍那些变得模糊不清并且开始拖延的大事件。总是需要不断地去明确：这到底是什么？什么时候能见到结果？更重要的是，即使是在我们构建V1版本的时候，大卫也并不是全职的担任我们唯一的技术人员。他每周只编程10个小时。

So we had this really intense pressure of like, how can we really use David's time well? You know, we don't want to ever kind of give something that this is the thing we want to build. And then it turns out not to be what we want. We have to throw it away and then come back again. Or you know what I mean? Like those kind of and cycles of waste. Let me actually ask about this because this is really interesting.

所以我们面临着巨大的压力，比如，如何更好地利用大卫的时间。我们不希望做出一个东西，结果发现这并不是我们真正想要的，然后不得不丢掉它，再重新开始。你懂我的意思吧？那种浪费时间和资源的循环。所以，我想聊聊这个，因为这真的很有意思。

So this is DHH. He was working part time when when he started 37 hours a week. Yeah. Was he working on like Ruby, basically, and that whole thing? Well, Rails came out of the first. So he told, he told Jason, I want to try building this in Ruby. And because before they had done some collaboration and David had done things in PHP before that.

这是关于DHH（David Heinemeier Hansson）的故事。他在开始每周工作37小时的时候，是兼职工作。是的，他当时基本上是做Ruby这方面的工作吗？实际上，Rails是其中的一个成果。他对Jason说，他想尝试用Ruby来构建这个项目。在此之前，他们曾有一些合作，David之前还用PHP做过一些事情。

And he had this new idea he wanted to try Ruby, this language he fell in love with. And then, you know, the framework Ruby on Rails, he ended up releasing that after Basecamp was standing because it was kind of extracted from the things that were necessary to get V1 of Basecamp to stand up. So that's what he was doing the rest of his time. Instead of, I don't know, I don't know what he was doing the rest of his time.

他有一个新的想法，想要尝试使用他所钟爱的语言Ruby。后来，他推出了Ruby on Rails框架。这其实是从Basecamp项目中提炼出来的，因为这是让Basecamp的第一个版本能够运行所需的一些东西。所以，在剩余的时间里，他就是在做这些事情。我不太清楚他在剩下的时间具体做些什么。

Probably something great. But he's always been like that. You know, he's always doing something interesting. Like he's either racing or who knows what. You know what I mean? So, but all I knew was that we got 10 hours of that time. I love that that was like a constraint to design a way of working that uses engineering time most efficiently.

可能是一些很棒的东西。不过他一直都是这样。你知道的，他总是在做一些有趣的事情。比如说他不是在赛车，就是在做其他不知道什么的事情。你懂我的意思吧？不过我知道的是，我们有10个小时的时间。我喜欢把这当作一个限制条件来设计一种最有效利用工程时间的工作方式。

Yeah. I mean, put that put that together. So David's constrained of 10 hours a week. And then Jason has this, I mean, I think many really successful founders and especially CEOs have this thing. It's like all they want to see is movement. You know, I mean, like forward, forward, forward. So like, when do we get to see it? When do we get to try it? When do I get to put it into somebody's hands?

是的，我的意思是，把这些联系在一起考虑。David每周只能投入10个小时。而Jason有一种心态，我认为很多非常成功的创始人，尤其是CEO，都有这种心态。他们只想看到进展，一直向前。所以，他们会想，什么时候能看到结果？什么时候能尝试？什么时候能交给别人使用？

So that combination, there was just so much urgency. Even though there was no outside pressure, you know, I mean, it was completely just like, let's say cultural energy of like, how do we kind of keep getting somewhere and getting to something that we can celebrate and get excited about? I love that. That's and that's like an attribute. I think of a lot of successful founders. So that makes sense to hear that totally, totally.

因此，那种组合中充满了紧迫感。即使没有外部压力，我的意思是，这完全是一种文化上的驱动力。我们一直在想，如何不断前进，达到一个我们可以庆祝和感到兴奋的阶段？我非常喜欢这种感觉。我认为这也是许多成功创始人的一个特质。所以听到这一点，我完全能理解。

And that's why where I come back to you like, this is the part of the story where I think so many companies would say, yeah, I know that experience, right? Because I think that's probably the seedling of a lot as you said, of successful companies is that that combination of urgency and also that those guys were so talented and that they they had a clear vision of what they wanted to do and all of that is this amazing time actually these early days. Is there anything more to the backstory that's important to share? Super interesting.

这就是为什么我回到您这里觉得，这个故事的这一部分正是很多公司可以认同的地方，对吧？因为我认为，正如您所说，这可能是许多成功公司的萌芽阶段，因为它结合了紧迫感，以及团队的才华横溢和明确的愿景，而这些正是初创阶段的奇妙之处。还有什么关于背景故事的重要信息可以分享的吗？这真的非常有趣。

Yeah, I mean, the other big piece of it was, so Jason and I were like this kind of product. What do you call it? Like the two thirds, you know, and then the so I was doing UX at the time. And I was doing hands-on coding as well. So we're very, very integrated. Everybody kind of does a little bit of everything. All of us were coding like Jason was in the actual app templates as well, doing HTML and CSS to do the views. He's doing hands-on design.

是的，我的意思是，另一件重要的事情是，比如我和Jason在这类产品中处于一种合作状态。我们就像是三人团队中的两个成员那样紧密合作。当时，我负责用户体验设计（UX），并且亲自进行编码。我们非常紧密，彼此的工作交叉。每个人都涉足一些不同的领域。比如说，Jason也参与实际的应用模板工作，负责HTML和CSS的视图设计，他也亲自参与设计工作。

We're all like very much connected with like, why are we building this? What is this? You know, David's doing the David's doing the bulk of the programming. And Jason and I were having these little sessions, these little sessions where we would really figure out what the idea was. And there would be this moment where you would have a few strokes of the Sharpie pen on a big pad of paper. And all of a sudden you'd be like, oh yeah, like that's the idea.

我们都对自己为什么要做这个项目充满了好奇。大卫负责大部分编程，而我和杰森则经常聚在一起开小会，真正弄清楚这个想法到底是什么。有时候，我们在一大片纸上用马克笔画几笔，突然之间，我们就会恍然大悟，哦，原来这就是我们要的想法。

That's the thing we want to go try to build. And for me, like those those sessions with Jason, they were these short, very, very intense sessions where you're trying to crack the nut together. Like, where's the idea? What's the concept? Like how can we go? What's this thing that we're going to go and like 10 hours later? Right? David's going to come back and we're going to be like, this is awesome.

这是我们想要尝试构建的东西。对我来说，那些与杰森一起进行的会话非常短暂但极其紧凑，我们共同努力寻找解决问题的办法。比如，创意在哪里？概念是什么？我们如何前进？我们要去做的事情是什么？然后大约10个小时后，大卫会回来，我们会对结果感到兴奋不已。

This thing works and it does something we're excited about. Right? That was really kind of the seedling. I mean, actually that continued over years and years and years, those sessions. And that's the seedling of this word in the book shaping. What does it mean to do shaping? It wasn't sitting alone, writing a document. It wasn't making a bunch of requirements. It wasn't making a beautiful figma file to represent a concept that could maybe be a feature.

这个东西确实有效，而且它做了一些让我们感到兴奋的事情。对吧？这真的是一个初始的想法。实际上，这个过程在很多年的对话中不断延续。这就是书中“塑造”这个词的萌芽。塑造到底意味着什么呢？这并不是孤独地写一份文件，也不是制定一堆需求，更不是制作一个华丽的Figma文件来展示一个可能成为功能的概念。

You know, it was this like super intense, really exciting collaborative. Like, what about this? What about that? Oh, maybe this, you know? So that was a really big part of of how we worked also. Very intensely collaborative sessions to figure out what the idea is. And getting it sharp enough and crispy enough that we could very confidently get a yes from David and that he would know exactly what it is and what it means and come back.

你知道的，那是一种非常紧张而又令人兴奋的合作。就像，"这个怎么样？那个呢？哦，也许是这个，你知道吗？” 所以这就是我们工作方式的重要部分。我们通过非常紧密的合作会议来明确想法，把它变得足够清晰、有力，以便我们能够非常自信地从大卫那里得到一个肯定的答复，让他准确地知道这是什么、意味着什么，并给我们反馈。

And it would be what we pictured and it would work the way that we hoped so that we would kind of keep going and we wouldn't have to reverse or go back to the drawing board. What it sounds like is essentially kind of trying to maintain these startup way of working as the company grows. Like everything you're describing as house. It feels to be at a startup. And this is a method to keep that. Does that sound right? That's exactly what kind of became shape up was how do we hold onto that as much as possible. I mean, one big ingredient we had in advantage also, which was that Jason and David hired so deliberately slowly.

这段话可以翻译为： “这正是我们所设想的运作方式，并且按我们希望的方式运作，这样我们就可以持续前进，而不必反复推翻重来。从听起来的感觉，这基本上是在努力保持初创公司的工作方式，即使公司在不断成长。你所描述的一切都像是初创公司里的情景，而这种方法就是为了维持这样的状态。这样说是否正确？正是如此，这正是‘形塑’的要义：尽可能多地保留这种状态。我们的一个巨大优势是，Jason和David在招聘上非常慎重，速度很慢。”

And this is kind of like a fortunate side effect of the fact that they didn't take investment money. So there was kind of there wasn't there was never that moment of like now's the moment when we grow. It was always like one person. And then kind of the organism adapts one more person, you know? And so this natural way of working it was it was organically spreading. They there were I think maybe 10 years before we had the first kind of like, wait a minute, what just happened? Like that's not like that project didn't go well. That's not how things normally run. You know, I mean, we really it was it was that mean, of course, there were always like ups and downs, but there was it was it was about 10 years later when we had the first project.

这有点像是他们没有接受投资资金带来的一个幸运副作用。所以从来没有那种“现在是我们扩张的时候”的时刻。这种增长总是以一个人的方式进行，然后就像有机体适应一个新人一样，自然地发展。这种自然的工作方式就像有机地扩散一样。在我们遇到第一个“等一下，刚刚发生了什么？”的时刻之前，大概过了十年。就像那样的项目进行得不太顺利，不是我们一贯的运作方式。我的意思是，当然在这过程中总会有起伏，但大概十年后我们才遇到了第一个项目。

I mean, I remember the project. I remember being at the end of it was at that time already kind of it was maybe it had been like maybe six weeks or seven weeks. We hadn't yet completely locked the six-week thing that went into shape up. And I remember we had a review session and there was a fairly new person who was leading the the who's doing half of the work on that team. We had the review session. It was like instead of oh, look, this is about ready to ship. It was like there are a lot of open questions here. And not only are there a lot of open questions here. We're not getting quick answers. When we have what we know as we as we're asking and what we're starting to realize is like, Oh, this is not only is this not going to ship, but we can't even see the end of this, you know?

我记得这个项目。当时已接近尾声，大概进行了六七周的样子。我们尚未完全确定六周的时间框架，也就是后来所说的“成型”阶段。我记得我们进行了一次评审会，当时团队中有一位比较新的成员负责一半的工作。评审会上，情况并不像是“哦，看，这个项目快要完成了”，而是存在很多未解决的问题。不仅问题多，而且没有得到迅速的答案。随着我们不断提问并逐渐意识到，情况变成了：“哦，不仅这个项目无法按时完成，我们甚至看不到这个项目的终点在哪。”

And that was like one of those moments where you're like, Oh, this isn't going to automatically, organically just keep spreading as we hire forever. You know what I mean? We did reach a point where it's like, Oh, this we're going to have to figure out when this goes well, why does it go well? And what do we do differently? And how do we kind of formalize that? So it's reproducible as we keep onboarding more people. And that's that's actually when shape up as a as a framework started. That's when I really kind of started to lean in and I sort of took over that responsibility of, okay, how do I systematize this?

这就像是那种让你意识到的时刻，你会发现：“哦，这件事并不会自动、自然地随着我们不断招人而一直传播下去。”你懂我的意思吗？我们确实到达了这样一个节点，我们需要搞清楚，当事情进展得顺利时，为什么会顺利？我们做了什么不同的事情？我们如何将其正规化，使其在我们不断加入新人时可复制。这实际上就是“Shape Up”作为一个框架开始的时刻。当时，我真的开始认真对待这项工作，我接过了这个责任，思考：“我该如何系统化地处理这件事？”

That's a great segue. Let's actually talk about how the shape up method works. What are maybe just at a high level? What are like the core ingredients to the shape up method? There's basically kind of like three maybe big things. So the first thing is this notion of we are not going to start something unless we can see the end from the beginning. So we're not going to take a big a big concept and then say what's the estimate for this thing? We're not going to say, Oh, we need to build a calendar and then do a whole bunch of figma files or write a whole bunch of requirements and then ask for an estimate.

这是个很好的转折点。我们来聊聊 Shape Up 方法是如何运作的。从高层次来看，Shape Up 方法的核心要素有哪些呢？基本上有三个比较重要的方面。首先，第一个是这样的一个理念：我们在开始一件事情之前，必须从一开始就看到结束的样子。也就是说，我们不会拿一个宏大的概念然后去估算这个项目。我们不会说，我们需要建立一个日历，然后创建一堆 Figma 文件或者写一堆需求文档，再去要求一个估算。

We're going to go the other way around and we're going to say, what is our appetite for this? What is the maximum amount of time we're willing to go before we actually finish something and we have that startup moment that we talked about that moment of like, ah, you know what I mean? It works. We got somewhere we this at least this, if not the whole project, this meaningful piece we can literally walk away from. So then what we found was that there was a lot of experimentation. We found that six weeks is kind of the maximum that we could see into the future where we could actually say like, how do we work backward and figure out something we could build in that six weeks and really land it?

我们的做法会是反过来的，我们要问自己，我们对这个项目的接受程度如何？我们愿意在多长时间内完成一件事情，直到我们能够达到我们所说的那种启动时刻，就是那种“啊，这个时候，它起作用了”的感觉。我们希望至少能够实现一个有意义的部分，即便不是整个项目，这部分至少是可以让我们感到满意的，可以在必要时从中抽身。然后我们发现，我们进行了很多实验，最终发现六周是我们能够看见结果的最长时间。在这段时间里，我们可以倒推并确定出在六周内可以构建和实现的内容。

You know, so that's kind of the first piece is working backward from our the amount of time we actually want to spend on something and say, what can we do? What could we shape so that after that amount of time we've gotten to somewhere we want to be? You know, it's kind of like, if you're going to buy a car or you're going to you're going to buy a house or you're going to rent a new flat or whatever, you have to have like a budget in mind, right? And the budget then is how you choose between all kinds of alternatives and make a lot of hard choices and trade-offs to figure out like, well, you know, I want the faster engine, you know, but I can't, you know, but I have to give this up or, you know, I wanted it to be fun to drive, but we also need space for longer road trips and, you know, you're making all these trade-offs, right?

你知道，这是我们工作的第一个步骤，就是从我们想要投入的时间量开始回推，问自己，我们能做些什么？我们可以如何规划，以便在这段时间之后达到我们想要的目标？这有点像买车、买房或租新公寓时，你需要先制定一个预算，对吧？这个预算帮助你在各种选择中做出决定，并在面对各种艰难取舍时有所依据。例如，你可能想要更快的引擎，但是你可能得放弃其他东西；或者你希望车子开起来有趣，但同时也需要有足够的空间进行长途旅行，所以你要进行各种权衡。

So this is kind of this this second piece is this. work that we call shaping and the shaping work is how do we actually take this fixed amount of time that we've given for ourselves and vary the scope? How do we come up with a idea, some version of this that's going to work in the amount of time that the business is interested in spending? So this is that those creative sessions that I was talking about where we're jumping all over the all over the room in front of the whiteboard and and getting to an idea. And there the really key thing is that we're getting to an idea where we can see the idea. You know, we understand like why we're doing this, we're wrestling with the problem and we're wrestling with the solution until we have an idea that we can actually say this is what we want to go build. So it's not just calendar or dashboard or, you know, newsletter builder, but it's like this idea of how we're going to tackle this problem about the calendar request, right? So that's the shaping.

这段话主要讨论了一个叫做“塑造工作”的过程。所谓的“塑造工作”是指我们如何在限定的时间内调整项目的范围，以便能够在公司愿意投入的时间内提出一个可行的创意或解决方案。这通常是在创意会议上完成的，会涉及到在白板前头脑风暴的过程，直到我们找到一个明确的创意为止。在这个过程中，最重要的是我们要能够看懂这个构思，了解我们为什么这样做，面对问题和解决方案进行反复推敲，直到确定出一个可以付诸实施的想法。这不仅仅是简单的时间表、仪表盘或新闻简报生成器，而是要找到一个方法来解决比如说日程请求这样的问题，这就是所谓的“塑造”。

And then the third piece is when we've actually carved out a fixed amount of time, when we've shaped a solution that is from a experienced standpoint, from a functionality standpoint, from a technical standpoint, doable and desirable, something that we can make happen in that amount of time, then we can give it to a team and we don't have to do the sometimes call scrum the paper shredder, you know, that's where you take an idea and then you split it into a hundred tickets, right? And you hope that it all glues together still after you've done that step, you know, we don't want to do that. Instead, we want to have a whole idea, give it to a team so they see the whole, they really understand it, right? And then they can come up with their tasks and they can figure out how to track that and break it into pieces so they can actually take more responsibility.

然后第三部分就是，当我们确定了一个固定的时间段，并设计了一个在经验、功能和技术上都可行且理想的解决方案，我们可以在这段时间内实现它。这样一来，我们就可以把这个整体的想法交给一个团队，而不用进行有时被称为“Scrum纸碎机”的过程。那种方法是把一个想法拆成一百个小任务，然后希望在完成这些任务后，所有部分仍能完美结合。我们不想这样做。相反，我们希望将一个完整的想法交给一个团队，让他们全面理解。这样，他们就能自己制定任务，并找出如何跟踪和拆分这些任务，从而承担更多责任。

And so what we see is way more engagement, you know, especially from the technical team, right? Because instead of like here's your ticket, right? Or here's your user story, it's like here's the thing you understand that makes sense. And now you're going to have freedom to figure out how to actually make this a reality. There's going to be a million things to solve in the implementation detail. And now you have a bunch of fun problems and you don't have to keep asking questions to other people to understand what this is or how do I make a trade off for that kind of a thing? One of the core elements of this that I want to confirm is that you can pick and choose these things into your team. You don't need to do this wholesale, correct? You don't need to do, yeah, any of it.

我们看到尤其是技术团队的参与度大大提高了。原因在于，他们不再只是接受任务工单或用户故事，而是理解项目的整体内容，并能够自主决定如何实现目标。在实施过程中会遇到无数需要解决的问题，这对他们来说是一种有趣的挑战，他们无需不断向他人询问理解项目或做出权衡决策的问题。我想确认的核心要素之一是，您可以根据需要选择性地将这些方法应用到您的团队，而不需要全盘接受或实施全部内容。

So this is where we kind of, it helps to look at like what's going wrong and what are we trying to fix? And then, you know, what do I want to bring into this, right? And usually what I notice is that people they like to start sometimes with, oh, I want to give the team, let's say six weeks and I want to give the team more latitude or let's say more creative freedom that they're going to be responsible in the six weeks to figure out how to make it happen, right? And usually a lot of the drive for that is I'm getting tired of having so many meetings and rituals and things that are not actually working on the problem and doing the work, you know, I mean, especially scrum teams, they often complain about that.

所以，这就是我们需要关注的问题所在：出现了哪些问题，我们想要解决什么？接着，我又想带来哪些新的想法或做法呢？通常，我注意到人们有时喜欢先从给团队设定目标开始，比如给团队六周时间，并在这段时间内赋予他们更多的自由或创造力，让他们自己负责想办法实现目标。驱动这种改变的原因往往是大家对太多的会议和各种不解决实际问题的流程感到厌倦。尤其是Scrum团队，经常会抱怨这些问题。

So what they sometimes see in this is like, oh, I love this idea that the team is just going to be cooking for six weeks and they're not going to, you know, we're going to need as needed and we're going to workshop things, but we're not going to be busy with all these rituals all the time, right? Now, the thing that's tricky is that if you want that reality of the team happily buzzing and humming like a, you know, like some happy bee colony, you know, for this six weeks, they need to have a lot more clarity around what's the thing that we're solving, right? And so when we start working backward from that, then what we see is that, oh, well, if we don't shape better, then the team isn't going to have the clarity that they need to take over that responsibility, you know, so they can make choices and make decisions and make trade-offs so that they can get to the end of this thing.

有时候，人们对于这种情况的看法是这样的：“哦，我喜欢这个想法，团队将会有六周时间专注于工作，他们将根据需要来做事和讨论，而不必一直忙于各种固定的程序，对吧？” 现在，棘手的问题在于，如果你希望团队在这六周内像一个快乐的蜂群一样高效运作，他们就需要非常清楚他们正在解决的是什么问题。因此，当我们从结果开始倒推时，我们会发现，如果没有明确的计划，团队就无法获得他们所需的清晰指引来承担责任，他们也就无法做出决策和权衡，以便完成任务。

And worse, at the worst is that sometimes see cases where people are like, okay, we're doing shape up. So you guys are going to build, you know, the newsletter builder, okay? But you only get six weeks to do it. So use your fixed time, vary your scope, and enjoy your responsibility, you know what I mean? Which is just cruel, right? Because I think a quote, Bob Nesta, who's been on your show a couple times, you can't put 10 pounds of crap in a five-pound bag. So, you know, high academic statement, you know? And we can't just take any project no matter how giant it is and then throw it at a team and say, figure it out and ship something meaningful in six weeks by cutting away scope, right?

翻译成中文，表达意思如下：更糟糕的是，有时候我们会看到这样的情况：有人会说，“好吧，我们要实施 Shape Up 方法。所以你们要负责制作这个新闻通讯生成器，好吧？但你们只有六周的时间去做。所以利用你们的固定时间，调整你们的项目范围，享受你们的责任感，你明白我的意思吗？”这简直是残忍的，对吧？因为正如曾多次在你节目中出现的 Bob Nesta 所说的，“你不能把 10 磅的垃圾装进一个 5 磅的袋子里。”这算是一个很有学术深度的说法，对吧？我们不能把任何一个不论多么庞大的项目扔给一个团队，然后让他们通过不断缩小项目范围，在六周内解决问题并推出有意义的成果。

So it starts to, it starts to raise questions about how do we actually decide together what this project is? Do we actually have clarity around what the idea is and what we're going to build, you know? Let me follow up in a couple of elements. So appetites, I think for any product manager, engineer, designer, anyone that is like experienced, okay, we're going to, we estimate this, this landing page is going to take a couple weeks. Great. Let's work on it and it's a being six weeks. Can understand why this makes sense.

所以，这就开始引发一些问题：我们要如何共同决定这个项目是什么？我们是否真的清楚这个想法和我们要打造的东西是什么呢？让我从几个方面来跟进。首先是需求，对于任何产品经理、工程师、设计师或有经验的人来说，比如当我们估计这个登陆页面需要几周时间，但实际上却用了六周时，这种情况是可以理解的。

It's just like this landing page is not that important to us. Let us just say we will commit two weeks to it. We'll do as much as we can in two weeks and then we move on and scope is not allowed to go beyond that. Makes total sense. Like this just makes so much sense as you listen to this, especially for people that have just fallen to the problems of estimates not being accurate.

这就好比说，这个登录页面对我们来说并不是那么重要。我们可以这样说，我们会投入两周的时间来处理它。在这两周内我们会尽量多做一些，然后再转移注意力，项目范围也不会超过这个时间。这完全合理。尤其是对于那些经常遇到估算不准确问题的人来说，这样做是非常有意义的。

Then there's a six week element and the key there is your, and this is kind of counter to maybe two weeks sprints like scrum is that kind of the, where this comes from? So, you know, actually it turns out that the six week is only a maximum and that's really where this number does some work for us. If we think of six weeks as a maximum, that's going to force us to ask some really good questions to ourselves about where do we actually, what, what piece of this do we really think we can land?

然后，还有一个六周的环节，其关键在于你的理解。这与常见的两周冲刺（例如Scrum方法中的冲刺）有点相悖。那么，实际上，六周只是一个最大值，而这正是这个数字发挥作用的地方。如果我们将六周视为一个最大期限，这将迫使我们自问一些非常重要的问题，比如我们究竟能实现哪一部分。

Because if you try to say, you know, in six months, we're going to ship this thing. You can't get your arms around all of the problems that have to get solved for an entire six month chunk of work to actually happen. There are so many unknowns, there are so many ticking time bombs of things that we didn't understand or couldn't foresee, you know, but if we set a ceiling at six weeks, we have a much better chance of, I think that's the size of something where we can actually shape it and surface enough unknowns and reveal that complexity before we're in the middle of it, right?

因为如果你试图说，在六个月内我们要完成这件事，你无法掌控要解决的所有问题，而这些问题必须在整个六个月的工作中解决。有太多的不确定因素，还有很多我们不了解或无法预见的潜在问题。但如果我们把时间限制在六周，我认为我们会有更好的机会，因为在这个时间范围内我们可以更好地规划，揭示出足够的不确定性并展示其中的复杂性，而不是被动地在过程中应对。

It doesn't mean that we can't use this technique to do a two week project, you know, especially if you're on a growth team, you don't want to wait six weeks or you know what I mean, you're going to have to artificially bundle things together to do six weeks. It's like, look, I've got something I want to ship in the next week and then I've got a thing that might take two weeks after that and then a week after that, right? So it's more a question of what we're trying to take on, you know, it's really that upper limit.

这并不意味着我们不能用这种技术来完成一个为期两周的项目，特别是当你在一个增长团队的时候，你不想等上六周，你懂的。你可能需要人为地把事情捆绑在一起才能凑够六周。比如，我有件事情想要在下周发布，然后接下来的事情可能需要花两周，再接下来可能需要一周时间，对吧？所以问题更多在于我们想要承担多少任务，这实际上是关于我们能承受的上限。

Okay, so it could be a two week cycle and the added value thing. It could be a two week thing. Cool. So it's like, we're going to build a new landing page, we're going to give it two weeks and then the other shaping session on that. Now the other thing, the other side of that is when it comes to feature development or, you know, building something that's going to be needy enough to sell, you know, then there's very few things that are going to be a substantial value add to a product that you can do in two weeks, right?

好的，所以这可能是一个两周的周期和增值的事情。也许就是一个两周的事情，挺好的。就像是，我们要建立一个新的着陆页，给它两周时间，然后再进行另一轮的构思会议。另一方面，当涉及到功能开发或者构建一个有足够吸引力来售卖的东西时，你知道，在两周内能够为产品带来实质性价值提升的东西非常少，对吧？

So then you get into a point where, well, now we're just kind of sprinting and we're just kind of taking one bite after the other and then that's where we can land in that situation where we feel like I can never see the end of this. I just keep going back and saying one more sprint, one more sprint, one more sprint, right? But six weeks is long enough chunk or sometimes four weeks that the question is kind of what's big enough that we can actually get somewhere with this amount of time, right?

所以，你到了一个阶段，我们就像是在不断地冲刺，一口接一口地咬下去，然后我们就可能陷入那种感觉永远看不到尽头的情况。我总是告诉自己，再冲刺一次，再冲刺一次，再冲刺一次，对吧？但是，六周时间或者有时候四周时间已经足够长，那么问题就是，有多大规模的任务可以在这段时间内真正取得进展呢？

And there's an implied element of this that I think is worth highlighting. The whole idea is you commit to the appetite and if you are not on track to hit that instead of extending the date you cut in order to still hit it. This is a tricky one. So you're right that it's implied, but the thing is in real life, if you make a commitment and you get alignment that we are going to spend six weeks of engineering time building this thing, you know, if you get to that end of that six weeks and something is going wrong, you know, it wasn't shaped. We can't see the end of it. It's more complicated than we thought, all these different things.

这段话涉及一个重要的隐含元素，我认为值得强调。整个概念是你要承诺实现某个需求，如果进度落后了，而不是延长时间，你要削减内容以便仍然能实现目标。这是个棘手的问题。你说得对，它是隐含的，但在现实生活中，如果你承诺并达成共识，要用六周的工程时间来完成某件事情，那么到了六周末尾，如果出了问题，比如事情未成形，看不到尽头，或者比想象中复杂，所有这些因素都会影响到实现这个承诺。

And by the way, we can also talk about kind of why those things happen, you know, but when we get in that situation, if we're at the end of the six weeks and it's not looking good, I mean, we can't just cut off what we agreed to that made this thing valuable, you know, we can't just like cut the scope and say, oh, well now we managed to ship inside of six weeks. That's going to kill everybody's morale. Everyone's going to feel disappointed. We're going to feel like this wasn't really worthwhile.

顺便说一下，我们也可以讨论一下这些事情发生的原因。但是，当我们处于那种情境中，如果六周结束时情况不太乐观，我们不能就这样砍掉那些让这个项目有价值的协议。我们不能简单地缩小范围然后说：“哦，好吧，现在我们在六周内完成了。” 这样会打击每个人的士气，让大家感到失望，觉得这项目根本不值得。

And now we go into the next cycle with this kind of like debt feeling, you know, that we didn't actually finish the thing. We were kind of supposed to finish. So now we're like over time, you know, none of that is good. And if we also go the other extreme and just say, well, like we actually we say in the book, you know, we had this principle at Basecamp, which was this notion of the circuit breaker. Like if a project is not on track to actually finish after the six weeks, we're just going to cancel it and rethink, you know, almost no teams have the stomach for that.

现在，我们进入下一个周期时，带着一种未竟之事的负担感。仿佛有些事情本来应该完成却没有完成，因此我们现在像是进入了加班状态，这样的情况对任何人都不好。同时，如果我们走向另一个极端，仅仅按照书中的建议执行，比如在Basecamp公司有一个原则——断路器原则：如果一个项目在六周后看来无法完成，我们就会取消它并重新考虑。但几乎没有哪个团队有勇气这样做。

But the version of that that's more stomachable is look, we can't just we can't just cancel the project and then say, let's see what comes next, right? But what we can do is say, we're not going to keep reinvesting in something that we don't understand, you know, so let's take this out of build mode and bring this back into shaping mode, which might mean different people, a different conversation asking different questions, you know, doing a different kind of work to sus out like, what is it that's fuzzy here? What is it that we couldn't see?

更能让人接受的表达方式是这样：我们不能简单地取消这个项目，然后坐等下一步看会发生什么。但是我们可以决定不再继续投入资源到我们不理解的事情上。所以，我们应该把项目从开发模式转换到塑造模式。这可能意味着需要不同的人、不同的对话、提出不同的问题，并进行不同类型的工作，来搞清楚究竟有哪些不明确的地方，我们之前未能发现的是什么。

Like, what do we not understand? That's right, how do we get to the clarity that we need so that we can actually say like, this thing is going to happen if we give it another whack. And let's just how real this approach is, not this like theoretical, okay, cool. After six weeks, you just, did you scope in it? That's cool. Yeah, you just put the scope, you know, no problem. I've seen some shape up adoptions that looked like that, by the way, and that's, it's, you know, it's that's that's not the way.

就像，我们哪里不明白呢？没错，我们要如何达到我们需要的清晰度，这样我们才能真正地说，如果我们再努力一下，这件事情就会发生。我们要看看这种方法有多实际，而不是那种理论上的想法，比如说，好吧，六周后，你是不是把范围确立了？那很好，你只是把范围定下来了，没问题。我见过一些像这样的形状调整方式，但那并不是正确的方法。

The shaping step is crucial. And what you mentioned with your landing page example, by the way, it's so seductive because we can imagine, you know, oh, you know, Parkinson's law, right? If you give me six weeks to do the landing page, I'll find a way to use it, but if you give me two weeks, you know, then I'll stop after two weeks. But when it comes to real product work, you know, where there's some functionality that we have to figure out how to make it exist, we can't just cut the scope if we run out of time.

塑造阶段非常关键。你提到的关于登录页面的例子，非常吸引人，因为我们可以想象到——你知道帕金森定律，对吧？如果你给我六周时间来制作登录页面，我会找到办法用掉这段时间，但如果只给我两周，那么两周后我就会停下。然而，当涉及到真正的产品工作时，我们需要弄清楚如何实现某些功能，时间不够时我们不能随意减少工作范围。

So what it means is that the shaping work is really working hard together to figure out what are the main moving pieces of this thing. Right? How do we narrow down our understanding of the problem? And how do we identify what the moving parts are of the solution? And like what actually connects together for this feature to work? You know, and when we really get to the level where we can say, oh, we need to do this, this, this, this, and then the engine is going to turn, you know, that's the place where we can say, this is well shaped, you know, and that's it.

这段话的意思是，"塑形"工作是指大家齐心协力去搞清楚这个事情的主要组成要素。对吧？我们如何缩小对问题的理解范围？又该如何确定解决方案中的关键部件？以及这些特性如何能够有效结合在一起？当我们真正能够明确地说，我们需要做到这一点、那一点，然后这个“引擎”就能启动的时候，那就是我们可以说“这个方案已经成型”的时候，就是这样的一个过程。

That's a it's a different kind of work. We in shaping in real life, we call it, you know, we actually teach it as doing live shaping sessions. And this was how I did it for years with Jason, we'd get into the room, you know, and I had both the technical and the UX side. So the both sides were kind of represented there in one person in that case. But for a lot of teams today, we actually teach them how to bring the kind of the the senior engineering person who isn't just senior in title, but you know, like the one who actually knows where the bodies are buried, you know, like how the old stuff works and what's truly possible and what's hard and what's easy in our infrastructure, like the person that really knows, right?

这是一种不同的工作方式。在现实生活中，我们称之为现场塑造课程，我们实际上就是这样传授的。多年来，我和杰森就是这样做的：我们会聚在一个房间里，我同时具备技术和用户体验（UX）的背景，所以在这种情况下，两个方面都由一个人来代表。但对于今天的许多团队，我们实际上教他们如何引入资深工程人员，他们不仅仅是头衔上的资深，而是真正了解“内幕”的人，比如了解旧系统如何运行、哪些是切实可行的、哪些在我们的基础设施中是困难的或简单的，总之是那些真正了解情况的人。

You bring that person together with the product person who deeply understands the backstory of why this is an opportunity and what we're trying to solve with this, you know, and then a designer in the room and they're like whiteboarding and wrestling with each other to get to what's a version of this thing that we believe in that's real that we can actually finish in that time. This is great. Let's let's go one level deeper on this shaping session. So if you tack to questions, how long are these sessions? It sounds like the people that join are the designer and an engineer and an MPM. So add anything else there. And when do they happen? Is it at the end of a cycle? Do you call a cycle by the way or sprint?

你把那个深入理解这个机会背景以及我们试图解决什么问题的产品负责人和设计师一起召集起来，他们在会议室里一起用白板讨论和探讨，力求找到一个我们相信并且能够在时间内完成的版本。这很棒。让我们深入了解一下这个塑造环节。如果深入探讨一下，通常这样的会议时长是多久呢？加入会议的人包括设计师、工程师和MMP(项目经理），还有其他人吗？这些会议是何时进行的？是在一个周期结束的时候吗？你们怎么称呼这个周期，叫周期还是冲刺？

This six wish would be really what I actually like is time box actually because the thing is that some teams need regular cycles because they have parallel teams and they need that cadence in order to kind of reduce management overhead, you know. But if you're small and you only have like one or two teams, you might not need to be on a fixed cadence or a cycle plan. You might be able to just set one time box after another, right? So the key thing is actually that that time is pushing back at you and that you're being intentional about kind of what's my time budget that I need to shape into. Let me take a quick tangent because if you're that's so interesting that the time boxes can be very different links.

这第六个愿望实际上是我真正喜欢的，叫做“时间盒”（time box）。因为有些团队由于有多个并行的团队，需要固定的循环，以减少管理上的麻烦。但是如果你是个小团队，比如说只有一两个团队，你可能不需要一个固定的周期计划，而是可以一个接一个地设定时间盒。关键在于时间的压力推动着你，你需要有意识地去考虑你的时间预算，以及如何合理安排它。顺便说一句，很有趣的是，时间盒的长度其实可以非常不同。

Imagine that a larger company this gets complicated when other teams are trying, there's dependencies and timelines launch, go to market dates and all these things. What's like the largest company this this approach has worked at? Like what's the ideal company stage for shape up? It can function in very large companies. We have for example, I have some friends at a there, what is it called? They're doing clinical trials so they're in the pharmaceutical industry and I mean the companies, you know, thousands of people and it's not that every team is doing this but they have a few teams that are working in important areas, you know, and they're doing this and it's completely possible in that context.

想象一下，在一个大型公司里，当其他团队尝试协作时，由于依赖关系和时间线的存在，还有产品发布、市场投放日期等方面的问题，这会变得很复杂。那么，这种方法在规模最大的公司中曾成功应用过的情况是怎样的？Shape Up这种方法适用于什么公司阶段？其实，它可以在非常大的公司中运作。例如，我有一些朋友在一家从事临床试验的公司，他们属于制药行业，公司有数千名员工。并不是每个团队都在使用这种方法，但确实有几个在重要领域工作的团队在采用这种方法，并且在这种情况下是完全可行的。

If you have someone who's at a senior level on the engineering side who is able to make the right architectural choices and also do some negotiating and kind of be the backstop to make sure that someone isn't going to get pulled away onto something else, you know, you can kind of carve out of this system can be worked on independently of that system. This was actually what David at at Basecamp has always been amazing at is this dependency how it's actually not it's not so many people are used to it and they think that it's just how it is but it's actually not.

如果你有一位在工程领域处于高级职位的人，他能做出正确的架构选择，并进行一些沟通协调，同时充当后盾，确保团队成员不会被其他任务分散精力。这样，你就可以将一个系统与其他系统独立开来进行开发。在 Basecamp，David 一直在这方面表现得非常出色。他善于处理这种依赖性问题，许多人习惯于认为这是理所当然的，但其实并不是这样。

It is possible for engineering leadership, good engineering leadership untangles things. So we can work on this system without having to be thinking about this other system somewhere else, you know. So when you have some untangling with your infrastructure and with your architecture from an engineering standpoint, then you have some freedom and then if you can also figure out the capacity management side of I'm going to protect this team from that other work for this number of weeks, you know, you can really get a lot done.

工程领导有可能发挥重要作用，优秀的工程领导能够理清复杂问题。这样一来，我们在处理一个系统时，不必分心去想其他地方的系统。当你的基础设施和架构在工程方面得到理顺之后，你就拥有了一些自由。如果你还能在容量管理方面规划好，比如保护这个团队在接下来的几周内不受其他工作的干扰，那么你就能真正完成很多工作。

This insight that you can operate this way at a larger company and the whole company doesn't have to operate this way I think is really freeing to a lot of people. What's kind of like the adapter and I want to come back to the actual shaping process but I can't help but ask this, say the company is operating like a quarterly cadence or six month cadence and then there's like a team operating in a two week, sometimes six weeks, sometimes four week cadence, advice on how to like what's the adapter that connects those two cadences. So there's kind of two different things.

这种认知在大公司中是很有启发性的，即你可以以这种方式运作，而整个公司不需要以完全相同的方式运作。我认为这对很多人来说是非常解放的。这就像是一个适配器。我想回到实际的塑造过程上，但我忍不住要问：假设公司整体是以季度或半年为周期运作，而某个团队则是以两周，有时是六周，有时是四周为周期运作，那么如何连接这两种不同的运作周期有什么建议呢？所以这实际上涉及到两种不同的事情。

So like I've seen cases where they've decided on a four week plus two week or like so they'll do like five week and then one week of cool down in between and then they they time. it so that it adds up to a quarter. You know, I've seen that. The other thing I've seen is when the team is just continuously delivering meaningful things, it doesn't have to line up because from the executive level, if you are CPL or CTO or I mean in these bigger cases it's more like VP in some area but you're coming to the table where you're supposed to be reporting of what your group is doing and when you are consistently saying we said we were going to do this and nothing finished and now we're doing this and it's going to finish and the next time you say we said we were going to do that and it's finished, you know, without excuses and with that well maybe in other few more months or you know we're working at it like that. I mean that's what that's what everyone wants to see is that movement, you know.

我见过这样的情况：有的团队选择一个时间安排，比如先进行四周的工作，然后加上两周的休整，或者是五周的工作再加上一周的冷却期，然后这样计算时间，确保整个阶段总和为一个季度。我见过这样的安排。另一方面，我也见过团队在持续不断地交付有意义的成果，这样就不必严格按照时间表走。因为从管理层的角度来看，比如首席产品官（CPL）、首席技术官（CTO）或者更大的公司里某个领域的副总裁（VP），当他们在汇报小组工作时，如果能持续地说，我们打算做这个，并且已经完成了，然后下一次汇报时能准确地说我们做了那个并完成了，没有借口，而不是在说或许几个月后会完成，或者我们还在努力。大家都希望看到的是这种持续的进展。

Yeah, if you're doing great people will leave you alone, that makes sense. For sure. I love that point. Okay, coming back to shaping one maybe one way that would make it really easy for people to understand what's the output of the shaping session. The output of the shaping session is so and by the way about shaping session, you know, let's maybe we can talk a little bit about what shaping is not, you know, because we need the contrast sometimes. So very often when people try shape up what I see is a product team kind of creating either a lot of figma files or maybe a lot of documentation, you know, like a like a PRD with a bunch of requirements and a bunch of backstory and good reasons why we're doing this and stuff like that.

是的，如果你表现得很好，人们就会不再打扰你，这很合理。我非常喜欢这个观点。好的，回到塑造问题，可能有一种方法可以让大家更容易理解塑造会议的结果。塑造会议的结果是这样，顺便说一下，关于塑造会议，我们可以聊聊塑造不是什么，因为有时候我们需要对比。很多时候，当人们试图进行塑造的时候，我看到的情况是产品团队会创建一堆Figma文件或者大量文档，比如一个包含了一堆需求、背景故事和我们为何这么做的理由的产品需求文档（PRD）。

And what you see is when you give that to a team as like this is what we shaped, what happens is like it blows up. So I mean you probably know about what happens when the figma file makes first contact with the engineering team. There's a reality check that happens there, you know, and very often there's a kind of a back to the drawing board. So when there's a lot of solutioning all the way down to detail without engineering involved, usually that's a painful recipe, you know, and then it's kind of like no, we can't do that. Actually, it doesn't work like that. And then on top of it, the other big challenge is that there's so much that you can't see on the surface of a UI, you know, how do we flow from here to there? What are the different cases of logic?

当你把设计稿交给团队时，通常会出现一些问题，比如"设计方案"似乎遇到了阻碍。大家可能都知道，当Figma文件第一次交给工程团队时，会经历一次"现实检验"。这常常导致需要重新回到设计阶段。当在没有工程师参与的情况下设计方案一直深入到细节时，通常会遇到麻烦的困境，结果就是发现"我们不能这样做"或者"这么做行不通"。除此之外，另一个大挑战是：在用户界面的表面上有很多你看不到的问题。比如，界面之如何转换？有哪些不同的逻辑情况？

Like in which case do we move from here to here to here in the flow? Like what is happening behind the scenes? It's like the engineering team, they have to put on their x-ray goggles and like study this thing to try and understand like what's happening underneath, you know? I often use this analogy of like if you're doing a home renovation, you know, you can have like the most like a beautiful rendering of here's the new, here's the new bedroom and we're going to have these lamps on the side of the bed, you know, that are coming out from the wall. These like, you know, and you can have the perfect rendering in the perfect lamp in the perfect color. But if you have in check, if there's electricity in that wall there or not, right, it's going to drastically change the cost and the time and everything.

在什么情况下，我们会在流程中从这里移动到这里再到这里呢？幕后又发生了什么呢？这就像工程团队必须戴上“透视镜”来研究这个问题，以便理解到底发生了些什么。我经常用一个比喻来说明：如果你在做家庭装修，你可能有一个非常漂亮的设计图，比如新的卧室设计，床的两边会装上从墙壁延伸出来的灯。这些灯的款式和颜色可能都完美无瑕。但是，如果你不检查一下那面墙里是否有电线，这将极大地影响你的成本、时间和其他方面的一切。

If you're going to have to rip open those walls to feed some lines up to those lamps, right? So what we need to do in a shaping session when it's going well is we come out with some kind of of drawing or diagram where engineers, product and design are all looking at that and they're saying we understand that. I know exactly what to go build, right? I'll use the example of the calendar from the book. So what is a calendar, you know? So first of all, there was this work that we had to do before we could even shape it, which is like, can we actually narrow down this problem?

如果你需要拆开那些墙来为灯具布线，对吧？所以，在一个规划会议中，当一切顺利进行时，我们需要做的是画出某种图纸或图表，让工程师、产品经理和设计师都能看懂，并说“我们明白该怎么做了”。我来举书中提到的日历作为例子。那么，什么是日历呢？首先，在我们能够规划之前，我们需要做一些工作，比如说，我们能否缩小这个问题的范围。

In shaping in real life, we call this framing and in the book, there's a chapter called setting the boundaries where we get into this and it's like, like, we, we, we, we’re not going to just build calendar, which is like Google Calendar, you know, we, who knows where it ends? We narrowed it down to, we understand that for our specific customers who are requesting this again and again, it's more about I need to see empty spaces and in the existing agenda view, I can only see things that are already scheduled and I can't see free spaces where I could book something, okay? So we got to that point of like, so the what we're trying to solve here is the empty spaces.

在现实生活中，我们将这种情况称为"框架设定"，而在书中，有一章叫做"设定边界"，我们在这一章深入探讨了这个问题。这就像，我们并不仅仅是想要打造一个日历应用，比如像Google Calendar那样，你知道，这个项目的最终走向是未知的。我们明确了一个重点，就是对于我们那些一再提出请求的特定客户来说，他们真正需要的是查看空闲时间。在现有的日程视图中，他们只能看到已经安排好的事项，而看不到可以预约的空闲时间。我们要解决的问题就是这些空闲时间。

So that's a good frame. Then what are we actually going to build? We came to, here's a good rule of thumb. If it's shaped well, you can usually describe it in less than 10 moving pieces. Okay? If I can say it's going to have this, this, this, this, this and this and that's how we're going to let people see the empty spaces, you know? That's a good indicator that it's clear enough that it's, that it's shaped well.

这是一个很好的框架。那么我们实际要构建什么呢？我们得出了一个不错的经验法则：如果结构设计得当，通常可以用不到10个活动部件来描述。明白吗？如果我能说它将包括这个、这个、这个、这个、这个和这个，并且我们会让人们看到这些空白区域的话，这是一个很好的指标，表明它足够清晰，并且设计良好。

So in this case, we had a, you know, when you go to an airline and you, and you want to book something, you see this like two month grid, right? So it's like, there's going to be two months side by side, but they're just going to have dots in them to indicate if there's, if there's a free day or not, or I mean, if there's something in that day or not, kind of like, you know, the iPhone calendar, I think still has this, where it's just dots on the month view.

在这种情况下，当你去航空公司订票时，你会看到一个类似两个月的日历表，对吧？这个表格上并排显示两个月，但只用小圆点来表示某天是否有空位，或者说那天是否有安排。这有点像iPhone日历的月份视图，我想它现在还是这样显示的，只用小圆点表示。

And then if you tap a day with a dot in it or without a dot in it, there's going to be an agenda view that slides underneath, which is going to show you what's scheduled in that day, right? And then there's going to be navigation to go forward and back in the months. There's going to be a create button to create an event, right? And that's more or less, that's more or less it. So what you can see here is it's not like, what is a calendar? You know, it's not a calendar. It's a,

如果你点击一个有点或者没有点的日期，下面会出现一个日程视图，显示那天的计划，对吧？然后会有按钮可以前后浏览月份，也有个创建按钮来添加活动，对吧？大致就是这样。你会发现这不像传统的日历。它其实是一个...

it's a two month dot grid with scrolling agenda view underneath, right? And, uh, and the ability to, to hit new when you're looking at an empty space to create something and what you're viewing, right? So that's the kind of thing where that's shaped. And we can talk about what that means and what it entails. And we can have a really practical, realistic conversation about, is that a thing we can do in six weeks? You know, that's, that's going to be a real conversation and not looking at a whole bunch of mock ups and, and trying to x-ray to figure out what's actually the intent here and what's really real and what's not and what's possible and what's not.

这是一种两个月的点阵网格视图，在下面有可滚动的日程视图，对吗？然后，你可以在查看空白区域时通过点击"新建"来创建内容，对吧？这就是需要我们来探讨的内容，我们可以讨论这意味着什么以及涉及哪些方面。同时，我们可以进行一次非常务实、现实的讨论，看看我们是否能在六周内完成这项任务。这将是一场真实的讨论，而不是只看一堆模型图，再试图透过表面来弄清楚意图是什么，哪些是实际可行的，哪些不是。

That was a great example. This is really helpful. So if I were to try to describe this, essentially what you're coming out of it with a shaping session with is, uh, kind of like the user, the user experience with just like wireframes slash sketches of the screens and the key buttons and flows. So it's kind of like the architecture with key components, not like a dock of spec and not final design and also not just like a user story. As a user, I need to be able to see empty spaces. Exactly.

这是一个很好的例子。这真是非常有帮助。所以如果我要描述这个的话，基本上你从这个塑造环节中得到的是一份关于用户体验的大体框架，类似于屏幕的线框图或草图，以及关键按钮和流程。这更像是一个包含关键组件的结构，而不是详细的规格文档，也不是最终设计，也不仅仅像是一段用户故事。作为一个用户，我需要能够看到留白空间。确切地说，就是这样。

So because that's the thing where it goes wrong. You know, if, if we're going to commit engineering time, you know, and it's like, we believe there's some way to see empty spaces, but you know, the way is a question mark, it's a really risky way to spend that time. Because you're committing, right? It's like, I'm sorry. Yeah, you were committing and that time is really valuable, right? That's six weeks of engineering time, you know, and that time wasn't easy to get in the first place, right?

所以，因为那就是问题出错的地方。你知道，如果我们要投入工程时间，而我们相信有某种方法可以发现空白，但具体的方法还不确定，这样投入时间是很冒险的。因为一旦投入，就是承诺了。抱歉，是的，你要投入，而这些时间非常宝贵，对吧？那是六个星期的工程时间，而这个时间本来就来之不易。

Because of course, there's all these other forces in the company that want to be doing something with the engineers, right? You know, so if we want that team to be really using that time well, where they are moving, they understand what they're solving and they're creatively engaged, because they know what it's supposed to be doing, right? You know, they need to have that clarity both on the problem side of this is about the empty spaces and on the solution side of it's a dot grid with two months in a scrolling agenda view and a button.

当然，公司里还有很多其他力量希望与工程师合作，对吧？因此，如果我们希望那个团队能够真正利用好他们的时间，他们需要明白自己在解决什么问题，并能够富有创造性，他们需要知道他们应该做什么。明白问题所在，这涉及空白空间；而在解决方案方面，这是一个带有两个月滚动议程视图和一个按钮的点阵网格。他们需要在这两个方面都很清楚。

There's still a million interesting creative tasks there in the actual high fidelity design in the code, you know, there's so many things to solve there, but that is something that they can all hold in their heads and understand and work on. This episode is brought to you by AirTable Product Central, the unified system that brings your entire product org together in one place. No more scatter tools, no more misaligned teams.

在高保真设计的实际代码中，还有无数有趣的创造性任务可以去解决。这些任务都是他们可以掌握、理解并着手解决的。本集由AirTable产品中心赞助。它是一个统一的系统，可以将你的整个产品组织聚集在一个地方。不再需要分散的工具，也不会再有团队不协调的问题。

If you're like most product leaders, you're tired of constant context switching between tools. That's why AirTable built product central after decades of working with world class product companies. Think of it as mission control for your entire product organization. Unlike rigid point solutions, product central powers everything from resourcing to voice of customer to road mapping to launch execution.

如果你和大多数产品负责人一样，已经厌倦了在不同工具之间不断切换。那么，正是出于这个原因，AirTable 倾力打造了产品中心，这源于其与诸多世界级产品公司合作多年的经验。可以把它看作是你的整个产品团队的任务控制中心。与那些僵化的单一解决方案不同，产品中心支持从资源调配、客户反馈、路线规划到产品发布执行的一切需求。

And because it's built on AirTable's no code platform, you can customize every workload to match exactly how your team works. No limitations, no compromises. Ready to see it in action, head to airtable.com slash Lenny to book a demo. That's airtable.com slash Lenny. You mentioned, and I think a lot of people listening to this are going to be like, I'm scared of doing this is if you get too detailed, the engineers and designers on the team are just like, what the hell? You're just telling me what to build.

因为它是基于AirTable的无代码平台构建的，您可以自定义每个工作流程，以完全符合您团队的工作方式。没有限制，没有妥协。想要看看它的实际操作，请访问airtable.com/Lenny预订演示。网址是airtable.com/Lenny。您提到的一个问题，我想很多在听的人可能会觉得害怕，就是如果你过于详细，团队里的工程师和设计师可能会觉得：“你这不就是在告诉我该怎么做吗？”

That sucks. I don't want to, I don't want that kind of work. So what's like, is the solution? to that? The engineering lead was super involved in detail and the design lead was super involved. And so you can trust that it's that you're not just the code monkey building anything they told you to build. That's really interesting. I've got to tell you, the dominant failure case that I see in the real world is always again and again, not enough detail. And it's also the most common failure mode where engineers run back to the product folks and say, I'm not getting enough from you. It's really like that. But I can understand why the hair stands up on the back of the neck a little bit. You know, thinking about it, because of course, if you if you give a senior engineer, like here's how I want you to go implement the schema for this database change for this model, they're going to be like, what do you like, wait, do you? Who are you?

这太糟糕了。我不想这样，我不想做这样的工作。那么，解决方案是什么呢？工程主管非常参与细节，设计主管也非常投入。所以你可以放心，你不会只是一个按照他们指示编写代码的"代码工人"。这真有趣。我必须告诉你，我在现实世界中看到的主要失败原因总是反复出现，那就是细节不够充分。这也是最常见的失败模式，工程师总是跑回产品团队说，你们给我的信息不够充足。情况确实是这样，但我能理解为什么会有些不安。想想看，如果你告诉一名资深工程师，我希望你这样实施这个数据库更改的模型，他们会困惑地问：你是谁？你到底想干嘛？

But what's really interesting is it's not a universal thing. The amount of detail that the team is going to feel helps them is a dial that we can turn that depends on who's on the team. So if you have a more junior person who's on the build team, and then you have a more senior engineer who's involved in the shaping, they can make that junior engineer much more successful with additional detail. Right. So like we're going to do this and I would suggest approaching it like this, this, this, and this. Right. That junior person is when they don't know how to do it, they're not going to ask because they don't want to show that they don't know. And they're going to hide the fact that they're lost and it's going to blow up later in the project. And on the other hand, if they are given more guidance, they're going to be able to be successful. They're going to learn about, you know, this is how this person who knows well kind of approached it. And then in the next round or a few, you know, a few projects later, you can dial it back and say, well, let's give less detail and see how they handle it. Right. So you can really give people bigger shoes to grow into and help them to be successful.

但有趣的是，这并不是一个普遍适用的事情。团队所需的细节程度是可以调整的，这取决于团队中的成员。如果团队中有一位较年轻的成员，而参与决策的是一位资深工程师，那么通过增加细节可以大大提高年轻工程师的成功率。举个例子，资深工程师可以建议更详细的步骤，这样，当年轻成员不知道如何做时，他们不会因为害怕暴露自己的不足而不敢提问，进而在项目后期导致问题爆发。相反，如果给他们更多的指导，他们就能顺利完成任务，并从资深成员的经验中学习。下次或在几个项目之后，我们可以减少细节的提供，看看他们如何应对。这样一来，就能帮助他们成长，为他们创造更好的发展空间。

And then, of course, you can also do it the other way around where if you've got some really stellar talent on the team and you have a long history and you have a lot of trust that they are going to be able to understand and solve it. Then of course, you can leave things out. Right. But the thing that I often see is if there's someone on the build team who really feels that they should be involved in the fundamental decisions about the approach, then a better solution would be to actually bring them into the shaping and have them play that technical role in the shaping session. You know, if they're, if they have the right skills and the right perspective and the right knowledge to play that role well, then just bring them into the shaping. Right. So it's all about how do we bring people into a moment where we are using their strengths, you know, and then we're giving them an input so that whatever their kind of work step is that they're able to apply the maximum creativity, but also have the maximum clarity so that they can really use that time well and also like feel good about what they're doing.

当然，你也可以反过来操作。如果你团队中有一些非常出色的人才，并且你们之间有很长时间的合作历史，还有足够的信任，相信他们能够理解和解决问题，那么当然你可以省略一些步骤。但是我经常看到的是，如果团队中有成员强烈认为自己应该参与关于方法的基本决策，那么更好的解决方案是让他们参与到筹划阶段，并在筹划会议上承担技术角色。如果他们具备合适的技能、视角和知识来胜任这一角色，就让他们参与筹划。因此，关键在于我们如何让人们参与到他们能够发挥长处的时刻，给他们提供输入，这样无论他们处于哪个工作步骤，他们都能最大限度地发挥创造力，同时也有最大的清晰度，让他们能够充分利用时间，并对自己的工作感到满意。

It feels like the core of this is de-risk, the biggest risks and address the biggest unknowns as much as possible. Like there's probably this 80% of here are the risks. Let's just understand them deeply before we commit to this appetite. That is exactly right. There are these, you know, we can call them rabbit holes, we can call them time bombs. There are these things where we say, oh, you know, it'll be fine. You know, like one example, like simple example, I worked with the team and they had a step of onboarding in a Fintech product. Okay. And there was this step of onboarding and they would lose a lot of people in the funnel at that step because you had to fill out a whole bunch of information and they figured out that they could actually pipe that data in from one of the partners that they had because they were partnered with banks and they're like, we don't even need to be asking people this, right.

核心意思似乎就是尽可能降低风险，解决最大的风险和未知问题。大概有80%的风险在这里。让我们在承受这份风险之前，深入理解这些风险。这是非常正确的。有些事情，我们可以称之为“兔子洞”或“定时炸弹”，就是我们可能会觉得没什么问题。但实际上，比如一个简单的例子：我曾与一个团队合作，他们有一个金融科技产品，在新用户注册过程中有一个步骤。他们在这个步骤上流失了很多用户，因为需要填写大量信息。然而，他们发现可以通过与银行的合作伙伴直接获取这些数据，从而不需要让用户亲自填写。这个发现很大程度上优化了注册流程。

So we're going to end, we're going to fix conversion. We're going to eliminate a step from our user experience. It's going to be great, right. You know, the thing that they didn't look at was if you go into the code on that step of the onboarding, it's not actually one step. There's like three different branches of that step depending on which bank the customer is integrated on, you know. And so that's the kind of thing where it all sounds so great and simple and then you get into the weeds and you realize like, oh, wait a minute. You know what I mean?

所以我们打算结束这个问题，修复转换问题。我们还计划简化用户体验，去掉一个步骤。这听起来很好，对吧？但是他们没注意到的是，如果你查看那个入门步骤中的代码，其实并不是一个步骤。根据客户连接的银行不同，实际上有三个不同的分支。就是这种情况。一开始听着简单美好，但是深入了解后你会意识到，哦，事情并不那么简单。你懂我的意思吧？

So now we have decisions to make. Now, if you're in the middle of a project and it's already been resourced, right. And people are already on the hook that we're supposed to be doing this and you already got the alignment that the engineering time is happening for this and you're finding that out in week four. You know what I mean? You did all these beautiful drawings by the way and now you're finding this out in week four. Like, that's a bad place to be.

所以现在我们需要做出一些决定。如果你正处于一个项目的中途，并且项目的资源已经分配好了，人们也已经承诺要完成这些任务，并且工程的时间也已经安排好了，而你在第四周时才发现这些问题。你明白我的意思吗？你之前做了所有漂亮的设计图，但是现在在第四周才发现这些问题，这种情况真的很糟糕。

But if we're in the shaping room and we didn't kick this thing off yet, right. We didn't even green light the project yet. And we have an engineer there, not just the product people, not just the designer, but we have that engineer who really insists on sometimes I like to think of it, you know, like the grumpy old plumber who's seen everything and he insists on opening up the walls and looking at the pipes before he'll give you a quote, right. So it's like, we've got that person in the room.

但是如果我们还在讨论项目的阶段，而还没有正式启动这个项目，对吧。我们甚至还没有为这个项目开绿灯。而在这个房间里，不仅有产品人员和设计师，还有一位工程师。我有时候喜欢把他想象成那个经验丰富的老水管工，他总是坚持在报价前先拆开墙看管道的情况。所以，就好像我们有这样一个人在现场。

They're saying, yeah, that all sounds great. Let's take a quick look at the code and figure out what screen you're actually talking about. Just let's just take a quick look and it only takes a moment to open up the code, find this thing that we're talking about and really look at it and say, oh, you know, it's more complicated than we thought. And now it's not like, okay, no, we're screwed and the project is going to be bigger. No, now we can have a really cool conversation about trade-offs.

他们在说，好像所有的听起来都很不错。让我们快速查看一下代码，弄清楚你实际上在谈论哪个屏幕。只需快速看一下，打开代码只需片刻，找到我们讨论的内容，并认真查看。然后我们可能会发现，它比我们想象的要复杂。但这并不意味着我们就完蛋了或项目会变得更庞大。相反，现在我们可以进行一次关于权衡取舍的精彩对话。

So let's say we've got three different integrations here, three different segments integrated into different banks. How big are they relative to each other, right? In terms of the deals we made or the percentage of customers who flow through those three different conditions, right? If we just did this on one of those branches, would it be a win? You know, and like if we did it on all three, how much more time would we have to negotiate for? And would it feel worth it? You see, like we're getting into this horse trading of like, what is important? What's worth it? What do we need to get out of it? And that's really productive.

所以，假设我们在这里有三个不同的整合项目，分别与不同的银行进行合作。那它们彼此间的规模多大呢？我们可以从交易规模或通过这些不同条件进行的客户比例来比较。如果我们只在其中一个分支进行这样的整合，算不算一个成功呢？如果我们在所有三个分支都这么做，我们需要多花多少时间来谈判呢？这样做会值得吗？你看，我们在权衡哪些因素重要，哪些值得我们付出，我们期望从中获得什么。这种思考是非常有成效的。

That's and when you're doing that before the project starts off, that feels like, oh, we're talking about the important things. We're not failing right now. We are engaged in the hard questions that are going to enable us to really ship something that's successful later. Well, let's go one level deeper on the shaping session because clearly that is so core to this working. And I know you'll whole book about like how to actually do this.

在项目开始之前，当你这样做的时候，会觉得自己正在讨论重要的事情。我们现在并没有失败，我们在思考那些艰难的问题，这些问题会帮助我们将来真正成功地推出一个项目。让我们更深入地探讨一下规划会议，因为显然这是工作的核心。我知道你还写了一整本书来讲述如何实际做到这一点。

So we're not going to answer all the questions and there's a lot of detail on new ones. But a few questions, how long do these usually take? Is it like, sounds like a whole day kind of experience? And then it sounds like you invite us few people as possible, but not too few people. What's your guidance on who should join? So we run in this shaping and real life course. We've been doing workshops where we try to help people to learn what it's like in a shaping session.

我们无法回答所有问题，而且在新问题上有很多细节。但有几个问题：这些通常需要多长时间？听起来是个需要花上一整天的活动吗？然后，听起来好像你想尽量少邀一些人参加，但又不能太少。对于谁应该参加，你有什么建议？所以我们正在进行一个锻炼和实际生活课程。我们一直在举办工作坊，帮助人们了解锻炼课程的实际情况。

And one of the things that's always interesting to me is how, so like, Katya and I will be running the session. And we have to like, people aren't used to working so fast, you know, to like, like, what are we actually doing right now? What's the decision? Like, what's an idea? Like, right now, we're not going to go away and draw something and then and then all comment on a document and then come back and get together tomorrow. Like, what ideas do we actually have right now?

对我来说，一件总是让我感兴趣的事情是，像我和Katya一起进行会议的时候，我们得让大家习惯快速工作。人们常常不习惯这种节奏，比如现在我们实际上在做什么？我们做了什么决定？有什么想法？我们不会暂时离开去画些什么，然后再对一个文件进行评论，之后明天再聚在一起。那么，现在我们真正有什么想法？

Like starting from zero. So like, imagine, imagine like, we've narrowed down the calendar problem too. It's about empty spaces, right? We are willing from a business standpoint to spend six weeks on a whack at this where it's solved. We believe there's a way that's possible. So what can we come up with? And that's how you, that's the input to the framing session or sorry, the shaping session. Exactly. So that's so that they're having a narrowed down problem from the framing work.

就像从零开始。想象一下，我们已经把问题集中到了日历上的空白空间。从商业角度来看，我们愿意花六周时间来解决这个问题。我们相信有一种可行的方法。那么我们能想出什么办法呢？这就是我们在筹备会议或规划会议中的输入，也是问题缩小后的结果。

And this is a whole other topic of, you know, very often the PMs are sometimes just taking something of face value and not negotiating down to really narrow down what is this really, you know, and where is the value in this? But let's suppose that that's happened, right? That we've narrowed down the problem. So now we've got a narrow problem. So now what we need to do is try out different ideas and, and this is the real thing. We have to try to break them. So I want to draw an idea. And then I want the technical person to find like, oh, this isn't going to, you know, I mean, this isn't going to work because of this reason. Or the product person is going to be looking in and saying, I don't think like I get that that's really an easy way to do it technically, but I don't think that we're actually delivering the value. If I play through the customer scenario here, you know what I mean?

这又是另一个话题，很多时候产品经理只是表面上接受一些东西，而没有深入探讨，真正弄清楚这到底是什么，价值在哪里。但假设我们已经这样做了，我们已经明确厘清了问题。那么我们现在有一个明确的问题，接下来我们需要尝试不同的想法，这才是关键所在。我们必须努力去挑战这些想法。我提出一个想法，然后技术人员可能会指出：“哦，这行不通，因为某个原因。” 或者产品人员可能会说：“我知道从技术角度来看这样做很简单，但我不认为这真的能提供价值。如果我考虑一下客户的场景，你知道我的意思吗？”

So there's these different angles where the idea can fail. And one of the things that we also coach people to do in a session is not just to go down one path and then be sort of stuck in one idea and now you're kind of going in circles around little details of one idea for three hours, but to really step back and say, here's an approach, you know, what if we had the scrolling agenda view, okay? And that's idea A, like then what's what's a very different way of doing this? You know what I mean? Like if we didn't want to have the agenda view there, like, is there a way to do this where it's just the month view? Let's like see if we can draw that, you know? So that's that's the kind of thing that's happening. You asked about the time and I started with like people aren't used to just going all the way in to actually trying ideas, you know?

所以，从不同的角度来看，这个想法可能会失败。在某个讨论会上，我们建议人们不仅仅沿着一条路径思考而卡在一个想法上，然后围绕这个想法的小细节绕圈子花上三小时。而是要真的退一步看看，比如说，我们有一个滚动议程视图的方案，这是方案A。那么有没有一种完全不同的方式呢？如果我们不想用议程视图，那么有没有可能只使用月视图呢？我们可以试着画出来看看。这就是我们正在做的事情之一。你问到时间问题，我的回答是，很多人不习惯完全投入去尝试不同的想法。

So there is a little bit of learning how to just face that blank page and start trying things together, you know? What we find is that a three hour session can be very, very productive to help you figure out kind of what what do we already have that are possible approaches to this? What are some major missing things? You know? Like, okay, I've got the calendar dot dot grid, I've got the agenda idea, but like what about what about multi day events? Do you know what I mean? Like so there can be these things these like what about? So then maybe we break and we think for a little bit and somebody sketches some ideas on that and does a spike or two on something and we come back again, you know, for another three hours, we come back the next day, right?

所以，这有点像是学习如何面对那张空白的纸，并开始尝试把想法凑在一起，对吧？我们发现，一个三小时的会议可以非常有效地帮助你理清我们现有的可能方案是什么？有哪些重要的缺失呢？你明白我的意思吗？比如说，我已经有了日历表格和议程的想法，但像多日活动这样的事情呢？有没有想过呢？于是，也许我们会休息一下，稍微思考一下，有人可能会针对这个问题画出一些草图或者做一些初步的尝试，然后我们再回来继续讨论，对吧？也许会是另一个三小时的会议，或者是第二天再回来继续。

And what I would say is if the project that you're trying to do is doable with let's say your existing technology, right? You're not inventing a new algorithm. You're not inventing some new database or you know what I mean? You're not doing a new new AI model. It's more about like how do I use the APIs and the frameworks and the tech stack that we have? How do I put that together to build something? You know, then you know, if if the if the problem is clear and the time is now like you will be able to come to a conclusion about what's possible to build in, you know, three sessions, something like that, you know? The key thing is leaning into those sessions and really wrestling with each other, you know?

我想说的是，如果你正在做的项目可以用现有的技术完成，比如说，你没有发明新的算法，没有创建新的数据库，也没有开发新的 AI 模型。更多的是关于如何使用我们已有的 API、框架和技术栈，把它们结合起来建设一些东西。如果问题明确，并且现在就是动手的时机，那么你应该能在大概三个阶段内得出结论，看能构建出什么。关键是要积极参与这些阶段，并且积极交流和探讨。

If you have just the product and the designer there and and and then it's kind of like, well, we'll show this to the technical person later, then it's it can all blow up and then you find out it's more complicated than you thought you have to go back to the drawing board. We need to have the right all the right the necessary information in the same room for these sessions to go fast. There's so much genius built into this approach and it like sits on top of human nature. One is just you you need to actually spend like go into the deep edge cases and nuances and not like let me let me let's find let's go more concreteness. Very concrete, very like in in depth and the appetites, there's just like so many elements of this that just connect with the way humans work versus a theory of just like yeah, well, yeah, it'll take it'll be go great and we'll figure it out as we're building we don't need to really figure this out.

如果产品和设计师在一起，而技术人员却缺席，想着以后再给技术人员看，这种情况下可能会出现问题，然后你会发现事情比你想象的要复杂，你不得不重新开始。因此，我们需要在同一个房间里拥有所有必要的信息，以便加快进程。这种方法中蕴含着很大的智慧，与人性自然契合。首先，你需要深入研究极端情况和细节，而不是敷衍了事。要非常具体、深入，涉及多种元素，这些元素符合人类的工作方式，而不是一种理论化的想法即"没事，我们在建设过程中会搞定"。真的需要在一开始就搞明白细节，而不是随便应付。

Yeah, we don't have time for that. And we're solving a puzzle together, you know, if it needs to be doable in this amount of time, but it also has to hit these points in terms of the problem we're solving. You know what I mean? It kind of has to do these things, but in this time and you know, one other thing that I would mention is that we can't be drawing Figma files. By the way, I'm being very mean to Figma, you know, so far in this conversation, there is a time, right? When when it's the right time for the Figma file, right? What we want to do is have that clarity around, you know, the let's say we already know where the sink is going in the kitchen. And now we can make final calls about the tile and the exact fixture and stuff like that. Right? Grout color. We don't want to have to throw it all away every time something changes, you know?

好的，我们没有时间处理那些事情。我们正在一起解一个难题，你知道的，这个难题需要在这段时间内完成，同时也必须在我们解决的问题上达到这些要点。你懂我的意思吧？它要在这个时间内做到这些事情。另外，我想提的一件事是，我们不能再画Figma文件了。顺便说一句，在这次谈话中，我已经对Figma有点苛刻了，不过也有对的时间来使用Figma，对吧？我们希望能更清楚地知道，比如说，我们已经确定水槽要放在哪里了，然后我们可以做出关于瓷砖、具体配件和灌浆颜色等的最终决定。我们不想每次有变化时都得推翻重来，你知道吗？

So there's a time in a place where Figma is amazing and feels good and it's like, oh, now it's beautiful. You know, now it's amazing, right? But in a shaping session, you can't collaborate on on on something so high fidelity, right? And so we need also some ways to collaborate. And this is where you see these techniques in the book like breadboarding and fat marker sketching. These are tools to help us express an idea very, very clearly in detail. You know, we're going to hit this button and from this button go to here, this calculation runs, then we get this answer and then we have this choice to go here or here, right? Like that's the kind of thing that we need to be seeing. And that's that's kind of the sort of the level of detail where we can move fast together, but still see something real as more this kind of breadboarding level.

有些时候，使用 Figma 让人感觉特别棒，它让一切都变得美丽。但在讨论方案时，你无法在如此高精度的设计上进行合作。因此，我们需要一些其他的方式来进行协作。书中提到的一些技术，比如线路板（breadboarding）和粗记号笔绘图（fat marker sketching），就是用来帮助我们非常清晰地表达一个想法的工具。比如，我们要按下这个按钮，然后从这个按钮进入这里，运行这个计算后，我们得到这个结果，然后我们有这个选择可以去这里或那里。这是我们需要看到的细节程度，是一种能够让我们快速协作，同时又能看到实际效果的方法，这类似于线路板这样的层级。

Fat marker session is like very evocative of what this whole session is about is like very high level sketches. That's a great thing to say. The danger there that I often see is that what we don't want is to say, oh, Figma isn't the right thing at this level. So instead, we're going to do fat marker sketches. And what you get is the equivalent of a blurry Figma. Do you know what I mean? Just less detail. What we need from a from a fat marker sketch for it to be valuable to us as builders is it has to really communicate the idea. So when I look at that, I'm like, oh, now I get it. Right? And if it's kind of more this sort of general wireframe of like, you know, dashboard goes here and there's going to be four reports. And it's like, I still don't know what to build. Right?

“粗标记笔会议”就像是这整个会议的缩影，本质上是进行非常高级别的草图绘制。这是一个很好的说法。但我经常看到的一个隐患是，我们不希望的是仅仅因为觉得 Figma 不适合这个阶段的工作，就转而使用粗标记笔草图。这样的话，你得到的可能只是一幅模糊的 Figma，细节更少。对于我们建设者来说，要让粗标记笔草图有价值，它必须真正传达出创意。当我看到时，我应该会想：“哦，现在我明白了。”如果草图只是更像一个通用的线框图，比如“这里是仪表盘，这里会有四个报告”，那我还是不知道该构建什么，对吧？

So if it's not telling me what to build. So maybe this is a way to come back to your question about what's the output of the shaping session. It's like, it's shaped. If we can give this to a technical person and they say, yeah, I know what to go build now. I'm very happy with our overview of the process. I think we've done a really good job giving people the gist. And obviously, if they want to actually implement it, they can get the book and dive in or work with you, which will point people to say, someone's like, this is awesome. I want to do this. What would you say is a good first step for a team that's currently, let's say like they're in startup land and they're just like shipping every two weeks, maybe every week? So maybe for that bucket of folks.

所以，如果它没有直接告诉我该构建什么，也许这就是回到你问题的一个方式：成型环节的输出是什么。可以说，它已经成型了。如果我们把这个交给技术人员，他们说，好的，我现在知道要构建什么了，那就表示我们的过程总览做得非常好。我认为我们已经成功地让人们了解了大致内容。当然，如果他们想实际实施，可以去获取这本书深入研究，或者与您合作。当有人觉得这个过程很棒并想要践行时，你会怎么建议？对于那些可能在初创阶段、每两周甚至每周推出产品的团队来说，第一步应该是什么？我觉得这些人群或许可以这样开始。

And then also for a larger company that's, you know, I don't know, agile scrum safe. And they're just like, oh, let's try something different. Sometimes dev teams, they like the idea of not having the scrum ritual. So they want to take in the six weeks. But unless the engineering and product come together to figure out how to collaboratively shape, like we talked about before, you know, that time box isn't going to go well. Right? I think they're going to not have to do stand-ups. But now it's like a day of hard thinking. It will kind of turns into even more meetings because we don't know what to do.

然后，对于一家大公司来说，你知道，使用敏捷开发、Scrum或SAFe框架的公司，他们可能会想尝试一些不同的东西。有时候开发团队会喜欢不进行Scrum惯例的想法，所以他们想要尝试六周的周期。但是，除非工程和产品部门能够如我们之前讨论的那样一起合作，共同规划，否则这个时间框架可能不会顺利进行。对吧？我认为他们可能不需要进行站立会议，但结果却变成了今天要进行大量的深度思考。由于不知道该怎么做，这反倒可能带来更多的会议。

And the more meetings is just that shaping session specifically. No, I mean is that if we didn't, if we only adopted the six week cycle and said, we're going to figure it out and we didn't adopt the shaping, then we just don't know what to do. And then we reach the end and we're basically scrambling to shape it as we go. And then we run out of time. And then we feel like this wasn't, you know, it was nice to get a break from the from the scrum rituals. But we can't say that we are, you know what I mean, knocking the champagne bottle on the boat because we're celebrating the launch, you know, or whatever, you know, again, it again, right?

这段话的大意是，如果我们只采用六周一个周期的方法，而没有进行计划和准备（即“shaping”环节），那么我们就不知道该如何操作。当周期结束时，我们会仓促地进行准备，却发现时间已经用完了。虽然暂时摆脱了scrum的流程，但不能算得上是成功地推出或完成项目。实际上，我们无法庆祝我们的成功。

It's a good actually time to maybe talk about. There's obviously the spring kickoff in scrum. Yeah. What's like the main difference for people because they may be thinking, oh, that's just like a spring kickoff. That's a good one. That's a good one.

其实现在是个不错的时机来谈谈这个问题。显然在Scrum（敏捷开发）中有春季启动会。对大家来说，主要的区别是什么呢？因为他们可能会想，这不就是一个春季启动会吗？

So what you often see in a scrum team is that there's somebody who creates these tickets. I've like, these are the things that are going to happen inside of the sprint, you know, and really in, in, in, in my opinion, too many cases, it's not the person who's doing the building who's creating those tickets. It's like a product owner. So there's a big, big gap there. There's a, we could talk a lot about that. But there's, there's gaps in context. The person who's writing the ticket doesn't actually understand the work that's involved. You know what I mean? So there are so many unknowns and time bombs waiting in those tickets that sound reasonable, but they weren't really created by the person who understands the work that needs to happen, you know?

在一个Scrum团队中，你经常会看到有人负责创建这些任务卡。这些任务卡就是在冲刺期间要完成的事项。在我看来，很多情况下，创建这些任务卡的并不是实际负责执行任务的人，而通常是产品负责人。这里存在很大的差距，可以说有很多上下文的信息是不对等的。撰写任务卡的人实际上并不完全理解工作中涉及的内容，你明白我的意思吧？因此，这些任务卡中存在很多未知的因素和潜在的问题，听起来合理，但实际上并不是由真正了解需要完成的工作的人创建的。

So the key difference is two things. So in scrum, you have, you have a person who's not the builders making tickets. And this is what, and you know, in the cruel picture is the paper shredder. In, in the shape up world, you have a single idea that was shaped. This is the thing we shaped, right? With the two months in the agenda view and da da da da. Go make your own tasks because you're the professionals. Do you know what I mean?

关键的区别在于两点。在Scrum中，有一个非建设者角色来创建任务卡，相当于一个形象比喻就是碎纸机。而在Shape Up的方法中，你有一个完整构思的想法。这是我们精心打磨的想法，对吧？在两个月的计划视图中，等等等。去自己创造任务，因为你们是专业人士。明白我的意思吗？

So like, the contractors, you know, like if you're building a house, like they have to know the plans, but you don't have to tell them now take the hammer and go over here, you know? That's their expertise, right? So in a shape up world, a kickoff is, uh, here's the well-shaped idea and now this time box starts. And, um, at base camp, it was, it was really, really loose because, I mean, they are just stocked with senior people. I mean, they have so many very senior engineers and all the designers are coding and they're very technical, really, really skilled people.

所以呢，比如说承包商，你知道的，就好像你在建房子，他们得了解设计图，但你不需要告诉他们现在要拿起锤子去干什么，对吧？这就是他们的专业所在。在 "Shape Up" 的工作环境中，启动会议就像是给出一个经过精心设计的想法，然后时间框架开始。在 Basecamp，这个过程非常宽松，因为那里有很多资深人员，他们有很多非常有经验的工程师，所有设计师也都懂得编程，他们非常专业且技艺高超。

And what I found is helpful when the team is a little bit more mixed, if they're not all super senior is a simple exercise of at kickoff, take whatever was shaped and just draw grid with nine boxes and give me nine boxes of the nine major chunks that you think have to get implemented from an implementation standpoint. So like translate this into nine major scopes of implementation that need to somehow happen over the time box. So really, really useful exercise to kick things off and we have a lot of teams doing that now, you know?

我发现，当团队的组成稍微多样化一些，而不是全部由资深成员组成时，一个简单的练习非常有帮助。在项目开始时，拿出计划好的内容，画一个三行三列的九宫格，然后告诉我在实施层面上你认为需要完成的九个主要部分。也就是说，把这个计划转换为九个主要的实施范围，这些范围需要在限定的时间框架内完成。这真的是一个非常有用的启动练习，现在我们有很多团队在这样做。

If you take six weeks, that's like 30 business days, you divide that by nine, it's like kind of like four days per box, you know? So you're going to get a lot of clarity from a quick exercise. And again, this is done by the builders. This is a really also good exercise for them to notice like, oh, wait a minute, we think there's too much scope here, even though it seemed reasonable, when we put it into nine boxes, it's like, I, you know, I don't think we can do this all.

如果你花六个星期，那大约是30个工作日，你将这些天数除以九，大概每个方框四天。通过这个简单的练习，你会获得很多清晰的认识。而且，这个练习是由建造者们完成的。这对他们来说也是个很好的练习，让他们注意到：“哦，等一下，我们发现，虽然最初看起来合理，但实际上任务量太大，当我们把它分成九个方框时，我觉得我们无法全部完成。”

Or it's also a good moment where somebody who's more junior might kind of describe their implementation approach. And then someone who's senior can review that and say, actually, you know, we've done that before and we'll run into this trouble if we don't use this other thing, you know? So those kind of really nice kind of coaching moments can happen. So this is like, if you were to try this approach and have a shaping session, this is a sign you're heading in a good direction is if the output, the team that's building it can come up with nine.

或者，这是一个很好的时机，让较为资浅的成员描述他们的实现方案。而资深的成员则可以审核这个方案，并指出，实际上，我们以前这样做过，如果不使用另一种方法，我们可能会遇到麻烦。这种情况下，就提供了一种很好的指导机会。因此，如果你尝试这种方法并进行一个规划会议，那么当团队能够提出九个成果的时候，这就表明你正在朝着正确的方向前进。

And is it like more like does it have to be nine? Is it like six, cool, 10 cool? What I found is if it's more than 10, then you just get into ticket land. Of here's a million things I have to do, you know what I mean? If you have a hundred things, it's like that doesn't tell me anything. But if it has to be nine or less, you know, I actually think, I actually think I'm speculating here, but you know, the UX designers in your audience will know about this rule of seven plus or minus two.

这段文字可以翻译成中文如下：那么，是一定要九个吗？还是说六个也可以，十个也可以？我发现如果超过十个，就像是进入了“任务清单”状态——有成千上万的事情要做，你明白我的意思吧？如果有一百件事情，那根本不能传达任何有效信息。但是如果必须是九个或更少，我在这里只是推测，但你们中的那些用户体验设计师可能会知道关于“七加减二法则”的事情。

It's this cognitive science principle that was found about how many things someone can hold in their head at once. Yeah. And so this nine is the upper limit of seven plus or minus two. And it basically, you know, it's kind of like, do we actually have a picture of what it means to build this that we can all hold in our heads? Can we kind of see the whole castle?

这是一项认知科学原则，研究发现人们同时能在大脑中记住的东西数量有限。通常来说，这个数量的上限是九，也就是七加减二。换句话说，我们是否能在脑海中形成一个清晰的画面，理解如何一起构建这些东西？我们能否看清整个城堡的全貌呢？

So what I'm hearing is like, if you're an agile scrum team today, if you want to start trying this out, it's schedule a shaping session, assume it six weeks to start, try to get into it with a framing of like, here's the problem we're trying to solve. Is that a good way to think about it? Like the problem we're trying to solve?

听起来是这样的：如果你现在是一个敏捷Scrum团队，并且想要尝试这种方法，可以安排一个塑造会议，假设从六周开始，尝试先以“这是我们要解决的问题”这样的框架来进入。这是一个好的思考方式吗？比如我们要解决的问题是什么？

Yeah, for sure. The question is what problem we're trying to solve, you know, because the shaping work is more what are our options for the solution? You know, and if the problem is too fuzzy and big, if the problem is just calendar, you know, then the shaping is going to be this ever expanding, never-ending thing. And we're not going to be able to get anywhere.

当然可以。问题是我们到底在解决什么问题，因为塑造工作更多的是在考虑解决方案有哪些选择。如果问题过于模糊和庞大，比如说只是一个“日历”问题，那么这个塑造过程就会变成永无止境的事情，而我们将无法取得任何实质进展。

Yeah. Okay. So you spend like three hours, maybe six hours, like in the first session, would you recommend like, try to keep it to this many hours when you're first trying it out? No, I wouldn't do that. You know, I think the key thing is actually, if you get to the point where you're trying to hold a shaping session and you manage to get product and engineering into the same room to do it, you are far along. You're doing great if you're at that point, you know, so much of the challenge is getting to the point of kind of aligning between product and engineering that we cannot keep, we cannot have projects that are dragging and dragging and dragging.

好的。那么你第一次进行这种会议时，会花三到六个小时左右，你是否建议在第一次尝试时保持这样的时间长度呢？我不会这样做。我认为关键在于，如果你能组织一场塑造会议，并让产品和工程团队坐在同一个房间里进行讨论，那你已经走得很远了。如果达到了这个阶段，你已经做得很出色了。因为很大一部分挑战在于如何在产品和工程之间达成一致，我们不能让项目一拖再拖。

We can't keep ending in a place where like, this is the end of a sprint or the end of a cycle and we still can't see the end of it, you know, or we have to make so many cuts and compromises at the last minute that it's not the quality of, or it's not really matching what it was supposed to be in the first place, when those problems are happening or, you know, also by the way, this is surfacing at the exact level. Imagine, you know, you're the CPO, you're the CTO, and you're supposed to be answering to how's that work going, right? And it's like, well, actually, you know, we're working on it.

我们不能总是陷入这样的状况：无论是项目的冲刺阶段结束还是一个周期的结束，我们仍然看不到任何成效。或者，我们在最后一刻不得不做出许多削减和妥协，以至于结果的质量和最初的预期严重不符。当这些问题出现时，想象一下，你是首席产品官（CPO）或首席技术官（CTO），需要回答工作进展如何时，只能说：“嗯，其实我们正在处理。”

I mean, oh, I can just think of a couple times when I needed to go to Jason and he expected me to be making progress on something and I had gotten nowhere on it, you know, and that feeling, you know, when you were with top leadership in the room and you don't have a good answer for where you are on something is like, oh, it's brutal, right? And then from the CEO's perspective, it's like, where's the movement? We're running a business here, like, really, nothing is shipping still, you know, this can't just keep happening, you know?

我的意思是，我能想到好几次去找杰森的时候，他期待我在某件事情上有进展，但我却完全没有进展。那种感觉，你知道的，当你和高层领导在一个房间里，而你对自己的进展无法给出好的回答，真的很让人心力交瘁。从CEO的角度来看，他们会想：“我们的业务在哪里有进展呢？我们在经营一家公司，但什么都没有推出，这种情况不能继续下去。”

So there's some recognition somewhere either at the top higher levels or within the team, you know, of like, we don't want to keep dragging, we don't want to keep being lost in the weeds. And then this can be the, you know, like the activation energy, like you gather the power to be like, okay, we actually want to try something different. And in that case, what I would say is what usually works best is, okay, we're going to try a pilot project.

在高层领导或团队内部，或多或少都意识到我们不想继续拖延下去，也不想继续在琐碎的细节中迷失。那么这就像是启动能量，你聚集力量来决定，我们确实想尝试一些不同的东西。在这种情况下，我会建议通常最有效的方法是尝试一个试点项目。

And what we want to do is, as you said, kind of choose a problem that's important enough to all of us that we think it's meaningful, that's going to be worth, you know, trying to do well. And it doesn't have to be six weeks, it could be something that is a little bit smaller. Maybe you feel comfortable taking on a three-week thing for the first time. What's important is just matching, matching these things together, right?

我们想做的事情是，正如你所说，选择一个对我们所有人来说都足够重要的问题，我们认为这个问题有意义，值得去努力做好。这不一定需要六周的时间，可以是一个规模较小的事情。也许你觉得第一次尝试时做一个为期三周的项目比较合适。关键是要把这些事情匹配好，对吧？

Here's a problem that we actually care about. It's timely. Something that we would like to be shipped soon. It's not so small that we're not going to actually learn this new muscle, you know? And it's big enough that it's going to feel like we really achieve something, right? So maybe that's going to be four weeks, maybe it's going to be six, maybe it's three, I don't know.

这是一个我们真正关心的问题。它很及时，是我们希望能尽快解决的事情。问题不那么小，不至于让我们无法锻炼新的能力，对吧？同时，它又足够大，让我们感到确实完成了一些事情，对吗？可能需要四周的时间，也许是六周，或者三周，我也不确定。

And then kind of getting to a place where we have, we wrestle a bit with the problem to get the problem narrowed down, we get into our shaping session. And then we do our best, do you know what I mean? And usually what happens, too, is if we have an engineering team that's going to become free to do this work for those X number of weeks, that's the upper limit on how long we can spend to shape. And that's another kind of like real-life thing.

然后，我们努力缩小问题的范围，进入解决问题的阶段。我们会尽力而为，你明白我的意思吗？通常情况下，如果我们有一个工程团队可以在接下来的几周内投入这项工作，那么这也就决定了我们能用多长时间来规划。这也是一个现实因素。

Sometimes we talk about like, you know, you know, like if on the one hand, there's this universe of kind of never-ending documents. back and forth to get feedback and comments, you know? And then on the other hand, there's like, the team is going to be available. We're trying to actually do this. So actually, we've got a week to shape because engineering needs to kick off next week. You know what I mean? That's kind of a little bit more the real scenario when you're actually in this aligned world of like, we want we want to ship something now. Yeah, real-life constraints. That's a really helpful way of telling you how much I may have to do this.

有时候我们会讨论，比如，你知道，如果一方面是那种永无止境的文件，来回反馈和评论，你懂的？而另一方面就是，团队已经准备好了，我们实际上是想做这件事。所以，实际上，我们有一个星期的时间来规划，因为工程部门下周需要启动。你懂我的意思吧？这就是在一个目标一致的世界里，想要马上发布某个东西时的真实场景。现实生活中的限制真的是很好地告诉我们，事情可能有多紧迫。

For people that are just like, this is like, like, I don't know any friends that are using this, it's like weird, this way of working. Like it's not a thing I hear about all the time. What can you say to them to help them be like, okay, I should actually give this a try. Here's like, how many people are using it? Here's an impact they've seen. Anything you can share there to help them get over that home. I would say, wait until it hurts more. You know, if if if if if the unfamiliarity is kind of the big problem with it, you know, then then maybe the things are fine.

对于那些感觉这种方式很奇怪、没有朋友在用、也很少听到有人谈论的人，可以怎么说来说服他们尝试一下呢？你可以告诉他们有多少人在使用这种方式，以及已经取得了什么样的效果。任何可以帮助他们克服不安的信息都是有用的。我会说，可以等到问题更明显的时候再考虑，如果只是因为不熟悉而感到不确定，那么或许暂时现状是可以接受的。

I mean, because it's not like this is the only way. It's more like, I mean, changing is really hard, you know, and if there's a good reason to do it, and it's like, look, we've we've done it the old way. We've tried different experiments. You know, we've even already churned through a new head of product or we've cut a different CTO in, you know, and we're still having the same problems. Then there comes a point where it's like, like, I know that this is uncomfortable and I don't know somebody who's done it, but, you know, like, I think we need to try something different because we can't continue this way. That is a great answer.

我的意思是，这并不是唯一的方法。更像是，我是说，改变真的很难，你知道的。如果有一个好的理由去改变，比如说，看，我们过去一直用老办法，我们也尝试过不同的实验。你知道的，我们甚至已经换过一个新的产品负责人或者新的CTO，但我们还是遇到同样的问题。那么到了某个点，我们就会觉得，虽然我知道这很不舒服，而且我也不知道别人有没有这么做过，但我觉得我们需要尝试一些不同的方法，因为我们不能再继续这样下去了。这是一个很好的答案。

Following that same thread, just what are signs that it's time to try something like what sort of pain do you often see? That's like, okay, this is, you shouldn't look into this seriously. You know, there are pains all along the journey. So I mean, I think the the the place where it's most obvious is at the end of the line when we thought we were going to be done and this thing is just dragging and dragging and dragging, right? Like the teams like we're not shipping things, we're running in place, we keep going in circles on this. Like we don't see the end. Of course, that's kind of like the culmination, you know, but there's also a lot of pain points along the way.

沿着同样的思路，怎么判断什么时候该尝试别的方法呢？有哪些痛点是我们常见的，让你觉得应该严肃考虑这个问题呢？在整个过程中总是会有各种各样的痛点。我觉得最明显的地方就是当我们原以为事情已经结束，但它却一拖再拖的时候。就像团队说我们没有发布新东西，我们总是在原地打转，事情始终没有进展，看不到尽头。当然，这是痛苦的顶点，不过在这个过程中还有许多其他痛点。

So there's if we go all the way upstream, you know, there's if we go to the source of a project, right? Sales talk to a customer, you know what I mean? Or sales talk to a lead and we and and want us to they have this idea of this thing we need to build, right? Or the CEO had this idea on the shower the other day, or the product team did a whole bunch of research and they have a big case for why this is the thing that's important to build next. Whatever it is, there's there's a there's a source, right? For the from the business perspective of like this is the thing we should do next.

所以，如果我们从头开始追溯项目的起源，你会发现，比如销售人员与客户交流，或者与潜在客户沟通，他们会提出我们需要开发的一个新想法。也可能是CEO在洗澡时想到的一个想法，又或者是产品团队进行了大量研究，并且有充分的理由说明这是下一个重要的开发项目。不管是什么，总会有一个起源点嘛，从业务的角度来看，这就是我们接下来应该做的事情。

If it's if if we just say dashboard and we don't negotiate with that means, if we just say calendar and we don't negotiate like what that actually is, then what do we experience this kind of fuzzy fuzzy thing where you know, like it's really hard to get to a conclusive answer about like, yeah, that's what we need to go do, you know, it's kind of like the ever expanding blob, you know? So if we've if you felt that before, that's already a first pain. And then of course, where does it go from there? So we say calendar. So we don't know what it means, but we say calendars are now we give it to product and we've either got a whole bunch of figmophiles or we have the PRD with a million requirements about what a great calendar is, you know?

如果我们只是说“仪表板”，而不讨论其含义；或者我们只是说“日历”，而不具体阐明它到底是什么，那么我们会经历一种模糊不清的状况。我们很难得出明确的结论说：“对，这就是我们需要去做的。”这种情况就像一个不断扩展的模糊体。如果你以前感受过这种情况，那就是第一个痛点。那么接下来会如何发展呢？我们说“日历”，但不知道它具体意味着什么。然后我们把这个任务交给产品团队，他们可能得到的是一堆设计文件，或者是一份有上百万条关于一个优秀日历需求的产品需求文档。

And of course, you know, I don't want to be cruel to the people who are putting their hearts into that work because the figmophile is beautiful, you know, it's just coming a little early, right? And the PRD is full of a lot of true things that are probably really important for decision making in the project, but the way that it's packaged at that moment isn't something that gets absorbed, you know? I mean, you you write this document and who I mean who actually I'm sorry, like who actually reads it, you know what I mean? Like and I know it's painful, but it's like that, you know?

当然，我不想对那些投入心血工作的人苛刻。Figmophile 的确很美，只是出现得有些早，对吧？PRD（产品需求文档）中包含了许多对项目决策可能非常重要的真实信息，但目前的包装方式不太容易让人吸收。你明白我的意思吗？你写了这份文件后，究竟有谁会真正去读呢？我知道这很痛苦，但事实就是如此。

And then even when we try to read it, because it wasn't shaped and we didn't get down to it's this, it's that it's that and that's how it works. It's hard to it's hard to walk away from reading that and kind of have anything that's in your head, you know? As like this is what we're going to go build, it's kind of like a million puzzle pieces that you're going to have to solve, right? So what we see is either, you know, there's the figmophile and then there's the pushback from engineers, you know? There's the there's the PRD, but then it's like, okay, but we still don't actually know what to build. There's kind of all those things where instead of moving forward, there's like more and more questions, more and more pushback, more and more going back to the drawing board. So that's another kind of big indicator that something is going wrong.

当我们试图理解它时，因为内容没有经过精简，我们没有弄清楚具体是什么、如何运作，所以很难从阅读中得到什么明确的概念。最终就像面对一百万块拼图，需要自己去解决。于是我们看到，要么是设计师喜欢新的设计工具，要么就是工程师提出很多反对意见。有产品需求文档（PRD），但还是不清楚具体要构建什么。这样的情况下，与其说是在前进，倒不如说是问题越来越多，反对意见越来越多，一次次地回到起点。这是一个明显的信号，表示某些地方出了问题。

And then and then when we're in the building and we thought we knew what we agreed to, we thought we all said, yeah, this is what we want to go make. And it's just more and more questions coming out, you know? More and more unexpected complexity, things that we didn't anticipate, you know, and it's just it just doesn't feel like we're getting warmer and and coming closer. It just feels like it's getting harder and harder, you know? Those are all those are all the signs that like whatever process you use, you know, that there's a lack of there's a lack of clear shaping and there's a lack of clear framing because there's a lack of clarity, right? Around what it is that we're doing.

然后，当我们在建筑里以为已经知道我们同意了什么时，我们都认同说：“是的，这就是我们想要做的。”但是，越来越多的问题不断冒出来，越来越多我们没预想到的复杂情况出现。感觉我们并没有越来越接近目标，而是越来越困难。这些都是迹象，说明我们使用的任何流程中都缺乏清晰的构建和明确的框架，因为我们对正在做的事情缺乏清晰的认识。

Before we started recording, you made this interesting point that there's all this talk of feature factories and that rarely are they actually like efficient factories like they do. Yeah, talk about that. Yeah, well, I understand what the feature factory critique is supposed to be. It's actually to the framing point of we're not negotiating the value and the outcome we're trying to get from something. We're just kind of taking it and building it, you know? And then of course, in the end, according to the feature factory critique, we just built it because somebody said we should build it and then people didn't use it and didn't value it and the product is just getting bloated, right?

在我们开始录音之前，你提到一个有趣的观点，说到关于“功能工厂”的讨论很多，但实际上这些“工厂”并不像真正的工厂那样高效。能详细谈谈这个吗？我理解“功能工厂”批评的意思是，我们没有真正去商讨某个功能的价值和我们想要的结果，而是简单地去构建它。最后，根据“功能工厂”的批评意见，我们只是因为有人说要开发这个功能就去做了，结果人们并不使用它，也不认为它有价值，产品因此变得臃肿。

The thing is that like, I would say if you have a feature factory meaning you're continually cranking out features, you're probably quite healthy. All you need to do is feed a different input to the beginning of the factory, right? What most teams are struggling with is that they can't they can't they don't have predictable repeatable shipping of things, you know? I mean, at least from my experience, the bigger, really widespread struggle is like stuff isn't moving, it's dragging, I can't see the end. I'm losing my, like I'm feeling burned out, you know what I mean? Like it's not exciting to work on this anymore, like all that kind of a thing.

这件事呢，我会说，如果你有一个“功能工厂”，也就是说你不断地推出新功能，那你可能是相当健康的。你所需要做的就是在工厂的开始投入不同的原料。大多数团队面临的困难是，他们无法预测和重复交付项目。至少根据我的经验，更广泛、普遍的问题是项目进展缓慢，看不到尽头，我感到筋疲力尽。你明白我的意思吧？就像在说，这项工作已经不再令人兴奋，类似这样的情况。

Maybe last question here is what's what's kind of like the sweet spot stage for a company to start using shape up? I know you basically worked in this way from the very beginning when it was just three people. What do you find is like should startups that are just starting out start breaking this way or do you find it's more useful later on? We didn't formalize it until we had to and there was a long time where there wasn't a fixed length for projects. There was just an understanding of the urgency and kind of a feeling of what too long felt like, you know?

也许这是最后一个问题，什么阶段的公司开始使用 Shape Up 方法最合适？我知道你们从仅有三个人的时候就开始以这种方式工作。你觉得刚刚起步的初创公司应该马上采用这种方法，还是在公司发展到一定阶段后更有用？我们直到不得已才正式化这种方法，在此之前，我们的项目并没有固定期限，而是依靠对项目紧迫性的理解和对“太长”的感觉。

And it didn't actually click into, oh, this is a cycle length and this is six weeks and then we pause and this is how this is who comes together to make the decision of like what's the next project? And here's who is mainly doing the shape. You know what I mean? Like all that stuff didn't get solved until we had reached a certain size. Usually the main tipping point if we start from smaller to big is, you know, there's a phase when the founders are still involved in everything. And so it doesn't matter what your process is, it's going to be fine.

起初，我们没有意识到这些是一个周期，比如每六周是一个周期，然后我们会暂停，再决定下一个项目是什么，以及由谁来主要负责这个流程。这些事情直到我们团队达到一定规模后才解决。通常，从小到大发展的关键点在于，创始人们依然参与所有事务的阶段。在这个阶段，无论你的流程是什么，都没有太大影响，因为一切都会顺利进行。

But then you start to hire the first other people. And then for the first time you try to delegate some of those things and the founders try to be less involved. And that's often where a lot of these problems start to appear. And the founders start to ask themselves like, we used to be fast. And now we hired people because we needed a scale, but now we're slow, you know? So like, how will we be fast again? Because we know what it's like if we if we just got back in there as founders and you know, got our hands dirty, like we could make this go.

但是当你开始雇佣第一批员工时，你会尝试把一些工作委派给他们，而创始人则开始减少直接参与。这通常是很多问题开始显现的时候。创始人可能会问自己：我们以前动作很快。现在我们雇了人是为了扩展规模，但我们反而变慢了。我们该如何再次提高速度呢？因为我们知道，如果我们作为创始人亲自参与并投入实干，我们是可以让事情顺利进行的。

But how do I get, how do I get these, like the people that we've brought in to make these, make these tradeoffs and make these decisions? And how do I get the work to flow again? You know? So that's something that we definitely see there. So that's a really good moment. I'm onboarding new people. I don't know what to tell them how to work. I don't want to introduce a bunch of scrum rituals. Just winging it on Kanban isn't working because they don't have enough clarity. I run what to go after. So I have to babysit them all the time. You know what I mean? Like these kinds of things.

但我要如何让我们招募来的人做出这些取舍和决策呢？你知道的，我该如何让工作重新流畅运作呢？这是我们一定会遇到的问题。这是一个非常好的时机，因为我正在把新员工带进团队，但我不知道该怎么指导他们开展工作。我不想引入一大堆 Scrum 仪式，仅仅依赖 Kanban 也不起作用，因为他们没有足够的明确方向。我不知道该如何引导，所以我必须经常监督他们。你懂我的意思吗？这种情况就是这样。

There is another extreme, which is, we've already gone past that. You know, we've been scrum or whatever for years. You know, the company has been growing. Like revenue is coming in. Like sales is doing their job. Like things are running. But man, nothing is getting out the door. And we're years in. And we have an entrenched development. We have like an entrenched engineering team, which is a wall away from an entrenched kind of product team and everybody's apart. And this thing is like we're like stuck.

还有另一种极端情况，那就是我们已经过了那个阶段。你知道，我们的公司已经使用Scrum或其他类似的方法好多年了。公司的业务一直在增长，收入在增加，销售部门的工作也做得很好，一切看起来都在正常运转。但是，事实是，什么成果都没有推出。时间已经过去好几年了。我们有个固化的开发团队，一个固化的工程团队，各自在墙的一边，而产品团队也是各自为政。这种情况让我们陷入了一种停滞状态。

And that is more where there's going to be some tensions that are starting to appear at the executive level. There's going to be some finger pointing. There's going to be some like, why isn't this moving? Why isn't this happening? How can we be spending so much money and all these engineers? And we don't have anything to show for it. You know? And that's a point where there can be kind of so hard, some hard conversations need to start happening about how do we actually start to negotiate around how we spend time.

在这个层面上，会出现一些紧张局势。高管们之间可能会开始互相指责，比如：“为什么这件事没有进展？为什么这事没有发生？我们花了这么多钱，雇了这么多工程师，结果却没什么成果？”到这个时候，就需要进行一些艰难的对话，讨论如何有效地安排我们的时间。

And we can't just have endless refactorings and infrastructure projects. But we need to be actually building things that we can sell again. What an idea. Yeah, you know, but it can, you know, there are a lot of kind of engineering works that have been standing around for a while, you know, and it's all refactoring all day and tech debt and stuff like that. And there's reasons why all those things got there. But there comes a point where we have to figure out how to cut through it and make some hard choices so that we can carve out time to build the stuff that's actually going to to be needle moving again and not just sustaining us where we are to like run in place.

我们不能一直进行无休止的重构和基础架构项目。我们需要真正开始建造一些可以再次出售的东西。这是个好主意。是的，你知道，但实际上有很多工程项目已经停滞了一段时间，整天都是在进行重构和处理技术债务。这些问题有其存在的原因。但我们必须在某个时候想办法突破现状，做出一些艰难的选择，以便腾出时间来开发真正能带来实质性进展的产品，而不是仅仅维持现状、原地踏步。

Imagine the slatter bucket as you mostly work with the kind of companies that bring you in. Actually, it's been so far a lot of the, it's been a lot of the folks who still remember what it was like to be fast. And they're kind of newly too big and they don't like being slow. I've had a lot of that. I actually think that there is, I think that your intuition is right that the market for the last category is the biggest. But it's hard to reach them. It's not easy to talk about these things. These are sensitive topics.

想象一下，你主要与那些会把你引入的公司合作。实际上，到目前为止，合作的大多是那些仍然记得自己曾经动作迅速的公司。他们现在发展得有些过大，不太喜欢行动缓慢的状态。我遇到过很多这样的情况。其实，我认为你的直觉是对的，最后一类公司的市场最大。但要接触这些公司并不容易，这些话题都比较敏感，不太容易交谈。

Do you know what I mean? Like our engineering team isn't shipping, you know? And like it's like, and it's happening at leadership level. There's a ton of complaints happening deeper in the org, but nobody down in the org can change anything. At the end of the day, it's actually the interface at the executive level of being able to say, how are we using our time? Like we have to change something to make it even more concrete in that first bucket.

你明白我的意思吗？我们的工程团队好像没在产出，对吧？而且这种问题是发生在领导层。组织内部有很多深层次的抱怨，但在下层的人根本改变不了什么。本质上，还是要在高层面临并处理这些问题，思考我们如何利用时间。我们必须要在最初的步骤中做出一些改变，让情况变得更明确。

What's like the size of org that you find is most in you to this is like, how many engineers or is it like when they hire the first PM? Like what's kind of the I sometimes have the like how the heck do I hire the first PM? And what do they do? Conversation, you know? But usually it's later than that. It's after they hired the first PM, after they hired the second PM, and maybe even the third, you know? And they're kind of getting to like the product and engineering together are like 30, 50 people, you know?

您觉得一个组织的规模达到多少会触发这些问题？比如说，是多少工程师？还是说是在他们雇佣第一个项目经理（PM）的时候？我有时候会想，该如何雇佣第一个PM，他们具体会做什么？不过通常这些问题出现在后面一点的阶段，就是在雇了第一个PM、第二个PM，甚至可能第三个PM之后。到那个时候，产品和工程团队加起来可能有30到50人左右。

And it's like we thought we put everybody in the right roles. We kind of did what we were supposed to do and everything is just grinding and like why are we so slow? Perfect. So 30 to 50-ish people seems like a good time to that's probably like basically you're finding that's when things start to really break down. That's when they show themselves, you know? And I think I mean if someone kind of hears this and it all starts to make sense and they're earlier in that wave, then of course the earlier that you can anticipate it the better, right?

我们以为我们已经把每个人都安排在合适的位置上，尽到了我们的责任，但事情却进展缓慢，仿佛在停滞不前。为什么会这么慢呢？大约在有30到50个人的团队规模时，问题就开始真正显现出来。这个时候，问题开始暴露出来。我觉得如果有人听到这一点，开始明白其中的原因，而他们正处于这个过程的早期阶段，那么当然越早预见到问题就越好，对吧？

That's a good point. So if you're- That's a good point. That's a good point. That's a little bit too late is when they come out. I mainly hear about it when it's too late. You know, that's why they're reaching out. Yeah, that's maybe closer than 30. Okay. But I think I really think it honestly, I think it starts the first project where for example the the founding engineer is hands off and then the the new hire is taking over responsibility or the person who was like sort of founder slash CEO is like first giving it to a PM to kind of thinking they're going to carry it through, you know?

那是个好观点。所以如果您——那是个好观点。那是个好观点。他们出来的时候已经有点晚了。我通常都是在太迟的时候才听到这件事。你知道，这就是为什么他们会联系过来。是的，可能比30更接近一些。但是我真的认为，真的，我觉得这从第一个项目就开始了，比如，创始工程师不再亲自参与，而由新员工接管责任，或者那种既是创始人又是CEO的人第一次将任务交给项目经理，认为他们会完成。

And then it's not exactly meeting their expectations of what they thought was going to happen. to happen, you know? I think that's when those disconnects actually start. It's the first step away from the work where the seeds of all of these problems actually start. I want to talk about base camp and how maybe not every company can operate like base camp before we get there. Is there anything else along the lines of shape up that you want to add or share?

然后这并没有完全符合他们原本的预期。你懂的？我认为，这就是脱节真正开始的时候。这是偏离工作的第一步，也是种下所有这些问题种子的起点。在我们谈论Basecamp以及为什么并不是每家公司都能像Basecamp那样运营之前，你还有什么关于“Shape Up”的内容想要补充或分享的吗？

Yeah, there's there's one key thing which is the role of the PM. I think what we see today out of necessity in a lot of teams is that the PMs spend a lot of time kind of chasing around inside of the build phase, inside the time box to try and make sure that people aren't stuck and getting lost in the weeds and try and keep things moving, you know? And it can sometimes be too close to project management rather than product management, you know? And what we see in really in shape up teams when they hit their stride is that the PM moves upstream.

是的，有一个关键点就是产品经理（PM）的角色。我认为我们今天在很多团队中看到的是，出于必要，PM在产品开发阶段花费了大量时间，尽力确保团队成员不会陷入困境，或在细节中迷失，从而保持项目的进展。然而，这有时更像是在做项目管理，而不是产品管理。当团队真正成熟时，我们会看到PM从事的工作更趋向于前期规划。

So the PM is less busy with how do I get this project to like not be in a bad state when it's getting built? And they're way more in how do I understand the the business context? How do I narrow down the problem? How do I negotiate back and forth with maybe the CPO who kind of brought this to me to understand where the core of it is? That that really getting deeper understanding of the business and the problem and the customer domain and like what problem is worth solving and what's even slice of that problem is the valuable slice to to argue that we should spend a few weeks on, you know?

所以项目经理不再只是关注于如何让项目在施工时不出现问题，而是更加专注于理解业务背景。他们需要明确问题所在，并与可能提出这个项目的首席产品官进行反复沟通，以找出问题的核心。深入理解业务、具体问题和客户需求是很重要的，从而识别出哪些问题值得解决，以及其中哪个部分是最有价值的。这可以帮助他们论证为何需要花几周时间来处理这些问题。

That's the place where the PMs can really contribute a lot in the shape up world there. That's kind of what they do rather than shepherding the process or being a ritual master or something like that. That sounds pretty wonderful. I've been doing some thinking about what a world an AI oriented world does to the role of PM and it feels like very similar to that actually where the building now is going to happen for you with AI tooling and that means the bigger question now is like what the hell should I build? And is the thing I'd built right and correct and likely to work and it feels like this is similar.

这就是项目经理们真正能在这个世界发挥重大作用的地方。他们更多地参与实质性工作，而不是单纯地引导流程或是充当形式上的专家。这听起来很棒。我最近一直在思考一个以人工智能为导向的世界对项目经理角色的影响，感觉它与上述情况非常相似，现在建设工作将由人工智能工具为你完成，因此现在更大的问题是：我到底应该建造什么？我建造的东西是否正确且有效？这感觉很相似。

It's like the PM spending a lot more time up front thinking through what to build and then the building is more a lot more hands off. So hands off it gets done in like five minutes when you're just like full build this thing for me but I'm there it is. Yeah let's see let's see yeah. Let's see. I'm also very curious. Yeah. Oh man what a well time. Okay let's talk about base camp. I think we talked about this ahead of the podcast that I think you you want people to know that it's a base camp is very unique and not everyone can work the way base camp works.

就像产品经理在前期花更多时间思考要构建什么，然后在实际构建时就变得相对放手。当你说“全力以赴把这个东西做好”时，它很快就完成了，可能只需要五分钟。我很期待，我们来看看吧。我也很好奇。哦，真是时候了。好，现在我们来谈谈Basecamp。我记得我们在播客之前谈到过，我认为你想让大家知道Basecamp是非常独特的，不是每个人都能像Basecamp那样工作。

Just talk about your insight there and advice there and people see all this advice coming out of base camp. Well I got to tell you I had no idea how unique we were until I was outside and there are so many things for example it's a lot of the things that people ask to me about that are kind of not in the book that started to reveal those things to me you know that's so many things that I was just taking for granted. I mean every designer codes. Imagine if every designer codes and not and I don't just mean HTML I mean like running the app locally going into the place where that view is rendered to make that thing look the way that they wanted to look or whatever right I mean like really codes every designer.

只要分享你在那里的见解和建议，人们就会看到很多来自基地营的建议。我得说，直到我离开后才意识到我们的独特性。在外面有很多事情让我意识到这一点。例如，有很多人在问我一些书上没有提到的问题，这让我开始意识到有许多我视为理所当然的事情。比如，每一位设计师都懂代码。想象一下，如果每个设计师都会编码，不仅仅是HTML，而是可以在本地运行应用程序，进入视图渲染的位置，使其看起来是他们想要的样子，也就是说每位设计师都真正懂代码。

So every designer codes where's the wall between design and engineering where is that where's the moment where you arrive with the figmophile and then all of your you like the disappointment and all of the your hopes get destroyed because the engineers tell you know right like those moments don't even exist right in that world and then also I think also there was this lack of distance between sort of the business objective the thing we're trying to the reason we want to maybe do this project and the blessing of the founders and the like there wasn't this kind of you know executives far away with some big targets and then some layer of PM and then some building I mean the founders were always there right there in the problem definition still I mean I can't say today but I mean up until 2021 when I was still there you know so it meant that there was so much clarity all the time around what we're solving and why and why we're making time for it.

每个设计师都会编写代码，那么设计和工程之间的界限在哪里呢？在这个过程中，什么时候你带着满满期待用Figma搞定设计，却被工程师告知不行，让你所有希望破灭呢？这样的时刻在那个世界里根本不存在。我认为也没有那种商业目标与实际项目之间的距离感，这个项目可能是由于某些原因创立的，并且获得创始人的支持。在那里，你不会感到高高在上的领导层给出一些遥不可及的目标，然后再由产品经理执行，再到开发团队来完成。创始人们总是直接参与问题定义的过程，我最多只能说到2021年我还在那里时的情况。因此，我们总是对我们在解决什么、为什么要解决以及为什么要为此花时间有非常明确的认识。

And then of course on the engineering side as well I mean imagine you have no sales org you have no marketing that all of sales sales selling and marketing is happening by the unicorn founders so it means that there isn't contention for engineering time that there isn't kind of like all these different sources of requests that you have to wrestle with you know and David did such an extraordinary job of I mean the more I see the world the more I'm amazed at how every six weeks there was clear runway in engineering of like we have time for whatever. The whatever we'd agree together is the most important thing just blank check like six weeks at a time you know that'll blank check but you know what I mean like a blank six weeks yeah again and again and again years without end you know keeping that engineering capacity focused on readiness for product you know and and totally leaning into like what's exciting to do to build for the product and not getting lost in all this refactoring and new infrastructure and technical dad and stuff like that.

当然，从工程方面来看，想象一下，如果公司没有销售团队，也没有市场营销部门，所有的销售和营销工作都是由创始人的“独角兽”团队完成的。这意味着没有工程时间的争夺，没有各种层出不穷的请求需要处理。David 在这方面做得非常出色。随着我对世界了解的加深，我越来越感叹于每六周工程团队都会有明确的时间安排：我们有时间专注于我们共同认为最重要的事情。这就像每六周一次的空白支票，让工程团队反复聚焦于产品准备，享受构建产品的乐趣，而不是迷失在重构、新基础设施或技术债务当中。这样年复一年地保持工程能力的专注。

I mean that's those are amazing so those are some really big differences and it doesn't mean that you have to be based camp to do shape up but what it does mean is that when we say oh just have a shaping session and if you have the pressure of the time box then you can make trade-offs together it's like well if we are used to having a big wall between for example engineering and design then we're going to have to learn somebody who wants to start shaping is going to have to learn like well oh I need to figure out kind of who to bring together and how to have that session and how do we interact with each other so that we are combining all of that knowledge that maybe at base camp was all in the same head in a lot of cases.

我觉得这很惊人，这些差异很大。不过，这并不意味着你必须在 Basecamp 工作才能使用 Shape Up 方法，但它意味着当我们说“哦，只要进行一个塑造（shaping）会议”时，如果你面临时间限制的压力，那么你就可以一起做出权衡。比如说，如果我们过去在工程和设计之间有一道很大的隔阂，那么想要开始塑造的人就需要学习如何召集合适的人，如何进行这个会议，以及如何互动，以便我们能够结合所有那些可能在 Basecamp 时集中在一起的知识。

This is such an important point for people to hear because there's so many people that come on podcasts like this and share here's here's how to do it based on their experience and there's so many just assumptions about their resources the people they hire the way to founders operate like no sales team I think that's like I don't even think about that yeah I imagine you never know such thing as a request from sales yeah no such thing as pressure of like we need this thing in order to upsell right or to close the steel never it sounds like you're kind of in this like base camp by the way it was like all 37 signals like it's interesting call a base camp not 37 signals.

这是一点非常重要的信息，人们需要意识到这一点，因为有很多人参加这样的播客节目，并根据他们的经验分享“这是这样做的方式”。但是其中有太多的假设，比如他们拥有的资源、他们雇用的人、创始人运营的方式，甚至像没有销售团队这样的事情。我觉得这简直不在我的考虑范围内。我想你永远不会知道销售部门会有什么样的请求，也不会有诸如“我们需要这个东西来增加销售”或者“为了完成这个交易，我们需要这个”的压力。听起来你有点像是身处“基地营”，顺便提一下，它以前叫“37信号”，而不是“基地营”，这很有趣。

Yeah I mean so it's just like the timing of when I left you know we were originally 37 signals and then base camp became so big that we renamed ourselves to base camp I didn't know that yeah and then so for example like on the book you know on the it's it says shape up and there's a base camp logo on the bottom not a 37 signals logo you know but then they since I went back so it's 37 signals again so I sometimes struggle with I don't know what to call it you know but it's both whatever whatever people can recognize it's the same you know it's the same powerhouse okay cool I'm glad I'm not the only one that's confused but 37 signals the train name great yeah yeah so you said that it kind of felt like you left and it was like this bubble you got out of what was was there like a moment where you're like you wrote this book everyone you're like hey this is how you should work and then you're like oh wait this doesn't actually work in real life for a lot of people is there a moment there.

嗯，我的意思是，我离开的时候正好赶上我们原来叫 37signals，但 Basecamp 变得非常受欢迎，以至于我们把公司名字改成了 Basecamp。我那时并不知道这个变化。比如说，像书籍封面上，下面印的是 Basecamp 的标志，而不是 37signals 的标志。不过后来他们又改回了 37signals，所以有时候我也不知道到底该叫什么，但无论叫什么，人们都能认出是同一家强大的公司。嗯，我很高兴我不是唯一感到困惑的人，37signals 是个很棒的名字。是的，是的，你说过这就好像你离开了一个泡泡，你突然从中跳出来。有没有过这样的时刻：当你写了一本书，告诉大家应该如何工作，然后又发现，哦，等一下，这种方法对很多人来说其实并不奏效，有过这样的时刻吗？

It wasn't that this doesn't work I was just in a like a foreign country you know it was like um we tried it and it didn't work you know one of the common things I would hear is um the projects kept running over you know we weren't finishing them at the end of the cycle they kept running over and running over and then I would be like huh so can you show me your shaping work and then they would show me a PRD and I'd be like like well that's not that doesn't look like what's in the book and then and then I would and again like can you show me your shaping work and they'd show me like a bunch of figma files you know and then and then what I started to understand was like we have some people in a role who were used to making a certain artifact of a certain step and they just kind of kept doing that you know and um I didn't appreciate it took me a while to realize like there's no engineer in the picture here.

这并不是完全行不通，而是我好像身处一个陌生的国家。我们尝试过，但没有奏效。我常听到的一种情况是，项目总是拖延，总是没能在周期结束时完成，一再推迟。我就想，能不能给我看看你们的规划工作呢？然后他们会给我看一个PRD（产品需求文档），我心想，这看起来和书上的不一样。于是我又问，能否再给我看看你们的规划工作？他们会展示一堆Figma文件。渐渐我开始明白，有些角色中的人习惯于完成某个步骤的某种成果物，他们就一味地这样做。然而，我却没有注意到，直到后来才意识到：这个过程中居然没有工程师的参与。

And uh and it was when we started to actually do the course as well I did actually a couple projects where I helped teams hands on and I learned that they they it was the first actually consulting project that is yet where I helped a team who was stuck and what we did was we we chose the engineer who was best suited to come over to product and be there in the shaping and that was the moment when it was like ah now I'm in the world I know again when we when we had all of that mixed in the same room again and so that was kind of like that was really something I mean it was a total learning curve for me you know.

我们开始实际开展课程时，我参与了一些项目，其中包括亲自帮助团队。我了解到，这是我第一次真正参与的咨询项目，帮助一个陷入困境的团队。我们选择了一位最适合调到产品部门的工程师，让他们参与到产品设计的过程中。这一刻让我感到豁然开朗，就像重新回到以前所有人都在同一房间一起工作的感觉。这次经历对我来说真的是一个巨大的学习曲线。

and there's a lot of things like that but that was for example a really big one that's like oh we have to get engineering in there you're the type of guest I most love having in this podcast because you basically work with many many companies study what's working what's not you're like in you're not like in the clouds pontificating about something you're like working with teams to make things better and then you take all of that learning put it into a book and share with us all and so the ROI is just incredible for us all because you've spent so much time doing this and you've actually done the work you're not just in theory about it so so this is amazing

翻译成中文，这段话可以表达为：有很多事情都是这样的，但这是一个非常重要的例子，比如说，我们需要让工程团队参与进来。你是我最喜欢邀请的嘉宾之一，因为你与许多公司合作，研究哪些方法奏效，哪些不奏效。你并不是在空中楼阁里空谈，而是真正与团队合作改进事情。然后，你把这些学习经验写成书，与我们分享。因此，对我们来说，这带来的回报是巨大的，因为你花了这么多时间实际去做这些事情，不仅仅停留在理论上。太好了！

uh but we're not done yet one question I wanted to ask is Jason was tweeting that there's he's working on a follow-up shape up book what's happening there you involved in that with the story so I also saw the tweet and I have to admit I was a little surprised when I saw this tweet you know but I had had a conversation with Jason a year earlier and he reached out and he said hey you know we're thinking about doing a second edition of the book and my first reaction I mean I was imagined I was actually really in the middle of learning you know all these things that teams need to learn in order to kind of catch up to what was natural for base camp to do and uh so for me it was like interesting I have a lot of new things I have a lot of new ideas maybe a second collaborating on the second edition could make sense.

嗯，但我们还没结束。我想问的问题是，Jason 发推说他正在制作《Shape Up》一书的后续版本，这是怎么回事？你参与其中的故事吗？我也看到了这条推文，说实话，我有点惊讶。但我之前一年和 Jason 谈过一次，他联系我时说：“嘿，我们在考虑出这本书的第二版。”我的第一反应，我是说想象一下，我当时正处于学习阶段，正在了解团队需要掌握的各种知识，以便赶上 Basecamp 自然做的那些事情。所以对我来说，这很有趣，因为我有很多新的想法，也许参与第二版的合作是有意义的。

but what I understood was that what he wanted to do was to kind of make an updated version of of how they work because that's always been kind of a big thing of how I have to show you the right name 37 signals of how they how they market and also how they lead is they like to really show a clear example not like this is how you could do it this is how some people do it but like this is how we do it and I think it's their strength is that they are very very clear like this is how we do it and kind of take it or leave it and what I understood was that if I did another version of the book that was just kind of how base camp does it I think it would leave so much opportunity on the table like there's so many people where what they need to learn is more like how can it come closer to where I am if I have the wall today between product and engineering how do I bring the right people together into a shaping session how do we actually do that how do I overcome all of these little challenges because this is so far from our current way of working you know.

根据我的理解，他想做的是更新他们工作的方式，因为这一直是个重要的事情，他们一直以展示明确的例子为傲。就像37signals的运作和领导方式，他们喜欢展示一个清晰的例子，而不是告诉你可以怎样做或别人是怎么做的，而是告诉你这是他们的做法，并且相信这就是他们的优势：非常明确地说“这就是我们如何做”的方式，你可以选择接受或不接受。如果我再写一本书，只讲Basecamp是如何运作的，我认为这会错失很多机会。因为有很多人需要学习的是如何让他们的做法更接近他们当前的实际情况，比如如果今天在产品和工程之间有障碍，我该如何把合适的人聚集在一起进行策划会议，我该如何实际操作，以及如何克服这些小挑战，因为这些与我们当前的工作方式相去甚远。

so the work that I'm doing with for example with shaping in real life is kind of all about those gaps and then I don't know what's going to be in the second edition you know because they are I guess someone there is going to be working on that but what I'm guessing is it's going to be an update on you know kind of up on top of the mountain over here this is this is what base camp is doing so hopefully it'll be kind of a cool thing to look at as like here's a model of what they're doing and then the question is what can I take from that and what do I need in order to actually be able to make it work in the real situation I'm in you know and that's kind of where well that's my focus

我在现实生活中进行塑造工作的主要目的是填补那些空白。我不确定第二版会包含什么内容，因为可能会有其他人负责这个部分。我猜测可能会是一些更新，比如帮大家更好地理解当前的情况，比如这是大本营正在做的事情。所以希望它会成为一个很酷的参考模型。关键问题在于，我能从中获取什么，以及在我实际面对的情况中，我需要哪些东西来让它奏效。这就是我关注的焦点。

this is so interesting thank you for sharing sounds like a fork fork he forked it and yeah and these go going potentially in different directions but inspired by each other um totally so interesting Ryan is there anything else that you want to share before we wrap up one thing I could throw out there is um sometimes people reach out to me because their projects aren't shipping there's a lot of straw gold there's a lot of lack of clarity but the root cause is actually that the input at the very beginning of the process is too unclear or you know like we we don't actually know what's important to customers or not actually sure where the value is or this kind of a thing you know so there is this link this framing step that we talked about of what is really the problem before we go into shaping this this is the link to product strategy also and this is the place where uh it can be really useful to reach for a lot of for example bob messed up stuff with the jobs to be done and the demand side work of trying to get clear about things so that's the tool that I reach for at that and you can think of kind of this you know before the problem definition there's this question of like what's the demand where are people struggling where is the really the the the place the itch they're trying to scratch you know

这太有趣了，谢谢你的分享。听起来像是一个分支，分支，他分叉开来了，是的，这些可能会朝不同的方向发展，但又彼此受到启发。真的非常有趣。Ryan，在我们结束之前，你还有什么想要分享的吗？我可以提到一个事情，有时候人们联系我，因为他们的项目没有进展，存在很多障碍，不够清晰。但其根本原因其实是流程一开始的输入不够明确，比如我们其实并不清楚客户的重要需求，或者不太确定价值所在等等。因此，我们谈到的这个需要框定问题的步骤非常关键，要先明确究竟是什么问题，然后再去构思方案。这也是产品策略的一部分。在这个阶段，诸如“完成工作的理论”（jobs to be done）和需求侧分析等工具极为有用，可以帮助我们弄清楚问题。因此，这是我经常使用的工具。在问题定义之前，我们需要先问：需求是什么？人们在哪些方面感到困扰？他们真正想要解决的痛点在哪里？

and then a lot of the shape up stuff is kind of when I have something where I think there's an opportunity or I think there's something meaningful there because of what we learned from customers or the job to be done research or whatever it was now how do I turn that into something that we can actually go do and ship in a reasonable amount of time that's kind of the supply side that's where the shape up part fits in so maybe it just might be cool for people to sort of seal link there that's a great plug for bob messed episode we talked in depth about the jobs to be done framework and had actually applied what's the book you'd recommend there sounds like basically it's like shape up plus uh this book gives you a lot actually the one that I recommend the most is a demand side sales 101 and it's funny because it's like sales you know especially for a product person like you're like I'm the product person not the salesperson but it's it's uh it's such a good dive into what are people really trying to solve and and getting into that mindset of what's the struggle what's the problem I think that's a really good entry point for that

当我认为有机会，或通过客户反馈、任务研究等了解到一些重要信息时，就会出现很多与“形塑”（Shape Up）有关的事情。这个过程是为了将这些信息转化为我们可以在合理时间内完成并发布的项目，这属于供应方的工作，“形塑”就在这里发挥作用。或许人们会觉得有必要看看相关内容，这也是对鲍勃·梅斯特（Bob Mesta）那期节目很好的推荐，我们深入讨论了“待完成任务”（Jobs to be Done）框架并实际应用了它。针对这方面你有什么书籍推荐吗？基本上类似于“形塑”加上一些东西。我最推荐的一本是《需求侧销售101》（Demand-Side Sales 101）。有趣的是，谈到销售时，尤其是对于产品经理来说，你可能会想“我是产品经理，不是销售人员”，但这本书深入探讨了人们真正想解决的问题和他们的思维方式，了解他们的困扰是什么，问题在哪里。我觉得这是一个很好的入门点。

yeah I don't love that title I feel like feel like you could have done better there with that book title because it's uh yeah you know what's what's interesting about it is that it's very very pointy for like if you are trying to make progress on sales then it's this other kind of sales this demand side sales you know so I think maybe it's more for us who are kind of using it for different purposes like where the product people trying to pull something out of it that it's a little bit less aligned but it's it's still useful yeah but basically it's like the the jobs to be done book yeah it's kind of like the jobs to be done book that's a bit more tactical you know if if if you're really curious about the general spirit of jobs to be done then competing against luck is a really good intro that's the one the Clayton Chris Clay Christianson wrote with a lot of uh I think I think I think I think there's a lot of stuff that Bob worked on that's in there but I but for a little bit more tactical like what's it look like to do the interview and how to think about the struggling moment and stuff like that this demand side sales is good for this strategy stuff awesome and we'll link to this episode where you could get the gist of it in one hour's time oh that's right you did that episode was great by the way that's yeah right thanks Ryan okay we did it this was amazing I think this is gonna help so many people we're not we're not done yet two final questions for you where can folks find the book find you if they want to work with you anything else that you want to share and how can listeners be useful to you

我不太喜欢那个书名，我觉得你应该可以想个更好的书名。因为那个名字有点尖锐，如果你想在销售上取得进展，它说的是另一种销售，就是需求侧销售。我觉得可能对于像我们这样的人，它的用途不同，可能跟我们产品人员想从中获得的东西有些不太一致，但仍然很有用。基本上，它就像《要完成的工作》那本书，不过更具战术性。如果你对《要完成的工作》这种理念感兴趣，《与运气竞争》是一个很好的入门，那本书是克莱顿·克里斯坦森写的，里面有很多博布的贡献。不过，如果你想要一些更实际的东西，比如如何进行访谈、如何思考困难时刻，那么《需求侧销售》在策略方面会很有帮助。太好了，我们会链接到这一集的节目，你可以在一个小时内了解个大概。是的，你做的那集节目真的很好，顺便说一下。好的，谢谢，瑞安。我们做到了，这真是太棒了，我觉得这能帮到很多人。我们还没结束，还有两个问题想问你，人们要在哪里买到这本书，如果他们想与你合作，要如何联系你，还有没有其他想要分享的？听众们可以怎么帮助你？

well they can find me at my website that's RyanSinger.co I'm also on on xrjs I'm on LinkedIn you know so just reach me there and uh how can people be useful to me I love hearing from people who are having these problems you know like if you're having these problems where it's like things are dragging or we can't see the end and we're not getting the quality we need and you know all this stuff like and this is I mean this is how I learned all this stuff is by talking to people who are in it you know so you know even if it's not clear what's the next step yet you know if that problem is real it would be cool to hear about it I'd love to chat be careful what you wish for about Meste was just on the podcast and he told me he's got over 100 LinkedIn DMs of people sharing their struggles with their job search so here you go.

你可以在我的网站找到我：RyanSinger.co。此外，我也在 XRJS 和 LinkedIn 上，你可以在那里联系我。至于大家怎么能帮到我呢？我很乐意听到那些遇到问题的人和我分享经验。比如说，如果你遇到拖延、看不到结果，或者没有达到预期质量等问题，这些都是我通过与有类似经历的人交流学到的。所以，即使下一步还不明确，如果这是真实的问题，我很愿意了解并聊天。不过要小心自己的期望，Meste 刚在播客上说他收到了超过 100 条 LinkedIn 私信，都是人们分享他们在求职过程中的困扰。

oh yeah my job moves that's a big one you know I think that's a broad appeal yeah that's true yeah I'm gonna ask you to explain that when you do consulting work just like how does that work who's that for just because you know that's something else you do so it basically starts with either often first cpo or cto often reaches out first you know and uh what I'm what when it works well is when we actually get them together you know and then they understand that they need to change something or we have like a head of product and a head of engineering that kind of a thing.

哦，是的，我的工作变动是个大事。你知道，我认为这具有广泛的吸引力，是的，这是真的。我想请你解释一下你在做咨询工作时是如何运作的，是为谁做的，因为你知道这也是你的一个工作。基本上，通常首先联系我的是首席产品官（CPO）或首席技术官（CTO）。当一切顺利时，就是我们能够让他们聚在一起。这时，他们会意识到需要做出一些改变，或者我们会有一个产品负责人和一个工程负责人这样的安排。

if those two are both seeing eye to eye that there's a problem then we can start a conversation around okay so who would be the right people for a pilot team what are the things that are going on business wise that could be a good pilot project and then I can kind of help to figure out like how do we actually so almost like guiding through like narrowing down that pilot project framing so that so that they have the support that it's going to be successful in shaping you know and then coaching the team so that they actually learn those shaping skills so that they can get through a session and come out with much more clarity like how do they actually run those sessions you know.

如果他们两人都同意存在一个问题，那么我们就可以开始讨论谁适合组成试点小组以及在业务方面有哪些项目可以成为好的试点项目。然后，我可以帮助他们确定如何具体开展这个过程，几乎就像指导他们如何缩小试点项目的范围并进行框架设定，以确保他们能够成功地塑造项目。从而在教练团队的过程中，让他们真正学会这些塑造技能，使他们能在一次会话中获得更多清晰的结果，以及如何实际运行这些会话。

so it's kind of first working with leadership who do we need to get to do this work who are the right people how do we bring them into a pilot project narrowing down doing some framing work on the pilot so it's going to be clearer in the shaping and then giving some guidance on how to get through that shaping with some feedback rounds this this is usually a good approach amazing and they can find us in your website if they want to explore this yes amazing Ryan thank you so much for being here yeah thanks a lot you had amazing questions you know it's a subject that can go in so many directions and you kept bringing us on to some kind of a main track so I'm really pleased it is really nice thanks a lot you're my best.

首先，与领导层合作，确定我们需要谁来完成这项工作；谁是合适的人选；我们如何把他们引入试点项目中。然后，在试点项目上做一些框架工作，使形态更清晰，并提供一些指导，帮助在塑形过程中进行反馈。这通常是一个不错的方法。非常棒，他们可以在我们的网站上找到更多信息，如果他们想深入探索这个项目的话。太棒了，Ryan，非常感谢你的到来。是的，非常感谢。你提出了很棒的问题，这个话题可以有很多方向，而你一直把我们带回主线，我很高兴，真的很好，谢谢，你是最棒的。

yeah thanks Ryan and bye everyone thank you so much for listening if you found this valuable you can subscribe to the show on ample podcasts Spotify or your favorite podcast app also please consider giving us a rating or a leaving review as that really helps other listeners find the podcast you can find all past episodes or learn more about the show at Lenny's podcast.com see you in the next episode.

好的，谢谢Ryan，再见，感谢大家的收听！如果你觉得这期节目有价值，可以在Apple Podcasts、Spotify或你的常用播客应用上订阅我们的节目。同时，请考虑给我们评分或留下评论，因为这能够帮助更多的听众找到这个播客。你可以在Lenny's podcast.com上找到所有的往期节目，或了解更多关于这个节目的信息。我们下期再见！

A better way to plan, build, and ship products | Ryan Singer (creator of “Shape Up&quot;)

摘要

中英文字稿

A better way to plan, build, and ship products | Ryan Singer (creator of “Shape Up")