导语：之前上线的X功能最终用户都没有用起来，惨遭下线，你觉得是因为什么？B端产品经理做久了，大家手上或多或少总会有那么一两个最终没有落地成功的项目。今天本文作者借着这个问题简单的复盘之前碰到过的类似经历，也为大家的后续项目提个醒。

一、用户为什么不用

需求并不是凭空出现的，基于[问题]和[目标]出现的需求，上线了为什么没有人使用了呢？啥问题不存在了吗？还是目标变化了？还是出了其他问题了？

通常，项目到了落地阶段，相信整体上还是已经经过多轮沟通，多番验证，大家对需求实现上还是达成一致的，那怎么到了使用环节上就变了卦了呢？我们第一反应肯定也是揪着用户问，为什么不用啊，哪里不好用还是怎么的？

通常会得到以下这么几个答复：

• “有问题用不了啊，怎么用啊”；
• “我不想用，需求又不是我提的”；
• “啊，要用这个吗，我不知道啊”；

整体可以概括为以下几类：

1. 细节偏差-用户无法使用

针对用户无法使用，我们可以再细分为两类，由于：产品细节或外部依赖造成的使用问题。

1）案例一：TMS物流计费-外部依赖

物流计费是指通过系统内维护好的计费规则，结合外部流入的运单自动计算运费。记得刚上线的时候，我兴冲冲的问业务方，你们是不是算账方便多了，业务方泼了我一脸冷水说“没有，更麻烦了”。

详细了解之后发现，因为他们的物流方式是整车物流，目前大部分整车物流公司都是不具备线上平台能力的，所以线上的运单都是我们员工自己录入的，但是录入过程又无法约束，导致进入系统的运单数据杂乱，生成的账单可用率低。

对账人员之后是线下对账之后，再对一遍线上账，造成了2倍的工作量。那功能自然就使用不下去了。

2）案例二：个人库存-产品细节

在运营过程中，业务为了管控员工个人身上的库存，管控过程资损，建立了个人库存概念，将个人当成库位，进行出入库和库存的管理。通过领用增加库存，通过安装后设备感应安装结果扣减库存，对用户来说实操上没有变化。因此在前期推进时，阻力不大。

但是随着整体灰度范围扩大，逐渐发现由于设备感应的准确性问题，会直接影响个人库存的准确性，小雪花慢慢滚成雪球，一两次误判逐渐累加，个人的库存不再具备可行度，资产过程管控更是无从谈起。

主要原因在于设计前期没有针对设备感应能力进行准确评估，并且也没有设计针对设备结果的补偿判断逻辑。因此虽然过程没有问题，但是由于无法达到预期的管控目标，只能暂时下线。

在上面这两个案例中，其实用户是有使用意愿的，但是由于设计细节的问题导致用户无法正常使用产品，也无法达到预期价值。这类问题其实反映了产品规划阶段的思考不到位，没有将所有关键影响因素纳入考虑范围。

2. 沟通偏差-真用户假用户

B端产品很多时候，使用的是一线的人，提需求的是管理的人。管理者希望通过系统规范用户操作，使用者希望通过系统简化操作，两者常常存在不可调和的矛盾，而产品的实现则是需要权衡和兼顾两者。稍有偏颇，很可能就导致项目落不了地了。

1）案例三：扫码组装

扫码组装是指针对管理到ID级别的贵重商品，在安装过程中，要扫商品ID和组装品ID来确认两者的绑定关系以实现资产管理。

想法是好的，没有错。在产品方案的设计上也并不复杂。但最终落地失败，主要原因就在于给组装员工带来了巨大额外工作量的同时，并没有对他们创造“额外价值”。

在实操过程中，由于实际环境的问题，经常存在扫码失败、扫码延时的问题，且因为作业量大（一天整体组装量在数十万量级），实操用户叫苦不迭，甚至直接做走了一大票临时工。

因此在B端产品的设计中，不能只听一家之言，哪怕真的是来自管理方的需求，也应该和实操方进行确认，确保流程可以落地。能落地的需求才是真正能带来价值的需求。

之前和一个做B端的朋友沟通关于业务系统的价值，其中聊到最重要的环节在于“业务流程化”，以此为基础其后才能实现“流程系统化”。对没有经过流程化验证的实操进行系统化，务必要慎之又慎，确保全链路全方位的沟通。

3. 推进偏差-用户不懂使用

这类问题通常比较少，但是我确实也遇到过。因为当前所在公司全国各地基本上都有仓库，人员流动性也不低，用户培训和运营很难做到慢慢俱到。特别是一些使用不频繁的工具，到下次要使用的时候可能仓里人已经换完一轮了。

导致用户错用、乱用功能，问起来就是“啊，我不知道要这么用啊”。而这方面对于产品的考验主要在于产品的易用性和引导性设计。

二、思考总结

上面主要针对于我遇到过的一些落地失败的项目总结。对于产品来说，当遇到产品落地失败之后，挫败感自然是难以避免的，但是更应该做的是去思考为什么落地失败，以及针对当下的失败情况，积极沟通应对处理。

1. 基于核心价值的思考

首先，要明确，项目的方向上是否有问题。这个问题，其实问的是需求解决的核心目标是什么。或者说，我为什么希望用户按照我设计的做。

比如上面案例三-扫码组装中，核心目标实际上是为了解决资产管理的问题，并不是为了扫码而扫码。而人工扫码绑定的这个方案，目前看来显然是得不偿失了，非要死磕，那这个问题就过不去了。这个时候我们就应该去思考有没有其他方式可以实现核心目标。

补充说下，这个问题我们最终是通过硬件上报取代人工扫码辅助产品的方式解决。

而不同于案例三，案例一中，本身产品目标就是为了解决各种物流方式下计费难的问题，因此碰到“来源数据不准”的石头，不管怎么绕，始终是解决这个问题的必经之路。那么接下来显然是需要去解决这个依赖问题，而不是推翻重来。

之前我在制造工厂的时候，也会碰到一线说经常使用错物料导致装配返工的问题，让在电子SOP上做提示，做各种优化警告。结果最终问题是通过一个简单的安装工装解决的。分清目标和手段，在碰到问题时，你总能想到更好的解决方案。

2. 如何避免失败

与其说如何避免失败，不如说降低失败的概率更合适些。最后我用一张脑图总结今天的这篇文章。希望这篇文章对你有所启发。

#专栏作家#

麋鹿产品，公众号：麋鹿产品手册，人人都是产品经理专栏作家。专注供应链挖掘提升，热爱生活，热爱产品。

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CCO协议。