转行B端产品经理要注意的坑

被坑的多了,才显得成熟!跟大家聊一下B端产品经理工作中经常遇到的一些坑。

转行B端产品经理要注意的坑

一、需求收集和预处理

1.收集需求,问题不够细致

先来看一个需求收集的例子:

示例1:

产品经理:您需要一个什么功能?
客户:我要一张报表,很简单的,就是看到每天的整体运营情况就行了。
产品经理:好的!
客户:
一周后。。。报表上线
客户:你这个报表不对呀,不是我要的。字段少好几个,都是很重要的。更新时间也不及时,老板要看到实时的数据的。这么简单个报表做一周还做不好。你们赶紧改好,要不我要去找领导告状啦!
产品经理:
可以看到,前期需求收集沟通不充分。后期成果交付的时候就会很痛苦。所以要在前期充分沟通问题细节。

再来看个例子:

示例2:

产品经理:您需要一个什么功能?
客户:我要一张报表,很简单的,就是看到每天的整体运营情况就行了。
产品经理:具体字段要什么?总交易量、用户总量?还有吗?
客户:嗯,,,还需要新增用户数、交易量环比增长率,,,,,,,
产品经理:这张表的实时性要求有多高?是每天9点上班看到前一天的数据就可以吗?
客户:基本是这样,但是有时候老板也可能要看当前的最新数据。
产品经理:如果是看最新数据,例如是上午11点要看,那环比增长率怎么计算?
客户:这个你等我回头想想。
产品经理:报表需不需要导出?需要哪些筛选条件?哪些角色可以查看、导出?上线预期时间什么时候?
客户:XXXXXXXXXX
产品经理:功能使用频繁吗?如果不经常用,不做功能,让开发每次后台拉下数据行不行?
客户:我再去问问老板,可能每次看的时候后台拉下数据也行。问完再跟你说。
是不是发现结果不一样?这样沟通,能够大大减少资源的浪费。每个问题都可能影响实现方案。
所以收集需求一定要细致,不要遗漏键信息。并且关键信息在产品设计的时候,要标注清楚。

2.需求收集,干系人识别不全

示例:

“哎呀,当时因为工期紧,跟运营同事聊的比较多比较透。财务同事沟通的比较少,结果这个资金异常场景没做兼容!”
如果上线后发现这种问题,是不是觉得很尴尬。。。
B端产品跟C端产品比,相关人员角色更多。例如公司领导希望看到全面的数据看板;中层管理人员希望看到大家的工作任务和进度;基层员工希望系统能帮助完成日常的工作任务。基层员工又会分为多种角色。各个角色的需求都是有区别的,因为工作专业性的划分,很难有某一个人能够把所有人的需求都说清楚。在需求收集的时候,要识别B端产品涉及到的所有干系人,然后都要进行充分的沟通。可能后期会做减法,但是一定不要遗漏关键信息。
干系人识别,可以通过了解对方组织架构,工作流程划分的角色来了解。

3.需求出口多不统一

今天需求方的A跑来跟你说我要个这个功能,明天B又跑来跟你说我要这个功能,都是需求方提的,哪个做那个不做?

如果这样收集需求,可能造成如下问题:

  • (1)需求收集零散,容易打断自身工作,且需求了解不充分;
  • (2)无法确定优先级,造成排期,版本管理困难;
  • (3)可能代表某个人的需求,而非业务方整体需求;
  • (4)涉及商务的合作,商务流程增加工作量;

针对这种问题,一方面要求需求方有统一的需求对接人,所有需求都需要经过对接人发出。促使其在提出去需求前,先进行内部沟通达成一致。另一方面,自身要做好需求管理,进行变更控制。

4.记录需求,没有进行需求处理

最经典的例子就是用户跟福特说要一辆更快的马车,福特给客户提供了汽车!

因为B端产品的作用是解决组织痛点,辅助用户完成工作。B端产品用户会很积极很明确的跟产品经理提出各种问题。有利的一面是产品经理能收到很明确的需求,不利的一面是用户在提出需求的时候往往提出的不是需求,而是直接给出“解决方案”。

这种说法是不是很熟悉:我这遇到个问题,你帮我加个XXX功能吧,是这样这样这样的。没问题吧?

但是用户仅仅是了解自己的工作,并不了解整个产品的设计思路。所以在收集到用户需求后,需要进行预处理,将用户提出的需求,转换成真正可行的产品需求。主要包括矛盾的需求、重复的需求、个性定制需求等。

当然,转换完成后,要用恰当的方式获得用户的认可。

如果不进行需求转换,用户说加什么就加什么,最后你的系统会变成一堆乱糟糟的石头。

5.需求接收前,没与技术沟通

因为B端系统复杂度高,一个功能可能与很多其他功能在业务流程上和技术实现上有很多关联。在需求正式接收前,要与技术讨论可行性。否则可能一个看似很小的非必要改动,产生很大的工作量。

需求方会抱怨进度太慢,技术团队会抱怨没有意义。

二、工作推进技巧

1.工作协作沟通,信息模糊

示例1:

客户:这个功能,你给实现下吧!
产品经理:好的!
半个月后。。。。。。。。
客户:那个功能上线吧?我跟老板承诺了,半个月上线的。
产品经理:团队工作排满了,那个功能排到了2个月之后了。
客户:。。。。。。。

示例2:

测试:那个功能模块根据计划昨天应该开发完成,今天测试。什么时候能提给我?
开发:还没开发完呢?
测试:为啥呀?
开发:那个开发模块,按照计划,5天之前需要XX给出接口,我还没有拿到。
测试:。。。。。。。。

以上两个场景,第一个是没有充分沟通预期时间和完成时间。第二个是工作无法按期进行,没有尽早识别风险。在工作协作中,这种沟通方式,会大大影响合作双方的满意度,耽误工作进度。如果长时间这样,团队之间将会慢慢的失去信任。对整体工作也会失去信息。

所以建议工作沟通,采用"5+1"的方式,及明确5个要素和1个约定。

转行B端产品经理要注意的坑

沟通过程中要明确这五个要素,分别是:

  • (1)工作输入资料、信息、资源:例如接口文档,业务约定以及为完成此任务配备的人力、设备资源是否充足;
  • (2)前置依赖任务:进行当前任务,必须要完成的前置任务,一项或多项。例如要进行系统连调,涉及到的单元模块都要完成开发。
  • (3)当前节点负责人和工作任务:此工作具体由谁去完成,工作任务是什么?
  • (4)当前任务输出成果:具体产出成果是什么?
  • (5)输出成果时间,具体到小时:时间约定的详细,为下游人员工作安排提供依据。

一个约定:5个要素出现问题,需要当前节点负责人在问题出现时,立即通知各个干系人。

明确这”5+1“信息之后,再发挥各个节点的主观能动性。才能很好的把控各个环节的工作协作,最终降低整个工作协作计划的风险。

2.口头确认,未留档记录

C端产品,大部分是与技术、运营团队去协作完成产品实施工作,大家都是公司内部同事。利益出发点相对一致,合作会相对和谐。B端产品的实施流程中涉及到比C端角色要多,除了技术、运营,还有销售、需求方。涉及到的角色多,并且大家的诉求不一致。需求方一定是希望花费更少的资源完成更多的工作。这几造成在商务谈判的时候,对方一定会仅仅强调必要的功能。但在实际需求收集过程中,各种干系人又会尽量全面的提出自己的需求。这种情况下“撕逼”的事情就很难避免。各方都没有错,只是大家的出发点不一样,才会产生分歧,也造成这种分歧不可避免的出现。有时候是因为时间太久了,大家都记不清细节了,会产生分歧。

这种情况下,在工作推进过程中,各个环节就要做好”签字画押“的工作。就是要留存可追溯的资料,供大家查询核实。例如需求交付开发团队前,要进行需求评审,需求范围,产品设计方案,各种细节,要获得需求方确认,并且留档。

三、市场调研和竞品分析不充分

做过产品经理的朋友都清楚,对C端产品来说,市场调研和竞品分析都是很重要的工具。同样,这两个工具在做B端产品的过程中同样重要。但是在B端产品,因为信息收集比较困难,很多刚刚转型的产品经理会选择放弃。内心独白是这样的:“不是不想做,实在是找不到有价值信息呀!!!”

但是B端产品这两个工具其实是很重要的。原因主要有两个,一是由于B端有很强的行业特征,行业经过多年的发展,有了一套自己的运作模式。产品方案需要兼容这套模式,所以需要充分了解行业、市场运作模式。二是B端系统业务流程复杂、设计干系人角色多,很难做到完美。当前现存的竞品,一定是经过前辈们踩过无数的坑才幸存下来的。所以做B端产品借鉴前人经验,更加的重要。

一般初步的收集信息方式可以去平台申请产品DEMO试用账号、与客服沟通、与销售人员沟通索要资料等。详细的信息收集方法和分析步骤,稍后有机会单独展开介绍。总之,市场调研和竞品分析对B端产品还是很重要的,切不可忽略。

不过,踩坑也并不是坏事。每次踩坑,都能让我们发现工作中的问题,增加自己的实践经验。

希望我们都能在踩坑过程中不断成长!

作者:董小圣,公众号:小圣聊产品,互联网产品经理经验分享、交流!

本文由用户@道格发布于新媒体运营,未经许可,禁止转载。

题图来自Unsplash,基于CC0协议。

本文由 新媒体运营 作者:道格 发表,其版权均为原作者所有,文章内容系作者个人观点,不代表 新媒体运营 对观点赞同或支持,未经许可,禁止转载,题图来自Unsplash,基于CC0协议。
1

发表评论