阅读视图

发现新文章,点击刷新页面。
🔲 ☆

Things I Know in 2025

2024 年,我没有写 Things I Know in 2024。现在回头看,我几乎想不起那一年具体做了什么,也说不清自己到底学到了什么。但事情并非没有进展。我的信条依然是 Stay Hungry, Stay Foolish,依然在 keep looking, don’t settle.

If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it. And, like any great relationship, it just gets better and better as the years roll on. So keep looking until you find it. Don’t settle.
如果你还没找到这些事,继续找,别停顿。尽你全心全力,你知道你一定会找到。而且,如同任何伟大的关系,事情只会随着时间愈来愈好。所以,在你找到之前,继续找,别停顿。

只是那种寻找,更像是在迷雾中前行,知道自己在走,却不知道在走向哪里。不确定性、黑天鹅、反脆弱、认知偏见……这些词构成了 2024 年的主线。它们让我意识到世界并不稳定、理性并不可靠、判断经常出错。但是关于如何在这种不确定中生存,我并没有答案,我模糊的知道,不要给自己设限,兵来将挡,水来土掩似乎是当时的方案。

有一个哲学问题一直让我印象很深:

如果从果园的一端走到另一端,只能走一次,那么你如何摘到果园里最大的苹果?

你是早早下手,避免错过?还是一路观望,希望前面还有更大的?又或者,你在犹豫中走到了终点,却发现已经失去了选择的机会?这里的问题其实是,「寻找」并不是坏事,Dont’ Settle 也不是坏事,问题在于你要「寻找」到什么时候?Don’t Settle 到什么时候?如果你的人生过半,依然没有找到合适的方向,应该怎么办?如果已经过去了 80% 呢?我当然也没有答案。也许是永远,也许是人生的前三分之一,也许根本不存在一个明确的摘苹果的时刻。

但 2025 年,我开始隐约感觉到一些变化。我开始更清楚,我在用什么方式寻找,又为什么要寻找。

Look Back

Look back 无形中开启 2025 年的主题。有意思的是,2025 年我看的第一部电影也恰好是 《Look Back》。电影讲的是一段友情,一个并不完美、甚至可以说相当悲伤的结局。如果当初没有这样选择,会不会有一个不同的结局?如果再早一点意识到某些事情,故事是否会变得更好,甚至更完美?

我们太习惯用结局来否定过程。一旦结果不理想,过去的一切努力、情感、选择,仿佛都变成了错误的铺垫。于是「Look Back」成了一种惩罚,而不是理解。这种对未知和对不确定性的恐惧,恰恰是很多时候我们逃避一件事情的原因,但逃避本身也是一种选择。

我一直以为我所寻找的东西在未来的某个时刻会逐渐清晰。但当我回头看时才发现,有时候这种信号不见的那么的「清晰」,它可能不是那种你看一眼就能决定的「这就是我想要的」,而是一直都默默的驻在自己的脑海中,只是一直未被察觉。

很多年前,我很喜欢一个社交应用 Path。一个私密的社交网络,只和你真正熟悉的人分享生活:电影、音乐、位置、一些很日常。我一直用到 Path 关停。Path 消失之后,我一直在寻找一个替代品,然而资本并不青睐这样的产品,自 Path 之后再也没有人做这样的产品。「也许我可以自己做一个 Path」这个念头总是在不经意间出现在我的脑海中,然后被现实压回去,我不懂开发 iOS App,于是它就一直停留在想法阶段。

但 Swift 能有多难?在 Vibe Coding 成熟之前我便开始尝试过用 SwiftUI 和 UIKit 来做一些小工具,确实需要花费不少精力去学习和了解 Apple 生态的知识。有了这些基础,再加上有朋友和 AI 的帮助,App 的本地版在上半年做完,下半年则是在接入服务端,但其实几乎重写了整个 App。到目前为止,核心功能基本完成了,也算是达成了刚好能用的状态。我也和几个朋友开始日常使用,它还很早期,也很不完美,但我也不着急上架 App Store,它还远远没有成为我期望的样子。

我将其命名为「Dot」,正如这个 Blog 的副标题「Eventually everything connects - people, ideas, objects.」。Dot 就是那些需要被连起来的点,也是生活中的点滴。这个名字的灵感最初来自 Carl Sagan 的《Pale Blue Dot》,1990 年 2 月 14 日,NASA 的 Voyager 1 探测器在离地球约 60 亿公里的地方对着地球的方向拍了一张照片。在这张照片中,地球也不过是一个像素点。Carl Sagan 写到:

Our posturings, our imagined self-importance, the delusion that we have some privileged position in the Universe, are challenged by this point of pale light.
我们的自负、幻想的优越感,以及那种自以为是的幻觉,在这一点微光前显得如此可笑。

人们总是不可避免的质问一款新产品的商业模式,我不能像 DHH 那样通过银行存款的逗号来回答,但这点成本我还负担得起。这将会是一个付费的 app,我也无所谓最终有没有人会付费,哪怕最终只是和几个好友在用,也足够了。我并不确定是否还有很多人像我一样,怀念 Path,怀念那种小圈子、低噪音的社交方式。如果你恰好也是其中之一,不怕麻烦的话,也欢迎这里申请加入 Alpha 测试

Settle Down

Jerry Seinfeld 有个段子是说小孩子总是说 Up 而大人总是说 Down,Settle Down 大概也只会出现在成年人的世界里吧。我说的 Settle Down 并不是接受这样的现实,而是确定了一个方向,然后沿着这个方向继续前行,相比过去的随机游走,也算是某种意义上的 Settle Down。

过去,我一直是一个不太确定的人,总是被各种新鲜事物所吸引。无论是书籍、电影、科技还是趋势,我总是在寻找,总觉得真正想要的东西可能还没出现,答案可能在下一个转角。然而当我真正开始动手做 Dot 的时候,我发现这种寻找其实并没有让我真正感到满足。相反,让我真正获得满足的,是每一天投入在创造中的时间。和朋友讨论如何实现某个功能,反复推敲一段交互逻辑,甚至半夜醒来突然想到一个可能的方案,这种投入其中的状态,让我感到自己脚踏实地,真正连接到某种确定的东西上。

这种感觉是在某天看王家卫的《堕落天使》的时候突然意识到的。某种意义上,这是一部相当无聊的电影,我完全不记得自己曾经看过这部电影。电影中几个看似独立却又隐约相关的故事线,每个角色都像被困在自己的过去里,努力尝试改变,却又一次次回到原点,回到熟悉的确定性里。改变像是一种姿态,而不是一次真正的选择。这让我意识到,真正困难的,从来不是「要不要改变」,而是是否愿意为某个选择放弃其他可能性。

这让我想起一个网络梗:

小孩子才做选择,成年人我全都要。

在物质世界里,这句话或许成立。资源、金钱、机会,在某些阶段确实可以通过积累来「同时拥有」。时间、精力、注意力,这些东西本质上是排他的。你选择投入到一件事情上,就意味着放弃无数其他可能性。

成年人之所以是成年人,并不是因为拥有得更多,而是因为学会了如何做选择,也学会了如何放弃。选择意味着接受,接受事情可能不会如愿发展,接受自己无法同时走完所有道路,接受有些可能性会永远消失。

Thinking in Bets

过去,我不喜欢每周每月的回顾自己做过的事情。我尝试过,但经常不知道应该如何回顾,以及回顾什么?因为事已至此,我习惯的想法是去思考接下来应该怎么做。在我看来,一件事情无非两种结果,要么成功,要么失败。成功,意味着我们做对了,那么就继续下去,失败,则意味着做错了,那么改过重来。

但问题在于,结果从来不是纯粹由决策决定的。结果是决策、运气、时机、环境、他人行为等多种变量的叠加产物。我们却习惯性地把这些复杂因素压缩成一个简单的因果关系:结果不好 → 决策不好。

当我们站在现在的时间点去回顾过去的时候,总会带着一种「事后诸葛亮」的偏见,如果当初怎样怎样,现在就会怎样怎样。同时我们也会不自觉地为自己辩护:成功时,把它归因于能力;失败时,把它归因于运气。另一方面,我们又会对过去的自己变得异常苛刻: 站在结果已知的视角,去批评当时的信息不足、判断失误,仿佛一切早就应该显而易见。但这其实是一种错觉。我们用现在的确定性,去审判过去的不确定性。

在这种框架下,回顾不再是学习,而更像是一种情绪化的复盘:要么自我安慰,要么自我指责,却很难真正提高下一次决策的质量。直到我读到《Thinking in Bets》,我才第一次真正意识到,要把「决策质量」和「结果好坏」拆开来看。

Annie Duke 的核心观点其实非常简单,人生中的很多决策,更像是在下注,而不是在解一道确定有解的题。一手好牌,也可能输;一手烂牌,也可能赢。真正值得评估的,不是输赢本身,而是,在当时的信息条件下,这是不是一手值得下注的牌。

在之前关于《思考,快与慢》的文章里提到过「认知资源」,它就像决策所需的燃料,认知资源越充足,我们越有能力放慢节奏,考虑更多变量,做出更深入的判断。但关于什么才算真正意义上的「高质量决策」,我还没有答案,《Thinking in Bets》我还没读完,也不确定是否能从中找到答案,不过,这个问题留给 2026 年的自己来回答吧。

The Future Is Fragile, Handle with Care

写到这里,我不禁想起米兰·昆德拉在《不能承受的生命之轻》中的一句话:

要逃避痛苦,最常见的,就是躲进未来。在时间的轨道上,人们想象有一条线,超脱了这条线,当前的痛苦便不复存在。

于是在 2025 年的最后一天,在飞往成都的飞机上,我重新翻开了这本书。巧的是,在飞机起飞前,New Yorker 推送的一篇文章《The Art of Decision-Making》,仿佛这一年注定要以「选择」这个主题来结束。

以色列哲学家 Edna Ullmann-Margalit 将选择分成两种:一种是最大化我们价值观的选择;另一种,则能够改变我们价值观本身。前者就像决定买一辆丰田还是一辆斯巴鲁,这种选择不会改变你的价值观,也不会改变你将成为怎样的人。后者则不同,它会重塑我们的生活经历、社交结构,甚至价值观。比如,选择理想但薪水较低的工作,还是选择收入更高但内心未必认同的职业;比如,选择在哪座城市定居。

回头看自己的轨迹,毕业后去广州,从广州到深圳,并最终在深圳定居。现在回头去看,对当时的我来说,并不是什么重大抉择,更像是顺其自然发生的事情,仿佛不存在其他选项。但如果你问我:再来一次,你还会做出相同的选择吗?我不知道,我大概率还会选择同样的路径。不是因为我确信这是「正确」的人生,也不是因为其他选项的不确定性。而是,当我经历了这一切之后,我才发现,所谓的「换一种人生」不仅仅是重新选择那么简单,也意味着要放弃现在的一切,包括所有我遇见的人、所建立的连接以及构成「我」的这些点滴。换一种选择,就一定比现在好吗?

正如昆德拉所说:

人永远都无法知道自己该要什么,因为人只能活一次,既不能拿它跟前世相比,也不能在来生加以修正。没有任何方法可以检验哪种抉择是好的,因为不存在任何比较。一切都是马上经历,仅此一次,不能准备。好像一个演员没有排练就上了舞台。

我们无法同时活过两种人生,也无法把不同选择的结果放在一起比较。于是,「是否正确」这个问题,在人生尺度上,本身就是无解的。

哲学家 David Lewis 提出了「Vegemite Principle」的观点(Vegemite 是一种澳大利亚的酱料),其核心观点是:如果你从未亲身经历过某种体验,那么无论你读了多少与之相关的说明、听了多少人的描述,你都无法在事前知道那种体验对你来说是什么感觉。因此,这类体验相关的重大选择,不可能被完全理性化。

我个人最喜欢的一句话来自 列夫·托尔斯泰的《战争与和平》,也恰恰印证了这一点:

If we admit that human life can be ruled by reason, then the possibility of life is destroyed.
如果我们承认人类的生活可以完全由理性所统治,那么生命本身的可能性也将随之消失。

「The future is fragile, handle with care」,这句话成为我在 2025 年最后的提醒。未来是脆弱的,我们所做的每一个选择,都在不断地塑造它,也塑造着我们自己。


现在看来,「不确定性」变成了一种确定「确定」,我逐渐理解并接受了「选择」的不确定性与风险。所谓决策,真正考验我们的或许并不是找到绝对正确的答案,而是在不确定性中持续前进,并承担由此带来的后果。

关于如何做出「正确」的选择,我尚且没有答案,也不知道能否在 2026 年找到答案,又或许,这个问题本身就不需要答案。

请允许我继续使用米兰·昆德拉的句子来结束这篇文章吧。

在永恒轮回的世界里,一举一动都承受着不能承受的责任重负。这就是尼采说永恒轮回的想法是最沉重的负担的缘故吧。
如果永恒轮回是最沉重的负担,那么我们的生活,在这一背景下,却可在其整个的灿烂轻盈之中得以展现。
但是,重便真的残酷,而轻便真的美丽?
负担越重,我们的生命越贴近大地,它就越真切实在。
当负担完全缺失,人就会变得比空气还轻,就会飘起来,就会远离大地和地上的生命,人也就只是一个半真的存在,其运动也会变得自由而没有意义。 那么,到底选择什么?是重还是轻?
🔲 ⭐

思考,快与慢

T L;DR

思考,快与慢

我们的大脑拥有两种不同的思考模式,这两种模式并不是大脑中的两个物理区域,而是从模式上进行的区分,作者称之为系统 1 和系统 2:

  1. 系统 1 快速、直觉,擅长处理日常琐事,但容易受到偏见影响;
  2. 系统 2 缓慢、理性,能够帮助我们做出深思熟虑的决策,但它的运行消耗大量的认知资源。

因为资源有限导致系统 2 的懒惰,因此我们需要合理分配认知资源,减少系统 2 的无效消耗,并通过习惯养成、环境布置和采纳外部建议,帮助自己在关键时刻做出更清晰、更理性的判断。


《思考,快与慢》这本书我看了很多次,但都没有看完,最初看了大概之后了解了系统 1 和系统 2,但一直不明白这有什么用。后来 AI 爆发,出现了基础模型以及推理模型,然后忽然明白,这不就是系统 1 和系统 2 么。于是又拿起这本书重新拜读起来,这次总算读完了。

系统 1 和系统 2 实际上从底层解释了我们如何思考、如何做决策,从早晨穿哪件衣服,到职业生涯中的关键选择,都离不开这两个系统。大多数人认为自己是理性的、善于分析的,然而事实上,我们日常的很多选择都是系统 1 无意识驱动的结果。

有一次晚上跟朋友玩德州,因为已经很晚了,我的系统 2 已经罢工。当时牌面看起来像顺子,我的牌也确实有可能组成顺子,结果最后一张牌开出来都没有成顺子 。但从对方的行为已经可以断定他手里有顺子,于是我就直接弃牌了。对方果然是顺子,然而弃牌后我发现,我虽然是没能成顺子,但我是同花啊。如果当时系统 2 还能正常运行一下,可能就不会错失这一手了。

认为我的牌可以组成顺子这个想法一开始就占据了思维,从忘记了其实还可以组成同花的想法,其实就是由认知偏误导致的。认知偏误又是有系统 1 导致的。系统 1 的判断虽然快速,但它经常会出错,尤其是在环境复杂或自己精力不济的时候。而系统 2,虽然可以纠正错误、做出更理性的判断,但它非常「懒」,更容易在我们精疲力尽时自动下线。

正是这种认知的盲区导致了决策失误,让我们可能在错误的事情上消耗了太多的认知资源,或者因为信息过载而错失了真正重要的机会。更糟糕的是,当环境变得复杂、压力变大时,我们的情绪、记忆和外界环境会进一步干扰理性决策。因此,理解这两套认知系统的运作方式,不仅能够帮助我们清晰地认识到自身思维的局限性,更能掌握具体的方法去优化和改善决策流程。

系统 1 和系统 2

  • 系统 1:速度快、能耗低、依赖模式匹配和直觉,适合快速决策,但容易受到偏见影响,无法进行深度推理。
  • 系统 2:速度慢、消耗大量注意力,擅长复杂推理和分析,可以处理新情况,但运行成本高。

系统 1 主要处理快速反应和熟练任务,例如: 走路、开车、识别人脸、阅读简单文字、做基本的加减法、躲避障碍物。系统 2 主要处理深度思考和新问题,例如: 逻辑推理、复杂数学计算、权衡利弊、长期规划、学习新知识。现实中,两者并不是独立运行,而是相互协作的。系统1 负责日常自动化操作,而系统2 在需要更高精度决策时介入。

既然系统 1 速度快并且几乎不消耗能量,那么自然把经常做的事情交给系统 1 就是最好的选择。这自然也是需要付出成本的:

  1. 训练系统 1 需要的花费大量的精力;
  2. 系统 1 虽然速度快,但是无法进行复杂的推理;

训练系统 1:学习

当你对执行一个任务越来越熟练时,需要付出的努力程度就会降低。对大脑的各项研究证明,与行动相关的活动模式会随着熟练程度的加强而变化,一些大脑区域将不再参与其中。

训练系统 1 的过程实际上就是我们所说的学习。人类学习一项新知识的过程,本质上是大脑内神经元之间建立新连接的过程。我们的大脑由数十亿个神经元(Neuron)组成,每个神经元之间的连接部位被称为突触(Synapse)。神经元通过它的轴突(Axon)向其他神经元传递电信号(动作电位)。当我们学习某项技能时,相关的神经元之间会通过突触建立更强、更有效的连接。1在我们真正的学会之前,我们需要用系统2 主动思考才能完成任务,但经过足够的练习,这些任务逐渐被系统 1 自动化处理,因为神经通路已经被高度优化了。

这并不是一个简单的过程,马尔科姆·格拉德威尔在 2008 年出版的畅销书《异类》中提出了 10,000 小时法则 。格拉德威尔引用 K·安德斯·埃里克森的研究解释说,在任何领域达到世界一流水平的关键在于练习一项特定的任务至少 10,000 小时 。虽然有研究指出 10,000 小时并不严谨,但从新手到大师不可避免的需要大量的训练。

系统 1 的学习过程其实可以类比为一种贝叶斯推断(Bayesian Inference)。在统计学中,贝叶斯推理是一种通过不断更新「先验知识」来调整对世界的认知的方法。而我们的系统 1,就是一个不自觉地在做贝叶斯更新的机器。每一次你做出一次判断、解决一次问题,系统 1 都会根据已有经验(先验概率) 和 新观察到的信息(似然性) 来调整自己的判断机制。这也是为什么我们训练得越多、经验越丰富,直觉就越准确 —— 因为系统 1 的「先验」变得更加贴近现实。

另外,随着年龄的增长,我们的「学习速度」也会下降,我们的学习速度实际上受到「神经可塑性」的影响。神经可塑性(Neuroplasticity)是大脑通过生长和重组来改变神经网络的能力 。这种变化包括形成新的神经元连接、皮质重映射等 。但随着年龄增长,这种神经可塑性会逐渐降低,因此成年人学习新技能时所需要的时间和精力要比儿童时期更多。2好消息是有研究表明,有规律的有氧运动可以改善大脑的神经可塑性。

我们不可能无限制地将所有技能和知识都训练成系统1的自动反应。另外,即便是系统 1 擅长的事情,我们也不能过分依赖于系统 1,因为系统 1 还存在另外一个问题,那就是「认知偏误」。

系统 1 的运行:启发法

我们前面提到,神经突触连接的强化为系统 1 的高效决策提供了「硬件基础」。但现实世界情况复杂多变,仅靠固定的神经模式显然不足以应对。系统 1 还需要另一种更灵活、更快速的「软件」,这就是启发法(Heuristic)。

人们依赖于数量有限的启发式原则,而这些原则能将测量概率以及预测价值的任务简化,使其成为更为简单的判断过程。

心理学家认为,启发法本质上是一种心理捷径(mental shortcut),可以在有限的时间和信息条件下快速做出决策。正如维基百科所定义:

启发法解释了在知识有限(资讯不完整)和时间有限的情况下,得出可能陈述或可行解决方案的艺术。 它描述了一种分析程序,在该程序中,在对系统了解有限的情况下,在推定结论的帮助下做出有关系统的陈述。 由此得出的结论往往偏离最优解。启发法的品质可以透过将其与最佳解决方案进行比较来确定。

换句话说,启发法牺牲了精确度和全面性,换来了决策的速度和认知资源的节省。作者在书中提到了几种常见的启发法:

  • 代表性启发(Representativeness Heuristic)
    当我们遇到一个新的事物 B 时,会下意识地将它与自己熟悉的事物 A 进行比较。如果发现两者十分相似,就认为它们有相同的特征,进而直接将对 A 的经验或知识套用到 B 上面。例如,我们看到一位穿白大褂的人会本能地觉得他可能是医生,而实际上可能不是。
  • 可得性启发(Availability Heuristic)
    如果某件事或信息更容易从大脑中调取出来,我们就会倾向于认为这件事更常见或者概率更高。比如新闻经常报道飞机失事的消息,因此很多人觉得坐飞机比开车更危险,而实际统计数据则完全相反。
  • 锚定启发(Anchoring Heuristic)
    在做决策时,我们倾向于受到最初信息(锚点)的强烈影响。例如,商品标价为 1000 元然后折扣到 500 元,顾客通常觉得非常划算,哪怕这件商品实际价值可能远低于500元。
  • 立体启发法(What You See Is All There Is, WYSIATI)
    人们做判断时,只会基于目前看到的信息作出决策,而不会主动去考虑还缺少哪些信息。也就是说,你看到的,就构成了你的全部判断依据。系统 1 不会主动怀疑信息的来源,也不会提醒你“还有什么是我没看到的”。
  • 情绪启发(Affect Heuristic)
    我们会用“好感”来快速决定一件事是好是坏,而不是去分析利弊。例如,如果你本能地喜欢某个人,可能会觉得他做事也更靠谱。这种启发可以让我们迅速下判断,但也可能让我们被情绪带节奏。

启发法的存在使得系统 1 能够极大地节省认知资源,快速做出决策。但这种快捷方式必然要付出代价——牺牲精确度,增加了我们在决策过程中产生认知偏误的可能性。

监督系统 1:系统 2

要避免系统 1 的偏见我们需要有意识地调用系统 2 来监督系统 1 的输出,以降低决策错误的风险。系统 2 负责检查系统 1 的直觉判断是否合理。

系统 2 的一大主要功能是监督和控制思想活动以及由系统1引导的各种行为,使得一些想法直接体现在行动上,或者抑制或改变其他想法。

举个实际的例子:在股票市场交易中,有一种投资策略叫做 Buy the dip(逢低买入),也就是说当股票价格下跌时买入优质股票。系统 1 在经过长期训练后,可能一看到股票下跌就产生了直觉性的买入信号,因为在过去这种策略曾经奏效过。然而,系统 1 只基于历史经验进行简单的模式匹配,并不考虑当前市场环境与以往的不同之处,比如市场中存在的系统性风险。

这时,系统 2 应该主动介入:

  • 为什么这支股票在下跌?
  • 现在是否存在系统性风险,比如宏观经济是否有重大变化?
  • 公司基本面或技术面是否已经发生了改变?

只有经过系统 2 的严格分析,确认当前的情况确实符合逢低买入的条件,才可以避免因为系统 1 的偏误而造成损失。然而,系统 2 本身也有明显的局限性,最大的局限就在于:

  • 系统 2 的运行成本非常高:系统 2 需要进行大量的信息搜集(财报、经济数据、政策环境等),并逐个进行理性分析。这不仅花费大量的时间,也会消耗极高的注意力(认知资源)。这自然不是系统 2 的问题,而是深入思考时我们需要大量的信息来辅助决策。
  • 系统 2 对认知资源的依赖,使它无法持续长时间高效运行,这就决定了我们无法对所有的决策都进行系统 2 的深度分析。

懒惰的系统 2

物理学中的最小作用量原理(Principle of Least Action)说的是光或物体总是沿着使作用量最小的路径前进,除非有额外的力作用在其上。同样,我们的思维也倾向于选择最省能量的路径,即系统 1 的直觉和启发式,而不是调用系统 2 进行深度思考。当认知资源不足时系统 2 甚至会直接认同系统 1 的结论。

系统 1是冲动、凭直觉的;而系统 2 则具备推理能力,它很谨慎,但对一些人而言,这个系统也是懒惰的。

系统 2 之所以「懒惰」,其实并不是缺陷,而是一种适应性的优势。人类早期所面对的环境是稳定的、重复的,很多决策场景都可以靠快速直觉(系统 1)来应对。大脑虽然只占身体 2% 的体重,却消耗了约 20% 的能量,而其中又以系统 2 的思考最为「烧脑」。为了节省能量来保障最基本的生存,系统 2 能不用就不用。

The metaphor of the cognitive miser assumes that the human mind is limited in time, knowledge, attention, and cognitive resources. Usually people do not think rationally or cautiously, but use cognitive shortcuts to make inferences and form judgments.2
认知吝啬者的隐喻假定人类的思维在时间、知识、注意力和认知资源方面是有限的。通常人们不会理性或谨慎地思考,而是使用认知捷径来进行推理和形成判断。

系统 2 的「烧脑」源于它运行过程中需要大量调动认知资源,并频繁占用工作记忆来进行深度思考。认知资源每天的总量是有限的,而工作记忆就像大脑的 CPU Cache —— 速度快,但容量极小。这两个条件的限制,是系统 2 无法被无限使用的根本原因。

认知资源

所谓认知资源(Cognitive Resources)是指人类在执行认知任务时所需的有限心理能量,包括注意力、工作记忆、自控力和思维能力。它决定了我们进行深度思考、抑制冲动和做出复杂决策的能力。

虽然系统 2 很懒惰,但是当然只要你愿意,你依然可以启动系统 2,但是要消耗一部分的认知资源来控制自己的思维。也就是你不仅要付出认知资源去思考问题,还要付出认知资源去控制自己的思维聚焦在需要解决的问题上。这种情况下人们在其他方面的思考就会降低。

在和朋友悠闲地散步时让他心算出“23×78”的结果,而且要立刻就算出来,这时他肯定会停下脚步来算。 对系统2有高需求的活动同样需要自我控制,而发挥自我控制力既有损耗又很枯燥。与认知负担不同,自我损耗至少会令人丧失一部分动力。在一项任务中控制自我后,在另一项任务中就感受不到自己在努力,但只要你真的想做,就一定能做到。

认知资源既像计算机内存(带宽有限),也像电池(能量有限)。在短时间内,它决定了我们能同时专注多少件事;在长时间内,它决定了我们一天能完成多少复杂任务。

刻意掌控意志和进行自我控制很辛苦。如果你必须强迫自己去做某件事,而此时这件事又面临一个新的挑战,你就会很不情愿或是根本无法进行自我控制。这种现象被命名为自我损耗(Ego Depletion)。 认知负担不是自我控制减弱的唯一因素。喝几杯酒,或者一夜没睡也会产生同样的结果。早起的人的自我控制力会在晚上受到影响,而夜猫子的自我控制能力则会在早晨受到影响。

心理学家米哈里·契克森米哈(Mihaly Csikszentmihalyi)提出过一种被称为「心流(Flow)」对状态。在这种状态下人们几乎不需要消耗自控力就可以专注在任务上,将所有的认知资源都应用在深度思考上。然后现实中大多时候我们很难进入心流,工作中经常需要与人沟通,或者被提及,经常需要在不同的工作流之间切换,这种切换便会打断原本的心流状态。

心流巧妙地区分了两种努力形式:对任务的关注和对注意力的严格控制。以每小时150英里的速度骑摩托车和在象棋大赛中角逐都需要付出努力,然而在心流状态下,集中注意力关注吸引人的事并不要求自我控制。因此,我们要将所有资源都用于手头上的任务才好。

工作记忆

工作记忆是一种记忆容量有限的认知系统,被用以暂时保存资讯。工作记忆对于推理以及指导决策和行为有重要影响。3

在 UX 设计中我们也经常提到「神奇的数字 7±2」理论,意思是说大多数人在一次只能保留大约 7 个(±2)信息块(chunks)在工作记忆中。例如,表单字段不超过 7 项;导航项尽量控制在 5–9 个之类。不过这一理论后来被 Nelson Cowan 修正,其实更准确的数字是 4±1 个 chunks

所谓信息块,可以是一个数字、一个单词,也可以是一个概念组合,例如一个电话号码可以被「打包」成一个信息块。这种容量限制意味着,一旦任务信息过多或过于复杂,工作记忆就会迅速被占满。

系统 2 的运行高度依赖工作记忆。当我们在做需要深度思考的任务时,比如写一篇文章、做数学题、做战略决策,系统 2 必须同时在工作记忆中「暂存」多个信息片段,同时进行比对、运算或推演。然而,当任务过于复杂,或信息超出工作记忆容量时,大脑的运行就会「卡顿」,系统 2 也会更容易出错、犯懒或放弃。

压力对工作记忆的影响

当我们处于压力状态时,大脑会分泌压力激素,比如皮质醇和去甲肾上腺素。这些激素会直接作用于大脑的前额叶皮层 ——也就是系统 2 主要运作的区域。结果就是,我们的大脑在压力下变得更难集中注意力,工作记忆的容量也会下降。有研究表明,人在压力环境下,工作记忆容量会下降 30% 以上。尤其是在面对复杂、结构不清晰或无反馈的任务时,这种影响更加明显。

这也解释了为什么在压力大的时候,我们总是容易出现「脑子一片空白」、「不知道从哪里开始」的感觉。这种情况下,系统 2 很容易崩溃,放弃思考,将决策交还给系统 1,变得冲动、短视,甚至陷入情绪化反应。

影响系统 2 的因素

认知资源和工作记忆从根本上会影响系统 2 的运行,除此之外,还有很多其他因素也会影响系统 2 的结果输出。我们可以从内外因素来看,内部因素主要是:记忆自我、情绪以及由系统 1 产生的认知偏误的影响;而外部因素则主要是信息输入和环境因素。

两个自我

体验自我(Experiencing Self)指的是当下的感受,比如此刻你是否感觉愉快或不适;而记忆自我(Remembering Self) 则是对过去经历的总结评价,比如回忆过去的一次旅行时,你总体上是觉得愉快还是糟糕。由于体验自我依赖「当前感受」,它可能导致我们做出短视决策,而记忆自我由于遵循峰终定律(Peak-End Rule),则可能让我们高估或低估某些经历,从而影响系统 2 在长远规划中的判断。换句话说,即使系统 2 在运行,它的输入信息仍然可能受到体验自我和记忆自我的扭曲。

大脑在做决定时,更倾向于参考记忆自我的评价,而非体验自我的实时感受。因此,当人们回顾过去时,更容易被一次经历中最强烈的片段和结尾时的情绪所影响,而忽略整体经历。

这意味着,我们的决策并非始终基于真实而全面的信息,反而可能依赖记忆中那些经过加工、甚至扭曲的信息片段。

情绪的影响

情绪的状态对系统 2 的表现也有重要的影响。当我们处于强烈的情绪波动(如愤怒、焦虑或兴奋)时,系统 2 很难保持冷静、客观地分析问题。

情绪反应的迅速性往往会激活系统 1,并暂时抑制系统 2 的理性运转。即使你知道理智决策的重要性,过于强烈的情绪也会让你本能地优先考虑短期满足或快速缓解情绪。

偏见的影响

前面我们提到系统 1 的运行主要是依赖于启发法,启发法虽快,但是会产生各种认知偏误。这些偏见也会渗透到系统 2 的决策过程中。尽管我们通常相信自己的理性能够修正直觉上的错误,但事实并非如此简单。尤其是在认知资源或工作记忆不足的时候,系统 2 会拒绝工作,直接认同系统 1 的结果,那么同样也会认同系统 1 的偏见。

作者在书中提到的几个主要的偏见。

  • 确认偏误
    确认偏误指的是人们倾向于寻找和记住那些支持自己观点的信息,而忽视甚至排斥与自身观点相冲突的信息。当系统 2 尝试理性分析某个问题时,这种偏误可能导致我们只关注那些“符合期待”的证据,忽略客观全面的信息,最终强化了原有的偏见。
  • 锚定效应
    锚定效应指的是人们在做决策时,过度依赖最初接触到的信息(锚点),即使这个信息可能与最终决策毫无关系。系统 2 虽然擅长分析与计算,但也容易受到初始信息的误导。
  • 框架效应
    框架效应描述的是同一信息在不同表达方式下,会导致人们做出不同的决策。系统 2 本应保持客观理性,但实际上,它很容易受到信息表述方式的干扰。
  • 禀赋效应
    禀赋效应是指人们对于自己已经拥有的东西,会赋予更高的价值,而对未拥有的东西则估值更低。当系统 2 在评估资产、投资或交易时,这种心理倾向会导致决策的不理性。
  • 层叠效应
    层叠效应指的是人们倾向于跟随他人的观点或行动,特别是当许多人表现出相同倾向时。这种效应可能导致系统 2 忽视独立的理性分析,而盲目追随多数。
  • 启动效应
    启动效应指的是某些前期接触到的信息或刺激,会无意识地影响我们随后的行为或决策。尽管系统 2 可能没有明确察觉,但这些无意识的影响仍会改变其分析和判断的方向。
  • 曝光效应
    曝光效应描述的是人们对熟悉的事物倾向于更积极的评价,仅仅是因为经常接触。这种偏好可能导致系统 2 过高估计熟悉选项的价值,忽略其他更优选项。
  • 光环效应
    光环效应指的是人们会因为某一突出优点而整体高估一个人的其他特质。例如,因为一个人外貌出众,可能系统 2 会下意识地认为此人在其他方面同样优秀,而忽略了客观事实。
  • 规划谬误
    规划谬误指的是人们倾向于过于乐观地估计任务完成所需的时间、资源或成本,而忽略历史经验或客观数据。要避免这种偏误,可以参考以往类似案例的数据,以获得更为准确的预测。

参考 List of cognitive biases,当中列出了更多的认知偏误。

信息输入

系统 2 的思考过程,简单可以理解为,收集信息、整理信息、然后分析并作出最终的决策。第一步所收集信息的质量和数量都会影响我们最终的分析决策。

但除了主动收集信息之外,我们每天都会被动接收大量信息,这使得系统 2 很难有效地分辨哪些是真正重要的,哪些是无用的噪音。更糟糕的是,大脑倾向于被即时满足感所吸引,例如刷手机和查看社交媒体上的信息流,这种即时满足感很容易转变成「信息成瘾」。

Passing a gas station, you see that prices are up, and within one second you’re thinking of your household budget, and other rising costs, then inflation, and politicians, and that person you know who voted for the bad politician instead of the good one, and so on.4
路过加油站时,你看到油价上涨,你会立刻想到家庭预算、其他不断上涨的成本、通货膨胀、政客,以及那个投票给坏政客的朋友,等等。

有研究表明接收新的信息也会促进多巴胺的产生5而产生信息成瘾性,我们在研究的过程中也可能会产生不断收集信息的冲动,担心自己会错过某些关键信息(FOMO 心态),FOMO 心态与信息成瘾会相互促进,是的有限的资源都被浪费在了收集过程中的对信息的处理。社交网络的成瘾性在于无限滚动设计与精确的算法,可以计算出用户最关心的东西,这东西与好奇心,好奇心会促进多巴胺的产生,于是让用户可以不停的继续刷新新的资讯。

你的思维关注什么,就会驱动你的行为。如果你每天都沉浸在社交媒体的争论中,你的现实世界也会充满焦虑和争吵;如果你每天都沉浸在创造性的思考中,你的生活会朝着更有生产力的方向发展。

系统 2 的认知资源是稀缺的,如果它被无关紧要的信息(如社交媒体上的政治争论)占据,就没有足够的能量处理更重要的决策。过载的信息摄入会让系统 1 过度活跃,我们会更加依赖启发法和情绪化决策,而不是系统 2 的深度思考。

环境影响

前面提到的框架效应反映的就是环境对我们决策的潜在影响。我们房间的布置、办公环境的布局,甚至日常用品的摆放方式,本质上都是默认的选项。这些看似简单的选项,实际上在潜移默化地引导和强化我们的行为。当一件事变得非常容易执行时,我们就更倾向于去做它。

外部环境对于我们的决策方式有着深远的影响。我们的大脑习惯于在熟悉的环境中采用固定的行为模式,这便是所谓的「习惯」。习惯形成的本质是环境提示(Cue)与随后的奖励(Reward)之间的反复联结,逐渐内化为自动化的系统 1 行为。

在外部环境没有明显变化的情况下,改变已固化的习惯非常困难,即使系统 2 理性地认识到了改变的必要性。

例如,如果你想要改变不健康的饮食习惯,仅凭借意志力和系统 2 的刻意决策往往收效甚微。更有效的策略是积极地改变外部环境,比如避免购买和储备零食,或是远离诱发不健康饮食的环境和场所,尽量减少习惯触发因素的存在。

优化决策系统

我们已经了解了影响系统 2 运作的种种因素。现在的问题是,如何在现实的约束下,尽可能提升我们的决策质量。前面我们提到过一些我们无法突破的限制:

  • 时间有限: 一天永远只有 24 小时。
  • 认知资源有限: 它像精力一样会被消耗,虽能恢复,但总量有限。过度使用会导致“决策疲劳”和判断力下降。
  • 系统 1 的容量与学习成本: 培养可靠的直觉(训练系统 1)需要大量时间、经验和高质量的反馈,并非一蹴而就。
  • 生理局限: 我们的学习能力和精力水平会随年龄和健康状态发生自然波动。

因此,优化决策并非追求“无限理性”,而是在这些限制条件下,进行聪明的资源管理,让宝贵的系统2发挥最大效用。

认知资源分配

把东西装进行李箱,是对资源管理问题的最好比喻。我们每个人都有一个时间箱,要在里面装上工作、休闲和与家人共度的时光。我们也都有一个金钱箱,要在里面装上住房、服饰和其他所有支出。资源的稀缺和富足,会改变我们装箱的方式。如果没有余闲存在,我们在装箱时就不得不进行权衡。可见,稀缺的本质就是没有余闲。6

当认知资源匮乏时(如同贫穷状态下对金钱的锱铢必较),我们的大脑会被眼前的“急事”或琐事占据,不断进行权衡,从而消耗大量带宽,无暇进行长远规划和深度思考。这会导致决策质量下降,甚至陷入恶性循环。

因此,优化决策的首要任务就是像管理稀缺资源一样管理我们的认知资源。

  1. 保障与恢复认知资源
  2. 在认知高峰期处理关键决策
  3. 减少非必要决策数量
  4. 保留认知冗余

保证认知资源充裕

  • 充足的睡眠是最基础也是最重要的认知资源恢复方式。长期睡眠不足会严重损害系统2的运作能力,导致注意力不集中、冲动控制力下降。
  • 规律作息与休息: 保持稳定的作息有助于调节生理节律。白天工作期间,短暂的休息(如番茄工作法的休息间隙)、冥想或正念练习,也能帮助恢复部分认知资源,缓解精神疲劳。
  • 健康生活方式: 均衡饮食、适度运动也被证明对大脑健康和认知功能有积极影响。

在认知高峰期处理关键决策

大多数人的认知资源和注意力高峰都集中在早晨。识别并利用好自己的精力高峰期,安排复杂决策、重要规划或创造性任务,能最大程度地发挥系统 2 的优势。相反,应避免在疲劳、饥饿或情绪不稳定时做重要决定。

我给自己定的投资规则是:“晚上不做投资决策”。虽然美股是在晚上开盘,但我会在早上规划好策略,晚上只是严格执行计划。当行情发生意外波动时,也不会在情绪激动时贸然做出新的决定,以免受情绪驱使而做出非理性决策。

减少非必要决策数量

每个决策都有重要性之分,有些决策不算重要,例如工作日的午饭吃什么,有些则很重要,例如女友生日的晚餐吃什么。我们要做的是把认知资源留给真正重要的事情,而将那些不重要、重复性的决策自动化或惯性化。

例如,工作日我会固定自带午餐。这些午餐并不追求美味,仅仅满足基本的能量需求即可。相反,周末或特殊场合的饮食决策则精心挑选,系统 2 资源在这些关键时刻发挥更大作用。许多知名人物(如乔布斯或扎克伯格)选择固定着装,正是通过减少无谓决策数量,释放更多认知资源投入重要事务。

保留冗余

留出一定的认知冗余,能帮助我们更有效地应对意外情况或突发任务。相反,认知资源长期处于超负荷状态不仅降低决策质量,还会导致分析瘫痪。

适当的「留白」还能促使大脑在无意识中整合信息,系统 1 在此过程中可能产生意外的洞察力与创造力。如果大脑始终处于超载状态,这种宝贵的机会就会被扼杀掉。分析瘫痪,也会影响我们在应付突发情况时的反应能力。

优化工作记忆

我们通常会分几个简单的步骤来执行任务,以避免大脑超负荷运行。这样的话,我们可以将中间结果储存在长期记忆中或是记在纸上,而不是简单地堆积在工作记忆中。

优化工作记忆的关键策略之一就是将信息从大脑中释放出来,这被称为「信息外部化」(externalization)。例如,使用白板、便签、脑图工具等来梳理思路;将复杂问题拆解为可管理的小任务;记录中间结果,避免反复回想;

满意原则

在决策优化的过程中,我们常常会陷入一个误区,以为这个世界上存在一个所谓「最优解」。虽然有些简单问题确实有,但大多数的实际问题并没有所谓的最优解。即使在数学上的「最优化问题」也并不总是存在最优解,因为现实的信息不完全且经常模糊、计算资源和决策时间又十分有限。

诺贝尔经济学奖得主 Herbert Simon 提出的满意原则(Satisficing):

现实中的人类不是「最优化者(Optimizer)」,而是「满意者(Satisficer)」——我们不会寻找最优解,而是找到一个「够好」的解。

正是《思考,快与慢》这本书的核心逻辑之一——大脑不是用来求解数学上的最优问题的,而是用来在有限时间和资源下,找到“足够好”的答案。

习惯养成

减少系统 2 决策负担的有效方法之一,是将重复性、不重要的决策交给系统 1 去自动化处理,这就是我们所说的「习惯养成」。

麻省理工学院的研究人员在每种习惯中发现了一种简单的神经逻辑回路,这种回路包含三部分:暗示、惯常行为和奖赏。8

真正驱动习惯回路运转的是对奖赏的渴望。当我们觉得一件事情有价值,但不想消耗系统 2 去执行的时候,就可以训练系统 1(开始的时候需要系统 2 强行介入),让它在未来自动完成这件事,减少自身负担。

过去几年我坚持每周至少健身 3 次。我会在日历上先 block 自己的时间,到点就去。最开始的时候可能会逃课,后来发现只要到了健身房,懒惰的想法就会降低,撸铁的动力就会增加一点。于是后面就是先让自己去健身房,去之前先说好,只做一组就行。我并没有遵守「提示(Cue)→ 惯常行为(Routine)→ 奖赏(Reward)」这样的路径,而是只有前两步「提示 → 行动」,并没有奖赏,完成训练后的那种「自律的成就感」也是一种奖赏吧。

前面我们也提到过框架效应以及环境对决策的影响,习惯养成最有效的方法就让环境来强化自己的行为。去掉那些会干扰自己的事物,让整个生活都围绕你想要的好习惯来设计。也许有人会说「这么活着不会很累吗?」,我觉得恰恰相反。虽然可能看似缺少一些生活中的小乐趣——比如每天吃同样的食物、做同样的运动、穿相同的衣服,但正如我们前面提到的,「稀缺」才是真正重要的。减少了每日的微小「乐趣」之后,之后的每一次大餐才会显得印象深刻,个人也会变得更容易满足。如果每天都充满了「刺激」,那么「刺激」本身就会变得平庸,人会变得更难满足,更难体验到生活中微不足道的乐趣。

习惯本身是中立的,好习惯可以被强化,坏习惯同样也是。习惯可以帮你坚持运动、早睡早起,它同样也会帮你建立起下班就点外卖、早起先刷短视频这样的“坏习惯”。所以,我们真正要做的,是利用系统 2 的清醒时刻,有意识地设计好自己的环境与习惯系统,让自己的未来尽可能少走弯路。

采纳外部建议

A remarkable aspect of your mental life is that you are rarely stumped … The normal state of your mind is that you have intuitive feelings and opinions about almost everything that comes your way. You like or dislike people long before you know much about them; you trust or distrust strangers without knowing why; you feel that an enterprise is bound to succeed without analyzing it.

内部视角是通过关注特定任务和手边的信息来考虑问题,并基于这组狭窄独特的输入(可能包含轶事证据和错误认知)进行预测。这是大多数人进行规划时的常用方法。

人们倾向于内部视角主要有几个原因:天性乐观、乐观主义错觉(认为自己的未来比他人更光明)以及控制错觉(认为自己能控制偶然事件)。此外,自我意识(Ego)也扮演了重要角色,人们倾向于认为自己与众不同且更优秀,因此相信「这次不一样」。有趣的是,人们在评估他人情况时,反而更擅长运用外部视角。

在与内部意见的竞争中,外部意见丝毫没有取胜的机会…偏向内部意见常带有道德的意味。

卡尼曼提出了一个有效的方法——参考类别法(Reference Class Forecasting)。不要只盯着自己独特的计划和能力,而是要查看同类型任务在现实中的平均结果。在做投资决策时,不仅考虑自己对市场的判断,还要参考市场历史上的平均收益与风险。

引入外部数据、他人经验、集体智慧,可以帮助我们矫正自身的认知偏见,尤其是系统 2 的过度自信与过度理性。

理性不等于正确

更进一步,我们还需要保持对系统 2 自身的警觉。很多人以为只要启动系统 2 就等于理性决策,实际上,系统 2 也有自己的缺陷。正如我们之前提到的斯坦诺维奇的观点:理性与智力并不等同。一个人在逻辑推理上能力很强,并不意味着他在现实生活中的决策就没有偏见和错误。系统 2 的过度自信、选择性接收信息、确认偏误,都可能让人陷入“自以为理性”的陷阱。

使用分析框架

上面提到的优化策略主要聚焦在「硬件」层面 —— 认知资源、工作记忆、自控力本身的限制。但在此基础上,我们还需要借助更好的「软件」——也就是分析框架,来提升系统 2 的决策质量。

分析框架指的是一套用来理解问题、拆解问题并制定应对策略的思维工具。比如: 结合跨学科的知识准备和通用的思维框架能显著提高决策能力。这些框架帮助从不同角度审视问题:

  • 逆向思维 (Inversion): 从反面或目标倒推来思考问题。
  • 二阶思维 (Second-Order Thinking): 考虑决策的后续影响,不断追问「然后呢?」。
  • 地图并非疆域 (The Map Is Not the Territory): 认识到模型或地图只是现实的简化,并非现实本身。

更多决策模型和心理模型可以参考 fs 的这篇文章:Mental Models: The Best Way to Make Intelligent Decisions

———

无论是通过习惯养成减轻系统 2 的负担,还是通过外部建议与批判性思维提高系统 2 的决策质量,我们最终的目标都是一样的:让系统 2 的有限资源被用在真正重要的地方。

一个优秀的决策者,并不是永远理性的人,而是一个懂得什么时候自动化,什么时候反思的人。他知道如何借助系统 1 的力量,同时也知道如何校准系统 2 的判断,让两者协同发挥作用。


  1. Cognitive Miser
  2. What’s Taking Up Your Mental Bandwidth Right Now?
  3. How information is like snacks, money, and drugs—to your brain
  4. 稀缺
  5. 习惯的力量
  6. Working memory
🔲 ⭐

从 Scrum 到 Linear Method:重塑我们的开发流程

从 Scrum 到 Linear Method:重塑我们的开发流程

过去 5 年,我们团队一直都在使用 Jira 来实践 Scrum。Jira 的难用是众所周知的,但作为产品经理我也理解为什么 Jira 这么难用。2B 尤其是面向大型企业客户的产品,最终形态都是像 Jira 或者 Salesforce 那样。体验极差,但是灵活性非常高,面对大型客户,每家公司都有自己的工作流,这种定制的工作流本来就不够 SaaS,所以为了满足这种需求,产品只能做到非常灵活,一个极端就是直接提供 API,让客户自己随便玩。但是并非所有人都有了编程经验,于是不会编程的用户便想要一些简单的规则引擎,规则引擎本身是一个非常复杂的任务;但规则引擎并不难解决所有问题,总会有一些高级用户会提出来为什么不增加这样或那样的规则,甚至为什么不直接增加一个可以运行代码的节点。灵活性不是一个简单的问题。不过这是另一个话题了。

但对于我们团队来说,我们不需要非常灵活的东西,他会让事情变得复杂,我们只需要简单的看板,可以统计 Velocity,可以无限嵌套子任务的工具。某次网上冲浪期间发现了 Linear,但一开始并没有直接使用,我的第一印象是“这不就是一个速度更快、更简单的 Jira 吗”,并不觉得有什么颠覆性的东西。一年之后我又无意间读到了 Linear Method,然后才开始入坑,也才慢慢理解了 Linear 背后设计意图。Shape Up 也是同理,只是 Basecamp 的理念可能过于先进,我到现在也没有完全吃透。

在使用 Linear 的同时,我们结合 Linear MethodShape Up,对我们的开发流程进行了重塑,尝试解决我们在 Scrum 中遇到的问题。实践了快一年,并非所有的问题都得以解决,但我个人的感受是整体项目的交付速度提升至少有 20%。有必要总结一下我们这一年的经验。

在使用 Jira 和 Scrum 的时候,开发团队每 2 周进行一个 Sprint,每个 Sprint 的最后一天我们会做 Sprint Review 和 Retrospective 以及 Planning。Sprint Review 就是把团队的交付的内容和 Stakeholders 同步,通常我们会测试环境 Demo 即将上线的新功能。Demo 完成后 Stakeholders 会提出一些问题或者建议,随后是 Retro,主要是回顾团队协作的情况。紧跟着就是 Planning,产品经理讲述下个 Sprint 的项目。Planning 之后是 Grooming,开发团队对项目进行拆解,将每个项目拆分成开发任务并评估出故事点,评估完成后 Scrum Master 会根据团队过去的 Velocity 给出最终的交付物。

这里存在几个问题:

  1. 故事点估算的交付周期几乎不起作用,很少会按时交付。
  2. 所有人都显得很忙碌,工程师总是在写代码,修 bug,对于项目价值以及原因并不理解。
  3. Sprint 不停的冲刺,团队很少能够审视过去做过的项目是否真的有价值。
  4. Sprint 目标确定后,极少有空间去修复技术债务。
  5. Sprint 开始的时候,往往技术方案还不是很确定,Sprint 冲刺的过程中存在着大量的不确定性。
  6. 如果项目出现风险,导致无法在 Sprint 结束的时候上线,结果就是延期到下个 Sprint,完全不够敏捷。
  7. 设计师应该在 Scrum 中的哪个阶段参与?如何参与?

过去,我们在 Scrum 的框架中打了很多补丁,效果并不理想,反而徒增了许多工作量。当时我们并没有意识到或许换一种工作流可能就可以很好的解决。其实也不用替换掉整个工作流,只需要少许改动就可以解决很多问题,这个改动就是在 Cycle1 之间引入了 Cooldown。我们参考 Basecamp 的 Shape Up 方法,并结合自身实践,将 Cycle 的长度设置为 3 周,在 Cycle 与 Cycle 之间增加 1 周的 Cooldown。

Cycle 中要做的事情与 Sprint 并没有太大的变化,主要是关注交付。我们保留了每天早上的站会,花 5–10 分钟来同步项目进展,主要目的是发现风险点。如果开发的过程中发现了新的不确定因素,团队成员会在站会上提出来,如果影响到项目的交付,我们会尝试调整项目的 Scope,或者安排更多的人力。风险确认之后,我们也会发布 Linear 的 Project Updates,内容会同步到 Stakeholders 所在的 Slack Channel,确保所有人都了解项目情况。

持续冲刺最大的问题就是很少去反思之前做过的项目,开发也没有时间去做性能优化,解决技术债,而这些问题在 Cooldown 中都有一定的缓解。在 Cooldown 中,我们主要关注以下事项:

  1. 回顾上上个 Cycle 的结果:分析每个项目是否达成了预期的目标。
  2. 制定下个 Cycle 的计划:结合之前项目的经验和数据,制定下个 Cycle 的计划。
  3. 明确方案和拆分任务:确定下个 Cycle 的计划后,开发团队会进行技术调研,确定技术方案 ,然后根据方案拆分出开发任务。
  4. 评估开发任务的故事点:开发会对每一个具体的开发任务给出相应的故事点,根据整个项目的故事点总数,我们可以预估下个 Cycle 的交付物。
  5. 优化和修复:优化上个 Cycle 中出现的问题,或者修复 Bug,为下一个 Cycle 的顺利进行做准备。

整个 Cooldown 从周一到周五大概会这样安排大概是这个样子:

周一:开会的一天

周一大部分时间都在「开会」。主要在做的事情实际上就是回顾之前的项目,然后计划下个项目。

1. 回顾会议

回顾会议由产品经理来同步上上个 Cycle 交付的项目的数据。通常我们的项目分成两种:一种是功能交付;另一种是试验一些新的想法。前者通常关心的是用户使用情况;我们团队做的比较多的是后者,后者我们会将每个项目的结果分成 3 种:

  1. 符合预期(Validated):即项目结果达成了我们最初设定的指标,并总结原因。
  2. 不符合预期(Invalidated):即项目结果没有达成最初设定的指标,然后分析原因可能是什么。
  3. 没有结论(Inconclusive):这个比较复杂,虽然指标可能符合预期或者不符合,但因为有其他因素的干扰,导致无法判断是否是因为这个项目导致的结果。

同样,针对 3 种结果,也会有 3 种不同的行动项:

  1. Validated:通常下一步行动是进一步优化,或者进行规模化。
  2. Invalidated:则会进一步讨论是否需要继续,或者放弃。通常一个项目会对应一个目标,而达成目标的方式通常有很多种,每一个项目通常我们会选择其中一种来做尝试,如果这种方法被证实为无效,我们可以会继续评估是否这个目标还值得去做,如果值得,那么再考虑其他方式。而如果已经没有新的想法了,则暂时放弃。有些放弃的项目也会需求下线之前的项目,清理代码。
  3. Inconclusive:与 Invalidated 的类似,不同的是当中有试验初期未被考虑的因素出现,这个因素对试验的结果产生了一定的影响。那么无论结果是符合预期还是不符合,都不能作为确定的事情,我们需要考虑这个新的因素后重新设计试验,然后重新评估项目是否还有机会成功,如果有,那么稍微调整下再继续观察。如果考虑到新的因素之后,原有的项目已经无法奏效,那么就像相当于是 Invalidated 了。

2. Planning 会议

Planning 主要是产品经理向团队介绍接下来一个 Cycle 的目标和方案。我个人很喜欢 Shape Up 中写 Pitch 的方法,不过对于并不是所有产品经理都能够写出合格的 Pitch,因此也暂时没有在团队内部推广。Planning 实际上会过 3 种项目:

  1. 产品经理原本安排在下个 Cycle 要做的事情。
  2. 回顾议会中,如果有提出新的想法,产品经理也可能会安排到下个 Cycle 中。
  3. Linear Triage 中所有的项目:Cycle 的过程中如果有任何新的想法,通常都会先进入 Triage 中,每次 Planning 的时候我们都会一条一条的 Walkthrough,如果决定不做的就会直接 Cancel 掉,决定要做的就会尝试安排到下个 Cycle 中。如果 Cycle 没有空余的时间,则会 Snooze 推迟到下下个 Cycle 再讨论。

3. Retrospective 会议

这个是从 Scrum 中延续下来的会议,这个会议与项目无关,主要关注的是团队协作流程中的问题。通常会议上我们会收集团队成员的反馈,大家回顾项目进行中碰到的阻力,跨团队协作、文档、做事方式等等,把所有认为不合理的地方都记录下来。会议中我们会讨论这些问题,并且商讨出一个可行的解决方案写入下个 Cycle 的行动项目 。会议结束后,每个行动项目都会有一个 Owner 来追踪。实际上,我们现在的项目运作流程就是在这个会议中讨论出来的。

周二到周四:Shaping

这几天相当于 Shape Up 中的 Shaping 过程(虽然并不完全相同),Shaping 主要达成几个目标:

  1. 目的是明确交付项目所需的具体内容,也就是 Definition of Done。
  2. 明确投入的成本,也就是 Shape Up 中提到的 Appetite。在《RICE 框架》中有提到一种衡量 ROI 的方法,讲道理应该遵守这种规则来设定 Appetite。
  3. 分析技术可行性,调研技术方案。
  4. 然后拆分技术任务,并评估点数。

对于开发来说,Planning 的项目可以分成两种状态:

  1. 我们知道怎么做,整个项目基本确定,需要用到的数据、服务、设计都是比较确定的。
  2. 项目看起来具备可行性,但还没有具体的实施方案,其中又可以分成以下几种状态:
    1. 不知道用什么技术来实现;
    2. 知道用什么技术来实现,但对该技术不熟悉;
    3. 技术都比较了解,但是有外部依赖性,可能需要依赖外部团队。

对于 2.a 和 2.b,工程师首先会调研技术方案,技术方案调研完成的标准是用简单的脚本构建了原本的需求,其中的代码质量可能无法到达 Ready for Production 的水平,但是基本的流程跑通了,也大概知道有哪些坑以及要做什么事情。确定这些之后就可以对项目进行拆解。

2.c 产品经理和工程师也会找对应的团队去沟通,如果其他团队可以在 Cycle 内提供支持,那么首先要做的就是协商接口协议和大致的时间,然后各自按照协议进行开发。团队确定协议后也会先拆解项目。

也时候也会出现一种情况,就是到 Cooldown 结束的时候也没确定技术方案。这个时候有两个选择:

  1. 暂停该项目,等待下个 Cycle 的时候再决定是否要继续,因为成本比较高。
  2. 把技术调研本身作为一个任务放进 Cycle 中,这种情况下该项目通常不会作为交付目标,而是如果有空余时间才会去做。

把技术调研放进 Cycle 的另外一个问题是 Story Point 无法确定。我们之前有出现过整个 Cycle 都是在做调研,尝试过很多方案,最终还是没有找到合适的方案。最大的问题是没有制定一个「止损」,我们现在通常会给一个固定的时间来做技术调研,通常是 1–2 天,如果 2 天之后没有任何进展,可以会先暂停调研,转而投入更确定的项目中。

从 Scrum 到 Linear Method:重塑我们的开发流程

Shape Up 中有个 Hill 的概念,技术调研就像是在爬一个山坡,爬到山顶意味着技术调研已经结束,方案已经很明确了。Linear 没有向 Basecamp 的 Hill 的概念,所以我们为进入 Cycle 中的调研任务定了一些规则。由于调研任务很难评估时间,所以我们会在调研任务一开始的时候确定一个最大时间,也就是根据项目本身的价值,我们最多还愿意投入多少的时间来做技术调研,通常是 1–3 天。然后我们每天会评估前一天调研的情况,通常在最大时间达到的时候会有几种结果:

  1. 方案已经明确:这是最理想的情况,接下来就是做任务拆解,但不一定需要在这个 Cycle 进行开发。
  2. 方向已经明确,但具体的技术细节还要在调研:这种时候我们通常会在给出 1 天的时间,一天之后在进入这个评估流程。
  3. 方向依然不明确:这种时候我们会暂定调研,转化把人力投入到已经确定的项目中。

周五:评估故事点的艺术

周五也是 Cooldown 的最后一天,在下周一的时候就会直接进入 Cycle 中, 因此周五最主要的事情就是确定下个 Cycle 的交付物(Scope)。 最初我们按照 Scrum 的 方式来评估点数,整个评估过程需要所有参与的工程师 一起,所有人 同时评估一个项目,评估的结果通常会有些出入,有些人的点数多,有些人认为的少,然后讨论为什么会有出入,通常是一些背景知识的差异,或者有些人想到一些 边缘情况,所有信息都聊清楚之后,最终达成一致。这种方法的结果是没有问题的,但是效率非常低下,因为每一个项目大家都要讨论很久,结果就是一个点数评估要好几个小时才能完成。

我们的解决方案是制作了一个评估点数的标准,每种类型的任务都有相对应的点数,例如对于前端来说,最简单的需求莫过于改文案,所以一个改文案的 Issue 就是 1 个 Story point;比改文案稍微复杂的就是改个 CSS 属性,改颜色,调整字号什么的,它比改文案复杂的点在于有时候你的修改可能不生效,CSS 覆盖什么的,所以可能会需要找一下在哪里改。以此类推,我们使用斐波那契数列来制作了一个 Cheatsheet 帮助工程师评估每个 Issue 的点数。整个项目的点数就是把所有 Subtask 的点数加起来。

我见过一些团队会被所有做过的任务都进行归纳,然后给每种类型的任务都给一个固定的点数,每个点数下面 也都会链接到一些典型的任务上。这样做唯一的问题也是效率,回顾过去做过的所有任务并分类归纳并不是一件轻松的事情。对比我们现在的做法是,先定义一些我们经常被碰到任务,作为一个锚点,然后遇到新类型的时候,会临时评估一个点数,到 Cycle Retro 的时候我们会重新调整下点数标准。效果也很不错,从最开始到现在基本已经稳定,中间值有过一次比较大的调整,是因为有一些新的任务比我们定义的 3 个点大,但是比 5 个点小。于是我们把所有的 5 个点之后任务都统一往后挪了一位,对应的 Cycle Velocity 也给这膨胀了。

另外就是评估点数的标准描述上,最开始我们定义的锚点就是“1 点:修改文案”这种比较清晰的,但是对所有任务类型清晰的分类和归纳依然是个体力活,所有基本上在 3 个点往后的,如果实在难以分类,我们就用很模糊的语言来表达,有几个案例可以感受下:

  • 5 个点有个类型是“写一个全新的、简单的 UI 组件”,意思是一个 Subtask 需要写一个之前没有的 UI 组件,但是这个组件很简单,简单就是一个很主观的词,但团队内部慢慢的就会达成共识,虽然没有文本说明。大家对简单的共识可能就有几个条件:没有动画、只有简单的交互(点击),甚至没有交互,所以大家一看到就知道这是一个简单的组件。
  • 8 个点也有个标准是写复杂的新组件,复杂意味着可能有多个交互方式,内部元素也比较多,但是大概看一眼也都知道应该怎么写。
  • 13 个点也有个写组件的,是复杂的带动画的 UI 组件:动画通常调试起来比较复杂,所以只是给一个组件加动画本身就是 5 个点。
  • 21 个点同样有一个是创建新的 UI 组件,但是你一眼看上去就知道这玩意非常复杂,起码得 3、5 天才能搞定。

再说一个拆任务的粒度,通常我们希望是越细越好,所有的故事点就是针对最小粒度的任务做的。举个例子,前面提到的 复杂的带动画的 UI 组件,有些组件本身和动画并不耦合,这种时候就应该拆分成两个任务:1 个写复杂组件的任务(8 个点) + 1 个给组件加动画的任务(5 个点);也有些组件 UI 和动画的耦合比较深,两个必须一起做才行,这个时候才会保留 1 个任务给 13 个点。

评估点数之后就是确定 Cycle 的 Scope,根据过往的 Cycle 数据我们已经大致知道在一整个 Cycle 中团队能够交付 600 个故事点,虽然每个人的数字都会有一些差异。但团队整体基本上就是在这个数字附近波动。在 Linear 中我们把所有要做的项目和任务都放进下个 Cycle 中就可以看到总体的点数了。通常为了预防一些未知的事情,我们会保留 20% 的冗余点数,也就是其中 80% 的点数是必须交付的,项目中有一些 Nice to have 的就会放在冗余里面,也就是能交付最好,如果有意外发生,不交付也行。

固定时间,动态范围

前面提到在 Scrum 中我们会遇到一个问题,如果 Sprint Goal 无法达成时应该怎么做?以前的做法是,那就延期到下个 Sprint 中。而在 Shape Up 中有一个原则我觉得可以非常好的解决这个问题:

Fixed time, variable scope.

在 Scrum 中,我认为的一个 Sprint 的定义是至少一次的发布周期,Cycle 同样也是,每个 Cycle 3 周意味着 3 周内我们要进行至少一次发布。发布不是没做完就直接上线,而是功能是完整的,但可能体验不是很好,甚至在某些边缘场景中会有 bug 存在,并且 bug 是已知的,我们称之为 Release with bugs。最根本的原因就是 Cycle 就一定要交付,而且交付物是可用的,即使有 bug 也不影响主流程。这也符合 Agile 本身所推崇的持续交付。从客户和项目 Stakeholder 的角度来看也更容易接受。Cycle 的交付物对于一个团队来说是一个 Commitment,如果时间到了没有交付,客户和 Stakeholder 会降低对团队的信任;而如果交付了,即便是存在 bug,这个时候大家都会表示理解,毕竟不是不能用。而 Cooldown 的过程中我们就会修补之前提到的问题。

作为买家,我自然也不喜欢这种交付方式,最明显的案例就是游戏行业,我们已经看到过很多刚发布的时候一堆问题, 然后慢慢改进的游戏,Cycberpunk 2077、无人深空这种。我的看法是 2C 产品最核心的就是体验,如果有功能且体验不错的产品就有很多,用户和玩家有很多选择;而在 2B 里面功能显然更重要一些,看看 Salesforce 和 Jira 就知道了,毕竟买的人不一定用,所以他不关心所谓的体验。另一方面 2B 涉及到的 Stakeholder 比较多,可能上下游的团队都已经准备好了,那么 Release with bug 好过什么都不交付。

举个例子,例如我们的项目是做注册登录,目标就是让用户可以注册并且登录到我们系统中。往大了说就是一个账号体系,最终一定会非常复杂,但是 3 周内我们能做什么呢?最基本的邮箱注册和登录一定是要有的。找回密码呢?自然也非常重要,但不一定要体现在产品功能上,意思是你的 UI 上有“找回密码”这个按钮,但是用户按下之后是 Contact support,然后 Support 可以 联系开发团队后台修改什么的,虽然加到了人力成本,但是作为 Edge case 来说,风险可以接受。

其他问题

到这里,我们使用 Linear Method 最关键的部分就已经说完了,其实就是引入了 Cooldown,而 Cycle 当中做的事情和 Sprint 本身没有区别。

关于交付

这个时候可能有几个问题,同样是 4 周,我们现在的方法只有 3 周实在写代码,另外一周更多的时候是在写文档;而在 Sprint 中,代码就是文档,有 4 周的时间都是再写代码,前者交付的产品应该会比后者少才对。

话虽如此,直接写代码的前提是你的知道你要写什么,虽然 Agile 宣扬拥抱变化,但是需求天天改 Agile 祖师爷来了也没用。拥抱变化是指对趋势和方向的变化,即如果之前的路走错了,下一次改就行了,其核心是通过学习,不断的提升认知,不断了解什么是“正确”的方向,然后不断的调整;而不是天天改需求,改需求意味着根本不知道方向是什么,只是在原地打转而已。

延期的问题其实也是 Sprint 过程中经常发生不确定性,这些不确定性导致的延期。基本上这种不确定可以分成两类:

  1. 需求的不确定
  2. 技术方案的不确定

这两个问题在 Cooldown 的过程中都有一定程度的解决。但在 Cycle 进行了一半产品经理要改需求,这种事情也拦不住,我们还是回到最开始的原则「Fixed time, variable scope」,时间就这么多,要改动也是可以,但是改动后的版本也要能保证按期交付,交付后可以在打 Patch 来进一步优化。

如果说连方向都变了,整个项目都需要推倒重来,我到目前还没有这种经历,但是我们的预案是会立即停止 Cycle,重新进入 Cooldown 阶段,重新评估项目。这种情况发生的时候,相当于 Cycle 的目标已经发生了变化,那么继续原来的 Cycle 就是没有意义的。

关于故事点

Some teams try to attach estimates to their tasks or scopes to report status. The problem with estimates is they have a very different meaning depending on the nature of the work being estimated.

一些团队会估算任务或范围来做报告状态。估算的问题在于,它们的含义因所估算工作的性质而有很大不同。

Shape Up 并不使用故事点,转而使用 Hill 来作为状态,我并未尝试过这种方式,一方面在 Linear 中没有这样的概念,比较难以实施,另外所有人需要转变思路。我们也不确定这样做是否值得,我们唯一对故事点的抱怨是估算花费了太多的时间,而这个问题已被解决。有了故事点,很大程度上可以帮助我们更好的跟踪项目动态。

故事点的意义在于让我们可以知道团队在一个 Cycle 内的工作容量,从而预估交付物,给利益相关方承诺。虽然并不是完美,但就我们使用的情况来看,问题也不大。

以下是我们在不同时间团队的 Cycle Velocity,你可以看到故事点可能会随着 Cycle 的进行而波动,实际上就是中途发现了不确定。但是我们的交付进度(蓝色实线)基本上是贴着 Linear 的预测(蓝色虚线,只是线性的平均线而已)在进行,基本上说明项目没有问题。

如果蓝色实线距离蓝色虚线有比较大的距离,那么意味着项目可能会延期,这个时候项目的 Lead 通常会发布 Project Updates 来报告项目状态为 At Risk,此时我们会有几个预案:

  1. At Risk:通常意味着增加人手可以解决,我们可以暂停优先级较低的项目,而让临时增加人手来解决。
  2. At Risk:如果实在没有人手,那么再次思考 Scope 能否继续缩小。
  3. Off Track:意味着没救了,无论如何 都不可能按时交付了。这个是最差的情况,我们也出现过 2–3 次。只能提前和 Stakeholder 沟通,达成一致。
从 Scrum 到 Linear Method:重塑我们的开发流程
Cycle 当中点数上涨也是正常,我们预留了一部分的冗余空间来应付不确定性
从 Scrum 到 Linear Method:重塑我们的开发流程
最初的大幅波动是不小把第一周 Cooldown 也算进 Cycle 了。

关于设计

遗憾的是我们依然没有解决设计师应该如何参与的问题。理论上 Shaping 的过程就是设计师和工程师通常参与 Shaping,搞清楚要做什么,然而我很少遇到能和工程师配合很好的设计师。这不一定是设计师的问题,在一些公司,设计师是一种资源,需要的时候得去申请。这种情况下,设计师调过来也只是完成一些任务,他不会尝试去理解你的项目目标、背景、所处的状态,只是来完成任务而已。当然并不是所有人都这样,但毕竟能够深入理解项目并负责人的是少数。我的项目中尽量不使用设计师,多数时候与设计师沟通要消耗不少时间,有这些时间我自己都把 Demo 写好了。这其实是敏捷(Agile)的另外一层问题,在一个公司当中,只有一个团队和项目敏捷是不够的,外部资源总会成为 Blocker,解决的方案就是让整个公司、整个组织都变得敏捷起来。

我的多数项目中,我自己承担了设计师的角色,从设计师和开发的沟通来看,相比较使用 Figma,我更喜欢用 React 来做设计(直接写代码)。原因是很多时候 Figma 做不到我想要的效果,尤其是要做非常灵活的组件的时候,例如按钮的颜色继承父级组件的颜色,这种情况在 Figma 中需要设计师手动标记,而开发常常会忘记去看这些标记。

对我来说 Figma 还不够灵活,我的习惯是,在做设计的时候,第一版基本上是不会做组件的,先把页面画出来。随着页面的增加,会出现很多重复的组件,这个时候我才开始做组件,然后把页面上重复的地方全部替换成组件。随着项目继续推进,有些组件就需要根据一些参数/变量来自动调整,这个时候需要回去改组件,同时再调整所有用到该组件的地方,很多时候要把组件的宽高一个个全部调整一次,基本上就是个体力活。虽然在写代码也是相同的流程,但是代码的行为比 Figma 调整 Responsive 更加可预测,所以改动起来也会更容易。

在与开发的配合中,我尝试过两种方式,我们目前的几乎所有的项目都使用 Radix ThemeTailwind

第一种做法是,我会在 Shaping 的过程中会有一个草图(通常使用 ExcaliDraw),工程师就可以根据草图来直接开发,有些地方可能需要工程师自己发挥,因为有 Radix 组件,多数时候都不会太差。开发完成后,我会先验收功能,没有问题我会在对 UI 做一些微调,然后就可以上线了。

第二种做法是,我先写 UI 和交互,只设计前端的逻辑,以及一些 Mock 的数据,并没有真正和后端交互。然后工程师会在此基础之上加上后端的数据。这种流程比较复杂的时候,用代码直接开发 Demo 有另外一个好处,每一次开发完成后我自己会先用一次,总是会发现一些不合理的地方,然后重新调整。用 Figma 当然也可以做一些流程,模拟点击来尝试,但和真正在前端 Mock 数据来使用时完全不同的。

对于一些需要复杂流程的我会选择第二种,如果只是一个做内容展示的页面,则使用第一种。


回到正题,以上就是我们过去一年使用 Linear 并且结合 Shape Up 和 Linear Method 调整后的实践经验,其中不可避免地带有我们团队的历史因素,例如团队成员配合默契,使得 Story Point 的标准即使相对宽松也不会影响最终交付。我们没有完全投入到 Shape Up 或者 Linear Method 中,而是结合自身情况进行调整。没有必要为了改变而改变,只有当现有流程出现问题时,我们才会考虑引入新的方法。我们也深知,没有一套方法可以完美适配所有团队。最佳实践,唯有在实践中根据自身情况不断微调、优化才能得到。


  1. Cycle 或者 Sprint 对我来说都是一个周期的单位。Linear Method 不适用 Sprint 是认为 Sprint 有冲刺和意思,而 Cycle 的重点是交付价值,而不是冲刺交付具体的工作量。我个人到无所谓。 ↩︎
🔲 ☆

Issue #10 - 通过 Zapier 聊聊 Product-Led SEO

Zapier 每个月有超过 6百万 的自然搜索流量,帮助 Zapier 成功的流量策略,被称为 Product-Led SEO。这里的 Product 指的是产品本身,Product-Led SEO 就是指通过产品本身的功能作为核心关键词,通过程序化的方式来拓展关键词,构建起大量的页面的方式来做 SEO。

Zapier 最初的业务很简单,用户在软件界面中简单的几步操作,就可以实现多个产品的对接。在 Zapier 出现之前,如果你想要对接不同的软件,那你可以写个脚本,通过调用不同软件的 API,并将其部署在服务器上来实现最终的对接。而 Zapier 相当于是把「写脚本」这件事情变成了可以通过「用户界面」来直接配置,并且无需部署,可以直接运行在 Zapier 的服务器上,明显降低对接不同软件之间的成本。

Zapier 的核心能力显而易见,就是「集成/对接」(Integrate/Connect),而这个词也正好就是 Zapier Product-Led SEO 中最主要的关键词。Zapier 的目标客户就是那些需要对接不同软件的人,而这些人在搜索引擎上通过会搜索诸如「如何对接 A 和 B」这样的内容。而 Zapier 就利用自身已经对接的软件,通过程序快速生成了大量的「对接 A 和 B」的页面。如今在 Google 上搜索有关两个产品之间的对接,Zapier 的结果总会出现在头部。

Product-Led SEO 的最主要的特征是可规模化,也就是说可以通过程序的方式来快速生成大量的相关的页面来做关键词排名,这种方式称之为程序化 SEO(Programmatic SEO)。程序化 SEO 结合了产品核心功能作为关键词就是所谓的 Product-Led SEO。

为什么 Product-Led SEO 会起作用?主要是和 Google 的 E-E-A-T 策略有关,其中第二 E 代表着专业度(Expertise),而 A 代表了权威性(Authoritativeness)。这两个的意思是页面的内容本身是否足够专业(如果是文章还要考虑作者),并且发布这篇文章的网站在这个话题(Topic)上是否足够权威。举个例子,一个非常专业美食博主,在自己的美食博客里发布一篇有关健身减脂的文章,即使文章本身可能足够专业,但你也会怀疑博主突然发这样一篇文章是否有广告嫌疑,Google 也是如此。

Zapier 本身的主营业务就是做软件集成,所以在「集成」这个词上就天然的具有权威性。类似的案例非常多,例如在 Google 搜索 Email Marketing,头部的结果基本上总是 Mailchimp, Hubspot, Brevo 这几个主营业务就是 Email Marketing 的网站。虽然作为一个搜索引擎的用户,我并不喜欢这种结果,原因是大部分内容都是千篇一律,而真正的干货文章可能是在某个从业多年的人的博客或者 Substack 上,但是头部的企业网站可以凭借更好的域名权威性来以及大量的内容输出,来获得更好的排名。另外,根据我个人的经验,这其实是可以作弊的,Google 其实并不是真的「理解」这个网站的业务,如果某个网站有很多有关某个话题的内容,那么 Google 可能会认为你的网站就是干这个的,从而提升改网站在相应话题中的权威性,也就是 SEO 的马太效应。企业博客可以雇佣大量自由写手来撰写大量关于某个话题的内容,而个人博主则没有这个能力,于是我们看到的结果就是大量的排名很高的 SEO 软文,而真正的干货却难觅踪迹。

Product-Led SEO 的一个好处是流量的质量得以保证,这也是我认为 Product-Led SEO 和 Programmatic SEO 最大的区别。如果一个网站主要是依赖流量的多少来赚钱(例如广告展示),而不关注流量质量,通过程序可以快速生成大量的页面来做排名就足够了,什么关键词流量高就做什么关键词,而无需关心来的都是些什么人。但如果是通过出售产品来赚钱,流量的多少自然也重要,但更关键的是流量的质量。那么如何评价流量的质量呢?对于类似于企业官网这种无需登录就可以公开访问的网站来说,我们很难直接知道访问网站的人都是什么类型的人、有什么诉求,是否符合产品的 ICP。虽然 GA 提供类兴趣爱好等标记,但只有在投放 Google 广告的时候才会有所帮助。B2B 领域有一些公司(例如 Clearbit)可以提供通过访客 IP 来识别 这个人可能来自哪个公司的,但一般来说价格不菲,而且即便所在企业符合 ICP,访客本身也未必符合 Buyer Persona,而后者几乎没有方法可以在匿名的情况下获知。低成本并且高效的方式就是通过页面关键词,例如你写了一篇如何运营网店的文章,有个人通过搜索引擎进来到这篇文章,虽然 Google 不会直接告诉我们「这个人」的搜索关键词具体是什么(如果是通过搜索引擎广告进来就可以知道关键词),但是根据文章内容也能猜出个大概,访客大概率是从事和网店运营相关的工作。

对于 Zapier 来说,如果一个人搜索 A 集成 B,或者如何集成 A 和 B 这样的关键词,那么这些人大概率就是目标客户。Zapier 就顺着这个关键词,自动生成了很多 Connect A and B 这种页面,如今 Zapier 已经支持 7,000 多个 App,这些 App 两两组合就可以生成 24M 的页面,而且边际成本很低,每新增一个 App,这个 App 就可以自然的与库里的所有 App 对接,就相当于新增了 7,000 多个页面。

如果我们看 SEMRush 的数据,Zapier 的流量差不多是在 2015 年左右才开始有起色,而 Zapier 成立于 2012 年,Product-Led SEO 的策略差不多是在 2013 年的时候开始做,所以问题出在哪里?

和所有的 Programmatic SEO 的方式一样,Product-Led SEO 需要时间才能起作用,Zapier 2012 年才成立,域名也是全新的域名,最初虽然页面数量不多,但 Google 对于新网站通常都会持怀疑态度,不会给很高的排名,需要时间才能验证。我自己也做过类似的项目,2023 年初的时候我们用一个全新的域名来做 Product-Led SEO,起初的一年每个月的流量都少的可怜。不过我们也没有花太多的成本来维护,直到今年 3 月的时候我们重新审查了这个项目,反思是不是我们那里做错了,或者说会不会这个域名已经被 Google 拉黑了,于是我们决定等到 5 月份的时候再看看情况,如果不好转的话就换域名或者干脆放弃。巧的是在 4 月底的时候流量突然发生了很大的增长,很难说清楚原因,因为当中我们其实没做什么,唯一可见的影响就是 Google 在 4 月份完成新 Core update(核心算法的更新),以及之后 Spam 内容检测的更新,之后流量大涨,月活直接是之前的 100 多倍,而此时距离项目上线已经过去 15 个月了。我的一个猜测是这可能就是 Google 给一个全新域名的一段时间的试用期,过了之后 Google 才认可这个域名。


Product-Led SEO 并不适合所有产品,它取决于产品核心功能的这个关键词的拓展性。Integrate, reviews, email template 这类型就很好扩展,xxx reviews 可以是任意店铺、网站、软件等等,G2, Trustpilot 就是利用 Review 这个关键词来做 Product-Led SEO。同样 xxx email template 可以是节日、风格、场景等等,很多邮件营销工具(Camppaign Monitor)和设计工具(Canvas)就利用 template 这个词做了大量的页面。如果产品的核心能力恰好是可以拓展的,Product-Led SEO 自然是最好的选择,虽然它不像看起来得那么简单,Product-Led SEO 最大的成本其实在于背后的基础设施,想象下如果你有 24M 个页面内容需要维护的时候,系统会变得多么复杂。一旦你成功的构建了 Product-Led SEO,网站相当于构建了一道 SEO 的护城河,其他人也可以复制你的策略,但是在域名的权威性等等方面,他们也需要花很多时间去积累,而 SEO 的马太效应会让已经成功的网站活得更好的排名。

🔲 ☆

黑天鹅:如何应对不可预知的未来

TL;DR

黑天鹅:如何应对不可预知的未来

黑天鹅事件是指那些难以预测但是冲击性极大的事件。难以预测的主要原因是:1)现实是非线性的,极小的变动都可能会产生巨大的影响;2)人类的认知偏误,导致我们会忽略黑天鹅事件发生的信号;3)我们的社会「并不鼓励」预防灾难,因为灾后救助的行为更容易获得认可和奖励。人类最大的问题在于我们以为我们能够预测黑天鹅事件(未来)


黑天鹅理论并不是一个新的概念,人们多多少少都了解这个概念,Nassim Nicholas Taleb 在《黑天鹅:如何应对不可预知的未来》中提出并定义了「黑天鹅事件」:

  1. 它具有意外性,即它在通常的预期之外,也就是在过去没有任何能够确定它发生的可能性的证据。
  2. 它会产生极端影响。
  3. 虽然它具有意外性,但人的本性促使我们在事后为它的发生编造理由,并且使它变得可解释和可预测。

概括起来就是:稀有性、极大的冲击性和事后(而不是事前)可预测性。

生活在 2024 年的我们对于这个概念一点都不陌生,我们经历了 2019 年灾难性的 COVID-19,又在 2023 年经历了可能会是改变人类历史进程的 ChatGPT 发布,这些都是黑天鹅事件,两者都具有意外性,都产生非常大的影响,这种影响并不总是负面的,ChatGPT 就是正面的例子。在本书中,作者要强调的是「我们表现得就好像我们能够预测历史事件,甚至更糟的是,我们以为能够改变历史进程。既然黑天鹅事件是不可预测的,我们就需要适应它们的存在(而不是天真地试图预测它们)」重点在于解释了为什么黑天鹅事件是不可预测的,至于如何适应黑天鹅,作者在这本书中并没有给出答案。

作者认为黑天鹅事件之所以不能被预测主要是认知偏误

  1. 我们只关注从已观察到的事物中预先挑选出来的那部分,从它推及未观察到的部分证实谬误
  2. 我们用那些符合我们对明显模式的偏好的故事欺骗自己:叙述谬误。
  3. 我们假装黑天鹅现象不存在:人类的本性不习惯黑天鹅现象。
  4. 我们所看到的并不一定是全部。历史把黑天鹅现象隐藏起来,使我们对这些事件发生的概率产生错误的观念:沉默的证据造成的认知扭曲。
  5. 我们“犯过滤性错误”:我们只关注一些有明确定义的不确定性现象,一些特定的黑天鹅现象(而不关注那些不太容易想到的)。

我想从另外一个角度来解释为什么黑天鹅事件不可预测,总结下有三个关键点:

  1. 非线性系统:我们生活的世界是一个混沌系统(复杂系统),也就决定了我们几乎不能预测未来。
  2. 认知偏差:我们的大脑对世界进行了高度抽象,抽象意味着会忽略很多细节,而关注发生概率更到的事件,这也是为什么我们会对黑天鹅事件视而不见,因为我们从内心里觉得这件事情不会发生。
  3. 社会奖励机制:包括对预防性措施和前瞻性思维的不足重视,社会奖励机制往往偏向于对已发生事件的响应而非预防未发生事件。

非线性系统

线性函数指的是只有一个变量的函数,例如 y=2x,线性函数在直角坐标中的图形是一条直线。在 y=2x 这个函数中,y 会随着 x 的增加而增加,缩小而缩小,哪怕我们对 x 的测量有一定的误差,对结果的影响也都是有限的。例如当 x=9.8 的时候,我们四舍五入的认为 x=10,对结果的误差也就只有 0.4。

黑天鹅:如何应对不可预知的未来
三个线性函数的图形都是直线。红色与蓝色直线的斜率相同。红色与绿色直线的y-截距相同。

非线性函数则意味着在直角坐标系中的,函数的图形不是直线,可能是曲线,甚至不是连续的。指数函数就是一个典型的非线性函数,非线性函数意味着 x 作为输入的变化,可能会对 y 产生很大的影响。例如 y=2x,如果 x 依然是 9.8,但是我们四舍五入到 10,那么测量结果将相差 132.6。(210 - 29.8 = 132.6)

黑天鹅:如何应对不可预知的未来
y=b^x 对各种底数b的图像,分别为绿色的10、红色的𝑒、蓝色的2和青色的12。

现实世界中的复杂系统通常是非线性的,每天早上我都会关注天气,你应该也有注意到,天气预报中,时间越长就越不准确,即便是当天的预报很多时候也是不准确的,望着窗外下雨的街道,天气 App 却告诉我今天不会下雨,只是阴天。现实世界中的许多系统(如气候系统、生态系统、经济系统等)表现出强烈的非线性特征,即输入变化的微小差异有时会导致输出的极大差异,这是混沌的典型标志,这也就是著名的「蝴蝶效应」。

黑天鹅事件经常发生的很突然,但其背后的原因往往是多种因素长时间积累的结果。而混沌系统的预测却需要非常精确的初始数值和函数,即使理论上存在能够完全描述系统的函数,实际上我们无法获取所有这些信息,或者即使获取到全部信息,也可能因为需要的信息量非常巨大导致无法有效的处理。也正因如此,黑天鹅事件是无法被预测的。

认知偏差

认知偏差是人类自己主动忽略黑天鹅事件发生前的各种信号。黑天鹅事件并不像太阳东升西落一样每天都会发生,它发生的频率很低,导致我们对相关事件的记载也就比较少,相关的理论也不够多。而每天都会发生的事情,因为案例多、研究多,我们经常会看到相关的信息,这些信息也会强化我们的认知,认为与之相对的事情都不会发生,这种认知模式并非一种缺陷,而是在漫长的演化中形成的。

想象一下你现在要过马路,路上有两辆车正在行驶,其中一辆在你离很远的地方,而另一辆则要近很多,你会关注哪一辆车。我们几乎不需要思考就能得出结论,应该关注距离较近的车,从概率上来说它更有可能造成危险。注意力对于人类来说是稀缺的资源,而通过逻辑推理来计算结果就需要消耗大量的注意力,这也导致我们其实无法关注太多的事情,在处理危机的时候我们倾向于关注更重要的(发生概率更高)的事情。

在《思考,快与慢》中,Daniel Kahnema 介绍了人类大脑运行的两种模式:

  • 系统 1 的运行是无意识且快速的,不怎么费脑力,没有感觉,完全处于自主控制状态。
  • 系统 2 将注意力转移到需要费脑力的大脑活动上来,例如复杂的运算。系统 2 的运行通常与行为、选择和专注等主观体验相关联。

系统 2 的运行需要消耗大量的注意力,人脑实际上更倾向于使用系统 1 来处理日常事件,直到遇到系统 1 无法处理的事情的时候才会调用系统 2。例如当有物体超我们飞过来的时候,我们无须调用系统 2 去计算这个物体的初速度和飞行路线等等,只需要系统 1 我们就可以快速做出闪躲的动作。这种快速反应在我们遇到危险的时候能够显著提升我们的生存机率。Malcolm Gladwell 在他的书《异类:不一样的成功启示录》提出了一万小时理论,这一理论认为要在某个领域达到专家水平,通常需要大约一万小时的刻意练习,该理论正是基于系统 1 的学习模式。系统 1 通过反复的经验和模式识别,将复杂的信息和任务简化为直觉反应,我们将这一过程称之为「抽象」。而抽象就意味着关注事件的共同点,而忽略一些细节上的差异,不幸的是黑天鹅事件往往隐藏在被忽略的细节中。

Taleb 在书中所提到两种谬误又会强化这种模式。系统 1 有证实偏见的倾向,即倾向于寻找和重视支持我们现有信念和假设的信息,忽视或否定与之相反的信息。而恰恰又是因为我们会容易找到经常发生的事情的资料,而那些被忽略的细节却鲜有人关注,也难以找到与之相关的信息,这种现实情况又强化了我们的偏见(幸存者偏差)。这在面对黑天鹅事件时尤为明显,因为这些事件通常与我们的常规经验和信念不符,系统 1 会自动忽略或低估其可能性。

18 世纪苏格兰哲学家 David Hume 质疑了这种基于经验的推理过程的合理性,他认为从过去事件的发生归纳出未来事件将如何发生,并没有逻辑上的必然性。也就是说,仅仅因为某件事情在过去发生过很多次,并不意味着它在未来也必然发生。Hume 说得没错,遗憾的是他并没有给出问题的答案。

社会奖励机制

社会奖励机制也是影响我们预测和预防黑天鹅事件的原因,预防性措施(如完善的公共卫生基础设施、库存疫苗和防护设备等)如果成功,就不会有显著的「成果」展示给公众和决策者。预防的成功往往意味着「没有灾难发生」,这使得这些措施难以获得社会的广泛认可和奖励。在 COVID-19 之前,许多公共卫生专家和组织曾多次警告全球应对大规模流行病的准备不足。然而,这些预警和预防措施在当时并未受到足够的重视和投入。相反,当疫情爆发后,救治患者、疫苗研发和抗疫措施得到了巨大的资金支持和社会认可。对预防措施的投入不足也导致人们没有足够的动力去做预防。


现实的非线性、人类的认知偏差和社会奖励机制都指向了同一个结果——黑天鹅事件的不可预测性。但这并不代表我们什么也不能做,Taleb 在本书中没有给出答案,但是在后续出版的《反脆弱 : 从不确定性中获益》中给出了答案,他把事物分成三类:

  • 脆弱类:脆弱的事物喜欢安宁的环境
  • 强韧类:强韧的事物并不太在意环境
  • 反脆弱类:反脆弱的事物则从混乱中成长

脆弱的事物喜欢稳定的环境,无法应对环境的变化,因此对黑天鹅事件几乎没有抵抗力;强韧类的事物有足够大的防御力,黑天鹅事件可能会对它造成影响,但是影响不大;而反脆弱类的事物则喜欢变化,反脆弱的事物不但不会被黑天鹅摧毁,反而会从中受益。而我们要构建的,正是反脆弱性的事物。

反脆弱的事物恰如尼采的那句名言:

What does not kill me makes me stronger
🔲 ☆

Issue #8 - Scrum is a Cancer

很多年前一位经验丰富的前辈给我介绍了敏捷开发,让我开始了解 Scrum,后来的工作中也一直是在使用 Scrum 来开发产品。Scrum 有很多规则和会议,每天有站会、每隔几周有 Retrospective 会议,然后还有 Sprint planning 和 grooming。有时候这些会议确实需要花费不少时间,也有人会觉得这些事情都是在浪费时间,还不如多写几行代码。我也会有这样的疑问,Scrum 是否真的需要严格按照这些规则来执行呢?

TL;DR

  1. 形式主义的 Scrum 或者敏捷开发确实是 Cancer,它会降低团队的效率。
  2. Scrum 的核心在「验证产品价值。」
  3. 因为产品价值存在风险,所以要尽可能的降低成本(工时),所以要「快速交付」。
  4. 为了快速,我们要控制开发成本,于是有了 Sprint(最小交付周期)。
  5. 为了了解能否在 Sprint 内交付,我们需要评估成本,单位就是故事点。
  6. 为了评估故事点,团队成员都需要了解「需求」。
  7. 需求根源是问题,团队成员一起设计方案才能更好的理解交付物。
  8. 开发过程中总是充满变数,确保问题可以及时的提出。
  9. 当成本发生变动时,需要动态的调整需求范围。
  10. 记住,目的是为了验证产品价值,不是为了交付代码。

交付价值

简单来说 Scrum 只是一种软件开发的流程,「流程」显然不如「目的」重要,所以我们先抛开 “Scrum” 来谈谈软件开发本身。就软件开发的目的而言,显然不是为了「交付代码」给客户(如果是外包公司那就另说),而是交付「有价值的产品」。这里的关键是「有价值」的产品。

价值源于「交换」。 软件的价值同样如此,从表面上来看,客户付钱给公司,对公司来说获得了商业价值;公司交付软件给客户,对客户来说获得了使用价值。那么问题就变成了如何界定这次的交付物是「有价值」的?这个价值应该由谁来界定?虽然交付什么产品/功能是由产品经理决定的,但产品经理实际上只是用户的代言人,最终决定交付物是否有价值的只能是「用户」(或者某些情况下是客户,在这里我们将其视为相同的意思)。

产品经理(或者是 Product Onwer,这里认为是同一个人)决定了交付物,即使产品经理很理解用户,但不能 100% 确定这个交付物就是满足用户需求的,也就是我们说的有价值,所以产品的价值在真正交付给用户之前,就像是薛定谔的猫一样,是不确定的。这种不确定性的风险,哪怕是产品经理在前期花了很长的时间,拉上设计师给客户演示设计,甚至可交互的 mockup 让用户亲自上手尝试,这种风险依然存在。Mockup 的问题在于用户并不是真正的在使用产品,而是再尝试,看起来可以解决问题,但当产品真正交付出去,用户每天都开始使用的时候,很多问题才会显现。

也就是说有一定的几率我们的交付物没有价值的,或者价值很低,而这种风险又无法完全避免,那么当风险发生时,我们应该尽可能的降低成本。这里的成本,就是软件开发的时长。降低开发成本并不意味着我们要交付一个半成品给用户,这虽然降低了成本,但实际上也增加了风险。我们需要做的是在风险几乎不变的情况下降低成本。

这就要提到产品开发中的另外一个概念 MVP(Minimum Viable Product,最小可行性产品),或者说 MVF(F for Feature)。显然用户并不是想要一个功能,而是要解决一个问题,这些问题可大可小,小问题直接解决就行了,基本上也没什么风险可谈,但是「大问题」往往很复杂,这种复杂的问题也不是一个两个功能就可以解决的,问题通常会涉及到上下游以及各种 Stakeholders,通常是一个完整的解决方案。这么说是没错,但请把它当作是「最终」要交付的产品。最终我们确实是要交付一个完整的解决方案,但没有人说我们只能交付一次。

假设我们最终要交付一个 120 分的产品,有两种交付方式,第一种是一次性交付(在我们辛辛苦苦开发了一年之后),风险自然是有可能用户觉得我们交付的产品就是一坨狗屎,只给了我们 0 分,那就不得不返工再来一次,但即便是返工,在花了一年调整,我们也很难保证第二次的交付就是 120 分;另外一种方式是我们分成 12 次交付,每个月交付 10 分,第一个月的交付同样可能会被用户认为是狗屎,但是没关系,只浪费了 1 个月,我们可以持续改进,那么怕是推到重来也都可以。(但你大概率不会真的交付一个 0 分的产品吧。)

这其实就是敏捷开发中所说的「持续交付」。除了能够降低风险发生时的成本,持续交付的另外一个好处是,在很短的时间内可以把产品交付给用户,虽然它很难用,只能解决非常有限的问题。而此时的一次交付还在开发中,对用户来说没有任何的交付物,也还不能解决任何问题。

持续交付表现出来的就是用户可以在很短的时间内使用产品,在完成第一次交付之后,用户就可以对产品提出改进意见,而正是用户的反馈,让产品的价值不断的提升。虽然大概率我们无法在 1 年内交付产品,但是 1 年之后,用户已经有一个还不错的产品在使用了。而一次性交付在会进行第一次交付,结果怎么还是未知数,而我们更喜欢确定性,不是吗。

总结来说:我们关注交付「有价值的产品」,而产品的价值由用户来界定,为此我们需要尽快将产品交付给用户,而要尽快交付,我们需要控制产品 范围(MVP)。持续交付是为了尽快听取用户反馈,基于用户反馈来持续改进产品。无论你将这种流程称之为什么 Scrum、Lean、或者 Shape 都行,其核心都是一样,交付价值,而非代码。这里我们就继续称之为 Scrum 吧。

控制成本

这么来看 Scrum 可以理解为就是在控制成本,也确实如此,Scrum 并不能提升产品的价值,如果产品是一坨狗屎,使用 Scrum 并不能改变其狗屎的性质,最多变成了快速交付的狗屎。Scrum 能做的单纯的就是降低成本实现快速交付,因为快速交付,产品才能够快速的去验证「Product-Market Fit(PMF)」。

快速交付首先要定义什么是「快速」,一天、一周还是两周。实际上「快速」取决于你的开发 MVP 的周期是多少。Scrum 不仅仅要快速,还需要交付,理论上可以每天进行一个 Sprint,但如果没有实际交付,这种做法就失去了意义。我的经验是两三周是交付一个 MVP 比较合理的时间(Basecamp 内部的 Sprint 是 6 周)。对于新的团队,对于交付时间可能不好把握,因为 Sprint Velocity 还没有稳定,那么 2 周算是一个稳妥的选择吧,这个时间可以随着团队越来越熟悉,产品越来越清晰进行调整。

对 Sprint 的另一个误解是把 Sprint 等同于发布周期,虽然两周确实有关联性,但我更愿意将 Sprint 成为最小交付周期,即一个 Sprint 内至少要发版一次,你也可以多次发版,愿意的话每天发版都行。

软件开发中最大的成本就是开发的工时,限制 Sprint 的天数实际上就是在限制开发成本,准确来说是预算。Sprint 就好像规定了,开发预算只有 2 周,我们得看看 2 周后我们可以交付什么。也就是我们需要在每个 Sprint 开始之前就要做的 Planning。

Planning

Sprint Planning 实际上解决两个问题:

  1. 我们要交付什么?
  2. 我们能否在两周内交付?
  3. 如果不行,那么要缩小需求范围。

Planning 的一开始产品经理向团队宣布我们接下来一个 Sprint 的冲刺目标。如果是写 PRD 的产品经理,这个时候有点像是产品经理给团队阅读 PRD。我不喜欢 PRD(有人喜欢吗?),这个时候的重点就是对齐这个 Sprint 的交付物,也就是目标。产品经理对交付物有一个大概的定义,之后团队就要一起来 Shaping(细化)这个交付物。

定义范围

交付物是什么?它是一个解决方案。解决方案首先是从一个(用户提出的)「问题」而来,为了解决这个问题,产品经理给出了一个解决方案(也就是所谓的需求)。一开始我们之所以要快速交付,是因为我们无法 100% 确定我们的「解决方案」能否解决用户提出的「问题」,所以需要快速交付来获取用户反馈。言下之意,「需求就是有待验证的假设」。

条条大路通罗马。解决一个问题的方案可能不止一种,产品经理提出的方案未必是「最佳」的,这就是为什么团队需要对其进行「Shaping」。如果不考虑时间限制,那么永远都会存在一个「更好」的方案。所以我们需要一个时间限制,也就是在一个 Sprint 内,我们能交付的「最佳」方案是什么。

你可能听说过「第一性原理」,事实上这个过程就是我们寻找这个 original 的问题。如果你有用户和你一起参与方案设计,那么直接询问用户是最佳的方法,否则产品经理就是那个被询问的人。如果产品经理不理解这背后的问题,那么一切都免谈。

Mind the Gap

即使我们定义了 Sprint Goal,Shape 了解决方案,我们依然可能在交付的过程中出现意外。例如未知的技术问题,为了解决某个问题需要引入一项新技术,工程师以为很了解这种技术,但实际上有很多的「坑」,这个过程中总不可避免的会出现意外,所以我们经常会有一个「study」的任务,即工程师提前去研究清楚这种技术,写一个简单的 demo 出来。这个过程可能是 1 天,也可能需要 1 周,很多时候 Sprint Goal 无法达成也都是因为这个缘故。

有一些团队会在 Sprint 中引入 Cool-down period,我喜欢这个想法,Linear 中也恰好提供了这个设定。Cool-down 显然不是什么也不做,我认为这段时间让团队来进行 study,并尝试着写一些 demo 可以降低我们在真正进入 sprint 之后的风险。

评估成本

了解清楚「交付什么」只是第一步,我们还不清楚成本。假设我们的 Sprint(预算)是两周,那么接下来的问题就是我们能否在两周内交付,或者说两周内我们能够交付什么?

那么接下来就要评估这个方案(Issue, Story, Task, whatever),这个是时候实际上就进入了工程的范围,工程师把需要做的 Task 拆解为 Subtask,然后评估每个 Subtask 需要消耗的故事点(Story Point),然后将所有的故事点加总就得到了整个方案需要消耗的点数。理想情况下,工程师在每个 Sprint 能够消耗的故事点是相同的,我们称之为 Sprint Velocity,就叫它总点数吧。

方案评估完成,如果方案的点数小于等于总点数,就意味着团队可以在这个 Sprint 交付方案(当然风险总是存在);也可能出现方案的点数大于总点数,意味着无法在 Sprint 内交付。这个时候你有两种选择:1. 延长 Sprint 的天数,加到 3 周或者 4 周,要是你愿意你就可以无限延伸下去,但是别忘了快速交付;2. 缩小方案范围,也就是 MVP。显然我们更推荐后者,因为它也符合我们前面提到的快速交付和交付 MVP 的理念。

在评估的点数的时候工程师拆分了 Subtask,每个 Subtask 都是非常细粒度的任务,当我们在缩小范围的时候一方面可以从 subtask 入手,看看哪些 subtask 不做也不会影响用户「使用」,例如一些提升体验或者性能的 subtask,那么交付物可能体验并不好,但至少是可用的。将这些 subtask 移出 Sprint,直到整个方案的点数小于总点数。

这并不是一个简单的工作,从介绍需求(问题)到拆分 subtask 再到评估点数,整个团队可能花费半天的时间来完成。所以看起来确实是一件「浪费时间」的事情。所以我们还是回到核心,我们需要交付「有价值」的产品,如果我们可以非常确认现在做的东西就是有价值的,那么什么 Sprint, Standup, Story Point 都不重要,做就是了。


软件开发的核心是「交付价值」,而 Scrum 的大前提是「你无法 100% 确定你的交付物是有价值的」,于是你需要缩减成本来进行快速验证。如果你可以确定交付物 100% 有价值,那么就不需要 Scrum。当你确认需要 Scrum 之后再去思考 Scrum 的那些规则和形式是否「助于快速交付」。如果不理解这层核心,只是跟着 Scrum 形式来开发软件,那就和普通的「瀑布流」没有区别了,只不过是两周一个迭代的瀑布流。

站会、故事点这些工具都是用于控制成本,如果一切都很顺利,那么站会同样不需要,站会是用来主要是用于提出 Risk,如果一切都是顺利(On track),根本不需要开会,大家埋头写代码就好了,到期按时交付。现实却总是充满变数,而站会就是让所有人都知晓这种变数,尤其是「影响成本」的变数,如果成本超出预期,那么可能需要缩小需求范围,那么交付物与最初定义的可能会有所不同,而这些是 stakeholders 所关心的,这些问题也就是在站会上提出,让信息尽可能的透明。

Santiago 评价说 Scrum is a cancer,列出了 Scrum 几宗罪:

  1. 评估故事点是浪费时间;
  2. Standup meeting 浪费时间;
  3. 同样的问题 PM, PO, SM 都会问一遍,浪费时间。

必须得承认,如果只是机械的遵循 Scrum 的规则,确实会出现这种情况,Scrum 里面的所有规则都是为其目的服务。

🔲 ☆

魔鬼出没的世界

魔鬼出没的世界

小时候特别喜欢看「世界未解之谜」类的书,书中提到「百慕大三角」、「死亡谷」之类的事件总是令我着迷,神秘的百慕大三角跟外星人一样成为了大众为文化的一部份,一名图书馆管理员在 Lawrence Kusche 在研究了百慕大之后解释道,百慕大三角的失事船只和飞机数量并不显著高于其他海域,失踪事件总是被夸大,多名目击者和参与者的陈述中有大量的错误和矛盾,有些事件仅仅是因为船只延期。但科学的阐述显然不如神秘的力量作祟更吸引人。

We don’t see things as they are; we see them as we are.
– Anaïs Nin

卡尔·萨根是美国天文学家、天体物理学家、宇宙学家、科幻小说及科普作家,萨根提倡怀疑精神和科学方法。Wikipedia 这样解释科学方法「 科学方法是一种有系统地寻求知识的程序,涉及了以下三个步骤:问题的认知与表述、实验数据的收集、假说的构成与测试。」这个步骤实际上与我们在做增长实验的过程一样的,事实上 Sean Ellis 在《增长黑客》中就一直强调要「增长黑客方法将科学试验的严谨和精准引入创造过程。」成功学总是给人一种错觉,因为成功之前他做了某件事,所以这件事就是他成功的关键,这其实是一种常见的逻辑谬误,称之为「形式谬误」,即使前提成立,也无法推到出结论为真。

卡尔·萨根《魔鬼出没的世界》(The Demon-Hunted World)书中列举了外星人、UFO、上帝与魔鬼等迷信的观点,并解释了为什么他们存在以及为什么人们更愿意接受迷信而非科学。他在书中写道「一个人更愿意相信他所倾向的东西,而不是真理。因此,他因为缺乏研究的耐心而排斥困难的东西;因为目光短浅而排斥伟大的东西;因为迷信而排斥大自燃中深奥的东西;因为傲慢和自大而排斥经验的启示;因为顺从无知的平民的意愿而排斥未被普遍认可的东西。简而言之,个人感情会通过种种途径,而且有时是令人难以觉察地,影响人们对事物的理解。」

精神病学家乔治·加纳维曾对一个处在催眠状态下很容易受到诱导的病人提示说,某一天中有五个小时从她的记忆中消失。当他说到她的头上有一盏明亮的灯时,她立刻告诉他见到了 UFO 和外星人。他坚持说她被外星人做过试验,于是一个详细的遭绑架的故事便产生了。一般来说,倾向于相信神秘事物的人,特别是相信有外星人的人,以及用外星人假设来解释特异感受和幻想体验的人,更容易产生 UFO 体验。

卡尔列举了 F·M·巴特勒 在他的著作《魔术师的神话》中提到一则小故事:

  • 我说「在我的车库里有一条喷火龙」
  • 你问「龙在哪里」
  • 我说「就在那里,他是一条看不见的龙」
  • 你问「可以在地面撒上面粉,就可以看到龙的爪印了」
  • 我说「龙是漂在空中的」
  • 你问「那你可以用红外探测器来看到它」
  • 我说「它看不见,也不会发热」
  • 你说「可以在空气中喷漆,可以看到了」
  • 我说「它是非物质的龙,油漆粘不上去」

总之每一个问题都有特殊的理由来解释,外星人以及各种牛鬼神社的迷信理论也都是如此。这些理论都存在一个共同特点就是无法被证明,但也无法被证伪,与科学恰恰相反,科学强调的是怀疑精神,所有的结论都需要通过实验来获得,通过观察、测量等方法得出结论,如果结论中存在很多假设,那么这些假设也都需要接受检验。

卡尔·萨根在书中提出了一个科学方法思维的工具箱,用来识别谬论和谎言,这个工具箱帮助人们重新审视前提和结论。这个工具箱包括:

  • 如果可能,所有的「事实」都必须经过独立验证;
  • 鼓励见多识广的各种关键对已有的证据展开辩论;
  • 权威的一件并不重要;
  • 如果要解释某个东西,尽可能的构造出更多的假设;
  • 不要过分执著于自己的假设;
  • 定量,用数据来证明假设;
  • 结论的所有前提也必须保证是确证的;
  • 奥卡姆剃刀法则,当有多个说法都可以很好解释结论时,选择假设最少的一个(最简单的一个);
  • 假设是否能够被证伪,不可校验、不可证伪的命题是没有多大价值的。

同时卡尔也列举出了常见的谬论:

  • 攻击人而非观点;
  • 依赖权威;
  • 因果倒置;
  • 求助于未知,认为没有被证明是错误的就是正确的;
  • 攻击修辞(用词)而非观点;
  • 回避问题本身;
  • 观察的选择性,记住成功的,忘记失败的;
  • 对很少的样本进行统计;
  • 对统计数据的误解,例如不理解什么时候使用平均值,什么时候使用中位数;
  • 自相矛盾;
  • 非必然推论,即前提并非结论的充分必要条件;
  • 因为前提发生在结论之前,故而前提导致了结论;
  • 提出毫无意义的问题
  • 采用二分法,而不讨论其他中间状态;
  • 将短期与长期对立,为了解决眼下的问题而不去讨论长远的问题;
  • 将长期与短期统一,而不考虑其中的差异;
  • 混淆相关性和因果性;
  • 丑化一个观点,使之更容易被攻击;
  • 隐瞒证据;
  • 模棱两可的陈述;

我觉得科学与伪科学最核心的区别是,「科学允许被质疑,而伪科学则不」,英国物理学家 Michael Faraday(迈克尔·法拉第)曾说过「The Man Who Is Certain He Is Right Is Almost Sure To Be Wrong.」伪科学的提出者知道自己在说谎,但是他们不愿意承认,也不允许其他人质疑,因为质疑会拆穿谎言。但是很多人愿意相信是因为科学过于复杂,它需要首先理解一些基本知识,才能理解结论;另一个原因在《不平常的观念:科学的异端性》(1993)中,克鲁默提出科学之所以难是因为它不断推陈出新。我上学的时候所学的太阳系是有 9 大行星,而如今只剩下 8 个了,冥王星从原来的行星提出了,成了一颗矮行星,2006 年的 IAU 决议修改了行星的定义,因此冥王星不再是行星了。也恰恰是因为「允许被质疑」,科学才会不断的进步,不断的修正我们已知的观点和认知。

素有「微信之父」之称的张小龙有一句话「我所说的,都是错的」,我对这句话的理解就是,因为我们对世界的认知正在不断的进步,因此我说的这句话放在今天是正确的,但是在未来可能就是错误的。不要因为这句话「正确」,而不去质疑。

在科学以前的世界,人们依靠宗教了解这个世界和宇宙,维基百科中对宗教的定义中有一条是「联系人与神祇或超自然、神圣存在的文化体系」当人们对世界有疑惑或者不解的时候宗教总是会给出答案,他们构想出一个万能的神来解释各种神秘世界,这种解释非常简单,而通常人们认为这个世界就应该是简单的。中文互联网里面有句话叫「造谣一张嘴,辟谣跑断腿」,意思是造谣的成本很低,而辟谣则要收集很多证据来自证清白才行。科学与伪科学也是如此,伪科学即所以容易传播是因为它足够简单,不需要什么基础知识都可以理解,而科学则需要人们对基础学科的理解,这也是为什么教育如此重要。1790 年 乔治·华盛顿在国会致词:「没有任何事情比提高公众的科学和文化水平更值得我们去给予支持。在每一个国家,知识都是公众获得幸福的最坚实的基础。 」

即使是在软件设计中,我们在做产品和增长的过程也一直坚持在用「科学」的方法,很多时候人们会提出需求,而我和团队也经常提问目的是什么,有什么证据表明做这件事情可以达成这个目的,或者说有什么证据表明他们有相关性,多数时候人们的答案都是「我觉得」。这当然也是一种理由,但是非常不充分,这种时候我们也不愿意付出很大的成本去验证,通常会使用半天或者一天的事件来设计并上线一个简单的实验来验证,如果结果是正向的,我们会形成一系列的猜想,来推断造成这个结果可能的原因,然后在通过实验来继续论证。

在我看来「科学方法」应该成为每一个人的基本技能,面对每一个结论我们都可以去质疑;而作为提出结论的人,也都应该尽可能的给出足够的证据。

🔲 ☆

Issue #6 - PLG 产品的设计原则

上一期聊到 PLG 的核心是好产品,而什么是好的产品让我想起 Jesse James Garrett 那本经典的《用户体验要素》,这本写于 2002 年的书放在今天去看依然经典。在 Garrett 的书中,用户体验最底层是战略层,即用户需求,好的产品首先要满足用户的需求,解决用户的痛点,用现在的话来说就是要有 Product-Market Fit。PLG 实际上又让我们回到起点去关注产品本身,回头去看 PLG 的出现其实也有一定的必然性。

What is Product-Led Growth? How to Build a Software Company in the End User Era -
Whenever someone asks me what product led growth (PLG) is, I like to start by asking them how their company adopted Slack.
OpenViewBlake Bartlett

B2B 产品的销售模式经历过 3 个阶段:

  1. 80–90 年代称之为 CIO 时代:软件的销售对象主要是企业内部的 CIO,他们负责购买各种第三方的软件。当时考量一个产品是否要购买的关键要素是这个产品能否与公司内部的其他系统相互集成,对 CIO 来说这样的产品更加容易维护。
  2. 21 世纪之初则是管理者时代:这个阶段软件的销售对象主要是针对团队的管理层,管理层购买软件的决策因素是 ROI,即购买这个软件是否能够帮助团队达成既定的目标,如果可以,那么价格是否便宜。
  3. 如今则是用户时代:软件不是被销售给对方的,而是有用户自主发现并且自助购买的,因此人们说「Softwares are bought, not sold」
Your Product Is Your Go-to-Market Strategy. Here’s Why.
Get the product right, and it will sell itself — or your customers will help you sell it.
Expand UponScott Maxwell

销售对象的改变使得产品 Go-to-Market(GTM)的策略也在不断的变化,经历过 4 个阶段:

  1. Field Sales:简单理解就是「地推」,销售代表在线下约见 CIO,给客户演示产品的功能,代表们花费很长的时间在见客户的路上。
  2. Inside Sales:此时销售代表更少的约见客户,而是坐在办公室里通过打电话给从各种渠道获取的销售线索,以 Oracle 和 Salesforce 为主,他们从各种渠道购买销售线索,然后一个个打电话。
  3. Marketing:随着互联网的普及,线索的获取越来越容易,销售代表不可能每个线索都打电话或者发邮件过去询问,效率太低,随着搜索引擎的成熟,通过 SEO 等市场的方法,让市场部先验证一下这个线索是否有效,然后再交给销售代表去跟进。HubSpot、ExactTarget 是这方面的高手,前者依赖于 Content marketing 获取了大量的线索。
  4. PLG:随着互联网的发展,人们获取信息的方式更加容易,Leads 数量的增多依然需要大量的销售代表,那有没有一种更加低成本并且可规模化的方式来获取客户呢。Atlassian 在创世之初就使用这样的模式,因为他们没有足够的销售于是就在网站上让用户自己付款购买软件,而这样的模式随后被证明是有效的。

销售对象和 GTM 策略的改变有着非常明显的时代特征,上世纪 80–90 年代互联网还没有普及,也没有 Google 这样的产品,人们获取信息的方式非常有限,即便有很好的产品出现,客户也难以察觉,线下销售就成为人们获取软件的渠道。随着电话成本的降低,电话成了更好的 GTM 的渠道。21 世纪互联网飞速发张,Google 成为人们访问互联网的门户,搜索引擎的崛起和广告成为主流,人们发现信息的渠道也更加多样化。

在互联网时代以前,软件市场相当于是卖方市场,因为信息匮乏,购买软件的人并不知道市面上有哪些软件可以选择,销售代表可以抢占先机来获取用户;互联网普及之后,信息快速普及,同时软件市场上也开始出现大量的同类产品,市场转化为买方市场,买方有了更多的选择,因为所有的信息都很容易获得,产品本身成了购买者关注的重点,与 PLG 成为主流。

Age of Connected Work: The New Era of PLG
Product-led growth has entered a new era: the Age of Connected Work. Now, software is a fundamental utility powering our working lives.
OpenViewKyle Poyar

PLG 有一个明显的特点就是「可规模化」,虽然 Content marketing 也可以规模化,但是在 Marketing 作为 GTM 的主流的时代,当 MQL 产生之后还需要销售代表进行跟进才能转化为客户,也就是 MQL -> Customer 这个过程是不可能规模化的。而 PLG 则注重让用户 self-serve,用户自助购买不需要人工介入,因此整个流程从 Acquistion 到 Activation 再到 Retention 都可以规模化。

OpenView 在这篇中提出了 PLG 的 11 个原则,我认为没有必要这么多,因为 Growth 是一个系统,这些原则实际上都是可以通过 1 个主要的原则推导出来,这个原则就是「为用户设计而非客户」,这个是从用户的角度来理解,而从商业的角度来理解就是「等价交换」。

为用户而设计

  • 原则 #1:Build for the end user
  • 原则 #9: Monetize after you deliver value

实际上所有的原则的核心都是「Build for the end user」,如今一些 2B 软件的购买者实际上是用这个产品的用户,而决定购买因素主要是产品是否能够解决用户遇到的问题。当用户了解产品可以解决自己的问题时,也就感受到了产品所能提供的价值,在此之后再鼓励用户付费,用户也更容易转化。

我把 原则 9 提前的另外一个原因是即便是一个全新的产品,从第一天开始就要考虑商业化,虽然说用户价值优先,但不代表着不可以在这个阶段去获取商业价值。事实上产品的早起就思考商业价值也可以进一步验证 Product-Market Fit(PMF),如果产品真的帮助用户解决他们的痛点,用户一定会选择付费。

  • 原则 #2:Build to be discovered
  • ‌原则 #7: Deliver instant product value

原则 1 和 9 对于验证 PMF 很重要,当产品有了 PMF 之后我们才去讨论如何让更多的人了解产品。PLG 的一个关键特征是 touch less,即用户发现和购买的流程尽可能的减少人为干预,让用户可以更加容易的自助的完成发现和购买。用户自助发现产品的一个关键渠道就是搜索引擎。

我把原则 7 提前是因为它和 discovered 密切相关,当用户发现产品之后,产品要尽可能的在更短的时间内让用户感受到产品的价值(Time-to-Value, TTV),时间越短越好,而「Instant」这个词并不夸张。我之前有个诉求是想要根据网站访客的 IP 来识别这个访客是来自哪个公司的,通过 Google 我找到了 Clearbit,然后在 Clearbit 的 Landing page 上我直接看到了我们公司的官网,显然 Clearbit 通过这个工具直接让我看到它可以通过我的 IP 识别到我是来自哪个公司的1,在这一瞬间我就感受到了 Clearbit 的产品价值。

  • 原则 #8: Deliver instant customer experience

Touch less 鼓励尽可能的减少人为干预,并不代表着完全不与客户接触,有些产品过于复杂,用户在使用的过程中难免会遇到问题,这些问题越快解决用户也就越容易的感知到产品价值。

  • 原则 #3:Build to meet your users where they work

企业用户有一个共同点就是用户不可能只使用一个软件来完成所有的工作。所有企业用户都会使用聊天工具,可能是 Slack 也可能是 Teams;同样他们也一定在用文档工具,可能是 Notion,也可能是 Office 365 或者 Google docs。不存在一个软件可以满足企业用户的所有需求,因此「为用户而设计」就要考虑用户所有可能的使用场景。例如当你在 Slack 里面粘贴一个 Google docs 的链接的时候,你无需再附上文档的名称,Slack 会自动获取文档的名称;在或者你在 Notion 里面修改了某个重要文档,你个改动是可以通知到 Slack 中让其他关注该文档的人知晓这次改动。

  • 原则 #4: ‌Build for openness

为了尽可能满足各种不同客户的使用场景,产品就需要有更多的 integration,如果要把用户使用的所有第三方产品都集成进来显然是不可能的。Openness 的意思是说,产品要保持开放(开放 API),让第三方可以帮助产品做各种 Integration,类似于 Zapier 这样的产品就可以帮助产品快速 Integration 成千上万个第三方应用。

  • 原则 #5: ‌Build for flexibility

Openness 是指产品对外要保持开放,而产品内部同样也需要开放(灵活),原因同样是企业用户不仅仅是用的上下游工具千差万别,他们的工作模式和流程也是千差万别,以 Jira 为例,虽然大多数软件开发公司都在使用 Agile,但每家公司的 Agile 的实施过程都各不相同,这就导致使用 Jira 的过程中用户角色和 ticket 流转过程也不相同,Flexibility 的意思就是用户可以根据自己的诉求在配置不同的 ticket 流转过程,来适应自己的工作流程。

  • 原则 #6: Build community as a competitive advantage

Flexibility 与 Complex 总是同时出现,一个灵活性非常高的产品复杂度也会更高,而当产品变得复杂的时候教育用户就成了比较棘手的问题。你当然可以通过完善的帮助文档来用户学习如何使用产品,但用户通常不会按部就班的学习如何使用产品,他们会自己探索,只有当遇到具体的问题的时候才会去寻找帮助,而这些问题在灵活的产品中几乎无法穷尽,通过社区,用户可以相互交流自己的使用场景和遇到的问题,这些记录都可以让有相同的问题的用户来参考。显然社区不是给新用户准备的,它跟 Deliver instant product value 相违背,社区更多的面向是用户向更高级的转变。

等价交换原则

以上几条的核心都是「为用户设计」,都是关于如何创造用户价值,但做产品不可能只考虑用户价值,用户使用产品实际上是一种「交易」,即通过商业价值来换取用户价值,这其中我觉得最重要的理念就是「等价交换」。所谓等价交换是指产品能够为用户带来多大的价值,就可以收取相应的费用。SaaS 软件商业化通常采用订阅制,用户每个月都需要支付一定的费用才能使用产品。以下几个原则都是跟商业价值有关,不过这几个原则我认为跟 PLG 并无关系,只要是 SaaS 产品都适用。

  • 原则 #10: Monetize based on usage

以 Apple Music 为例,每个月支付 $10.99 就可以听其中的所有音乐,但无论你每天只听 1 首歌还是 100 首歌,Apple Music 带给你的价值并不会有多大的差异;而 Shopify 则不同,商家通过 Shopify 开店,每个月能够获得 GMV 越多,价值也就越大,那么 Shopify 就可以根据商家的 GMV 抽佣,因为它提供了更多的价值,这就是 usage based pricing,这里的 usage 不是随便什么用量都可以,而是一定跟用户的价值相关联的,usage 的变化是可以反映出用户价值的变化的。

  • 原则 ‌#11: Monetize beyond software

最后一个原则其实所有的软件都适用,用户购买软件的目的不是使用软件,而是解决一些特定的问题,软件只是解决这个问题的工具,除了软件本身以外,软件使用的最佳实践(best practice)作为一种服务也可以收费。OpenView 给出的例子是 Shopify Payments,我觉得并不合适,Shopify Payments 类似于 Amazon 把自己服务器基础设施做成一个平台类似,将软件中的一个模块做成了一个 PaaS(Platform-as-a-Service),是通过现有产品延伸出来的新产品,作为第二增长曲线的新产品。


PLG 显然并不适合所有的产品,尤其是极度复杂,用户难以在短时间内上手并理解其价值的产品,他们需要销售代表向用户演示产品如何运作,例如 Workday2。抛开 PLG,为用户而设计的产品永远都不会过时,这里的「为用户而设计」已经不仅仅是产品的 UX 所代表的用户体验,而是整个用户生命周期中的体验,从发现产品到试用,再到付费,续费和升级。Hila Qu(Former Director of Growth)也提到 B2B 可以从 B2C 领域学习很多增长模式3,而其中的一个关键点就是 B2C 鼓励用户自助服务。归根结底,无论是面向企业还是面向消费者,产品最终面向的都是人,好的产品是那些真正能够解决用户痛点的产品。


🔲 ☆

Issue #4 - 产品流量获取

要说 PLG 有什么特点,我觉得最重要的就是「可规模化」。可规模化的意思是边际成本低,也就是获取 1 个客户的成本和获取 100 个客户的成本是差不多的。所以广告、内容影响、社交网络影响以及 KOL 这些方法都不能算 PLG,因为不可规模化,那广告来说,假设获取 1 个客户需要投 10 美金的广告费,那么获取 100 个你至少有投入 1000 美金。社交网络和内容影响虽然不需要直接投钱,但是规模化需要内容团队的规模化,需要有足够多的人来实现产出的规模化。线下活动和 SDR 的模式就更不用说了,那么 PLG 的获客看起来就只能是依赖是 SEO 和口碑。

Hot $10 billion productivity startup Notion is acquiring Cron, a calendar app backed by top execs at LinkedIn and Figma
Notion has been on the rise over the past few years and is acquiring the new calendar app Cron as it looks to support its growing user base.
InsiderPaayal Zaveri

Notion 在 2022–06–09 宣布收购了 Cron,后者是使用 Mac 原生技术开发的日历工具,主要集成 Google Calendar 和 Outlook,本身并不提供日历服务。在 Atlassian 文章中提过,收购其实也是一种增长方式,Notion 在 2021–09–08 的时候收购了专注自动化流程的软件 Automate.io,2022–07–12 又收购了专注数据报表的 Flowdash。显然 Notion 想要快速扩充产品线,通过收购来扩展产品的使用范围。虽然 Notion 已经足够强大了,很多人也会把 Notion 作为 GTD 工具,但是 GTD 没有日历肯定不行,于是 Cron 就是一个不错的选择。采访中 Cron 的创始人 Raphael Schaad 已经和 Notion 的创始人 Ivan Zhao 已经是好朋友,两人经常聊天,发现两家公司最终的目标其实是一致的,都是为了提供先进的工具来解放人们的生产力,而日历作为生产力工具中非常重要的一环,也恰恰是 Notion 所缺失的。

我觉得 Notion 应该不会直接开发一款日历服务于 Google 和 Outlook 之间竞争,而是利用 Cron 现有的功能来打通 Google Calendar 以及 Outlook,原因在于日历不仅仅是一个日历服务而已,背后是 Google Suite 和 Office 365 一整套体系,最起码现在对于 Notion 来说,还不是直接竞争的时候。

SEO Case Study: How Canva Used Outreach & Content To Grow
In this SEO case study, we highlight how Canva used SEO, backlink outreach & content marketing to grow their business to a $6B valuation.
Foundation MarketingRoss Simmonds

Foundation 是一家内容营销的咨询公司,他们分析了很多 PLG 公司流量获取的关键,在他们看来 Canva 的流量获取主要依赖于 SEO,Similarweb 的数据显示 canva.com 的流量有 20% 来自搜索引擎,更多的则是直接访问。

其实从产品的功能来说,创作类的工具,例如 Notion、Canva、Figma 这类型的工具都很适合用模版作为关键词。不同于 Canva,Notion 的模版更多是由社区提供(PGC),而 Canva 虽然也是创作者提供,但是不同于 Notion 自发的社区,Canva 的内部有一个团队专门寻找创作者来贡献内容。那么 Canva 有没有可能走 Notion 的路线,或者 Notion 走 Canva 的路线呢?后者我觉得没有问题,PGC(由专业人提供内容)其实 Notion 也已经有了,Notion 也在官网上线了专门的模版页面。但是 Canva 走 Notion 的社区模式我认为不可行,原因在于人群,虽然 Canva 相对于 Figma、Sketch 或者 Adobe 全家桶来说已经是非常的亲民了,但是除了专业的作图人员之外,普通人不会每天都去使用 Canva,但 Notion 却可以是人人每天都在使用的工具,Notion 的受众群体更广。

How Calendly Harnesses PLG and Virality for Growth - OpenView
Calendly is a great example of a product that has used product led growth and virality to great advantage. Learn how they do it in this article.
OpenViewOji Udezue

Calendly 则走了另外一条不同的路线,这也与 Calendly 本身的产品特性有关。Calendly 本质上是一个预约日程的工具,发起人向接受人发送一条链接,接受人可以看到可预约的时间,因为 Calendly 也是和 Google Calendar 以及 Outlook 做绑定,所以如果你私人日程上有效的时间被 Book 了,那么这段时间在 Calendly 中就会显示为不可用。

所以在 Calendly 的场景中一定会至少存在 2 个人,会议的发起人和接受人,发起人把链接发给接受人,接受人打开链接后选择了某个日期,实际上也就变成了 Calendly 的用户,在之后的某个时间他也会变成一个发起人向其他人发送 Calendly 的链接,于是 Calendly 就利用产品内在的机制让产品在用户之间快速传播。在 Calendly 的页面你可以清晰的看到「Powered by Calendly」的标识。

The Growth Toolkit: How Shopify Landed 188,029 Links & 2M Visits
Shopify the powerhouse continues to push forward and make waves. But how did they get started? Check it out here.
Foundation MarketingRoss Simmonds

Shopify 最初的获客方式依赖于 Free tools(免费工具),所谓的 Free tools 就是开发一系列的免费工具,让用户可以在所搜引擎找到这些工具,从来来到你的网站,对品牌进行曝光,进而让新用户有机会了解产品并转化。Free tools 也不是随便搞一大堆工具放在网上就好,首先工具的目的是为了吸引流量,所以本质上工具本身也就是关键词,这点和内容影响类似。而关键词是什么取决于你的用户群体,他们经常会搜索什么内容,有些内容是你的产品本身就提供的,这些关键词应该主推产品本身,而有些关键词也是同样的用户群体会搜索,但是你的产品本身并不提供这样能力,那就可以通过 Free tools 来作为补充。

Shopify 本身是开店平台,用户群体简单来说就是想要开店的人,而想要开店的人会需要搜索哪些内容,首先你需要想一个店铺的名称,然后买一个对应的域名,设计品牌 Logo 和 Slogan 等等,这些当然不是 Shopify 的主业,所以 Shopify 提供了一系列这样的工具来生成关键词吸引用户。

2017 年 Shopify 收购了 Oberlo,后者在 2021 年每个月能够带来 2M 的用户,收购再一次为增长提供了动力。

这里补充一下收购驱动增长算不算 PLG,在我看来算是,因为收购本质上也是为了扩充产品,只不过产品的功能原因是内部团队从零到一的开发变成了直接买一个,而开头说的 PLG 要保持规模化,收购实际上是可以做的规模化的。收购并不是说收购一款产品可带来 100 个用户,要在获得 100 个用户你需要在收购一款产品;每一次收购是可以持续不断带来新用户的(自然也会存在失败的收购),所以这里跟规模化并不矛盾,虽然一次收购可能非常贵,但这些钱是一次性的,而规模化里面的「低成本」是指「边际成本」低。


在流量获取上,方式需要与产品自身的特点相结合,Canva 和 Notion 无法复用 Calendly 的方式,同样 Shopify 也无法复用 Notion 的案例。如果产品本身是用于内容创作,特别是公开的内容创作,那么模版就是很好的方法;如果产品本身就需要多个人才能使用,那么尽可能的让双方都能够成为自己的客户,并鼓励分享;Free tools 是用于所有类型的产品,因此无论是 Shopify 还是 CRM 领域的 HubSpot 都在出用类似的方法,而你说 Notion 怎么不出 Free tools 呢,显然 Free tools 的效果不如 UGC 更好,毕竟最疯狂的增长需要网络效应,而 Notion 和 Calendly 天然带有这样的能力。

🔲 ☆

Notion:社区驱动增长

Notion:社区驱动增长

2018 年 Notion 在 Product Hunt 上发布了 2.0 版,随即获得 6000 多个 Vote1,如今这个数字已经是 9000+。用 Notion 创始人 Ivan Zhao 的话来说:

Notion 2.0 is really the 1.0 for us.
Notion:社区驱动增长

Notion 2.0 真正意义上实现了 Notion 的 All-in-one workspace。我使用 Notion 主要是因为团队在使用,我个人的笔记并不适用 Notion,我更倾向于离线的笔记系统2。Notion 作为团队写作的 All-in-one 产品可以说是无人能敌了,在此之前我们团队的文档管理使用过 Confluence, Google docs 以及一些开源的 Wiki 系统,但最终还是选择了 Notion,即便按人头收费确实很贵,但也确实很好用。

产品形态

笔记类的产品数不胜数,我自己用的有 Microsoft OneNote、Bear、Evernote 等,本质上来 Notion 也是一个笔记工具,从笔记工具来看 Notion 最大的区别是基于云服务(SaaS 软件),不同于其他笔记产品,你的笔记本质上还是在你的本地,即便没有网络你也可以访问你的笔记。Notion 则完全基于云,基本上没有网络你就无法访问你的笔记了,这也是我个人不使用 Notion 的原因,但现实中没有网络的情况实际上已经很少见了,尤其是移动互联网的发展,现代人几乎每时每刻都在联网中。

从能力上来说,Notion 与这些前辈们也完全不同,传统的笔记软件是基于内容(文本或者图片),而 Notion 是基于 Block,这个 Block 可以是文字、图片、DataBase、Board,并且 Block 之间可以相互关联和转化,这种灵活性让 Notion 以及超越了笔记软件,而成为一种灵活组织内容的软件。也正是这种灵活性让 Notion 几乎无所不能,吸引了大量的忠实用户。

增长模式

Notion 每一次更新都会在 Product Hunt 上发布,每一次发布都为 Notion 吸引了大量的关注,Notion 也曾经尝试过自己做一些内容:博客、视频来吸引用户使用,但最终他们发现其实已经有一些粉丝自己组建了各种各样的社区,在其中相互交流分享心得。其中 Ben Lang 作为一个拥有大量粉丝的 Notion 论坛的管理员最终加入了 Notion 来负责社区运营,这些社区包括 Reddit、Facebook Group 等,如今 Notion 的 Reddit 成员已经超过 20 万了,社区最终成为了 Notion 最大的获客渠道。

有了获客的渠道还需要将这些流量都够转化,转化的方式就是尽可能的让用户能够快速感受产品的价值。Notion 依然是依赖于社区中的 KOL,他们通常热衷于写各种各样的 Notion 教程,你也可以在 YouTube 上找到大量分享如何使用 Notion 的视频,甚至一些还是付费教程,并且有些人已经以此为生。这些 KOL 很像 Notion 的 Partner,Notion 通过提供优秀的产品,让这些 KOL 可以分享自己的观点以此获利,但是传统的 Partner 通常需要给他们分成,例如微软 Office365 通过 Partner 每个月可以获取 50K 的 SMB 客户3。但 Notion 与 KOL 并没有实质上的商业关系,Notion 并不需要给 KOL 分成,相反 KOL 需要通过自己的努力让客户来购买他的课程,或者在 YouTube 上吸引更多流量。除了课程,KOL 也会发布一些 Notion 的模版,这些模版也可以帮助新人更快速的了解 Notion 能够做什么,也可以快速上手产品,其中比较有名的 Newsletter OS 这个模版已经为创作者产生了 $68K 的收入。Notion 也顺水推舟的在自家的官网了开设了 Template 板块,专门放置这些 Templates。如果你有关注 Product Hunt,你可能会注意到最近一段时间,几乎每天都可以看到与 Notion 相关的产品发布,大部分是各种各样的模版,尤其是 2020 年因为疫情的缘故,远程办公有了大量的市场需求,Notion 相关的产品也指数级上升4

Notion:社区驱动增长

Notion 的营收大部分依赖于企业客户,如何让更多的企业客户购买 Notion 也是问题,Notion 的方法依然是依赖于社区。正如我前面提到的,我们公司内部已经有很多 Notion 的客户了,他们也会分享自己的心得,于是 Notion 就招募这一批人成为 Notion Champions,让这些人在公司内部推广 Notion,邀请更多的人加入 Notion,成为企业客户。也正是如此 Notion 宣布个人版永久免费,实际上也是为了降低门槛,能够让更多的人使用 Notion,而最终期望这些人都能够成为 Notion 的拥护者,无论在公司内部还是对普通用户都可以推广 Notion。

商业模式

Notion 的收费模式可以说是非常标准的 SaaS 了,收取基础的订阅费,对于团队版和企业版则是按照人头收费,这部分也正是 Notion 收入占比最大的。

观点

如今的 Notion 俨然是一个面向企业的工具了,但他依然还是那个简单易用的笔记工具,企业版中的个人协作一些审计功能等普通用户也用不到,难得的是即便是加入了各类的企业功能,Notion 依然对个人用户友好。

作为 All-in-one 的产品,人们常常说 Notion 可以取代 JIRA、Airtable 等一大批工具,也正如我在讨论 Beamer 的时候谈到,大而全的产品更适合中小型公司,大客户则需要更深入某个领域的工具。在笔记领域,Notion 是非常深入的,也是它能够吸引大客户的原因,而在广度方面,如果轻量级的使用,Notion 确实可以替代 JIRA,这也是中小型公司所需要的,一个产品解决所有问题。但是对于大客户来说,Notion 是不可能替代 JIRA 的,如今的 JIRA 看起来已经是一个非常臃肿的产品了,但是它确实非常强大,对于流程的各种自定义 Notion 一时半会也不能追赶,也不会去追赶,取代 Airtable 等产品也都是类似。

我自己日常使用中,有些正式的文件,或者需要与外部交流的,大家还是倾向于使用 Google Docs 或者 Microsoft Office,后者可以离线修改,如果有些内容不便放在网络上,那么通过邮件可以直接发送给相关人,这些场景 Notion 大概率不会去涉及,可能对它们来说这种场景过于小众,也难以撼动 Microsoft 和 Google 两位老大哥的地位。

微软在去年年底的时候宣布了 Microsoft Loop,看得出 Microsoft 也心动了所谓的 All-in-one workspace,毕竟微软已经打造了那么多的 Workspace,再通过一个工具将其整合进来也顺理成章,我们也看过了 Microsoft Team 如何抢夺 Slack 的市场,微软凭借多年与大客户打交道的经历,或许对 Notion 在未来会成为不小的威胁。

不过 Notion 带给我的思考是哪些产品更适合 Community-Led Growth(社区驱动增长,CLG),另一个 CLG 的成功案例是 Figma,观察这两个产品我将其归类为创作工具,两者都有着丰富的 Templates,并且这些 Templates 也完美的阐释了产品的使用方式,无论是制作 templates 的人还是使用的人都能从中收益。而 templates 的也意味着产品足够开放,它从不限制用户如何使用它,没有所谓的 Best practice,反而它鼓励用户用自己的方式来使用产品。这让我想到开源产品,大部分的开源产品其实都是由社区驱动的,例如我最喜欢的笔记工具 Emacs,虽然严格来说 Emacs 是一个 IDE,但产品本身并没有限制用户只能用它来写代码,其中的 [[][OrgMode]] 就是将 IDE 扩展成了笔记工具和 GTD 工具,而插件 Org-roam 又在 OrgMode 基础之上将其扩展成了知识管理工具,同样也有大量的插件是基于 Org-roam 又做了更多的拓展。产品本身的不设限让核心用户愿意不断的去探索各种各样的使用方式,并将这些使用方式分享出来不断拓宽产品的边界。从这个角度去看 Notion 开放 API 以及收购 Automate.io 也都是顺利成长,两者都是在让 Notion 变得更加开放,让创作者有更多的发挥空间。另外就是 Community 的成员是否可以以此获利,我觉得并非必要条件,但是 nice to have,就像开源社区的大部分人都没有从中获利,更多的获取的是参与感或者荣誉感,但也有可以从中获利的,最起码产品不应该阻止或者干预这个过程。

总结下来,用户体验无论是何种 Led Growth 模式下都是不可或缺的必要条件,以此来吸引核心用户;在此之上产品的灵活性和开放性能够让一部分的核心用户从使用者的角色变为「创作者」的角色才是 Community 的关键。这也就让决定了不是所有产品都可以使用 Community 模式,尤其是面向特定行业的产品、或者面向企业客户的产品,例如财务类的软件,这些产品本身的局限性决定他们只能按照特定的方法来使用,即限制了使用者的使用方式,也难以将使用者转化为「创作者」。


  1. https://www.producthunt.com/products/notion ↩︎
  2. 我正使用的是 OrgMode 和 OrgRoam 插件来记录笔记。 ↩︎
  3. The Most Successful SMB SaaS Acquisition Channel Ever Built ↩︎
  4. How Notion fostered an avid community on Product Hunt ↩︎
🔲 ☆

Beamer:优秀的产品运营平台

Beamer:优秀的产品运营平台

Beamer 给自己的定位是 Product Marketing Platform,其实就是运营工具,但是与国内各个大厂的运营平台相比它又显得格外简单。Beamer 是一家特别低调的公司,网络上鲜有其相关的信息,Crunchbase 的数据显示 Beamer 整个公司只有 1-10 个人,从 2017 年至今只有一次融资记录,还是发生在 2017 年,具体金额也不详[1]。但是 Beamer 实际上在 2019 年就已经开始有 $450K 的营收了,应该也是实现盈利了,2020 年更是上一年的 2.4x,达到了 $1.1M,2021 年($1.9M)也是上一年的 1.76x[2],收入的增长也是相当迅速。这么一间低调的公司能够如此快速增长也让我很好奇他们是怎么做到的。

产品形态

我们最初发现 Beamer 是搜索是否有一个工具可以来管理什么时候向用户推送什么信息,因此也可以说 Beamer 是一个站内通知管理的工具,然后发现了两款产品:Beamer 和 Appcues,后者的特色在于非常灵活的 Popup 配置和用户 Onboarding 流程的可视化配置。虽然两者目的都是 Engage 用户,但侧重点略有不同,Beamer 更注重消息的传递,可以通过 Popup、消息面板、Web push、Email 等,而 Appcues 则主要是 Popup,然后把这个功能做的很极致。而价格上 Appcues 可以说是 Beamer 的 10x。

Product Marketing Platform 在国内是大家熟知的运营平台,但即便在国内,也没有一个非常大的 SaaS 公司是专门做这种平台的,大厂的运营平台基本上都是内建的,原因也很简单,运营平台有大量的客户数据,大厂不愿意把自己的数据放在第三方平台;另外就是客户运营很大程度上依赖于个性化,这就需要与业务系统做深度整合,同样还是数据的问题,如果用第三方,那么系统如何将第三方工具与自己的数据平台打通也是问题。海外也更不用说了,也没有相应的 SaaS 产品。如果搜索运营平台,很多时候出现的是 HubSpot 这类的 CRM 系统,无论是客户运营还是 CRM 其最核心的资产都是客户,两者其实有很大的重叠,所以像 Beamer 这种从运营平台切入,做到最后的形态大概率也会成为 CRM。

其实作为一个运营平台,用一句话来说,要做的事情就是把正确的内容传递给正确的用户。这里面有几个信息点:

  1. 客户:最核心的资产,需要能够根据用户特征确定用户;
  2. 内容:用户需要对内容进行管理,内容配置需要多样化;
  3. 个性化:不仅可以圈定用户,最好还可以 AB 测试;
  4. 数据分析:活动上线后需要有工具可以持续的关注整个活动的效果;

任何运营平台都需要以上 4 个最基础的功能,Beamer 也是如此,不过所有功能都比较基础,而上一次我看到类似的工具是 Mixpanel,但是 Mixpanel 后来放弃了内容管理,也就放弃了 AB 测试,转而把自己定位成一个数据分析工具,把数据分析做的更完善,原因正如前文所说,资源有限,聚焦于更核心的功能来服务大客户,比做一个什么都有但什么都做不好的产品来服务中小客户而言,大客户显然可以带来更多的营收。这符合马太效应,大客户通常有更多的资源,愿意付出更高的价格,而且更加稳定,流失率会更低。

产品功能

Beamer 的功能类型有 3 中,虽然都是和客户运营相关,但其实 3 者并没有很大的关联性,每一个都可以独立做一个产砒霜的:

  1. 内容通知:一个简单版的 CMS 通知系统,可以通过 Popup、Web push、Email 来向客户发送通知;
  2. Feature Request & Roadmap:用户可以通过 Beamer 给题提需求,也可以给已有的需求清单投票;
  3. NPS:让用户给产品打分,实际上反应用户体验和忠诚度;

这三个功能都是为让用户运营在做,但其实内在并没有很大的关联性,即便把这三个功能拆分成 3 个产品也不是不行。我们最初是通过「内容通知」发现 Beamer,其他两个功能我们在内部演示之后也有其他部分对此感谢,所以算是一个加分项。与之相比的 Appcues 其实也有 NPS 和 Survey 功能,而 Beamer 的 Survey 也正在开发中。

增长策略

Beamer 的官网流量在今年 8 月份差不多有 $1.1M[3],并且过去 3 个月一直在保持增长。且流量分布分绝大多数是靠外链带来的的。因为 Beamer 的 Changelog 以及 Roadmap 功能实际上是可以呈现在一个单独的页面上,这些页面上都会自动带上 Beamer 的链接,间接让 Beamer 这个品牌曝光给了更多人。这种自动生成页面并且加上自动链接在 SaaS 中算是一个非常常见的功能,像 Hotjar 如果你使用免费版就一定会打上 Hotjar 的品牌,就像传统软件的水印一样,间接的为产品和品牌带来了更多曝光。

Beamer 也有一部分流量来自于付费广告,但少的可以忽略不计,这种体量的小作坊公司并不适合过早的去做付费引流,PLG 才是更合适。Beamer 也正是如此,与上次讨论的 PostHog 不同,Beamer 采用的是 Free Trial 加 Freemium 的混合模式,即便它有基于 MAU 的数量来限制的策略,但 MAU 实际上对 Beamer 的成本影响并不大,而是作为一个区分大小客户的指标(中小客户 MAU 肯定不高,而大客户则不然,所以大客户也自然需要收取更多费用),既然这些功能对成本影响不大,那确实可以一开始就放开所有功能让客户使用。虽然网站上没有写,但 Beamer 是有一个 Free Plan,当 14 天的试用期结束后就会转为 Free Plan,仅保留 Changelog 的功能。Changelog 本身有反链,也是最适合作为免费功能提供小客户使用。

Beamer 本身也很特别注重用户体验,他们使用 Intercom 作为 Livechat,Beamer 应该只有 2 个 CSM(Customer Sucess Manager,客户成功经理),每次跟我聊天基本上不是 Anne 就是 Laura,她们俩都不是实时在线聊天,也是因为时差的问题,基本上我问一个问题要过一两个小时才会有人回复,但是她们也确实很专业,基本我提出的所有问题都会在几句对话中解决。并且 Beamer 所有的营销邮件也都是从 Anne 的个人邮箱发出,让你感觉不是那么的营销,会有更高的打开率。

Beamer:优秀的产品运营平台

商业模式

作为一个标准的 SaaS 产品,Beamer 的几个 Plan 都是收取固定的订阅费用,NPS 虽然是一个 Add-on,并不包含在基础的 Plan 中,需要额外付费。跟 Usage 相关的应该是客户数量,Starter plan 的 MAU 是 5K,Pro 是 10K,Scale 是 50K,Beamer 在 9 月份对价格做了一次调整,原本的 Scale Plan 实际上是不限制活跃用户数的[4]。这点 Beamer 跟 Appcues 类似,只不过后者的价格是 Beamer 的差不多 10 倍。

Beamer:优秀的产品运营平台

观点

很难说 Beamer 会不会走到 Mixpanel 的道路,当用户群体逐渐倾向于大客户的时候,有限的资源一定会倾斜,而专注于提升某一个领域的能力。实际上单说发通知的能力,我们自己已经对 Beamer 的 SDK 做了很多改动,来满足一些我们特殊的要求。实际上我们的诉求 Appcues 都可以做到,只是成本比较高,而我们的改动也在 1 天内就可以完成,但随着使用场景越来越多,使用的部分也也来越多,当不断的个性化需求被提出来的时候我们自己开发改动的成本也增加,那个时候如果 Beamer 不在这个「通知」这个功能上做的更加灵活,我们可能也会切换到 Appcues。

我觉得从一开始小而全到大而专,再到大而全似乎面向企业的 SaaS 产品的必经之路,一开始小而全实际上是通过产品的特点以及性价比来吸引更多中小客户,随着产品知名度的增加,客户群体也在逐步变化,大客户强大的钞能力会左右产品的发展方向,开发资源不可避免的会倾斜。此时可以像 Mixpanel 那样大刀阔斧的直接砍掉对营收贡献不大的功能,果断抛弃低收入的客群,让产品更加聚焦。Beamer 显然还没有遇到这个问题,但是他们也不可避免的在朝着这个方向发展,8 月份的价格调整也可见端倪,新增了一档 Enterprise Plan 必须与 Sales 谈合同才行。

Beamer 未来会将资源倾斜在哪里还看不出来,或许他们也不知道,以现有的功能尽可能多的获取更多客户,然后观察客户的使用方式,找到客户愿意加钱获取的功能才能找到方向。从我个人作为用户来看,我自然是期望它可以朝着 Appcues 的方向去做,但如果是从产品经理的角度去看,我可能会避开 Appcues 而做差异化竞争。


  1. https://www.crunchbase.com/organization/beamer/company_financials ↩︎

  2. https://getlatka.com/companies/beamer ↩︎

  3. https://www.similarweb.com/zh/website/getbeamer.com/#traffic ↩︎

  4. Everything you need to know about our plans update ↩︎

🔲 ☆

RICE 框架:使用定量的方法来决定需求优先级

对我来说,产品设计有两种方法:一种是根据产品所在的领域和模型的自上而下的设计,称之为概念模型设计;另外一种是根据具体的业务指标而进行的自下而上的设计,称之为假设驱动设计。两种方法的使用场景各有不同,本文介绍的 RICE 框架主要是应用在后者当中,可以帮助团队定义需求优先级。

概念模型设计是从产品自身所在的行业和用户场景出发,找出在用户场景中出现的所有概念以及这些概念之间的联系,当中的概念和概念之间的关系与产品的商业模式和形态无关。例如设计一个自动贩卖机的系统,当中一定有「订单」「商品」「买家」这些概念,一笔订单一定由买家创建,并且包含了至少一个商品,买家付款后拿走商品,商品的库存要对应的减少。可以说这些概念和逻辑在现实世界中已经存在,不需要去发明创造,也没有定制化,无论这台贩卖机是面向国内还是国外的人群,是放在学校还是小区,卖到是零食还是玩具,其概念和逻辑都是一致的,你可能会想到「中台」这样的概念,确实如此。概念模型设计也会涉及到需求优先级的定义,与假设驱动的设计不同,概念设计通常不需要「假设」,因为产品最初要解决的问题就已经给需求定义了范围了,自动贩卖机的系统大概率是不会加入像「代言人」这样的概念的。这样的设计更多是从产品的战略层驱动的,战略决定了产品的方向,也就是概念延伸的方向,概念延伸的路线就是需求的优先级。

假设驱动的设计更多的是针对更加具体和细节的目标,这些目标与产品的概念无关,而是在已有的概念中不断优化,例如提升用户转化率或者功能渗透率这样的指标。如果说概念设计的推进是相对比较稳健,像是正规部队作战那样,那假设驱动的产品设计更像是游击战,虽然目标是固定的,但是达成的方式却有很多种,有时候可能只是改个文案,或者换个标题颜色就可以。所以对于这类型的需求,主要关注的是战术上是否有效,效果更好的需求优先级自然就更高,那么问题就是如何判断哪个需求的效果更好。

在互联网行业,你可以也会常常看到团队中产品经理之间为了谁的需求先做而争吵的面红耳赤。很大的原因是大家都没有办法说服对方,或者说没有找到一个团队内都认同的机制来合理的评估每个人的需求。在没有合理的制度规范下,每个人都会认为自己站在用户的这一边。而 RICE 就是通过一种量化需求优先级的模型,通过 4 个纬度给需求打分,然后计算出最终的得分,通过比较每个需求的得分来计算优先级。RICE 这个框架由 Intercom 提出,最开始的版本只有 ICE,之后的演进中又增加了 R,RICE 代表的意思是:

  • (R)each:触达的广度;
  • (I)mpact:影响的深度;
  • (C)onfidence:对需求的信心;
  • (E)ffort:研发成本;

Reach 代表这个需求覆盖的广度;Impact 代表影响的深度;Confidence 则代表你对问题的理解程度;Effort 就是开发成本;对于每个需求我们都要去通过这四个方面给它打分(0–10 分的范围),最后通过公式 (reach x impact x confidence) / effort 计算一个结果分 score,再通过 Score 从大到小来对需求进行排序。而这当中最关键的,就是如何给每个参数进行打分。

并非任何需求都可以直接拿来进行对比,参与对比的需求其最终目标应当是一致的。如果一个需求的目标是提升功能 A 的渗透率,而另外一个需求的目标是提升用户留存率,虽然说提升功能 A 的渗透率有助于提升用户留存率,但要记住这只是一个假设,不能作为依据,而且间接指标通常有很多其他的影响因素,也难以作为最终的观测指标。因此所有的需求都是为了相同的指标,而且这个指标一定是该需求的最直接可以影响的指标。你可以说所有的需求都是为了提升功能 A 的渗透率;或者所有的需求都是为了提升用户留存率。

Reach:影响的广度

Reach 是用来评估这个需求上线一段时候之后能够影响到的用户数量。「影响」的意思是不仅仅是让用户看到,而是能够让用户使用这个功能,这样才能直接评价由这个需求产生的影响,如果用户只是看到了这个功能,但是没有使用,最终也产生了转化,这样的结果不能直接用来判断是因为这个功能带来的转化。例如上线一个新功能,可以覆盖 1000 个用户,但实际上只有 100 个人使用了这个功能,那么 Reach 的效果就是 100 人。评估 Reach 的效果要同时考虑流量和转化率以及时间周期。

评估广度的时间周期

时间周期的设定要依据需求的类型而定和达成目标所需的时间而定。从时间周期上来划分大致有两种需求:一种是长期运营的需求;一种是短时间的季节性的需求。

前者我们评估的周期通常是按照距离目标结束的时长,通常团队都会设定每个季度的目标,那么距离需求上线到这个季度结束的时长就是时间周期,其目的是评估这个需求能够为季度目标带来多大的影响,如果这个目标是月度或者年度也是相同的计算方式。

后者因为需求本身是季节性的,上线一段时间可能几天也可能几个月或者几周,最终我们还是以月度/季度目标来计算,如果需求早于季度结束时间,则以需求上线的时长来计算;如果活动可能要跨多个季度,则按照季度结束的时间来计算。

预估流量和转化率

如果是拉新的需求,此时流量都是从外部而来,需要去估算渠道的流量。有些渠道的流量是显而易见的,上线之后立即可以看到效果,例如在某个外部网站的首页明显位置添加广告,这样就可以通过预估这个广告位的点击率和以及观察该页面的流量来计算,因为流量通常是由周期性的,有些网站周末的流量更多,有些反之,因此我们通常会观察至少过去 7 天的平均值,或者过去 30 天。

另外一些渠道例如通过 SEO/SME 很难在短期内看到效果,竞价广告的流量也不好预估,时间可以放长一点到 1 个月左右。SEO 的流量估算可以借助 Google Adwords 中的 Keyword planner 工具来进行估算。在 Keyword planner 中输入对应的关键词,就可以大致判断出该关键词每月被搜索的次数。要注意的是 SEO/SME 的前提是你的内容或者广告能够出现在搜索引擎的首页,Keyword planner 中会展示该关键词 SME 的价格区间,可以帮助判断这个关键词的竞争激烈程度,价格越高意味着竞争越激烈,那么 SEO/SME 出现在首页的难度也就更大,时间也会需要相应的拉长。

转化率相对比较难估算,如果之前有过类似的需求,可以参考历史数据,如果没有,也可以参考一些行业数据来作为支撑。

相对评分机制

在估算完每个需求可以影响的人群数量之后,接下来的问题就是如何对这些数量进行打分。这里并没有一套标准的评估方法,毕竟每个产品所面向的人群不同,所处的阶段也不同,例如 to C 产品的影响范围一定比 to B 的要大很多。

GitLab 在内部的 Handbook 中有提到一种基于对已有用户进行覆盖的打分方法,这种打分主要是面向产品已有的用户:

  • 10.0: 如果能够覆盖绝大多数已有用户(>=80%)的已有用户或者潜在用户;
  • 6.0: 能够覆盖 50%-80% 的已有用户或者潜在用户;
  • 3.0: 能够覆盖 25%-50% 的已有用户或者潜在用户;
  • 1.5: 能够覆盖 5%-25% 的已有用户或者潜在用户;
  • 0.5: 能够覆盖 <5% 的已有用户或者潜在用户;

GitLab 只是给出了 5 个等级,而且等级越大的分值会高很多,之所以这样评分是因为网络效的作用,能够影响的用户越多,越可能产生网络效应让需求自发的扩散出去。但 GitLab 的基础以已有用户为基础,如果是用在拉新上,这样的评分方式可能不太合适,我更倾向于使用一种相对的评分机制,我们也在 Sprint Grooming 中使用这样的评分机制来给 Story 评估点数。

例如我们有五个 Story 分别可以触达到这样的用户量:

  • A:13 万用户;
  • B:15 万用户;
  • C:17 万用户;
  • D:8 万用户;
  • E:14 万用户;

列出所有的 Story 之后我们要做的就是使用其中的一个 Story 来作为基准,然后与其他的 Story 进行比较。

  1. 首先选择 A 作为一个基准,给 A 设置一个分值为 5 分,你也可以设置为 4 分,只是一个选择,并不重要;
  2. 拿出 B 和 A 来做比较,因为 B > A,所以我们给 B 为的分值要比 A 大,我们先给 B 设置为 6 分;
  3. 拿出 C 和 A 做比较,得出 C > A,所以我们需要再次比较 C 和 B,然后发现 C > B,所以我们可以给 C 设置为 7 分;
  4. 拿出 D 和 A 做比较,得出 D < A,所以我们给 D 设置为 4 分,或者 3 分,因为你觉的 A 和 D 的距离还挺大,不过不重要,因为 D 大概率也不会上榜;
  5. 拿出 E 和 A 做比较,得出 E > A,然后再拿出 E 和 B 做比较,得出 E < B,此时可以对 B 和 C 的分值作出调整,因为 E 介于 AB 直接,所以可以把 B 设置为 7 分,C 设置为 8 分,然后给 E 设置为 6 分,或者你也可以给 E 设置为 5.5 分;

通过这种相对的打分机制,不需要一个固定的标准我们可以得出一个具体的分数,这样的方法还可以应用在很多没有标准的打分机制中,其他几个参数的评分方式也都是如此。而关于分值,因为 Reach 会受到网络效应的影响,也不一定需要按照 0–10 或者以 1 为跨度来评分,可以借鉴敏感开发的故事点,使用菲波纳切数列作为分值来进行打分。

Impact:影响的深度

Reach 来衡量需求影响的广度,Impact 则用来衡量需求影响的深度,也就是这个需求对每一个用户的影响。例如你的目标是提升收入,那么 Impact 就是计算对客单价的影响。Impact 取决于两方面,这两个方面其实也取决于产品经理对用户和需求的理解。如果有定性或者定量的数据来支撑用户对这个需求有提出过,并且当前人群也符合目标用户,那么影响深度就相对会比较大。

例如我们曾经有一个目标时提升付费用户的流失率,包括付费用户直接取消继续付费,或者付费用户转变成免费用户。那么第一个问题就是用户为什么流失,针对定性的问题,最好的方法就是直接跟用户交谈,深度用户访谈的成本比较高,我们也会配合简单的问卷调查,在用户准备取消的时候询问原因。问卷调查的结果展示有 50% 左右的用户流失是因为价格太贵,另外 30% 的用户是因为某些功能的缺失。这里的 50% 和 30% 实际上对应的是 Reach 的评分,而要评估 Impact 我们需要去深入了解用户。通过对用户分层,我们因为价格原因流失的用户基本上都是买便宜版本的用户,这部分用户都是入门用户,客单价在十多块钱,对价格也会比较敏感;而选择因为功能确实流失的用户则是更高级的用户,客单价都是在上百块,这些用户对价格不敏感,而更在意产品的功能能否真正解决自己的问题。这里的客单价就很适合用来给 Impact 评分。

因为 Impact 是针对个人影响深度的评分,这部分相对更加主观一些,但即便是主观也需要有证据来作为支撑。Intercom 的文章 中也为这种主观的评判提供一种评分机制:

  • 3: 意味着对用户的影响非常大;
  • 2: 意味着对用户的影响一般大;
  • 1: 意味着对用户的影响很一般;
  • 0.5: 意味着对用户的影响比较小;
  • 0.25: 意味着对用户的影响非常小;

大份的工程同样是对过两两比较的方式来进行,选定一个需求作为标准,然后使用其他需求来与之对比。

Confidence:对需求的自信

信心实际上更多的描述的是产品经理对需求和用户痛点的理解程度,这个需求是否真的可以提升用户不转化或者不点击广告,我们是否了解用户不转化的原因。我们通常使用数据来作为评估信心的指标,如果一个需求有充分的数据来佐证,那么我们的信心就会给很高;但几乎所有情况下我们都没有 100% 的把握,总会有一些猜想在里面,这也是为什么这种产品设计方式叫「假设驱动设计」,因为在这样的场景中,每个需求都是有待验证的假设,没有人可以保证用户一定想要这样的东西。在假设的验证中,数据是能够证明其有效的唯一方式,数据越多假设就越少。

这个过程中我们需要列出如果要验证这个需求有效我们需要哪些数据作为支撑,然后标记出哪些数据是已知的,哪些是未知的。未知的数据就是我们需要通过实验来进行验证的,未知数越多,信心越低,未知数获取的难度越大,信心越低。对于难度,我们简单的评估标准是获取定量数据的难度小于定性的数据,而定性的数据则通过分析所需的样本量来评估,样本量越大,难度越大。如果没有数据支撑,Confidence 可能会给到很低 10% 这样。

Intercom 同样也提出评估 Confidence 的 3 个级别:

  • 100%:有定量的数据支撑 Reach,定性的数据支撑 Impact,并且开发评估了 Effort,那么 Confidence 就是 100%;
  • 80%:有定量的数据支撑 Reach,开发也评估了 Effort,但是 Impact 没有数据支撑;
  • 50%:有数据支撑,但是数据的可信度较低,Effort 的波动也可能较大。

Effort:研发成本

Effort 是评估研发成本的,但这里并不单单是指开发和设计的成本,假设驱动的需求中通常需要进行多团队的协作,通常会需要与市场、品牌和商务等多个团队配合,而所涉及到的团队越多,成本越高。简单的研发成本可以通过人天也打分,人天越多,分值就越低,也可以敏捷开发中的故事点的方式来评分,无论如何估算,最终也是通过相对的评分机制来进行打分。

假设验证的设计第一步永远是验证假设,因为没有人能够确定这个需求是否真实有效,所以我们通常不会去做超过 10 个人天的需求,一般最多是 5 天,因为需要快速验证数据,如果一个不确定的东西需要花 10 个人天来开发,成本是相当大的。所以我们就简单的给每个人天加 1 分,如果需求超过 10 天就会超过 10 分,我们直接给 0 分(不可除)。


正如一开始所说的,RICE 并不适合所有的情况,越是底层和基础的功能,在 RICE 的 PK 中的得分可能会更低,尤其是人们可能会提出反对声音「用户根本不知道他们想要什么」,那么用户研究和数据不都是没有用了?显然这种声音会出现概念模型设计的方式中,这种需求的优先级很多时候是靠勇气而非数字来排序。但是在产品的需求更加精细的时候,RICE 实际上是在降低试错成本。也有人会提到做这些调研需要花费大量的时间,这些时间也是成本,我的看法是,如果没有足够的数据,那么应该先把经历放在数据体系的搭建中,然后再来讨论 RICE。

❌