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)
本文作者 @非典型产品经理笔记 。
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!