中台产品经理需要掌握的“广义用户思维”

狭义的用户思维只聚焦在产品使用者这一个用户视角,而PM应该拥有广义的用户思维,善于发现隐zàng的所有用户。本文从决策分析、需qiú分析、产品方案、产品开发、交付使用5个方面讲述产品经理的“广义用户思维”。

用户思维的概念,其实就是从用户出发,关心用户要什么;然后企业/个人X对应产品满足用户需qiú。

之所以倡导用户思维,目的就是让产品开发人员换位思考;用同理心感受用户场景,最终能让产品/X更加贴近需qiú本质。

但是一个产品的面世过程,会有多人协作,且经历非常多的环节才能完成,而每次沟通都有不同程度的信息衰减。

一些人理解的用户思维,更多是狭义的,只聚焦在产品使用者这一个用户视角。而我却认为PM更应该拥有广义的用户思维,善于发现隐zàng的所有用户。

开始正文之前,我先定义2个概念:

  1. 用户:产品经理沟通/反馈/交付的对象;
  2. 用户问题:用户的原始需qiú/利益诉qiú/关注点。

接下来,我会以X中台产品经理的视角,聊聊我所认为的“广义用户思维”。

为了便于大家理解,我们搭个框架,一次按照产品设计的关键环节逐一切入来看。

不同场景中,我会不断代入以上2个概念,去问用户是谁?用户遇到的问题是什么?

一、决策分析(判断信息)

首先,第一环节是决策分析,也是最重要的一个环节。

对一些纯用户产品或B端商业化产品,市场/商业分析就属于这个范畴。宏观上会根据市场、X战略、资源、竞争等综合信息来判断一个产品是否要做,如要做还要明确大框架上的一些体量、收益、资源投入等关键指标。

而对X中台(支撑类)产品经理,这个环节更多决策是某个X需qiú要不要做,什么时候做,投入资源如何。

这里我们虚构一个案例,便于下文讲解:

案例:XA、XB分别给我(X中台产品经理)提了【积分】功能和【优惠券】功能。

我接收到这个需qiú,第一步应该怎么做,是直接跟他聊我们已经有这个功能?聊怎么实现成本最小?聊我们资源排不上?

X:都不是。

在这里,我们首先明确下这个场景下的用户和用户遇到的问题:

看到以上表格,大家就发现了,其实我们面对的不仅仅是XA和XB这两个用户,其实还有X和中台部门这2个用户,并且不同用户之间是有优先级的。

所以,最终我们想要很好解决掉这4个用户的问题,必须先从整体上进行决策分析,而非直接去聊【积分】【优惠券】功能。

经过综合分析,作为中台产品经理,你应该首先依次确定以下问题:

  • X战略层面,XA和XB本身处于何种位置?
  • XA想要的【积分】功能,背后要解决的X问题究竟是什么?这个功能对X本身助力如何?功能如果不能实现是否有其他替代方案?这个需qiú在X层面的时间预期是?
  • XB想要的【优惠券】功能,背后要解决的X问题究竟是什么?这个功能对X本身助力如何?功能如果不能实现是否有其他替代方案?这个需qiú在X层面的时间预期是?
  • 假如最终确定想要解决XA、B的问题,需要支持,那么【积分】【优惠券】功能在中台大概开发周期如何?在现有项目安排基础上,如果排上,预计是什么节点开始和结束?功能是否必须中台开发,X是否可有自主开发的可能性?功能在中台角度,预判后续会有其他更多X会用到吗?

zhēn对以上问题的发问,我们稍微加工,可以得到以下信息:

  • X层面:中台需要优先保证XA的需qiú实现;
  • X层面:XA的【积分】功能,根本需qiú是需要一种抓手,将一定的预算,转化为可以提升用户的平台粘性(登陆、浏览、关注店铺等);XB的【优惠券】功能,根本需qiú是想要一种抓手,将一定的预算,转化为可提升平台用户的转化率(下单支付);XA和XB对功能的实现预期都是在未来一个月内,时间上存在X;
  • 中台资源:在未来的一个月内,资源有限,只能支持一个项目;
  • 中台对需qiú实现的分析:【积分】功能和【优惠券】功能都具备最重要的共同特征:私有化凭据和liú通闭环;而最大的差异性是:积分类型不能zhēn对X对象进行使用X但可零散化核销(例如一次消耗5个积分或100个积分),而优惠券类型可以zhēn对X对象进行使用X但必须整券核销(一张要么核销要么不核销,不存在半张券核销);
  • 中台已有功能:具备【秒shā促销】功能,已实现促销资金预算化、订单特定减额的逻辑功能,整体实现【积分】【优惠券】等减额类运算有一定的框架基础。

接下来,根据和X的沟通协调,得到以下决策信息:

  • 中台未来一个月内开发交付【积分】功能,且会按saas化搭建框架(不同X可以配置平行多套积分X,互不干预);——后续可扩展,中台既支持了需qiú,也沉淀了中台能力,可以被后续类似X场景拓展使用;
  • XA直接使用中台【积分】功能,无需多余开发;——需qiú解决了;
  • XB自己在应用层做【优惠券】化包装,但底层复用中台【积分】功能;——X只需要少量开发,80%可以复用积分功能,需qiú也一定程度被解决了。

提醒:资源有限和XB优先级低于A,这些客观因素都可以让中台拒掉XB的需qiú,但这只是60分的做fǎ。而中台去帮XB想变通方案尽量满足X需qiú才是更高级的做fǎ。

大家发现了么?

中台在这个角度,所做的事情就是收集全“用户”问题并尽最大程度都解决掉,而决策分析其实就是获取更多信息得到最优解的过程。

二、需qiú分析(收集&分析信息)

以上决策分析环节,更多是从宏观层面判断一个需qiú做不做。在这个环节虽然也会有部分需qiú的沟通,但是颗粒度会cū很多。

而当决策一个需qiú确定要做之后,就会转到需qiú分析环节,而这个环节就会深入去聊许多需qiú细节。

接下来,我们就继续沿着上述案例往下chāi解。

看看我们需qiú分析的对象是什么?仅仅是【积分】的功能逻辑开发么?

X:不是的。

我们来看看此刻我们的用户和用户问题:

对于需qiú分析,一定不是直接切入到【积分】功能层面的沟通和设计,更多应该是找到所有相关的用户,以及定位各个用户的用户问题。

在这个环节,不仅要跟直接X去聊,同时还要去跟积分功能实现的所有上下游部门去沟通,聊资源、聊实现、聊协作。

总之,需qiú分析是产品主导深挖X背后真正需qiú;进而确定各部分需qiú范围、优先级、需qiú时间节点等信息的过程。

在这个过程中,有2个点儿需要特别说明下:

1) 优惠券功能属于上游X自助开发部分,中台需要关心么?

当然需要关心,你需要关心他们怎么实现。怎么去底层积分系统进行联动,因为目标只有一个——就是让XB实现这个需qiú,进而实现X目标;

2)风控、客服、数据跟中台部门属于平级关系,中台需要关心么?

当然也需要关心。因为某一块的进度或者实现,都是影响X需qiú最终可以被解决的变量,中台有动力需要去推动这类问题的解决。

这里擦一句,在我自己现实的工作中,我也在尝试推动《中台间虚拟X》的建立,力争共同为XX【一揽子解决方案】,后续有实践成果再跟大家分享。

三、产品方案(信息加工)

在需qiú分析环节完毕之后,产品经理就会获取到全量的X层信息并转化为了需qiúlist,接下来就会进入到比较详细的产品方案阶段。

在这个环节,产品经理的注意力会更多放在产品逻辑和页面设计上,也就是一般产品经理“最擅长”的工作上。

在这里,我不会阐述这个需qiú的产品方案细节该怎么去写,更多还是聚焦分析用户和用户问题:

在这个环节中,普通产品经理基本都能够做到功能设计的完整度。而高水平的产品经理,应该要意识到,“产品方案”环节不仅是方案本身,更是连接上游X需qiú和下游研发实现的核心中枢,就像一个漏斗一样;这一层有衰减,就会使得最终的结果大打折扣。

所以产品经理在这个环节,表面是在画交互和写PRD,但是动鼠标和键盘的每一刻,内心都要考虑以下问题:

  • 这个功能,X预期中的用户使用是否ok?
  • 这个功能,最终的用户使用是否ok?
  • 这个功能,产品本身逻辑是否ok?
  • 这个功能,技术实现大概逻辑和可行性是否ok?
  • 这个功能的文档或交互描述,能否更容易让技术同学理解?

可能有人会疑惑,难道画每一个按钮就需要考虑这么多?

是的,产品的每一个交互和每一句文档描述,上边罗列的各种用户都是其受众;他们的视角会care各自关心的内容,所以就需要产品经理具备这样的方案能力。

同时满足多个用户的需qiú是产品经理需要X的能力。从小需qiú做起,保持同理心,曰积月累,“用户思维”就会变为自己的xí惯。

四、产品开发

产品方案需qiú评审之后,就会进入产品开发阶段,在这个环节产品的“主导泉”就会转由技术GG们接手。

那么在这个环节内,PM同学就可以撒手不管了么?

X:不是的。

虽然coding咱不会,但是咱要做的事情还是不少的,来看看这个环节的用户和用户问题:

中台产品经理跟X保持实时双向沟通。对X既要保持项目进度的实时反馈,管理好X预期,哪怕遇到项目风险,及时的反馈沟通也能给予X不太差的感受;另外还要保持对X动态的了解,尽量降低需qiú变更的风险。

产品经理对研发团队要做好答疑支持,不要需qiú一提交不管不问了,每一个“疑问”的忽视都会影响产品最终的质量。另外,产品经理要隔离掉上游X其他人员对研发GG的“sāo扰”,为其X一个良好的coding环境。

还有,再说点老生常谈的。项目过程中,要让研发GG工作有干劲,加班不抱怨,产品经理一定要发挥程序员鼓励师的作用。嘘寒问暖不能少,破费mǎi吃的喝的“孝敬”一下效果更jiā哟,哈哈!

五、交付使用

产品开发环节完成之后,就到交付使用了。

同样,我们看下这个节点我们需要关注哪些用户和哪些用户问题:

写cāo作说明和产品培训属于常规cāo作了,不再赘述。

这里面着重聊一个容易被产品经理忽视的或者做的不太够的点——发上线邮件。

在这里,我们也用下用户思维,看看上线邮件应该怎么写:

项目上线是项目的重要里程碑,发上线邮件是仪式感的体现,所有的人都希望自己的付出被认可、被赞美。

对于比较大型项目,团队比较辛苦,产品经理X个饭jú犒劳下技术GG们是非常有必要的。哈哈!

另外,上线一段时间后,例如2周。产品经理一定要及时找X童鞋要对应的产品效果反馈,进而对项目组成员进行同步。如果X同学能有阶段化运营成果汇报,让项目成员参与也会起到很好的效果。

总之,任何的付出都希望有回音,哪怕是项目上线效果不好,至少也是一种反馈。

六、总结

以上分析,我们是代入进了一个具体的项目,其实回归到每个人的岗位工作,也同样适用用户思维。

白话来说,就是在这个协作合作的过程中,每个用户各自的核心诉qiú是什么:

产品经理作为X和研发资源的转化纽带,本身的水准直接决定了资源变为X助力的转化率。

一个好的产品经理,给人的直观感受就是能解决“各类用户”的“各类问题”,不仅仅是项目本身。

我一直信奉一句话:最高级的利己是利他。

“用户思维”其实没那么难,无非就是多为他人真诚地着想。

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 中台产品经理需要掌握的“广义用户思维” https://www.xiongfawang.com/2379.html

常见问题

相关文章

中台产品经理需要掌握的“广义用户思维”-海报

分享本文封面