90% 的功能失败 — 你的团队可能没有提出这个问题

Source: Dev.to

问题

我见过团队花了数月时间构建根本没人想要的功能。才华横溢的工程师、扎实的代码、清晰的架构——却在沉默中发布。零采纳。功能就这么……闲置着。

失败率非常残酷。根据 MIT 的数据，大约 95 % 的新产品未能达标。Pendo 的研究显示，平均 SaaS 产品中有 80 % 的功能很少或根本不被使用。这不是四舍五入的误差，而是系统性的问题。

为什么功能会失败

大多数团队跳过了最基本的问题：为什么会有人真的使用它？

• 不是 “这会不会很酷？”
• 不是 “有客户要求吗？”
• 不是 “竞争对手有这个功能吗？”

真正的问题更深——这个功能为某人完成了什么工作，这个工作是否足够痛苦，以至于他们会改变行为去使用它？

我尊敬的一位 CPO 如是说：在你知道“为什么”时再发布，而不是等代码写完时。实际上，几乎没人这么做。

典型情景：

1. 产品收到来自销售的需求。
2. 工程评估需要两个冲刺。
3. 领导层希望把它放进季度路线图。

没有人停下来验证那 200 位受益用户是否真的会采纳。两个月后，使用数据出来了：3 % 的采纳率。该功能悄悄被埋在子菜单里，团队继续前进。

Pendo 发现，平均每个 SaaS 应用的功能成本 超过 200 万美元 却完全未被使用。把这个数字乘以整个组织的产品表面，你会看到惊人的浪费。

战胜 90 % 失败率的团队习惯

1. 在写代码前先与用户交谈
   不是调查——是真正的对话。 五次访谈能揭示的内容超过 5,000 条调查回复，因为你能听到犹豫、变通以及“其实我会这么做……”的瞬间。

2. 提前定义成功标准
   示例：“如果在 60 天内有 30 % 的核心用户采纳此功能，则视为成功。” 没有这个标准，每个功能同时是成功也是失败，因为没人统一认同何为胜利。

3. 砍掉功能
   删除一个耗时三个月构建的功能看似浪费，但维护一个没人使用的功能才是真正的浪费——它增加了复杂度，拖慢代码库，并让新用户困惑。

4. 衡量行为，而非观点
   用户在调查中会说他们想要某东西，但随后从不使用。追踪人们的实际行为，而不是他们说要做的事。

最优秀的首席产品官会使用一个简单的过滤器：每个功能都必须有明确的用户问题、可衡量的结果以及淘汰标准。如果你不能用一句话分别阐述这三点，功能就还不适合交给工程实现。

如何落地

• 这并不是让你变慢，而是让你更有目的性。
• 在构建前进行验证的团队实际上发布得更快，因为他们在不重要的事上浪费的时间更少。
• 大多数功能失败的原因是：构建比思考更容易。写代码让人觉得在产出；进行用户访谈则显得慢。数学很清楚——一周的验证可以节省数月的无效开发。

下次你的团队准备构建某东西时，问自己：

“如果我们明天就发布它，具体会有谁使用，他们会停止做什么来使用它？”

如果你无法用具体的姓名和细节回答，那么你很可能正要加入那 90 % 的失败功能行列。

你们团队发布过的最糟糕、没有人使用的功能是什么？我真的很想知道——请在评论里告诉我。