Crypto OS
Non-Technical Crypto OS第五阶段 · Crypto Business

第 30 章 · Crypto Startup 如何找到 PMF

什么时候根本不需要 Token?

练习的能力
ResearchSystem ThinkingBuilder
动手
给你自己的一个想法,写清楚三件事:谁付钱、为什么非链上不可、没有 Token 能不能成立。
AI Lab
让 AI 扮演三种角色(用户、投资人、监管)各提三个质疑,逐条回答。

一个现实问题

同一周,三个创始人各自来问了同一个问题:「我们什么时候发币?」

第一个人的项目还只有一份文档和三张原型图。他的理由是:得先有代币才能吸引早期用户,也才能融到钱。

第二个人已经跑了七个月。他有 200 个每周都会回来用的用户,没有任何激励,他们付手续费,有人在社群里自发帮新人答疑。他的理由是:竞争对手都发了,我们再不发就落后了。

第三个人的产品上线四个月,注册地址不少,但几乎没有人第二次回来。他的理由是:产品没人用,发个币把人吸引过来,有了人自然就有留存了。

同一个问题,在三种情况下是三个完全不同的问题。

对第一个人,它是一个融资和冷启动的问题。对第二个人,它是一个所有权分配和长期结构的问题——而且他有一个真实的资产可以分配。

对第三个人,它根本不是一个关于代币的问题。 他真正该问的是「为什么没人第二次回来」,而代币会把这个问题的答案推迟至少一年——推迟的方式是:用激励制造出一批看起来像用户的地址,让那条曲线暂时变好看,直到激励停掉。

这一章要处理的,就是把这三种情况分开。核心问题只有一个:什么时候根本不需要 Token。

这也是整个 Part A 最后一个「建设者视角」的问题,而且它直接通向毕业项目

思想实验

两个团队,同一个想法,同一个月开始做。

A 团队第一个月就发了代币。 用代币做激励,用代币融资,用代币做空投预期。

B 团队不发币。 只做产品,找人用,收手续费。

看 18 个月。

第 1 个月 A:5 万个地址,曲线陡峭,社群 2 万人,媒体报道若干。 B:11 个用户,其中 4 个是朋友。

第 3 个月 A:日活 3 万,TVL 可观,融资顺利完成。 B:60 个用户,其中 20 个每周回来。团队改了三次产品方向。

第 6 个月 A:日活 2.5 万,激励按计划递减,开始有人在社群问「奖励怎么变少了」。 B:300 个用户,120 个每周回来,开始有人自己带朋友来。团队第一次听到一句「如果你们关掉我会很麻烦」。

第 12 个月 A:激励预算见底,日活 2000。团队在开会讨论是不是要再来一轮。社群里的讨论从产品变成了价格。 B:900 个用户,400 个每周回来,手续费收入覆盖了服务器和两个人的工资。团队现在很清楚这 400 个人是谁、在用哪一个功能、为什么离不开。

第 18 个月 A:还有 1800 个日活,其中大部分在等下一轮激励。团队面对一个困难的问题:最初那 5 万个地址里,有多少是真的需要这个产品的?没有人知道,因为从来没有测过。 B:2000 个用户,1100 个每周回来。如果这时候发币,团队可以明确说出这个代币要解决什么问题——而且有 1100 个人可以作为分发的依据。

这个推演不是在说 B 一定更好。A 的路径在某些条件下是对的,后面会讲那些条件。

它要说明的是一件更具体的事:Token 把「有没有人真的需要这个东西」这个问题的答案,推迟了 12 到 18 个月。

而这 12 到 18 个月,本来就是用来回答这个问题的。一个还没找到需求的团队,用代币买来的时间不是多出来的,是从验证里借走的。

你来决定

你有一个想法,也有一笔能撑 12 个月的启动资金。第一步做什么?

观察结果

四个选项指向同一件事:

先证明没有 Token 也有人用,再决定要不要发 Token。

这句话的关键在「证明」两个字。它不是一个态度,是一个可以被执行的检验。

把项目按 Token 的必要性分成三类,这是这一章最该带走的一张表

类别Token 在这里是什么怎么识别正确的顺序
必需品没有它,这个系统在机制上跑不起来去掉 Token,能说清楚具体哪一步会断可以早发,但必须说清它承担的机制职责
加速器有它更快,没它也能跑去掉 Token,产品仍然成立,只是增长慢先验证需求,再用它加速
伪装它在替代一个还不存在的需求去掉 Token,这个项目没有理由存在不该发;该回去解决需求问题

第一类比大多数人以为的要少。它主要包含两种结构:

一种是需要用经济激励维持一个去中心化网络的安全或供给。 一个由无数陌生人提供算力、存储或带宽的网络,需要一种方式支付这些人,而且这个支付不能依赖任何一家公司——这是代币承担的一个真实的机制职责。

另一种是所有权本身就是产品的一部分。 一个要把治理权和收益权分给使用者的系统,代币是这个分配的载体。

第三类是这一章真正想帮人避开的一类。 识别它只需要一个动作:把 Token 从描述里删掉,看这个项目还剩什么。 如果剩下的是「一个没有人特别需要的产品,加上一套很精巧的经济模型」,那么代币在这里的作用是让「没有人特别需要」这件事暂时不那么明显。

建立模型

Token 必要性四问

按顺序问,答不出前一个就不要问后一个:

  1. 去掉 Token 还跑不跑得起来
  2. 谁会因为 Token 做一件他本来不做的事
  3. 没有 Token 的这 12 个月用什么代替
  4. Token 跌 90% 还剩什么
四问的顺序是有意的。第一问答「跑不起来」时,第二问才有意义;第一问答「跑得起来」时,问题就变成了「那为什么要发」。
问题要回答到什么程度常见的不合格回答
1. 去掉 Token 还跑不跑得起来说出具体是哪一步会断,以及为什么没有别的办法「没有代币就没有激励」——这是同义反复
2. 谁会因为它做一件本来不做的事指出具体的人群和具体的行为,而且这个行为是你真正需要的「让社区更有参与感」——不是一个行为
3. 没有它的 12 个月用什么代替给出一个具体的冷启动方案「先小范围内测」——这不是方案,是延期
4. 跌 90% 还剩什么说出留下来的产品、用户和收入「我们的价值不在价格上」——那就说出在哪

第二问是四问里最容易暴露问题的一问。 因为它逼你回答一件事:这个行为是你真正需要的吗?

很多激励买到的行为是「为了拿激励而做的那个动作」本身,而这个动作对产品没有任何价值。第 28 章讲的门槛设计,本质上就是在处理这个问题——而一个连「我需要什么行为」都说不清的团队,设计不出任何有效的门槛。

Crypto 的 PMF 为什么特别难测

在 Web2,PMF 有一套成熟的信号:留存曲线走平、自然增长、付费转化、用户说「如果这个东西没了我会很麻烦」。

这些信号在 Crypto 里全部可以被补贴伪造。

Web2 的 PMF 信号在 Crypto 里怎么被污染
用户量增长一次激励活动可以让它涨四十倍
留存曲线走平只要激励持续发,曲线就是平的
自然增长「朋友推荐」可能是「让朋友也来领」
付费转化用户付的手续费,可能小于他领到的激励
资金留存资金留下是因为收益率,不是因为产品

所以 Crypto 的 PMF 判断必须先做一次「去补贴化」。 四个信号,每一个都是在补贴被剥离之后测量的:

信号具体定义怎么测
自费留存在完全没有激励的时间窗口里,用户的回访率以激励结束日为零点,看 30/60/90 天
付费意愿用户愿意付出真实成本完成一次非激励动作排除所有和激励合约相关的调用之后的交互数
自然来源新用户的来源不是激励活动页按调用来源和首次交互的入口拆分
留存深度用户愿意把资金留过夜、过周资金在合约里的平均停留时长分布

第四个信号最被低估,也最难伪造。 一个用户愿意把自己的资金在你的合约里放一个星期,说明他对这个产品的信任和依赖,远超过他点一次按钮所能表达的。

还有一个不在链上、但最有说服力的信号:有没有人在你打算关掉某个功能时表达出真实的困扰。 这个信号无法被补贴制造,因为补贴买不到「我离不开它」。

没有 Token 的冷启动怎么做

第三问需要一个具体答案。这里有四条已经被反复验证过的路径:

路径怎么做适合什么形态
自己当第一边团队自己提供另一边的供给,直到需求侧起来双边市场,且供给可以被自己承担
服务一个已有的群体找一个已经在痛苦地用别的方案的小群体,把他们服务好工具、基础设施
做零件而不是入口把自己接进别人已有的分发里(第 29 章的集成那条线)协议层、接口层的产品
用现金而不是代币做激励同样是补贴,但成本诚实、有上限、不锁死结构需要补贴但还不想发币的阶段

第四条值得强调。很多团队默认「补贴」等于「发币」,其实不是。 用现金做同等价值的补贴,效果类似,而且有三个好处:成本立刻体现在账上、金库有多少就只能发多少、不会锁死任何长期结构。

如果一个团队不愿意用现金发同等价值的激励,那它其实是在说:这笔支出的真实性它自己也不完全确信。 这个问题值得每个考虑发币的团队问自己一遍。

网络效应:哪些是真的,哪些是租来的

「我们有网络效应」是融资材料里出现频率最高的一句话之一。在 Crypto 里,它有三个可能的来源,而它们的牢固程度差别极大:

来源机制牢不牢固怎么检验
流动性深度好 → 体验好 → 更多人来 → 深度更好中等:它是真的,但可以被补贴撬走补贴停掉后深度还剩多少
集成越多产品接你 → 越难被替换 → 更多产品接你最牢固:替换需要对方改代码有多少外部合约在调用你,调用量占比多少
资产与标准你发行的凭证被广泛接受 → 更多地方接受它最牢固,但最难建立有多少第三方把你的凭证当作抵押品或计价单位

流动性带来的网络效应是最常被声称、也最容易被撬走的一种。 第 26 章那个激励一停就搬家的案例说明:如果你的护城河只是深度,那么一个愿意付更多补贴的竞争者可以在几周内拿走它。

集成带来的网络效应最牢固,因为替换你需要对方付出真实的工程成本。这也是第 29 章把集成排在优先级第一梯队的另一个理由。

决策顺序

把这一章压成四步:

  1. 找到真实付费的人
  2. 做到没有激励也回来
  3. 证明规模化会更好用
  4. 再决定要不要发 Token
第四步之前每一步都可以在没有 Token 的情况下完成。跳过前三步直接做第四步,是这一行最贵的一种走法。

第三步值得解释:「规模化会更好用」是判断需不需要网络效应的那一步。 如果一个产品在用户从 100 个增加到 10000 个时,对每个用户的价值没有提升,那它是一个工具,不是一个网络——而工具通常不需要代币。

它叫什么

产品市场契合PMF / Product-Market Fit

产品和某个群体的真实需求对上了,表现为他们持续地、自愿地、付出成本地使用它。

在 Crypto 里,这个定义的每一个限定词都要重新检验:「持续」要在没有激励的时间窗口里测,「自愿」要排除激励驱动的地址,「付出成本」要排除领到的激励大于付出的情况。

所以这里的 PMF 判断永远多一步:先做一次去补贴化,再看剩下什么。 这一步跳过去,所有的 PMF 讨论都是在讨论激励的吸引力。

留存Retention

第一次之后还回不回来。

第 28 章给过它的测量方法,在这一章它有一个更严格的版本:只统计完成过非激励付费交互的地址,在完全没有激励的窗口里的回访率。

这个数字通常小得让人难受,但它是唯一一个不会骗人的数字。一个团队如果不知道这个数字是多少,那它对自己的处境其实是没有判断的。

网络效应Network Effect

用的人越多,对每个人越有用。

在 Crypto 里它有三个来源——流动性、集成、资产与标准——牢固程度依次上升。最常被声称的那一种(流动性)恰好是最容易被撬走的一种。

有一个简单的检验:如果用户从 100 个变成 10000 个,对单个用户的价值有没有提升? 没有提升,那它是一个工具而不是一个网络。工具可以是很好的生意,但它通常不需要代币,也不该按网络的逻辑去估值。

流动性冷启动Liquidity Bootstrapping

让一个需要两边同时在场的市场第一次转起来。

它是激励最不可替代的场景,也是唯一一个「先发币」可能真正正确的理由。判断这笔钱花得对不对,只有一个标准:补贴逐步退坡的过程中,这一边有没有开始自己赚钱。

所以这类补贴必须从第一天就设计退坡路径,并且盯住一条曲线:这一边的真实收入(不含补贴)占它全部收入的比例。 这个比例往上走,说明市场正在接管;一直不动,说明补贴替代的不是启动成本,是需求本身。

Token 必要性Token Necessity

去掉 Token 之后,这个项目还剩下什么。

它有三种答案,对应三类项目:剩下一个跑不起来的机制(必需品)、剩下一个更慢但成立的产品(加速器)、什么都不剩(伪装)。

判断方法只有一个动作:把 Token 从你的项目描述里全部删掉,然后把剩下的部分读一遍。 读完如果说不出这个项目为什么应该存在,那么问题不在代币设计上。

这一问是分析工具箱十二问里的第 3 问,也是这一章的标题。

动手

动手给你自己的一个想法,写清楚三件事:谁付钱、为什么非链上不可、没有 Token 能不能成立一份文档 + 一个区块浏览器 + 和至少 5 个真实的人对话0 元。这个 Lab 不需要写任何代码,也不需要动任何资金;它唯一的成本是诚实

这个 Lab 是整个 Part A 里最难的一个,因为没有任何外部材料可以帮你。 前面所有 Lab 都是在研究别人,这一个是在检验你自己。

如果你现在没有自己的想法,用一个你最近觉得「这个应该有人做」的点子,或者拿你正在参与的项目来做。

第一件事:谁付钱。写到具体的人。

不要写「用户」,写一个具体的人:他是谁、现在在用什么方案、那个方案让他付出什么代价、他一个月因为这件事损失多少钱或多少时间。

这个人是:        (职业 / 角色 / 规模)
他现在怎么解决:  (具体的工具或流程)
他为此付出什么:  (钱、时间、风险,给出量级)
他会付多少钱:    (给一个数字,哪怕是估的)
我怎么知道的:    (猜的?问过?问过几个?)

最后一行是这一步的核心。 如果答案是「猜的」,这个 Lab 后面几步都不要做,先去问五个人。

第二件事:为什么非链上不可。

做一次替换实验:把链换成一个普通的数据库,这个产品哪一步会断?

换成数据库之后,会断的是:
  □ 资产的所有权无法自证        → 链是必要的
  □ 需要陌生人之间无需信任地结算 → 链是必要的
  □ 需要规则不可被单方面更改     → 链是必要的
  □ 需要任何人都能验证的记录     → 链是必要的
  □ 一步都不会断                 → 链不是必要的,这不一定是坏事

「一步都不会断」不是这个 Lab 的失败。 很多有价值的产品就是不需要链的。但它会改变接下来的一切:如果链不是必要的,那么代币几乎肯定也不是。

第三件事:没有 Token 能不能成立。把 Token 全部删掉再读一遍。

具体做法:写一份 300 字的项目描述,里面不出现「代币」「空投」「激励」「治理」任何一个词

写完之后自己读一遍,回答三个问题:

  1. 这个项目还有存在的理由吗?
  2. 第一步那个人,还会为它付钱吗?
  3. 如果会,那么代币是用来解决什么问题的?

第三问的答案就是你的 Token 必要性论证。 写不出来,答案就是「暂时不需要」,而这是一个完全正常的答案。

过一遍 Token 必要性四问,每一问写一段。

1. 去掉 Token,跑不起来的具体是哪一步?为什么没有别的办法?
2. 谁会因为 Token 做一件他本来不做的事?这个行为我真的需要吗?
3. 没有 Token 的这 12 个月,我用什么代替?(给一个具体方案,不是「先内测」)
4. Token 跌 90%,还剩下什么?(产品、用户、收入,各剩多少)

第三问要落到四条冷启动路径中的一条:自己当第一边、服务一个已有的痛苦群体、做零件接进别人的分发、用现金而不是代币做激励。

去和五个真实的人对话。这一步不能跳。

五个人必须是第一步描述的那类人,而且不能是你的朋友或同事。对话时只问三个问题,不要介绍你的方案:

1. 你现在怎么处理这件事?(让他描述具体流程)
2. 这里面最麻烦的是哪一步?(让他自己说,不要给选项)
3. 你为此付过钱吗?付了多少?(最重要的一问)

不要在前两问之后就开始介绍你的产品。 一旦你开始介绍,对方会出于礼貌给你正面反馈,这次对话的信息价值就归零了。

五次对话之后,回去改第一步那张表。如果五个人的第二问答案各不相同,说明你面对的不是一个群体,是五个人。

写下你的最小验证方案:怎样用 8 周证明有人要。

我要验证的那句话:   (一句可以被证伪的话)
验证方式:           (做什么,让谁用什么)
成功标准:           (一个数字,要在 8 周内能测到)
失败标准:           (达不到什么就说明假设错了)
这个方案需要 Token 吗:

「失败标准」那一行是整个 Lab 最难写、也最有价值的一行。 一个没有失败标准的验证方案,无论跑出什么结果都会被解释成「有希望」。

做完之后你会有:一个具体的付费人、一个链必要性的判断、一份不含代币的项目描述、四问的答案、五次真实对话的记录,以及一个 8 周的验证方案。

这六样东西加起来,就是毕业项目里「这个项目值不值得做」那一节的全部内容。 而且它们对研究别人的项目同样适用——把同一套问题拿去问任何一个你在研究的项目,你会比它的大多数投资人更清楚它的处境。

AI Lab

AI Lab让 AI 扮演三种角色(用户、投资人、监管)各提三个质疑,逐条回答Level 2 · AI Copilot

这个任务的价值和前几章不同:它不是让 AI 产出内容,是让 AI 当一面镜子。

三个角色的选择是有道理的,因为它们的质疑方向几乎不重叠:用户问「这对我有什么用」,投资人问「这门生意能不能成立」,监管问「这件事有没有边界」。 一个创始人通常只准备好了回答其中一类。

做这个 Lab 之前,先把上一个 Lab 做完。 没有那六样东西,你没有可以被质疑的对象。

下面是我的项目描述:
<把上一个 Lab 里那份 300 字的、不含代币词汇的描述贴进来>
<再贴上 Token 必要性四问的答案>

请依次扮演三个角色,每个角色提三个质疑。要求:

角色一:目标用户。
一个正在用现有方案解决这个问题的人。他不关心技术,只关心
这件事对他是不是更省事、更省钱、更可靠。
他的三个质疑必须是关于使用的,不要提代币价格。

角色二:投资人。
他看过很多这类项目。他的三个质疑必须包含:
为什么需要 Token、补贴停掉之后用户还在吗、谁在支付。

角色三:监管视角。
一个关注消费者保护和资金安全的审视者。
他的三个质疑要指向我的产品里的具体环节,不要写泛泛的合规担忧。

每个质疑都要具体到我的项目,不要写通用问题。
每个质疑后面附一句:如果我答不上来,说明什么。

最后单独列一节:这三个角色里,哪一个的质疑我最可能答不上来,为什么。

注意:三个角色都是虚构的分析视角,不要模仿任何真实机构或个人的
口吻,也不要声称代表任何真实机构的立场。

拿到九个质疑之后,逐条写回答。回答时只允许用两种句式:

「我们已经验证了 ___,依据是 ___」
「我们还没有验证 ___,计划用 ___ 在 ___ 之前验证」

不允许出现第三种句式:「我们会解决这个问题」。这句话没有信息量,而它是最容易写出来的一句。

写完之后统计:九条里有几条是第一种句式。这个比例就是你目前的验证程度。

这类任务上模型有四个高频错误,按危险程度排序:

  1. 用户角色问价格问题。 它会让「用户」问「代币什么时候上所」,这说明它在模仿社群语气,而不是在扮演一个有真实问题的人。看到这个就重写提示词。
  2. 监管角色写泛泛的合规担忧。 「可能面临监管不确定性」这类句子适用于任何项目,所以不提供信息。要逼它指向具体环节:资金由谁保管、用户能不能取回、出事了谁负责。
  3. 三个角色的质疑趋同。 如果三组问题读起来像同一个人写的,说明视角切换失败了。
  4. 质疑太温和。 模型倾向于礼貌。可以在提示词里加一句「假设你倾向于拒绝这个项目,请给出你的理由」,输出的锐度会明显上升。

最后那一节(哪个角色最难回答)是整个练习的重点。 模型给的答案未必对,但这一问会逼你自己想一遍。而你自己的答案,通常就是你一直在回避的那件事。

AI 说完之后,你必须自己验证

  • 用户角色的三个质疑,是关于产品体验的,还是关于代币价格的——后者说明它没在扮演用户
  • 投资人角色有没有问到「为什么需要 Token」和「补贴停掉之后呢」这两问
  • 监管角色的质疑,是泛泛的合规担忧,还是指向你产品里的具体环节
  • 三个角色的质疑有没有重复?重复说明它没有真的切换视角
  • 它提的质疑里,有几个是你之前没想到的?一个都没有,说明提示词不够尖锐
  • 你的回答里,有几条是「我们会解决」而不是「我们已经验证了」
  • 最关键的一条:有没有一个质疑是你回答不了的?把它单独记下来,那是你真正的风险
  • 它有没有假装成某个真实机构或真实人物的口吻——这类内容一律当作虚构处理

真实案例

做了两年才发币的基础设施多次出现工具与基础设施类项目

有一类项目的路径高度一致:先做一个开发者需要的工具或服务,靠订阅费、使用费或者一笔融资养活自己,跑两三年,积累起一批离不开它的集成方,然后才考虑代币。

这类项目发币时有一个很明显的特征:它能清楚说出这个代币要承担什么职责——可能是支付网络资源的费用,可能是分配运营节点的收益,可能是把所有权分给已经在用它的人。

对照那三类项目,这是典型的「加速器」变成「必需品」的路径:在需求已经被证明之后,代币用来解决一个具体的机制问题,而不是用来制造需求。

这条路的代价是慢,而且在市场热的时候会显得落后。但它有一个别的路径没有的东西:发币那天,它知道自己的用户是谁。

发币当天就是最高点反复出现先发币后做产品的项目

另一类项目的曲线也高度一致:发币日前后是关注度和价格的最高点,之后一路走低,产品的使用数据从未跟上。

复盘时常见的说法是「市场环境不好」或者「营销没做够」。但用这一章的框架看,问题在更早的地方:这类项目在发币时,从来没有回答过「没有代币还有没有人用」。

发币把一个待验证的假设,变成了一个已经定价的资产。而资产一旦被定价,团队的注意力就会从「怎么让产品更有用」转向「怎么让价格别跌」——这两件事需要的行动完全不同,而且经常冲突。

第 25 章那条红线在这里又出现了一次:Token 那一格填得比 Product 那一格详细,是一条强信号。

要说明的是:这不是在说先发币一定错。它是在说,先发币的项目必须在发币之前就对需求有把握,否则它买到的不是时间,是一个更难回头的位置。

积分制争取到的那 12 个月近年常见做法

一个团队选择先发积分:不锁死代币结构,但获得激励的引导作用,同时观察哪些行为是真实的。

这个做法在两种执行下会导向完全不同的结果。

执行得好的:团队把积分当成一个观察工具。他们盯的不是积分发了多少,而是每一批参与者在积分之外做了什么——有没有人在不拿积分的功能上花时间,有没有人把资金留过夜。12 个月后,他们知道自己的核心用户是谁,代币的设计围绕这批人展开。

执行得差的:团队把积分当成代币的预售,所有指标都被积分污染,12 个月后面对的是一个更大的兑现压力和一批同样不知道是不是真实的用户。而且因为积分的应计负债,现在退出比当初更难。

区别不在工具上,在于团队有没有保留一块不受激励影响的观察区。这是一个很具体的建议:永远留一部分功能不给任何激励,那里的数据是你唯一干净的样本。

Token 确实是必需品的那一类持续存在去中心化基础网络

有一类系统,代币承担的是一个无法被替代的机制职责:一个由大量互不相识的参与者提供算力、存储、带宽或验证服务的网络,需要一种方式持续支付这些参与者,而这个支付不能依赖任何一家公司——否则这家公司一停,整个网络就停了。

在这类系统里,代币不是营销工具,它是支付层和安全预算。去掉它,第一问的答案是明确的:供给侧会在几天内消失。

识别这一类有一个具体的检验:问「如果由一家公司用现金支付这些参与者,会有什么问题」。 如果答案是「没什么问题,只是成本高一点」,那它是加速器不是必需品;如果答案是「那整个系统的抗审查性和持续性就没了,而那恰好是用户来这里的原因」,那它是必需品。

这个检验能滤掉绝大多数声称自己属于这一类的项目。

改一个变量

如果你的竞争对手发了币,用激励抢走了你的供给侧

这是不发币路线最真实的风险,而且它在依赖流动性的赛道里几乎必然发生。

先做一次判断:走掉的那批供给,是被补贴吸引走的,还是本来就不属于你? 这两种情况的应对完全不同。如果他们跟着收益走,那么竞争对手停止补贴时他们也会走;如果他们走是因为你的产品确实不够好,那补贴只是加速了一个本来就会发生的结果。

具体的应对有三条,按优先级:守住需求侧(供给会跟着需求走,反过来不成立)、把集成做深第 29 章讲过集成是最难被撬走的连接)、必要时用现金做有期限的对抗性补贴(诚实、有上限、不锁死结构)。

最不该做的是为了应战而仓促发币。那意味着你在最被动的时候,做了这个项目最不可逆的一个决定。

如果投资人把「有明确的代币计划」作为投资的前提

这是很多团队真实面对的压力,而且它经常被描述成「行业规则」。

处理它的方式不是拒绝,是把它变成一个可以讨论的时间表:代币的必要性论证是什么(四问的答案)、什么条件达成后发(一个可验证的指标,比如去补贴化的留存达到某个水平)、在那之前用什么方式给早期投资人以确定性。

有一件事要想清楚:把代币计划写进融资条款,意味着发币的时间点从「需求验证完成时」变成了「投资人期望的时点」。 这两个时点如果不一致,后面所有的产品决策都会被这个错位牵着走。

也有一种情况是这个前提本身合理:如果你的项目属于必需品那一类,代币计划本来就该有。 分歧只发生在加速器和伪装那两类上。

如果你找到的那 10 个付费用户,全都是同一家公司的人

这不是 PMF,这是一个客户。而且它有一个隐藏的风险:你的产品会在不知不觉中被改造成只适合这一家。

但它也不是坏消息——它是一个非常有用的起点,只是需要被正确对待。正确的做法是立刻去找第二个和第三个完全不相关的来源,验证这个需求是不是普遍的。

有三个具体的检验:他们遇到的那个麻烦,是这个行业普遍的,还是这家公司特有的流程造成的?你为他们做的定制,有多少可以被别人复用?如果这家公司明天消失,你的收入还剩多少?

第三个问题的答案如果是「零」,那么你现在做的不是一个产品,是一个外包项目。 两者都可以是好生意,但它们需要完全不同的后续决策——而且外包项目几乎肯定不需要代币。

如果你的产品在用户从 100 个涨到 10000 个时,对每个用户的价值没有变化

那它是一个工具,不是一个网络。这不是坏消息,这是一个非常重要的诊断结果。

它意味着三件事。你不需要网络效应,所以也不需要用代币去补贴网络的启动。 你的增长可以是线性的,不用追求指数曲线,那反而会让你去做一些对产品无益的事。你的商业模式应该是收费,而不是代币。

很多团队在这个诊断上说谎,因为「网络」比「工具」更容易融到钱。代价是他们会按网络的逻辑去做产品决策——烧钱买规模、追求用户数、设计代币经济——而这些动作对一个工具毫无帮助,甚至有害。

一个工具型产品的正确路径在第 26 章那张损益表里:把抽成率、留存和续费做起来,让第五行为正。 这条路不性感,但它不依赖任何人的情绪。

带走的问题

1
它解决什么问题?

这一章把这一问推到了它最难的位置:不是问别人的项目解决什么问题,是问你自己的。

而且加了一个验证要求:你是猜的,还是问过五个真实的人? 上一个 Lab 的第五步就是为这一问设计的——而且它规定了在前两问之后不许介绍自己的方案,因为一旦介绍,你得到的就只是礼貌。

3
为什么需要 Token?

这一问就是这一章的标题。它的答案有三种,对应三类项目:必需品、加速器、伪装。

判断方法只有一个动作:把 Token 从项目描述里全部删掉,把剩下的读一遍。 读完说不出这个项目为什么应该存在,那么问题不在代币设计上,而代币也不会解决它。

11
如果 Token 价格归零,产品还能运行吗?

四问里的第四问就是它:Token 跌 90%,还剩什么。

这一问的价值在于它逼你把「产品」和「投机品」分开。留下来的产品、用户和收入,就是这个项目作为一门生意的底盘。底盘写不出来,说明这个项目目前是后者。

12
如果补贴停止,还有用户吗?

这一问在这一章从一个研究工具,变成了一个建设标准:在发币之前,先把它回答一遍。

具体是四个去补贴化的信号:自费留存、付费意愿、自然来源、留存深度。四个数字都难看的时候发币,代币会把这四个数字暂时掩盖住,但不会改变它们。 而掩盖的期限通常是 12 到 18 个月。

本章自测

一句话带走

先证明没有 Token 也有人用,再决定要不要发 Token。

做完这一章的动手环节了?勾上它查看全部进度

本页目录