Se Connecter Maintenant 转型做产品以后，我经手的几个项目，大部分都是 to B 的定制化产品。回过头看，我慢慢形成了一个挺朴素的标准——客户真心觉得你帮他解决了问题，愿意掏钱，而且还愿意把下一次合作继续交给你。反过来，如果这个都没做到，前期投入再多，最后也很难收场。
一个让我印象特别深的失败项目，就是这么来的。
那是一个靠老板关系拿下的实验室项目，要做一套内部管理系统，带一点行业门槛，是我们之前完全没接触过的业务。一开始做 to B 系统，想法很单纯：既然是定制，销售比我们更懂客户，那就照着现成的需求做，人家说什么我们做什么。业务方对接的时候，也常常直接就甩过来一句：“你给我加个什么什么功能。”我们想，按他说的做，总不会错吧？
项目就这么按传统的方式推了下去，我们把完整的系统流程全部跑通，交付验收。结果呢？客户付完一期费用以后，死活不愿意再付二期，项目被迫关停。这时候，我们才不得不回过头来复盘，问题到底出在哪。
一开始接触需求，我们找的是一线操作人员，他们最了解具体的业务细节。聊起来的时候，他们往往侃侃而谈，很明确地告诉你，“我要这个功能”“我要那个功能”。因为甲方太强势，我们基本上就靠甲方销售口头上那句“最终验收没问题”撑着，傻傻地照着他们说的去做。可实际上，这些东西根本解决不了他们的实际问题。他们自己可能都没想过，这项业务对管理到底有什么提升。他们提的 90% 以上的问题，归结起来就一句话：业务数据要能看得清清楚楚，平常在系统上记录数据、做操作，要比手工用 Excel 更方便。
产品经理在设计的时候，会本能地考虑页面整洁，把一些明细数据收进详情页，主页只保留最核心的数据展示，避免出现上下左右各种滚动条；不同模块的数据也尽量放在不同的地方，这样逻辑上才合理。可业务方不这么看，你如果不给他一个页面，让他一打开就能看到所有的数据，他马上就会跟你急，直接说需求没满足，系统不好用。他们不明白，为什么这么简单的“全放在一个页面”的要求，你都不肯给我。
很多业务人员确实只会站在自己那一亩三分地上思考问题，未必关注产品宏观价值、业务流程标准化或者管理规范这些事。比如，真正的目的是做数据统计，结果他提过来的需求只是加一个导出功能，或者在列表里多加一个字段。最后，我们做出来的系统，几乎每个页面都有一个导出按钮，尴尬得让人说不出话。
我们做的是实验室项目，很多平台各自做实验，每个平台都有自己的业务经理，某一步实验甚至还有单独的销售人员负责。单独沟通的时候，他只会说：我负责这一步，把我这一步弄完就行了。比如做 DNA 提取，他提的需求非常简单：导入提取数据，保存，提交，完工。他压根不会去想，如果你在其他平台上做实验，提取这一步可能需要区分是给第一代还是第二代实验做的；比如文库构建失败了，样本得重新提取；第一次提取量不够，或者样本没用完，剩下的样本怎么保存、怎么处理……这些问题，后来慢慢浮现出来，但那时候已经拖了太长的周期。
一开始我们不懂业务，只能听他们说。聊完、做完一个版本推出来，只能覆盖他们 70% 左右的常规情况，剩下 30% 的特殊情况，根本没法满足。更要命的是，他们理解不了产品是需要迭代的。在他们看来，产品上线就像传统企业交付一个东西，你得一次性给我最终版本，然后我才能用。总之，不 100% 满足我的业务场景，我就不用。
我们想推 MVP，从 0 到 1 先上基本功能再慢慢迭代，可他们一句话就怼回来：“为什么没有我想要的那个功能？”非要把他们想要的所有东西都做完，才肯开始用。想改变他们的习惯，尤其是线下那套已经跑得滚瓜烂熟的操作，真的太难了。他们早就习惯了用 Excel 记录数据、安排任务、打印审核报告，你突然让他用系统，他反而觉得不顺手，还不如 Excel 来得方便。
最后系统上线，我们做了一次评估统计，结果让所有人都惊呆了：80% 的操作人员不想用这个系统。我们明明已经把至少 95% 的业务逻辑都做进去了，花了那么多时间研发，几乎把自己逼成了行业专家，而且系统功能复杂完整，怎么他们偏偏要抱着那种“low”方法不放呢？
那种震惊，真的很难消化。
在这个项目里跟无数业务人员对接过之后，我含泪总结出几条教训。
最要紧的一条是，需求梳理一定要自上而下。多跟一线沟通当然没错，这个时间绝对不能省，但最先应该沟通的，是高层，而且最好是懂一点互联网产品的高层。你得搞清楚，他们企业为什么要做这个系统，到底要解决什么管理问题，现在最大的痛点在哪里，未来三到五年的发展方向又是什么。我们做的东西，怎么帮企业解决这些问题，哪些该优先解决，哪些又可以往后放一放。懂互联网的人，能省掉一大半沟通成本，他甚至可以给你描述出具体的使用场景。接下来，一定要找部门经理对接。他们最熟悉整个部门的业务，也有跨部门协作的视角，能从整个部门的发展角度，把一条完整的流水线讲清楚，还能告诉你主要的异常情况怎么处理，哪个环节和哪个环节之间会存在想法不一致。最后，再去找一线人员，让他们慢慢告诉你业务细节，怎么提高效率，怎么提升用户体验，改变以前的习惯能带来什么好处。当然，整个过程中，一定要有工作流程图，把所有人的认知对齐。
再一条，一定要进入实际业务，别光听他们说。甚至别让他们写需求文档，谁知道他们写出来的，跟你理解的，是不是一回事？一千个人眼里还有一千个哈姆雷特呢。每个人的专业背景、认知、性格、表达方式都不一样，对同一个需求的理解可能天差地别。我们得走进他们的实际业务里，去做角色扮演——假设我就是这个岗位的人，我这么做，有没有更好的解决方案？只有摸到他们需求的本质，再想办法用更好的方式去满足，然后直接告诉业务方我们的方案和好处，我相信他们不会拒绝。等你了解到一定程度，产品经理一定会比他们更专业，考虑到的细节也更多。他们想到的简单问题，你已经帮忙解决了；他们没想到的困难问题，你也替他们想了，还给出了不错的方案。这样，你才能说服他们——人，只会听比自己更厉害的人的话。当然，这个过程必须有文档和原型图，不能空口说白话。
还有一条，一定要划清界限，保持沟通。合作做项目是为了双赢，甲方提高效率、解决管理问题，乙方成为行业专家。但项目审批原本就是为了控制项目周期、成本、预期和风险，任何一次延期或者超出预期，都可能让整个项目崩盘。这时候，得引导用户一起确定项目范围，项目的目标和价值都得靠这个范围来锁定。我们甚至必须协调公司高层参与，最终通过高层对话把范围敲定下来。除了管好人，最难的是控制需求，防止需求一点一点往外蔓延，最后演变成大规模的需求变更。否则，业务人员的需求不断追加、不断变化，最后双方都累得不行，产品就成了客户和开发两边一起喷的对象。市场当然也在变，也许我们开发的时候，市场已经悄悄转向了；变化可以，但一定要算成本，否则客户不认，技术也不认，最后背锅的总是产品经理。交付一定要签字，只有签字才能引起重视，也才能把责任真正落实下来。
说了这么多，无非是因为失败的产品比成功的产品要多得多。下次有机会，再跟大家聊聊 C 端失败的案例，欢迎指正。