苏格拉底的书这样理解正确吗?

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

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

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

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

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

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

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

　　2)、使用场景是企业性场景，故该2B产品（即笔记软件）的开发人员、产品经理、销售人员、售前人员均没有深度使用该2B软件（即笔记软件)。

　　话说在XX年前(虚拟时代,勿考究)，X公司创始人H看中了2B行业，决心在此创业，成为一个2B青年。

　　1)、中小客户有相对明显的需求，且核心需求易满足，核心只需要基本的新建笔记、保存笔记、编辑笔记的需求，门槛不高

　　2)、均单不高，所以实际真刀真枪的产品竞争并不激烈，主要在于如何有效触及客户、以及影响本地渠道选择。

　　注：下述所有需求和问题均为基于2B笔记软件的假设模拟，同时进行了简化处理，仅为说明遇到的问题。

　　发布后不久，产品经理小A，就收到了渠道1的反馈。说客户Z有个关键需求，当前笔记只支持文字，但是该客户工作中需要涉及到图片和文字，希望能支持图片（注：本文假设）。

　　小A和渠道1聊了聊，认为基本了解清楚了客户诉求，于是没有去拜访客户。虽然小A自身不需要使用笔记软件(假设)，但是基于过往对客户和现有产品的了解 ，图片和文字是类似的，只是做一个加法而已。SO EASY！

　　小A认为该功能是浅记定位中的相对通用的功能。于是功能完成了交付，并升级到了 浅记的主线版本。

　　过了三七二十一天，小A估摸着笔记软件已经被客户Z升级并使用一段时间了(2B产品升级谨慎，变更周期长)，于是联系渠道1进行确认(中间有渠道)，渠道1又经过48个小时，给出了客户Z的反馈：

　　怎么说呢？功能一般吧。笔记是支持图片了，但是我日常用得最多的，是要在复制网页中的图片、或截屏，现在我需要把截屏或网页中的图片，保存到本地，再到笔记软件中去点击上传按钮，每次都很麻烦。这个有办法优化吗？

　　产品经理小A意识到存在偏差，于是经过和渠道2确认后，出差客户Z现场，和客户进行了交流，最终确认了实现一个可以从剪切板直接复制图片到笔记软件的功能，该功能得到了客户Z的好评。

　　客户Y：你的笔记软件能上传SVG格式的图片，为什么不能正常显示？而且svg图片也不能再下载回来。我把svg图片上传后，源图片就删除了，现在也找不回来，差评！！谁做的产品，脑壳有包吗？

　　几经了解，产品经理小A发现，原来是当时主要只考虑了png和jpg的常用格式，这两种格式笔记才能正确处理。svg是一种矢量图片格式，虽然可以上传，但是不可以显示。

　　经过再次献祭了X个程序员N根头发后，支持SVG图片的功能开发完成。这次小A特地盯瞩渠道2，一旦客户Y升级试用后，第一时间给出反馈。

　　以前上传svg，虽然不能显示不能下载，但好歹笔记不会丢失。现在是一上传，笔记软件就崩溃了，然后写了一半的笔记全丢了！！你们告诉应该怎么办？

　　大B: 客户的svg图片非常大，会超过1MB，以前不解析svg的时候，只是当文件传没问题，但是现在开始解析后，解析引擎不支持1MB以上的svg图片，一旦过大就会引发崩溃(注：问题为本文假设)。

　　大B: 不行，图片解析引擎需要重构，工作量不小(注：本文假设)。最简单的规避方法，就是不让客户上传1MB以上的svg图片。

　　产品经理小A通过当前销售的情况发现，svg大图片还是有不少客户需要，竞争对手同类产品当前也有此问题（注：本文假设）。于是决定采取如下策略：

　　1)、上门向客户一番道歉，暂时先软件限制 ，判断出1MB以上的图片先不允许上传，避免崩溃丢失笔记。

　　功能是正常了，1MB以上的也能用了，但就是太慢，需要转2分多钟的圈， 只能说勉强能用吧 ！你们还有办法优化吗？。

　　svg大图片支持，以我们目前研究到的业界情况和技术情况，目前1MB以上差不多都要好几分钟，咱们优化到2分钟，已经算快的了。目前技术上确实还没有找到好的方式优化(注：此为本文假设)，继续研究需要花很长的时间，确认咱们还要花很大的力气在这个点上进行攻坚吗？从我的视角，这个应该不算咱们非常核心的竞争力吧？只能说是一个小分支？

　　后续客户Y在使用过程中陆续发生了一些其他产品问题，于是产品经理小A决定携同开发架构师大B出差回访一下客户Y。

　　在出差交流时，大B特意又针对上次svg大图片的事情进行了说明: svg大图片的事情确实不好意思，我们目前暂时还没有找到更好的技术方案去优化，不知道对您现在使用上有什么影响吗？

　　客户Y摆了摆手，略显得意地说道:单用你们的产品，那肯定是有影响的。不过我在xx工作的朋友 ，给我推荐了一个svg图片缩放的软件，能够把svg图片给缩小了，但是图片细节不受影响，基本能缩小到几百KB，只要把文件拖进去，10秒钟就变小了，再用浅记的时候就没影响了。所以我现在影响还好。活人哪能被尿憋死，你说是不？

　　从客户Y拜访结束后，产品经理小A兴奋地说道:我们如果把这款工具给集成进去，是不是就能解决svg大图片的速度问题了? 前段时间的项目PK中，咱们刚开始靠着支持svg大图片，把其他几个友商狠狠地K了一顿，现在他们陆续也赶上来了。不少客户还是关注这个点的，我个人是认为有必要去优化，你的意见呢？

　　开发架构师大B摆了摆手，说道:集成可没意思，显得太low了。我刚刚在现场操作，然后也用工具做了分析，基本弄清楚了它的技术思路。结合之前做svg大图片时研究的，有可能还能做得更好，关键是，这个主要是思路很巧妙，技术难度和工作量都不算太大。

　　大B回去带着技术团队，不久后就将这个技术完成了突破，然后合入了功能主线秒做得还快，基本上秒级就可完成svg大图片转换。

　　svg超大图片秒级支持，基本保持了半年的竞争优势(注：本文假设)，在后续在一段时间内，都得到客户和渠道的一致点赞。

　　由于咱们自身不是2B客户不写笔记(注：本文假设)， 不了解客户的场景，容易出偏差。就像前面图片上传的功能，我以为真的是上传一个图片文件，哪晓得客户是截图复制；包括后面svg图片的，真是提前想不到png/jpeg两大主流格式还不够，要支持一个svg。。关键还有svg大图片

　　能够避免技术架构走弯路。这以说的话，见客户其实有两大作用：对产品经理而言，避免产品设计偏差；对研发而言，避免技术架构设计出现偏差。

　　svg大图片的技术方案是吧？这个我感觉确实是的。B哥后面也很开心，和我说如果有优质的客户或优质的产品可以现场分析的，让我再叫上他

　　跨品类汲取技术灵感。并且你说，可能也不仅限于技术灵感，对产品经理而言，产品灵感是否有可能呢？