B端产品经理小A故事:走进客户(1)

4 评论 2966 浏览 10 收藏 17 分钟

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还洞察到,中小客户还具备如下特征:

  1. 采购通路上, 通常是经过本地渠道采购,所以渠道非常重要
  2. 均单不高,所以实际真刀真枪的产品竞争并不激烈,主要在于如何有效触及客户、以及影响本地渠道选择。

所以H在商业模式上也进行了设计:

  1. 大幅让利给渠道,影响渠道选择,从而广泛建设渠道体系,快速触达客户
  2. 产品上需持续降低交付成本

很快,X公司的2B产品-笔记软件-浅记 上市销售了。同样很快,开始遇到了问题。

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

三、笔记支持图片的故事

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

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

于是,在献祭了X名程序员的Y根头发后,将图片上传功能给做了出来。类似于下图:

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

小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大图片还是有不少客户需要,竞争对手同类产品当前也有此问题(注:本文假设)。于是决定采取如下策略:

  1. 上门向客户一番道歉,暂时先软件限制 ,判断出1MB以上的图片先不允许上传,避免崩溃丢失笔记。
  2. 根据内部工作量评估,向客户承诺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协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 不走进客户 无法准确把控客户需求

    来自广东 回复
    1. B端尤甚,B端产品经理不是客户本身

      来自湖南 回复
  2. QQ邮箱当时实现产品突破的几个地方,其中一个就是超大附件,和这个超大SVG有异曲同工之妙。

    来自四川 回复
    1. QQ邮箱的超大附件还蛮好用的。在云盘没有起来的时代,基本是发大文件首选

      来自湖南 回复