极端版本原型法 · 操盘手年鉴

解决什么问题

"要有创造力""要跳出框架思考"这种建议说起来容易,大多数人真正卡住的地方是:能看清眼前的东西,但看不到两三步之外的可能性,面对无穷的可能性反而不知道该往哪个方向走。需要一套具体可执行的方法,而不是空泛地"多想想"。

核心内容

Nan Yu 描述的方法核心问题是:"沿着某个具体维度,你能把这个方案推到多极端?"——设计一个产品/方案时,主动问"这件事最离谱、最极端的版本会是什么样",并且刻意抛开成本、抛开实用性,因为这些都不是这一步要关心的东西。这一步真正的目的,是打破你脑子里那些自己都没意识到的隐性约束,重新打开被过早收窄的"可能性空间(possibility space)"。这与Brian Chesky在Airbnb提出的"11-star experience(十一星体验)"是同一类方法。

Yu强调这套方法真正的风险点在于:很多方案选择错误,不是因为在几个选项里选错了,而是压根没看到那个真正对的选项——它可能就藏在你从没看过的那个角落里。

具体操作流程,以Linear的"草稿保存"功能为例:

先做出一个维度上的极端版本并真实上线:"最快"版本——不打断用户,不弹确认框,关闭时直接丢弃或保存;上线后发现"感觉极其不安全",用户会觉得"我是不是不小心把修改弄丢了"。
再做出另一个维度上的极端版本并上线:"最安全"版本——从第一个字符开始就自动保存一切;上线后发现新问题——留下大量"未命名草稿"的杂乱痕迹(类似文档工具里一堆"Untitled Document")。
在两个极端之间找到真正的平衡点:最终方案是——新建issue时会打断确认(保证安全感),但已经存在的草稿继续编辑时则全自动保存(保证速度),这是一个"外人事后做拆解会觉得'他们做了非常精细的具体选择'"的方案,但抵达这个方案的路径,恰恰是先做两个完全相反的极端,再找到它们真正交汇的地方。

Yu 特别强调这些极端版本不是内部纸上谈兵,而是真实推给用户使用,收集真实反馈("是不是太不安全了""是不是产生了太多草稿"),这样才能获得可信的信号去定位真正的平衡点。

Yu 给出一个更通用的判断标准:面对不同产品/公司,该往哪个维度走极端,取决于**"你的产品/公司对用户的核心承诺是什么"**——比如"车永远随叫随到"这个承诺,可能导致你不得不做动态加价;而"价格永远可预测"这个承诺,则可能导致有时候没车可用。这些是你必须主动选择、并且认领后果的取舍,不存在两全其美。

适用边界

这套方法要求团队有能力和意愿真正把"明知不是最终答案"的极端版本推给真实用户,而不只是内部讨论,否则拿到的信号不够可信;
抛开成本和实用性只是"探索阶段"的临时策略,不代表最终方案可以忽视这些约束——最终版本仍然要回归可执行、可持续的现实。

关键引述 · 原话

"最好的解决方案事后看总是显而易见的,你只是需要在内部发展出一套流程,最终能带你走到那里。"——Nan Yu

— Nan Yu

关联卡片

与同源卡片"first-ten-percent-rule"(nan-yu)配套使用——极端版本本身就是"第一版不追求完美,只求能跑、能验证假设"这条原则的一种具体应用形式。