时间: 2021-07-30 11:24:25 人气: 7 评论: 0
狭义的用户思维只聚焦在产品使用者这一个用户视角，而PM应该拥有广义的用户思维，善于发现隐藏的所有用户。本文从决策分析、需求分析、产品方案、产品开发、交付使用5个方面讲述产品经理的“广义用户思维”。
用户思维的概念，其实就是从用户出发，关心用户要什么；然后企业/个人提供对应产品满足用户需求。
之所以倡导用户思维，目的就是让产品开发人员换位思考；用同理心感受用户场景，最终能让产品/服务更加贴近需求本质。
但是一个产品的面世过程，**有多人协作，且经历非常多的环节才能完成，而每次沟通都有不同程度的信息衰减。
一些人理解的用户思维，更多是狭义的，只聚焦在产品使用者这一个用户视角。而我却认为PM更应该拥有广义的用户思维，善于发现隐藏的所有用户。
开始正文之前，我先定义2个概念：
接下来，我**以业务中台产品经理的视角，聊聊我所认为的“广义用户思维”。
为了便于大家理解，我们搭个框架，一次按照产品设计的关键环节逐一切入来看。
不同场景中，我**不断代入以上2个概念，去问用户是谁？用户遇到的问题是什么？
首先，第一环节是决策分析，也是最重要的一个环节。
对一些纯用户产品或B端商业化产品，市场/商业分析就属于这个范畴。宏观上**根据市场、公司战略、资源、竞争等综合信息来判断一个产品是否要做，如要做还要明确大框架上的一些体量、收益、资源投入等关键指标。
而对业务中台（支撑类）产品经理，这个环节更多决策是某个业务需求要不要做，什么时候做，投入资源如何。
这里我们虚构一个案例，便于下文讲解：
案例：业务A、业务B分别给我（业务中台产品经理）提了【积分】功能和【优惠**】功能。
我接收到这个需求，第一步应该怎么做，是直接跟他聊我们已经有这个功能？聊怎么实现成本最小？聊我们资源排不上？
答案：都不是。
在这里，我们首先明确下这个场景下的用户和用户遇到的问题：
看到以上表格，大家就发现了，其实我们面对的不仅仅是业务A和业务B这两个用户，其实还有公司和中台部门这2个用户，并且不同用户之间是有优先级的。
所以，最终我们想要很好解决掉这4个用户的问题，必须先从整体上进行决策分析，而非直接去聊【积分】【优惠**】功能。
经过综合分析，作为中台产品经理，你应该首先依次确定以下问题：
针对以上问题的发问，我们稍微加工，可以得到以下信息：
接下来，根据和业务的沟通协调，得到以下决策信息：
提醒：资源有限和业务B优先级低于A，这些客观因素都可以让中台拒掉业务B的需求，但这只是60分的做法。而中台去帮业务B想变通方案尽量满足业务需求才是更高级的做法。
大家发现了么？
中台在这个角度，所做的事情就是收集全“用户”问题并尽最大程度都解决掉，而决策分析其实就是获取更多信息得到最优解的过程。
以上决策分析环节，更多是从宏观层面判断一个需求做不做。在这个环节虽然也**有部分需求的沟通，但是颗粒度**粗很多。
而当决策一个需求确定要做之后，就**转到需求分析环节，而这个环节就**深入去聊许多需求细节。
接下来，我们就继续沿着上述案例往下拆解。
看看我们需求分析的对象是什么？仅仅是【积分】的功能逻辑开发么？
答案：不是的。
我们来看看此刻我们的用户和用户问题：
对于需求分析，一定不是直接切入到【积分】功能层面的沟通和设计，更多应该是找到所有相关的用户，以及定位各个用户的用户问题。
在这个环节，不仅要跟直接业务去聊，同时还要去跟积分功能实现的所有上下游部门去沟通，聊资源、聊实现、聊协作。
总之，需求分析是产品主导深挖业务背后真正需求；进而确定各部分需求范围、优先级、需求时间节点等信息的过程。
在这个过程中，有2个点儿需要特别说明下：
1） 优惠**功能属于上游业务自助开发部分，中台需要关心么？
当然需要关心，你需要关心他们怎么实现。怎么去底层积分系统进行联动，因为目标只有一个——就是让业务B实现这个需求，进而实现业务目标；
2）风控、客服、数据跟中台部门属于平级关系，中台需要关心么？
当然也需要关心。因为某一块的进度或者实现，都是影响业务需求最终可以被解决的变量，中台有动力需要去推动这类问题的解决。
这里插一句，在我自己现实的工作中，我也在尝试推动《中台间虚拟组织》的建立，力争共同为业务提供【一揽子解决方案】，后续有实践成果再跟大家分享。
在需求分析环节完毕之后，产品经理就**获取到全量的业务层信息并转化为了需求list，接下来就**进入到比较详细的产品方案阶段。
在这个环节，产品经理的注意力**更多放在产品逻辑和页面设计上，也就是一般产品经理“最擅长”的工作上。
在这里，我不**阐述这个需求的产品方案细节该怎么去写，更多还是聚焦分析用户和用户问题：
在这个环节中，普通产品经理基本都能够做到功能设计的完整度。而高水平的产品经理，应该要意识到，“产品方案”环节不仅是方案本身，更是连接上游业务需求和下游研发实现的核心中枢，就像一个漏斗一样；这一层有衰减，就**使得最终的结果大打折扣。
所以产品经理在这个环节，表面是在画交互和写PRD，但是动鼠标和键**的每一刻，内心都要考虑以下问题：
可能有人**疑惑，难道画每一个按钮就需要考虑这么多？
是的，产品的每一个交互和每一句文档描述，上边罗列的各种用户都是其受众；他们的视角**care各自关心的内容，所以就需要产品经理具备这样的方案能力。
同时满足多个用户的需求是产品经理需要修炼的能力。从小需求做起，保持同理心，日积月累，“用户思维”就**变为自己的习惯。
产品方案需求评审之后，就**进入产品开发阶段，在这个环节产品的“主导权”就**转由技术GG们接手。
那么在这个环节内，PM同学就可以撒手不管了么？
答案：不是的。
虽然coding咱不**，但是咱要做的事情还是不少的，来看看这个环节的用户和用户问题：
中台产品经理跟业务保持实时双向沟通。对业务既要保持项目进度的实时反馈，管理好业务预期，哪怕遇到项目风险，及时的反馈沟通也能给予业务不太差的感受；另外还要保持对业务动态的了解，尽量降低需求变更的风险。
产品经理对研发团队要做好答疑支持，不要需求一提交不管不问了，每一个“疑问”的忽视都**影响产品最终的质量。另外，产品经理要隔离掉上游业务其他人员对研发GG的“骚扰”，为其提供一个良好的coding环境。
还有，再说点老生常谈的。项目过程中，要让研发GG工作有干劲，加班不抱怨，产品经理一定要发挥程序员鼓励师的作用。嘘寒问暖不能少，破费买吃的喝的“孝敬”一下效果更佳哟，哈哈！
产品开发环节完成之后，就到交付使用了。
同样，我们看下这个节点我们需要关注哪些用户和哪些用户问题：
写操作说明和产品培训属于常规操作了，不再赘述。
这里面着重聊一个容易被产品经理忽视的或者做的不太够的点——发上线邮件。
在这里，我们也用下用户思维，看看上线邮件应该怎么写：
项目上线是项目的重要里程碑，发上线邮件是仪式感的体现，所有的人都希望自己的付出被认可、被**美。
对于比较大型项目，团队比较辛苦，产品经理组织个饭局犒劳下技术GG们是非常有必要的。哈哈！
另外，上线一段时间后，例如2周。产品经理一定要及时找业务童鞋要对应的产品效果反馈，进而对项目组成员进行同步。如果业务同学能有阶段化运营成果汇报，让项目成员参与也**起到很好的效果。
总之，任何的付出都希望有回音，哪怕是项目上线效果不好，至少也是一种反馈。
以上分析，我们是代入进了一个具体的项目，其实回归到每个人的岗位工作，也同样适用用户思维。
白话来说，就是在这个协作合作的过程中，每个用户各自的核心诉求是什么：
产品经理作为业务和研发资源的转化纽带，本身的水准直接决定了资源变为业务助力的转化率。
一个好的产品经理，给人的直观感受就是能解决“各类用户”的“各类问题”，不仅仅是项目本身。
我一直信奉一句话：最高级的利己是利他。
“用户思维”其实没那么难，无非就是多为他人真诚地着想。
作者：减形简远，微信公众号：产品杂谈（life_pm）
本文由@减形简远 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
