#46 A003-B 端产品经理小 A 故事-你是在画猫吗？

• 0、前言

• 1、序

• 2、笔记扩容风波 2.1、问题： 客户环境模拟偏差 2.2、问题：偏离客户真实场景 2.3、问题：不理解客户的关注优先级 2.4、关键决策：调整规划优先级 2.5、导师老 C 和小 A 的交谈 3

• 3、 尾声

0、前言

开新坑啦！毕竟公众号名称就叫"非典型产品经理笔记"，至少也得来一点产品经理相关的内容,A 系列正式登场

A 系列主要用于描述 B 端产品经理的一些思考，主角被称为小 A，所以命名为 A 系列。

注：B 端产品也叫“2B(Bussiness)”产品，使用对象是组织或企业，也就是非面向个人/非消费者产品。

考虑自身所负责产品不便于细节展示、而且由于其技术专业性很多读者也不能快速熟悉，所以会虚拟出一个 B 端笔记产品-浅记。

众所周知，笔记类软件是一个特殊的软件，想必多数人都有用过笔记软件，类似为知笔记、有道笔记、印象笔记等。所以应当是更易于理解。

本系列会以小 A 为主角，将其工作中所遇故事、所产生的疑问问题以故事形式展示和剖析，可能会涉及到围绕 2B 产品经理相关的方方面面，不定期更新 。

如有相关想法或疑问需交流，欢迎私信，也可能会按照私信咨询的问题，进行故事更新。

--- 笔者按

1、序

A 系列的前 3 篇(A001~A003)主题是"为什么要走进客户"，这里的走进客户，不仅是指 B 端产品经理，还包含开发测试等相关研发类岗位。

A001~A003原文是 22 年 Q4 应邀整理，在公司内部论坛上发表的文章进行少量修改而来，当时受邀出发点首先是向B端研发岗位讲述 为什么需要走进客户，当时以故事化进行了整理。

由于原文章过长（有 1.6 万字），所以发表时拆分为 A001~A003 共 3 篇。

#44 A001-B端产品经理小A故事-走进客户1

#45 A002-B端产品经理小A故事-走进客户2

#46 A003-B端产品经理小A故事-你是在画猫吗？

2、笔记扩容风波

很显然，产品江湖永远也无法真正平静！

在见完客户 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 小时，我们这边有国内和海外的业务，全天候都有人使用的，只能找使用人员少一些的时间段进行变更。"

2.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.2、问题：偏离客户真实场景

老 C:"这次出差你有什么收获吗？"

小 A:"我觉得首先一个是 模拟客户的真实环境很有必要，而且越贴近真实越好，我们实验室模拟很可能出偏差"

老 C:"还有吗？"

小 A:"其实过程中还有一个问题，就是我们因为硬件库存原因，新设备只能先上一台单机，但客户老的生产环境是一套双机。我们之前有个限制，就是双机导出的配置，禁止在单机上导入。这个我们是通过后台修改，暂时放开的"

小 A:"现在想想，这个确实很傻。之前简单考虑，认为应该双机环境的就只能导入到双机环境，但实际情况可能会有很多异常，没办法限得那么死。"

老 C:"第一个你说要模拟的真实环境。那么后面你说的这个，你认为后面应如何避免呢？"

小 A:"我觉得和前面的模拟真实环境类似。只是这个是要模拟真实使用场景，咱们做运维类功能，不能单独基于功能去思考应该怎么做，而是应该串到运维场景中，按场景流去做"

老 C:"你的思考总结很好。我们不是客户的运维人员、也不是 2B 产品充分的使用者，就应该多模拟客户的环境，模拟客户的真实使用场景，才能尽可能避免遗漏"

2.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%，但仍未占满的客户依然能够正常使用。

2.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，赶紧动起来"

在接下来几个月的时间里，浅记停止了主线版本开发，转而去修复存储空间不足的问题，最终通过分阶段的方式对问题进行了修复。

2.5、导师老 C 和小 A 的交谈 3

老 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:"唔，这次咱们的篇幅太长了，如果有机会，咱们后续再补充说明。"

3、 尾声

老 C:"有个神秘的声音提醒我，希望你能总结一下，哪些岗位需要走进客户，为什么要走进客户，以及研发是否需要走进客户，又如何走进客户？"（应邀答复）

小 A:"C 哥，总结好了是不是要请我吃饭啊？去你家打火锅?"

老 C:"那就看你本事了，说吧"

小 A:"首先是产品经理类岗位，是一定要走进客户的，尤其是非甲方出身的产品经理，更需要。2B 产品最大的问题，是自己并不是真实使用者、运维者、采购者。走进客户，有如下作用：

1)、直面客户，避免中间二传手导致场景理解偏差

2)、能够跨品类汲取产品灵感

3)、能够理解不同客户的工作模式、业务模式

4)、能够理解不同客户的思维模式，他们关注什么。做客户优先关注的事情

5)、还能如 C 哥所说，理解客户之后，从画线演进成画猫

6)、最后还能回收质量问题，做出关键决策，比如说必要时调整质量规划。

小 A:"针对研发而言，技术管理岗位比如说架构师、研发主管、TL 等，是很有必要出差客户的。可能有如下作用：

1)、可以汲取技术灵感

2)、能够结合客户真实使用场景进行开发、演练闭环，避免闭门造车，最后驴头不对马嘴

3)、避免产品规划有时成为二传手，尤其是有些技术属性强的特性场景，技术人员出差是非常有帮助的话

4)、更有利于真正有效理解客户。雾里看花，终隔一层。 打个比方，就像你隔着手套去摸物，肯定是有差异的，手套越厚，偏差越大"

老 C:"说得很好。那普通开发人员呢，如何走进客户，说说你的理解？"

小 A:"个人浅见，我觉得普通开发人员的出差画像可能是这样的:

1)、针对自身负责的模块/子系统，有质量问题，比如说问题比较多时，可以直接出差，感受一下模块出问题对客户的影响，有助于提升质量意识； 同时，这类问题很多都可能和客户真实场景有关，有助于提升客户场景理解

2)、有些相对重要、相对关键的子系统/模块，也可以回访一些深度用户，从技术视角看是否有改进

3)、其他情况下，普通开发人员出差就是投入产出比不高的事情了。此时，则更多需要依靠于产品经理、技术管理者出差后，回来描述清楚这只猫长成什么样，有效传递给普通开发人员，使其提升客户意识。这就是二传手们面临的重大挑战了。"

小 A:"唔，这么说着，深感责任重大啊。尤其是上次和 C 哥你聊完后，发现我过往画猫的工作就没做好"

小 A:"对了，C 哥，我总结得怎么样？火锅啥时候搞起？话说这入冬了，正是打火锅的好时节啊"

老 C 笑了笑，边说边往外走:"哈哈，你倒是能挑时间。那就看看读者们怎么评价了。读者们说好，火锅立马就搞起"

小 A:"C 哥咋走了，上次讨论的画猫难，你说和商业模式有关，还没讲清楚啊"

老 C:"那个啊，那个不是说了有机会后续再讲吗。我之前和你说过，产品经理，最重要的是什么？

老 C:"是耐心！毕竟资源有限的情况下，规划的价值特性，经常要一年半载甚至更长才能进主线，也是常有的事。有耐心的人才能笑到最后"

小 A:"..."