软件正在从耐用品,变成快消品

最近，我感觉到一件事：

一部分软件，正在从耐用品变成快消品。

以前做一个软件，是件很重的事情。

调研、设计、开发、测试、上线。做出来以后，还要长期维护、不断迭代。

所以，我们天然希望它活得久一点。

用户多一点。留存高一点。

最好用了五年、十年，还在用。

这个逻辑，很像汽车、冰箱、空调这些耐用品：买一次，用很多年。

但越来越多的小软件，已经可以临时生成，用完就扔。

于是我开始好奇：

如果软件开始“快消品化”，传统快消品行业积累的方法论，是不是也能反过来启发软件行业？

顺着这个类比，梳理几个想法。

01 软件为什么开始像快消品了

最直接的原因，是软件的制作成本正在下降。

以前，一个很小的需求，也未必值得开发。

现在借助 Vibe Coding、Coding Agent，一些小工具已经可以现做、现用。

我要临时处理一批数据，生成一个小工具。

我要办一次活动，生成一个报名管理页面。

我要开一次会，生成一个只服务这次会议的分析工具。

任务做完，软件也就完成使命了。

甚至可以直接扔掉。

这时候，会出现一个过去看起来很反常的现象：

一个留存率为0的软件，也可能是一个非常好用的软件。

因为它本来就只应该活20分钟。

这已经很不像冰箱了。

更像一瓶水。喝完，就结束了。

02 从 Installed Base，转向 Occasion Base

耐用品行业很关心一个概念：Installed Base，装机基础。

已经卖出去、安装起来的设备有多少？还有多少在使用？后续能产生多少维修、升级、换代的价值？

传统软件也有类似的经营思路。

我们关心DAU、MAU、留存率、续费率、LTV。指标不同，但都在关注一段持续的使用关系。

背后的默认前提是：软件应该长期存在。

但喝完一瓶可乐，我们不会再去追踪那个空瓶子的日活。

更值得问的是：下一次口渴的时候，你会不会再次想到它。

所以，面对一次性的小软件，也许应该少问一点：这个软件还有多少人在用？

多问一点：用户一年会遇到多少次这样的需求？其中有多少次，会想到调用你的能力？

我暂且把这个观察角度叫作：Occasion Base，场景基数。

这是借来类比的说法，不是一个现成的行业标准指标。

过去，我们经营软件存量。

以后，我们可能还要经营需求发生的那些时刻。

03 从 Persona，转向 Occasion

软件行业很喜欢讲用户画像，Persona。

25～35岁、一线城市、产品经理、互联网从业者。

但快消品经常围绕消费场景来理解需求。

同一个人，早上喝咖啡，运动后喝电解质饮料，晚上聚会可能喝酒。

他还是那个人。但此刻想要的东西，很不一样。

于是，比“你是谁”更具体的问题是：你现在处于什么场景？

这件事放到AI软件里，也很有启发。

过去我们说：“给销售做一个CRM。”

以后可能是：“明天第一次见这个客户，帮我把过去半年的往来信息整理成一页。”

过去我们说：“给产品经理做一个需求管理工具。”

以后可能是：“还有20分钟开评审会，把这17份材料里的分歧点整理出来。”

需求还可以继续往下问：

Persona → Job → Occasion。

从一类人，到他要完成的任务，再到任务发生的那个具体时刻。

以前，给某类人做一个软件。

以后，给某一个时刻生成一个软件。

04 从 Retention，看向 Trial / Repeat

软件行业长期非常看重留存。

D1、D7、D30。

这当然有道理。但对于一次性生成的工具，留存需要换个对象来看。

快消品里，一套熟悉的观察方式是：Trial 和 Repeat。

第一次尝试了吗？用过以后，下次还会不会再买？

这套思路放到AI软件里，可能也合适。

比如，今天让AI生成一个“访谈自动聚类工具”。

用完，删除。

这个工具的D7留存是0。

但下一次碰到类似问题，我又回到同一个生成器：

“再帮我做一个。”

于是我们会发现：需要留存的，可能不是软件，而是生成软件的地方。

软件实例的Retention可以是0。

用户对生成器的Repeat，可以很高。

就像不必留住喝完的那一瓶，却要让用户下次还选这个牌子。

05 软件公司，也可能开始经营SKU

快消品公司很习惯经营 SKU，也就是具体的商品品项。

不同口味、不同容量、不同包装、不同价格，适应不同的消费场景。

然后持续上新、测试、调整和淘汰。

卖不好，就可以下架。不必要求每一个品项都活十年。

软件行业过去常见的做法是：把100个需求，尽量塞进一个App。

因为每多做一个软件，都要增加开发和长期维护的成本。

但当生成成本下降，一部分需求就可以拆出来。

100个需求，也可以生成100个小软件。

举个随手的例子，假设其中：80个只用一次，15个偶尔复用，最后5个逐渐沉淀成长期产品。

数字只是示意。重要的是，它们不必走向同一个结局。

于是，产品管理也可能从 Product Management，进一步走向 Portfolio Management / Assortment Management：产品组合、品项组合的管理。

我们面对的，可能是一大片不断出生、死亡、变异的软件。

不是每一个都要活下去，但整个系统要不断变得更强。

当然，生成便宜，不等于验证和维护免费。更值得留下来的，是复用能力和交付经验。

06 一个更有意思的概念：Postponement

供应链里，还有一个特别值得借鉴的方法：Postponement，延迟差异化。

简单说，就是不要过早决定最终产品长什么样。

先把通用能力准备好。等具体需求明确了，再完成最后的差异化生产。

因为需求预测难免出错。提前把所有可能的组合都做出来，库存和复杂度就留给了自己。

这个概念拿来理解AI软件，很合适。

很多传统标准软件，更像 Make to Stock：

先猜用户需要什么，提前把功能做出来，然后等用户来使用。

而一部分AI软件，可以走向 Generate to Order：

模型、数据、API、Skill、MCP、Design System都准备好了。

但最终那个软件，可以先不存在。

等用户说：“我现在需要这样一个东西。”

再现场生成。

这就是我之前聊过的“现炒型产品”：先备好厨房和食材，客人点了什么，再炒什么。

所以，未来最好的软件“库存”，可能是没有软件库存。

少囤一堆猜出来的成品，多储备生成软件的能力。

07 做水龙头，而不是只做水

我以前说过，未来产品经理做的，可能不只是具体产品，而是产品生成系统。

今年年初，我用了一个更直观的比喻：生成系统是水龙头，生成的产品是水。

今天流出来这一杯水，喝完了。

没关系。明天需要，再开一次。

真正值得长期建设的，是水源、管道、净化系统，以及那个随时可以出水的水龙头。

放到软件世界里，就是模型、数据、权限、组件、工作流、工具与接口，以及评价和安全机制。

还有，把这些能力重新组合成产品的生成系统。

过去，我们问：这个产品应该长什么样？

以后还要问：我要建设一个什么样的系统，才能持续生成合适的产品？

08 软件可能还不是“快消品”

所以，说“软件正在从耐用品变成快消品”，可能还不够准确。

传统快消品大多仍然要提前生产、运输、上架，等待购买。

而我们讨论的这类软件，可以在需求出现以后，再开始生产。

需求出现 → 生成 → 使用 → 完成任务 → 结束。

下一次需要，再生成。

我暂且把它叫作：按需生成品。

它不需要长期存在。

甚至不需要在需求出现之前，就被完整定义。

耐用品、快消品、按需生成品，当然会并存。这里讨论的是，越来越多的小软件可以选择第三种形态。

到那个时候，产品经理真正要设计的，也许就不只是那杯水了。

而是那个随时能流出合适的水的——水龙头。