2B产品的使用场景一般是企业性场景，它的综合开发成本相对较高，价格也相对高昂。那么，2B产品为什么要走进客户呢？本文作者虚拟出一个B端笔记产品——浅记，围绕这个笔记软件，以小A为主角，将其工作中所遇故事、所产生的疑问问题以故事形式展示和剖析，一起来看一下吧。
2B产品的使用场景一般是企业性场景，它的综合开发成本相对较高，价格也相对高昂。那么，2B产品为什么要走进客户呢？本文作者虚拟出一个B端笔记产品——浅记，围绕这个笔记软件，以小A为主角，将其工作中所遇故事、所产生的疑问问题以故事形式展示和剖析，一起来看一下吧。
A系列主要用于描述B端产品经理的一些思考，主角被称为小A，所以命名为A系列。B端产品也叫“2B(Bussiness)”产品，使用对象是组织或企业，也就是非面向个人/非消费者产品。
考虑自身所负责产品不便于细节展示、而且由于其技术专业性很多读者也不能快速熟悉，所以会虚拟出一个B端笔记产品——浅记。
众所周知，笔记类软件是一个特殊的软件，想必多数人都有用过笔记软件，类似为知笔记、有道笔记、印象笔记等。所以应当是更易于理解。
本系列会以小A为主角，将其工作中所遇故事、所产生的疑问问题以故事形式展示和剖析，可能会涉及到围绕2B产品经理相关的方方面面，不定期更新。
一、序
A系列的前3篇主题是”为什么要走进客户“，这里的走进客户，不仅是指B端产品经理，还包含开发测试等相关研发类岗位。
原文是22年Q4应邀整理，在公司内部论坛上发表的文章进行少量修改而来，当时受邀出发点首先是向B端研发岗位讲述为什么需要走进客户，当时以故事化进行了整理。
我们知道2B产品有一个很大的问题，是开发人员、产品经理往往并非其真实使用者。
所以我们需要假设本文所述笔记软件是一款“2B”产品，其同样具有如下特征：
展开全文
价格相对高昂，需要“企业”才能承担，个人通常不会购买。
使用场景是企业性场景，故该“2B”产品（即笔记软件）的“开发人员”、 “产品经理”、“销售人员”、“售前人员”均没有深度使用该“2B”软件（即笔记软件)。
综合开发成本相对较高，多数企业均难以自行开发，故有必要由专业的供应商来提供。
其他未描述到的相关B端特性。
话说在XX年前(虚拟时代,勿考究)，X公司创始人H看中了2B行业，决心在此创业，成为一个 “2B”青年。
经过洞察，H敏锐地发现，多数“企业”都具备 笔记软件的诉求。其中，中小“企业”具有如下特征：
中小客户有相对明显的需求，且核心需求易满足，核心只需要基本的新建笔记、保存笔记、编辑笔记的需求，门槛不高
中小客户市场上暂无明显巨头或先进入者，具备成功机会
中小客户成本敏感，需要一款物美价廉的笔记产品
最终其创业方向为 一款“2B”产品-笔记软件（注：本文假设）。
同时，H还洞察到，中小客户还具备如下特征：
所以H在商业模式上也进行了设计：
很快，X公司的2B产品-笔记软件-浅记上市销售了。同样很快，开始遇到了问题。
注：下述所有需求和问题均为 基于2B笔记软件的假设模拟，同时进行了简化处理，仅为说明遇到的问题。
三、笔记支持图片的故事
发布后不久，产品经理小A，就收到了渠道1的反馈。说客户Z有个关键需求，当前笔记只支持文字，但是该客户工作中需要涉及到图片和文字，希望能支持图片（注：本文假设）。
小A和渠道1聊了聊，认为基本了解清楚了客户诉求，于是没有去拜访客户。虽然 小A自身不需要使用笔记软件（假设），但是基于过往对客户和现有产品的了解 ，图片和文字是类似的，只是做一个加法而已。SO EASY！
于是，在献祭了X名程序员的Y根头发后，将图片上传功能给做了出来。类似于下图：
小A认为该功能是浅记定位中的相对通用的功能。于是功能完成了交付，并升级到了浅记的主线版本。
过了三七二十一天，小A估摸着笔记软件已经被客户Z升级并使用一段时间了（2B产品升级谨慎，变更周期长），于是联系渠道1进行确认（中间有渠道），渠道1又经过48个小时，给出了客户Z的反馈：
“怎么说呢？功能一般吧。笔记是支持图片了，但是我日常用得最多的，是要在复制网页中的图片、或截屏，现在我需要把截屏或网页中的图片，保存到本地，再到笔记软件中去点击上传按钮，每次都很麻烦。这个有办法优化吗？”
1. 问题：客户场景传递偏差
产品经理小A意识到存在偏差，于是经过和渠道2确认后，出差客户Z现场，和客户进行了交流，最终确认了 实现一个可以从剪切板直接复制图片到笔记软件的功能，该功能得到了客户Z的好评。
然而问题并没有结束，正当小A松了一口气之时，渠道2又反馈了客户Y的投诉。
客户Y：“你的笔记软件能上传svg格式的图片，为什么不能正常显示？而且svg图片也不能再下载回来。我把svg图片上传后，源图片就删除了，现在也找不回来，差评！！谁做的产品，脑壳有包吗？”
几经了解，产品经理小A发现，原来是当时主要只考虑了png和jpg的常用格式，这两种格式笔记才能正确处理。svg是一种矢量图片格式，虽然可以上传，但是不可以显示。
经过再次献祭了X个程序员N根头发后，支持SVG图片的功能开发完成。这次小A特地盯瞩渠道2，一旦客户Y升级试用后，第一时间给出反馈。
过了几天，渠道2给出了客户Y的反馈：『升级完，客户试用了下，可以了』。
然而小A预感问题并没有结束，果然没过几天，客户Y再次投诉：
“以前上传svg，虽然不能显示不能下载，但好歹笔记不会丢失。现在是一上传，笔记软件就崩溃了，然后写了一半的笔记全丢了！！你们告诉应该怎么办？”
由于问题比较严重，于是产品经理小A去找了开发架构师大B，大B经过分析后给出了初步的结论：
大B：“客户的svg图片非常大，会超过1MB，以前不解析svg的时候，只是当文件传没问题，但是现在开始解析后，解析引擎不支持1MB以上的svg图片，一旦过大就会引发崩溃(注：问题为本文假设)。”
小A：“有办法快速解决吗？”
大B：“不行，图片解析引擎需要重构，工作量不小(注：本文假设)。最简单的规避方法，就是不让客户上传1MB以上的svg图片。”
2. 问题：技术架构偏差，偏离客户场景诉求
产品经理小A通过当前销售的情况发现，svg大图片还是有不少客户需要，竞争对手同类产品当前也有此问题（注：本文假设）。于是决定采取如下策略：
过了X个月后，svg大图片功能发布，给客户Y升级后试用，客户Y如下反馈：
“功能是正常了，1MB以上的也能用了，但就是太慢，需要转2分多钟的圈， 只能说勉强能用吧 ！ 你们还有办法优化吗？”
产品经理小A找到开发架构师大B确认情况，大B为难地答复：
“svg大图片支持，以我们目前研究到的业界情况和技术情况，目前1MB以上差不多都要好几分钟，咱们优化到2分钟，已经算快的了。目前技术上确实还没有找到好的方式优化（注：此为本文假设），继续研究需要花很长的时间，确认咱们还要花很大的力气在这个点上进行攻坚吗？从我的视角，这个应该不算咱们非常核心的竞争力吧？只能说是一个小分支？”
产品经理小A思考后认同，于是向客户Y说明了情况，客户Y同意结束争议，暂时搁置。
后续客户Y在使用过程中陆续发生了一些其他产品问题，于是产品经理小A决定携同开发架构师大B出差回访一下客户Y。
在出差交流时，大B特意又针对上次svg大图片的事情进行了说明：“ svg大图片的事情确实不好意思，我们目前暂时还没有找到更好的技术方案去优化，不知道对您现在使用上有什么影响吗？”
客户Y摆了摆手，略显得意地说道：“单用你们的产品，那肯定是有影响的。不过我在xx工作的朋友 ，给我推荐了一个svg图片缩放的软件，能够把svg图片给缩小了，但是图片细节不受影响，基本能缩小到几百KB，只要把文件拖进去，10秒钟就变小了，再用浅记的时候就没影响了。所以我现在影响还好。活人哪能被尿憋死，你说是不？”
小A和大B都敏锐地意识到了这个点，问道：“Y总，方便说下这款软件吗？”
3.3、收获: 跨品类汲取技术灵感
从客户Y拜访结束后，产品经理小A兴奋地说道:”我们如果把这款工具给集成进去，是不是就能解决svg大图片的速度问题了? 前段时间的项目PK中，咱们刚开始靠着支持svg大图片，把其他几个友商狠狠地K了一顿，现在他们陆续也赶上来了。不少客户还是关注这个点的，我个人是认为有必要去优化，你的意见呢？”
开发架构师大B摆了摆手，说道:”集成可没意思，显得太low了。我刚刚在现场操作，然后也用工具做了分析，基本弄清楚了它的技术思路。结合之前做svg大图片时研究的，有可能还能做得更好，关键是，这个主要是思路很巧妙，技术难度和工作量都不算太大“。
大B回去带着技术团队，不久后就将这个技术完成了突破，然后合入了功能主线。速度比原本的软件10秒做得还快，基本上秒级就可完成svg大图片转换。
凭着svg超大图片秒级支持，基本保持了半年的竞争优势（注：本文假设），在后续在一段时间内，都得到客户和渠道的一致点赞。
4. 导师老C和小A的交谈
关于此事，小A去找导师老C去交流：“C哥，刚入职时你就告诉我，要多去拜访客户，我当时还不懂，经过这几次事情，我想我现在好像懂一些了。”
老C：“你的成长确实超出我的预料，敢拼敢打，勇于实践，而且还有思考！说说你学到了什么？所谓三人行必有我师，我也学习下从你的视角总结的内容。”
小A：“你看，浅记这个产品，说起来很简单，最核心的功能无非是写笔记。但是，由于咱们自身不是2B客户不写笔记（注：本文假设）， 不了解客户的场景，容易出偏差。就像前面图片上传的功能，我以为真的是上传一个图片文件，哪晓得客户是截图复制； 包括后面svg图片的，真是提前想不到png/jpeg两大主流格式还不够，要支持一个svg。关键还有svg大图片。”
老C：“嗯，不错，如果让你用一句话总结一下，你会怎么理解出差？”
小A：“我觉得是出差让我们能更好了解客户场景，避免产品设计偏差。”
老C：“很好！这是产品经理的视角。我看你还拉着架构师大B一起去见了客户，你认为开发去见客户和你见客户会在收获上有什么差异吗？”
小A：“我觉得B哥(架构师)如果最初见了客户，不对，光见还不够，还得了解清楚客户使用svg是超大图片，那么有可能svg大图片的技术点可以更早识别出来 ，能够避免技术架构走弯路。 这以说的话，见客户其实有两大作用：对产品经理而言，避免产品设计偏差； 对研发而言，避免技术架构设计出现偏差。”
老C：“很好！我也觉得是这样。另外我再补充一下，其实你们最近一次收获其实也蛮重要的，只是它不是每次一定都能成功，有一定的运气成分。”
小A：“哦，C哥你是说那个 svg大图片的技术方案是吧？这个我感觉确实是的。B哥后面也很开心，和我说 如果有优质的客户或优质的产品可以现场分析的，让我再叫上他。”
老C：“是的，所以出差客户，对开发而言，还有可能跨品类汲取技术灵感。并且你说，可能也不仅限于技术灵感，对产品经理而言，产品灵感是否有可能呢？”
小A若有所思地点了点头。
（未完待续……)
本文由 @非典型产品经理笔记 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议
特别声明
本文仅代表作者观点，不代表本站立场，本站仅提供信息存储服务。