Shape Up：来自 Basecamp 的产品方法论

感谢产品沉思录读者 建松 Jason 的分享，《Shape Up》是 Ryan Singer 在 2019 年发布的一本书。他在 Basecamp 工作了 17 年，从 UI 设计到产品经理，再到战略主管，其设计的功能影响了数百万人，也间接影响了早期 SAAS 行业。

和 Basecamp 其他书一样，这本书大概两三个小时就能翻完，短小精悍，其 Shaping 的方法更适用于小型团队。

可点击文末「阅读原文」查看本书

我很喜欢 Shaping 这个概念，可以翻译为「塑造」，因为这代表了一个「持续」的过程，而非一次性精确地设计好。这本书让我收获最大的是他们把产品从设计到交付，拆成了两个不同的轨道，交由两个不同的团队完成：

•成型团队：用来把想法转化为更清晰的方案•构建团队：用来将成型团队的方案完成并上线

这种做法看似将流程变长，但是看完本书之后我觉得还是有其可取之处：

•想法总是脆弱的，如果没有一个团队来保护他将其完善，很容易陷入到只解决已知问题的局部优化中。•成型团队需要的是洞察力，构建团队需要的是执行力，许多人并不同时具备这两种能力。•团队越大，对执行力要求越高，而这群人在一起讨论新想法时，那些想法火苗很容易被扼杀。•给有洞察力的人松绑，允许有些项目搁置、放弃，而不用总是在乎执行力。

在我之前带的团队中，就很容易形成大家太专注于达成短期目标，而对新想法意兴阑珊。而在在创业的这一年多中，我也频繁遇到在两种模式之间切换的消耗 —— 更准确地说是没意识到在切换。

那么如何 Shaping 呢？书中提到了四个方面，鉴于大家的情景不同，我摘选了其中对我有启发的方面。

设定边界，定义清楚问题

• 搞清楚在解决什么需求
  

我们很容会为一个漂亮的解决方案或一个大的愿景激动，比如在设计 flomo 之初我就曾为「用涌现的思路帮用户发现自己笔记背后的关系」而激动不已，但事实上却并未明确「用户遇到了什么问题」，导致上线一年后因 ROI 过低而下线。

同样在丁香医生时，也有一阵对于「年卡」这种模式很感兴趣，但并未思考适合什么科室，匆匆上线医生年卡功能，却发现除了头部医生根本销售不出去。

所以一定要小心，不要上来就讨论方案，而是要先确认：我们到底在解决什么需求。

• 定义好资源范围

之前大团队时，产品和开发是按照需求来交付的，即根据功能来评估时间，这样的问题就是许多时候层层加码，从产品到交互再到 UI，技术再加上一些重构工作，最终导致开发周期越拖越长，而最终上线了却发现许多设计并未达到预期。而本书中的模式则是，按照「六周」为一个单位，如果想法太大无法放在这个周期内完成设计，那么就需要将想法进一步拆分。

• 定义清楚问题边界

通过约束资源来约束问题的范围，就能让解决方案更加锋利。因为「好」是和约束条件有关，如果没有边界则会成为资源黑洞。而对于小团队来说「又不是不能用」的哲学能让产品快速获得反馈，继而进行关键路径迭代。

另外讲清楚哪些问题不解决也很关键，比如 flomo 的时候其实对于提醒、表格等需求也曾心痒痒，但一旦确定了 flomo 不解决这些问题，反而效率极大地提高了。

• 识别风险和兔子洞

风险不仅仅是没有满足用户需求，还包括法律风险，运营风险，新技术应用风险等，要小心给协作的上下游挖坑。

而兔子洞则是那种 ROI 很低的事情，典型如边研究新的技术方案边做新需求，或者视觉交互设计对于小地方不断地雕花。还有一种兔子洞是上面提到的「边界不清晰」，PM 总是不断添加需求。我的解决方法是：遇事不决，砍掉解决 —— 一旦决定开始设计，默认砍掉旁支需求而非添加。

多讲一句波普尔的「否定法哲学」 —— 否定比肯定有更强的确定性。

否定法的有效性有一个前提条件，就是答案最好是有限的集合。否则，无限否定下去就没有意义了。否定看似比较繁琐，但常常是找到答案最快的路径。

每一次否定，就缩小了范围，增加了找到的可能性。

References

[1] shape up 英文原文：http://basecamp.com/shapeup

[2] shape up 中文翻译（一共14章，可关注译者公众号查看）

[3] Ryan Singer个人主页：https://feltpresence.com/

[4] 寻家宝：如何找到10亿美金

[5] 说不的力量：https://www.notion.so/e9c3e2ad572842e39e48ddbfab3c8dbb