B端产品经理小A故事：你是在画猫吗？——走进客户（3）
A系列的前3篇主题是“为什么要走进客户”，这里的走进客户，不仅是指B端产品经理，还包含开发测试等相关研发类岗位。
原文是22年Q4应邀整理，在公司内部论坛上发表的文章进行少量修改而来，当时受邀出发点首先是向B端研发岗位讲述为什么需要走进客户，当时以故事化进行了整理。
一、笔记扩容风波
很显然，产品江湖永远也无法真正平静！
在见完客户W的第6307241分31秒之后，小A早上出门，落叶从车窗飘过，小A右眼开始剧烈地跳动。小A面色凝重，他知道，可能一波新的挑战要来临了（大误)。
当天，客户V上报了一个紧急故障，全员无法正常使用笔记。
经过排查，原来是客户私有部署的笔记服务器空间存储满了导致的。
通过紧急删除了一些不必要文件，临时放出7%左右空间后，暂时恢复了业务。
初步确认到的原因，是笔记服务器的控制管理界面在最后10% 剩余时有提醒，但是管理员基本不登录控制管理台，导致没有提前发现。另外，剩余空间不足时也有邮件告警通知，但是客户没有配置邮件。
但是这个剩余提醒客户并不认可，原因是客户认为存储空间是异常突增的，不应该增长这么快，很有意见。
应销售售前之邀，小A计划立即前往拜访客户V。
出发前，小A去见老C。
老C：“这次异常增长原因查出来了吗？”
小A：“目前还没有分析出原因，B哥还在看。B哥、B哥，你过来一下。”
大B：“确实是有些异常，从日志上粗略看，是近半年增长很快，还需要近一步分析。”
老C：“那我建议你跟小A一起去，这次问题可能是出在可靠性架构上，小A可能稳不住场。客户是本地的，过去也很快，你们这会就出发吧，不要耽误了。”
于是出发的人员增加了大B。
客户V：“我们之前用了两年多，只用了25%的存储空间，为什么今年一年用了80%，原因是什么？25%的空间是我今年开年主动看过的，因为涨得很慢，所以我每年都会检查一次空间。我们的员工数量也没有增加，这个非常奇怪。”
大B：“V总好，这边咱们分析后再给你一个答复，估计晚饭时间就差不多了。我们总部一直在同事在远程分析，我这边马上也现场接上去看。”
过了几个小时，情况大致清楚了。
大B：“V总，原因基本清楚了。我看到咱们在7个月前，升级了咱们的一个版本，然后默认支持了图片上传。咱们这边后续图片用量一直很大，我们初步分析了下，不包含系统本身，整个笔记占用里，文字大概只占容量的20%，图片占了差不多80%。”
客户V：“那你们计划怎么解决，我刚登上去看了下，就今天一个白天的功夫，空间就从7%掉到6.5%了，按这个推算，岂不是只能支持一周时间？”
大B：“这边预计是要进行型号升级或磁盘升级，我们接下来会内部讨论方案，讨论完再和您对齐。今天我们就先回去讨论了，预计明天我们还会再过来。您的现网设备我们同事会定期检视。”
客户V：“升级或扩容磁盘都可以，但是我希望业务断线时间不要超过1小时，我们这边有国内和海外的业务，全天候都有人使用的，只能找使用人员少一些的时间段进行变更。”
1. 问题： 客户环境模拟偏差
回去后，小A、大B拉上老C以及相关人员进行了讨论。
小A：“我先说明一个关键信息：因为客户业务全天都有人在用，客户有提出希望断线时间不要超过1小时。具体怎么变更，大家讨论下吧。”
大家开始了讨论，而老C一直在思考，没有说话。
小A：“C哥，你给说说呗，你这样子让人感觉没底啊。”
老C：“我确认一个点，刚刚讨论出来的步骤是不是计划先内部环境演练模拟 ，然后后续到客户现场变更时，上一套新设备，先把生产环境给停了，然后再导配置进行升级？”
小A：“是这样的。但是我们刚刚讨论你也听到了，只能这样啊。如果生产环境不停止，那么，用户可能还在不断修改新增笔记，就会导致最后新环境丢失数据，所以要这么操作。”
老C：“那我补充一个风险，我强烈建议不要先停生产环境。而是增加一个现场模拟阶段，直接从生产环境导出配置，再导入新设备，验证一下整个步骤过程顺利性以及耗时。验证充分后，再去动生产。否则很可能引发二次事故。”
第三天一早，小A一大早给老C电话：”C哥，你这个建议可真神了，昨晚我们避免了一个二次重大事故。”
老C：“哦？具体情况是怎么样？变更成功了吗？”
小A：“变更没有成功。但是我们还是很高兴、很庆幸，虽然没有变更成功，但是我们至少没有引发二次事故。”
小A：“你知道吗？我们内部模拟的时候，都在1小时内能搞完导入导出。结果到了客户现场，光从生产环境导出配置的时间就花了快1小时。导出后，再到新环境导入，花了2小时。一共花了3小时，断线时间客户不符合预期。”
小A：“关键是你知道吗，我们还发现了几个神奇的BUG，在客户的现场配置环境下，我们发现导出环节、导入环节都丢失了大概10%的笔记，一共丢失了20% ，这个问题影响可太严重了，要不是昨晚发现了，要真给客户这么升上去，那问题可就大条了。”
老C：“好好，发现就好。原因是什么？查到了吗？”
小A：“昨晚连夜查到了。多亏大B哥带上了导入导出配置这一块的模块负责人- 对应的开发人员现场保障排查，速度很快，要不然还真不一定能连夜查出。”
小A：“你知道问题原因是啥吗? 导出环节，是客户有一部分笔记图片多内容超大，然后我们的图片存储方式有些问题，导致这部分无法导出，而且处理慢；导入环节，是客户有一部分笔记的编码有异常，导入处理时对这些编码异常的没有正常处理，导致导入又慢又丢文件。”
老C：“这样子，内部模拟为啥没有发现这个问题？”
小A：“和大B哥对过了，还是客户的笔记配置模拟得不一样。这种图片超多超大的笔记，和编码异常的笔记，都没有模拟出来。”
2. 问题：偏离客户真实场景
老C：“这次出差你有什么收获吗？”
小A：“我觉得首先一个是 模拟客户的真实环境很有必要，而且越贴近真实越好，我们实验室模拟很可能出偏差。”
老C：“还有吗？”
小A：“其实过程中还有一个问题，就是我们因为硬件库存原因，新设备只能先上一台单机，但客户老的生产环境是一套双机。我们之前有个限制，就是双机导出的配置，禁止在单机上导入。这个我们是通过后台修改，暂时放开的。”
小A：“现在想想，这个确实很傻。之前简单考虑，认为应该双机环境的就只能导入到双机环境，但实际情况可能会有很多异常，没办法限得那么死。”
老C：“第一个你说要模拟的真实环境。那么后面你说的这个，你认为后面应如何避免呢？”
小A：“我觉得和前面的模拟真实环境类似。只是这个是要模拟真实使用场景，咱们做运维类功能，不能单独基于功能去思考应该怎么做，而是应该串到运维场景中，按场景流去做。”
老C：“你的思考总结很好。我们不是客户的运维人员、也不是2B产品充分的使用者，就应该多模拟客户的环境，模拟客户的真实使用场景，才能尽可能避免遗漏。”
3. 问题：不理解客户的关注优先级
老C：“大家停一下，小A，你说一下关键情况。”
小A：“近期技术支持报障率增加了50%个百分点，而且从增长来看，80%都来自于空间逼近不足的客户。从目前来看，只要存储剩余空间低于20%，就有可能会出现性能降低、访问时断时续、访问慢的问题，目前这方面影响明显的客户上报就超过20个。”
大B：“本市就有5例以上的客户。我已计划多派几个开发出去，分头排查根因，同时也保障一下客户满意度。”
小A：“我补充一下，现在问题比较棘手。因为性能降低、访问断续之类的现象，都是随机且非必现、非持续的。并不是低于20%一定会出现；也并不是低于20%，就某企业的所有用户都出现； 更不是问题出现后，就一直出现，可能一会就好了。你要说不能用吧，还有20%正常应该能用才对啊。”
大家讨论了一番后，暂时没有好的方法，只能先按部署开始出差客户。
小A和大B选了本市的一个影响力最大、情况也相对明显的客户U出差现场。
客户U有些不高兴：“你刚刚介绍的情况我清楚了，大概就是说现在情况不明确，需要排查，今天也未必能查出来，或者说本周都不一定能排查出来 ，对不对？”
客户U努力控制着情绪，说道：“我也懂一些技术，也知道有些事情急不来。所以我关注的是，你能不能先保证我们机构的领导层使用正常，不要出问题？”
小A：“U总，您的意思是？”
客户U：“很简单，这么解释吧，普通员工偶尔出现一些问题，IT部门还能兜得住，但是我们领导层要是总出问题，这个影响力太负面，IT部门完全顶不住。从优先级上看，如果你当前不能保证快速解决问题，那么就给我保证领导层可使用的问题。普通员工的抱怨，我来解决。”
小A和大B商量了一下，最后给出进一步答复：“我理解了。基于您说的点，我们初步有两个思路，您看怎么样？一个是我们再新建一套VIP环境，把领导的数据后台定向导入到VIP环境，再把访问请求引过去； 一套是我们技术上优先保障VIP用户的资源（包括磁盘IO、CPU内存等，都保障好，确保VIP用户能用）。两者唯一区别是不需要再新建一套环境。”
客户U：“我都可以接受，只要效果好，我希望尽快变更，这两天就变更！！”
客户U：“另外你的这些访问慢、时断时续的问题，和客户端有关的，一定要有办法自动收集客户端日志，就像上午我们机构1号领导出现问题，你让我找他拿日志，怎么拿？我们都没办法直接联系，只能找他的秘书中转。”
小A和大B回去后，一方面，快速解决了导入导出慢的问题，并快速落地了VIP用户保障的机制，针对较为明显的客户出具补丁，临时规避。
同时，继续排查找到20%剩余空间下时断时续问题的根因，并紧接着进行了解决，从而使得剩余空间低于20%，但仍未占满的客户依然能够正常使用。
4. 关键决策：调整规划优先级
20%剩余空间内高几率异常的问题虽然找到根因并修复，但是，这些客户的剩余空间依然是不足的，一段时间后还是会出现空间完全占满，再次导致无法正常访问。这个风险仍然存在，于是小A拉上大B和老C进行讨论。
小A：“C哥、B哥，咱们这个空间不足的问题，比较棘手，咱们讨论一下下一步应该如何解决？总不能每一个客户都去换新型号设备吧？不说硬件成本，光是升级迁移的交付成本咱们也受不了啊。”
老C：“我记得之前咱们对型号是有定义的吧，XX大小的存储，能支持10~15年的笔记存储，即使是用量大一些，也有七八年吧。现在才上市2年多，就有这么多使用到80%以上空间的了。”
小A：“我们之前是按纯文字笔记预估的，那确实10年都不一定用得完。但是后面我们更新版本后支持图片，图片占用空间可就大多了。”
老C：“大B，你有什么好的主意？”
大B：“从我的视角，我觉得无非几个。要么是通过资源解决，比如说换设备、加磁盘，要么就是通过产品和技术手段去解决，比如说我们把图片做压缩或图片保存到外部等。因为我们以前硬件选型就是按纯文字做的，现在增加了图片肯定是对不上了。”
老C说道：“那估计得这样，我们针对普遍客户，都推动升级，把图片保存到外部。这个图片服务器也可以客户自己搭建，但默认可以使用我们云端提供的，这样可以避免影响客户原定硬件选型。”
大B提出补充：”如果是客户是纯内网，无法连接到云端图床怎么办？”
老C：“那就只能本地部署。所以我们这个图片服务器应当支持云化和本地。”
大B：“从技术上考虑，客户未来还有可能会上传其他类型的文件，比如说视频、pdf附件等，虽然这些我们现在还不支持，我们这个服务器可能不能只是图片服务器，而是存储服务器。”
小A: “我也补充一下，前面在导出功能时，我们就犯了不理解客户工作模式的问题。这里上传服务器，客户可能会已经有自身的一些存储等，我们应该要能够支持和主流的客户存储系统对接。甚至是不是笔记也应该能直接存储过去？我们即使要自建一套，也应该符合主流的存储协议，不要自己造轮子。”
老C：“提得都很好。那接下来，就是关键的问题了。这些事情，应该什么时机做，是立即做还是什么时候做？以什么节奏做，是一次性做还是分阶段做？对现有产品规划的影响是什么？小A，你怎么考虑。”
小A沉默半晌，想着之前做的规划演进路线(roadmap)，以及之前承诺过部分客户的功能特性：”C哥，现在比较关键的有5个产品特性，**其中xx、yy两个麻烦一些，有针对个别项目说过时间，算是一种承诺。”
老C点了点头，鼓励地看着小A：“继续说，先说完，像我们往常分析问题一样，系统地描述一下，到底应该怎么分析，说说你的思路。”
小A：“首先从优先级上，存储满导致不可用，我认为优先级高于新特性。因为它是基本可用性。”
老C不置可否：“嗯，继续。”
小A：“从时机上，我们应该要尽快确认剩余空间低于20%或者甚至是40%的客户数，再判断一下20%的客户走到存储满需要多长时间，倒推出我们的完成时间。从当前主观来看，不少客户用完20%可能就是1-2个月左右，初步判断可能是要立即开始 。B哥，你初步估计这个优化完成，需要多久？”
大B：“方案可以分阶段，不过我认为从测试稳定到发补丁版本，还有搞定存储服务器，初步估至少需要1-2个月。而且，我预估要停主线版本，从里面大举抽人，以版本外的人力大概率搞不定。”
老C：“好，那策略上就明确，停主线版本，必须保证核心质量可用。”
老C：“小A，你承诺的2个客户，提前通知，该道歉道歉。另外在答复前，这两个特性明天我们核对一下，受此重大版本影响后，这两个特性是紧接着实现，还是彻底取消，需要结合其他受影响特性综合评估调整策略，评估完成后再答复。”
老C：“大B，你接下来从技术视角，制定一个分阶段落地的方案。这个阶段是要对客户有用的，不能是纯内部的开发阶段。比如说先做图片压缩，如果不影响图片阅读，又能缩减一定比例的空间，就可以作为第一步，否则就不行。我们后续所有的策略制定都高度依赖于你的方案。”
老C：“另外，从风险角度，一定要有分阶段缓解方案，直接上重大的外部存储变更，我很担心会出二次问题。”
老C：“我和小A先从产品视角制定一套，明天一早我们技术和产品的进行核对。”
老C：“GOGOGO，赶紧动起来。”
在接下来几个月的时间里，浅记停止了主线版本开发，转而去修复存储空间不足的问题，最终通过分阶段的方式对问题进行了修复。
5. 导师老C和小A的交谈
老C：“和承诺客户道歉了吗？感受怎么样？”
小A: “很难受，不知道是不是第一次的原因，感觉变成了渣男。我想不管如何，以后我承诺特性会更加谨慎。”
老C：“哈，或许以后你会更适应一些。对了，我看你还分析了后续其他友商的同类问题情况，从后续事情变化上，你学到了什么？”小A：“嗯，我确实做了分析。后面来看，一共有三类友商。”小A：“第一类，是同样有存储空间不足，但是没有及时修复的问题，xx厂商我了解了下，是不舍得停主线版本。”
老C：“这类厂商结果如何？”
小A：“XX厂商现在在市场上口碑很差。我们和其他厂商都在攻击xx厂商对客户不负责任，客户之间自己也在互传。基本上，预估他们今年市场规模要往下掉好几名。”
小A：“第二类，是同样有存储空间不足，但是和我们一样有及时修复问题的厂商。yy厂商是其中典型，但是他比较倒霉，第一波修复方案有问题，搞丢了不少客户的笔记数据，第二波修复避免了此问题，但是已经丢失的数据，据说有些是找不回来了，现在也被我们和其他厂商攻击。”
小A：“第三类，是有提前考虑到存储空间问题，提前做了图片压缩、对接外置存储的一部分机制。主要就是zz厂商。但是他们错过了这波机会，原因一是他们之前没有意识到这一点的重要性，没有做好宣传； 二是**他们没有做完整，差了外置存储服务器提供这一环节，存储协议支持也不完备，相当于提前做了70%，还差30%**。等这个问题暴露出来 ，我们支持度到了100%，他们还是70%，已经晚了。”
小A：“我们其实属于第2类。”
老C：“你对这3类怎么看？有什么收获？”
小A：“第一类，对核心质量不负责任的，除非是无竞争市场，否则必将被淘汰。这也说明我们的决策选择是对的。”
小A：“第二类，对核心质量负责任，但是提前没有做好工作的，其实是都付出了产品规划在意料外调整的代价，相当于是在战斗中犯了一个错误，纠正错误是有代价的。当然，不纠正，问题会更严重，就变成第一类了。我认为这种无准备之仗，情况后续要尽量避免。”
小A：“再说第三类，zz厂商提前考虑到了一部分问题，提前做了处理，后续对规划影响就不大。相当于是战斗前期少犯了错误。但是当其他友商犯错时，他们情报不足，没有抓住破绽及时攻击，给了对手(包括我们)修补防线的机会，从他们的视角，着实有些可惜。”
小A：“同时，我认为他们当时支持图片压缩、对接外置存储服务器，可能是有偶然的成分，所以没有把这个特性基于价值做完整（只做了70%），也没有借此在PK中发挥出优势。最终给了我们反败为胜的机会，反而化优势为劣势。”
老C：“很好，那对我们有什么启示？”
小A：“原则上所有产品特性，都应匹配于客户的价值，并完整闭环，当它不完整时，价值发挥度可能是很低的。投入产出比也很低。”
老C：“很好。我前不久在MOA群组里看到W同学转的一张图，是乔布斯讲知识->经验->创意的，知识好比是一个个离散的点，经验就是把点连成线段，而创意则是把线段和点连成一只猫。我觉得这个放在产品规划上，也是有异曲同工之妙。”（如下图）
老C：“反思过往，我们做的很多功能特性，有不少是单点功能，只是满足部分客户某个离散的场景，就类比于上面提到的单点的知识，我们可以称之为画点。”
老C：“有的功能特性，可能是针对某部分环节，做了几个相对连续、关联的能力，此时不能算是画点了，我们可以称之为画线。”
老C：“而我们做产品，如果是想做成一个堪称伟大或者说 真正优秀 的产品，真正需要的恰恰是画猫。”
老C说着有些激动了起来：“但是我们过往做了些什么？可能针对最小化客户、需求最简单的客户，是画有一只比较小的猫。”
小A听着，点了点头，不由补充道：“这只最小化的猫虽然有了，但可能还很丑，不够优雅、不够强壮。”
老C：“是的。我们可能针对A客群，画了几条线段； 针对B客群，画了一只猫爪； 针对C客群，画了一只猫的尾巴。”
小A连连点头：“是的，C哥，我也有这种感觉。听你说完，回顾过往，感觉我们确实很容易陷入到画点、画线的陷阱里面，有时候一些客户一倒逼，我们就给他画了一个点、或画了一根线，根本连不成猫。C哥，这个问题我们应该怎么办，我有些迷茫了。”
小A接着问道：“ 如果客户在我们的目标客群内，大场景也没有明显的偏离，不做就是没有客户导向，文化帽子有时压死个人。即使不在我们的目标客群内，有时前场拿着客户重要性、标杆性倒逼，再给我们画个未来的饼，我们就得费老鼻子劲去沟通，有时真是感觉蛮痛苦。”
老C：“你说这个有多方面的原因。首先记住，改变自己永远比改变他人要容易。所以先从对自身严格要求的角度来看，我觉得首先是我们自身的问题 – 我们不能很好讲清楚要画什么样的猫，不知道要先画什么猫，后画什么猫，是加菲，还是蓝白短尾。那就容易被别人逼着画加菲的耳朵、蓝白的腿、折耳的脚趾。”
小A点了点头：“那这点怎么提高呢？”
老C：“就是4个字，走进客户，从客户中来，回客户中去。搞清楚几只猫长什么样(目标画像)、先画什么(优先级)之后，决策就有了定力，就更不容易被动摇。”
小A：“C哥，你前面说的我很认同。但是C哥，我还有个疑问，我心底快速复盘一下过往接到的各类需求，不管是做了定制，还是进了版本，我感觉有些需求就是离散的，成不了猫。但是有些需求，又偏偏得做，咱们不做，又成不了单，客户不买。”
老C：“这个问题问得很好。你有什么思路？”
小A：“难道是把这些离散的点，放大、做细，画成一只小猫？从而增强在该点上的竞争力？”
老C：“哈哈哈，你有多少开发资源和产品资源，可以这么做? 假设你之前做了100个离散的点，如果都要强行画成猫，岂不是只能画3个、10个小猫？另外，这些离散的点，它真的重要吗？”
老C：“所以这里面一部分，是要靠咱们的规划定力来解决，做好选择和取舍，这个能解决一部分问题，但是无法根本性解决。因为另外一部分涉及到商业模式、规划方向等多方面，和我们的业务经营设计有关系，比较难解决。”
小A：“啊？商业模式，这个怎么理解？”
老C：“唔，这次咱们的篇幅太长了，如果有机会，咱们后续再补充说明。”
二、 尾声
老C：“有个神秘的声音提醒我，希望你能总结一下，哪些岗位需要走进客户，为什么要走进客户，以及研发是否需要走进客户，又如何走进客户？”（应邀答复）
小A：“C哥，总结好了是不是要请我吃饭啊？去你家打火锅？”
老C：“那就看你本事了，说吧。”
小A：“首先是产品经理类岗位，是一定要走进客户的，尤其是非甲方出身的产品经理，更需要。2B产品最大的问题，是自己并不是真实使用者、运维者、采购者。走进客户，有如下作用：
- 直面客户，避免中间二传手导致场景理解偏差
- 能够跨品类汲取产品灵感
- 能够理解不同客户的工作模式、业务模式
- 能够理解不同客户的思维模式，他们关注什么。做客户优先关注的事情
- 还能如C哥所说，理解客户之后，从画线演进成画猫
- 最后还能回收质量问题，做出关键决策，比如说必要时调整质量规划
针对研发而言，技术管理岗位比如说架构师、研发主管、TL等，是很有必要出差客户的。可能有如下作用：
- 可以汲取技术灵感
- 能够结合客户真实使用场景进行开发、演练闭环，避免闭门造车，最后驴头不对马嘴
- 避免产品规划有时成为二传手，尤其是有些技术属性强的特性场景，技术人员出差是非常有帮助的话
- 更有利于真正有效理解客户。雾里看花，终隔一层。 打个比方，就像你隔着手套去摸物，肯定是有差异的，手套越厚，偏差越大。”
老C：“说得很好。那普通开发人员呢，如何走进客户，说说你的理解？”
小A：“个人浅见，我觉得普通开发人员的出差画像可能是这样的：
1）针对自身负责的模块/子系统，有质量问题，比如说问题比较多时，可以直接出差，感受一下模块出问题对客户的影响，有助于提升质量意识； 同时，这类问题很多都可能和客户真实场景有关，有助于提升客户场景理解。
2）有些相对重要、相对关键的子系统/模块，也可以回访一些深度用户，从技术视角看是否有改进。
3）其他情况下，普通开发人员出差就是投入产出比不高的事情了。此时，则更多需要依靠于产品经理、技术管理者出差后，回来描述清楚这只猫长成什么样，有效传递给普通开发人员，使其提升客户意识。这就是二传手们面临的重大挑战了。”
小A：“唔，这么说着，深感责任重大啊。尤其是上次和C哥你聊完后，发现我过往画猫的工作就没做好。”
小A：“对了，C哥，我总结得怎么样？火锅啥时候搞起？话说这入冬了，正是打火锅的好时节啊。”
老C笑了笑，边说边往外走：“哈哈，你倒是能挑时间。那就看看读者们怎么评价了。读者们说好，火锅立马就搞起。”
小A：“C哥咋走了，上次讨论的画猫难，你说和商业模式有关，还没讲清楚啊。”
老C：“那个啊，那个不是说了有机会后续再讲吗。我之前和你说过，产品经理，最重要的是什么？
是耐心！毕竟资源有限的情况下，规划的价值特性，经常要一年半载甚至更长才能进主线，也是常有的事。有耐心的人才能笑到最后。”
小A：“……”
作者：非典型产品经理笔记 ；公众号：非典型产品经理笔记（ID：techpm2021）
本文作者 @非典型产品经理笔记 。
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！