十步洞察2B产品用户需求

人人都是产品经理 2017-05-17 11:44:55

人人都是产品经理是中国最大最活跃的产品经理学习、交流、分享社区。集媒体、社区、招聘 、教育、社群活动为一体,全方位服务产品经理。本文由人人都是产品经理社区 作者:艾老思,前腾讯首席敏捷管理教练,“极速产品研发”方法论创立者;原创发布。转载请联系人人都是产品经理。

blob.png

苦逼的2B产品经理

请注意2B产品经理不是骂人啊!而是指做企业产品的2B产品经理。(怎么感觉还是有点怪,干这行真吃亏)

艾老思认为2B产品经理是宇宙里最苦逼的产品经理!他们有三大苦难(排名不分先后):

1、自己做的产品,自己永远也用不上

正如金蝶李帆老师讲到的:“做了十几年2B软件产品,难以成为最终用户。但是即便2B,也必须要有用户的思维和最接近用户的方法,否则做的产品只是纸上谈兵。所以,靠自己单打独斗是不行的,必须借助外脑。”

2、客户和用户分离,到底该听谁的?反正自己说话不管用

艾老思也在后援团里说过:

“2B表面上是服务客户,但再往前挖一层,可能会有两种情况。如果2B产品是给自己企业用的,例如OA,真正的用户是客户企业的实际使用用户。如果2B产品是给自己的客户用的,例如订货系统,真正的用户是客户的客户,甚至是客户的客户的用户。”

3、客户要求极高,容错度极低

相比2C用户,2B客户那要求可是相当高。每一个细节都会反复确认。更重要的是不!能!出!错!谁都担不起这个风险。很多时候我们要花费了80%的时间在20%的细节上反复调试修改。

难怪无数2B产品经理会去羡慕2C产品经理作上帝的感觉……

艾老思后援团里的岳三峰老师对二者的总结非常精彩:

“2C的是用户,和2B的是客户,区别还是非常大的。一个是要让用户爽,一个是要让客户赢;一个是瞬间体验决策,一个是集体决策;引发内部的组织方式也不同,一个是小团队独立作战就可以搞的定,一个是必须多团队协同。”

难以洞察的用户需求

很多年前,我被关在江苏泰州的一个小黑屋里,和3个同学在老师的带领下,一起开发一款伟大的产品——某药厂ERP系统!

相比最牛叉的ERP——SAP,我们的竞争优势是“定制化”。上线前我们完全根据客户的业务特征进行定制,每一个字段都可以定制。上线后客户说要什么报表,我们就能迅速开发一个。在这个过程中,我们既是码农,又是产品经理,我们需要不断的收集需求、沟通需求、设计产品、培训使用……

绝对的以客户为中心。但是以客户为中心,并不代表客户满意。我们遇到过至少以下N种情况:

  • 接口人A告诉你,他可以全权代理所有内部需求,不必去和部门沟通。

  • 业务部门员工B告诉你,他非常忙,没时间跟你沟通需求。

  • 员工C告诉你,我需要请示我们领导,时间过了一周。

  • 员工D热情的告诉你他的需求,但是他的需求只是“他的需求”

  • 员工E坚定的告诉你,我们要的就是这个,但是做出来说不对

  • 你问员工F需要什么,他告诉你,一切都挺好啊

  • 你问员工G我们可以帮你简化现在工作,他告诉你,省省吧,别来折腾我们了

  • ……

难吧?这些难题逼退了很多人对真相的追求。传统的需求调研、需求分析,重点都放在客户代表身上,间接获取用户。真正面对用户的时候一般是比较粗略的。一个重要的原因是验收项目的是客户代表。但每天要用一百遍的是内部用户,他们才决定了我们的产品是否能够用好,带来好口碑。但他们的需求如上所述,实在难以洞察。

十步洞察2B产品用户需求

第一步:要搞清楚的是用户有哪些?

财务软件的用户可不只是财务人员,至少还会涉及领导查看报表、业务部门提交单据、IT部门负责数据安全和权限。

一定要搞清楚除了核心角色以外所有关联角色,哪怕是不使用产品的人,如果与该核心角色有利益关系,那么他们也是我们的间接用户。因为他们的需求很可能会左右核心角色工作业绩。

第二步:他们的满意度来源是什么?

识别出所有不同类型用户的满意度来源,例如他们的KPI、经济收益、工作负荷等。如果不是显性的满意因素,那么就需要通过分析他们的核心工作场景来获得他们工作中的痛点,解决他们的痛点将会获得他们的满意。

第三步:用户类别优先级是什么?

如果你识别出的用户少于3类,那么你应该还没识别全,通常我们能够识别出超过8类以上的用户类别。我们全面识别是为了找到最重要的用户。所以我们要对用户类别进行强制排序,然后选出最重要的1~3类用户,作为我们的核心用户。

第四步:找到他们的利益共同点

找到3类核心用户的利益共同点,作为他们之间的连通纽带,这个将是我们的工作核心,一旦满足,我们将同时收获三类用户的满意度。

第五步:识别关键产品特性

需求与特性区别是,需求是原本的诉求,而特性是满足需求的实现方式或者解决方案,所以当我们识别出核心用户的需求之后,就需要想办法解决他们的需求,制定出关键的产品特性。

第六步:绘制特性地图

对特性进行优先级排序是比较常规的做法,但是特性之间是有依赖关系的,我们需要结合这两个参数,绘制出特性地图。

第七步:强制拆分成三期规划

对特性地图中的几十个特性,进行强制分期,找到逻辑间隙,划分开来,然后把焦点放在第一期上。

第八步:第一期强制拆分周粒度版本

再对第一期的特性进行细化和再拆分——特性裂解。把粒度降到最低可验证规模。

然后以周为单位进行开发。

第九步:与核心用户每周验证中间成果

周迭代的核心目的是要求强制加速反馈验证的速度,保证至少每周一次对结果的验证,加速我们用户体验产品的速度。

第十步:迅速调整后续特性与规划

基于用户的反馈,对好的特性保留,错的特性删除,差的特性改进,用最快速度进行调整,并体现在下一周的迭代里。对于重大调整还需要调整产品整体规划。

为什么做不到?

以上方法也许你知道,或者自己也能想到,但是为什么做不到呢?

这一部分才是重点。

大多数企业的产品经理是将前四步合并为“需求分析”一步,而且由大量主观、片面、离散信息组成,更未经过严谨论证,仅仅是通过简单的群体决策或上级决策,得出结论。

第五步则由“撰写产品规格说明书”代替,这可能是花费时间最多,评审次数最多的步骤,但实际并没有什么价值,因为文档中通常存在大量bug,甚至是逻辑缺陷。更悲催的是在后续开发过程中,没有几个人领会说明书的每个设计初衷。

后五步,则通常省略,直接用几个月甚至一两年时间一次性做完,推给市场,用市场检验,用数据说话。然而检验的结果通常是打脸。返工、调整、撕逼、扯皮……噩梦开始。

没有什么可以化身用户的办法,你就是你,是颜色不一样的烟火。承认自己是常人,就按常人的办法——科学理性的方法一步一步老老实实的做,一定能成,这个事并没那么难。

长按二维码关注我们