转岗B端商业风控产品经理2个月，很荣幸一上手就接到一个0-1的项目。整个过程中，我的leader在指导我的同时，给了我足够自我发挥和思考的空间。今天，项目终于有了里程碑的进展，在这里分享我的成长和学习所得。
项目背景：
风险露出badcase频发，排查原因非常困难，要么排查不到，要么耗费几周时间才得到结果，几乎成了中心里各部门的痛点。为什么这么难？我总结原因如下：
1、常规的风险管控涉及多个环节，排查一个问题等于把所有相关部门的对应业务都调查一遍，对于负责单一业务的人员能力要求过高；
2、我所在的业务已经有一段历史积累，在漫长的发展过程中，很难一开始就建立完善的运转机制，各环节都能保持着和其他环节的良好衔接。历史业务的不规范化进一步加大了排查badcase的困难程度；
3、常规的风险管控外，存在很多复杂的特殊情况。比如为优质客户提供特殊权益，对劣质客户进行专项打击。各业务部门建立的非常规措施，未形成统一的管理模式。一旦出现问题，人工排查的效率非常低下。
说到这，大家也听明白了，这个事情痛吗？非常痛，但很明显，没有明确稳固的业务方支持。
当接到老板的指示，要做个能够解决badcase排查问题的产品，我们第一步应该怎么做？
1、摸清基本盘——以了解为主
（1）了解业务现状
了解业务人员现有的业务场景和操作流程、方法，包括业务场景涉及哪些角色、各角色如何配合流转、借助什么方法或系统、发生了什么操作或行为，并根据自己的理解梳理呈现一个明确的可视化业务流程。这里常使用的如基本流程图和跨职能流程图（泳道图），可以更好地呈现并帮助他人理解。
（2）聆听业务需求
聆听业务人员的诉求和痛点，通常需要调研多个业务部门，分别聆听各部门的业务诉求。这里需要提醒产品新人，在调研需求的时候，很可能在没想清楚的时候被业务人员带跑，甚至在调研阶段就对业务人员的痛点感叹身受。
注意：这里仅仅是聆听，先把大家的需求听完并记录好，切忌快速下判断
（3）摸清相关方合作意愿
这是非常容易被忽略的一点。对于一个项目，多个业务部门的角色差异非常大，有期待合作共赢的部门A，有担心影响其业务而采取消极态度的部门B，有只想看到成果而不想为共同目标付出的部门C等等。
前期摸清相关方的态度和做事风格，对于后续推进项目，选择合作方都会带来意想不到的帮助。
2、明确项目目标及成员——启动项目
（1）论证项目价值
为什么上级指定的任务仍然需要重新论证价值？上级指定某一任务的时候，不会具体到调研业务，通常只是某一方向。真正调研过业务，作为项目owner的是我们自己。所以我们一定要在项目开始前，自己把项目价值论证清楚。这样在项目过程中，无论是排优先级或是有人质疑项目价值的时候，都能够“牢守阵地”
（2）明确合作方
对于组织架构明确且稳固的业务，合作方很容易明确；
对于还不明确的新兴业务，我们要选择合作态度更积极，目标更一致的团队合作，同时也尽可能协助希望合作的部门得到相关部门及高层的认可，明确业务边界。
（3）对齐项目目标，求同存异
对于同一个业务问题，各部门基于自己的部门定位，都有不同的目标和利益诉求。
举个例子：对于basecase排查的问题，各部门的目标都是快速解决，但又不完全一样。业务团队只在乎需求能被解决，无论是有产品辅助或有研发人员协助排查都能满足需求，业务人员不一定愿意耗费时间协助产品梳理方案；
产品团队关心如何能通过工具产品帮助业务解决问题，提高人效，而不是协调开发人员人工排查，做一个传话筒；
开发团队关心的是不要总来麻烦我们的人帮忙排查代码，如果做产品，希望能够体现一定的技术难度和价值。
如何对齐各团队的目标，并让大家一起按照PM的节奏开展工作，需要从项目开始和整个过场中，不断对齐项目成员的目标，拉齐认知，减少gap。当然，PM在产品设计过程中，也要充分考虑业务和研发团队的诉求。
3、确立产品解决思路
（1）明确产品的边界
在开始项目前，一定要明确本项目面向的对象，解决的问题是什么，给出产品的定义，否则后期很容易出现纠纷。
以badcase排查项目为例，首先需要圈定我们要解决的范围。各个业务系统问题属于badcase吗，属于，但不是我们要解决的内容。我们面向的仅仅是风险露出，线上展现广告的风险露出问题
（2）确定产品解决方向
解决方向一定是做有形产品吗？对于业务问题的解决，可以是一个产品功能，也可以是一套解决问题的方案、流程机制。针对不同的问题“对症下药”
确定产品解决方向的过程中，需要对业务细节持续调研和系统梳理，挖掘真实需求和痛点。
4、设计产品
这里结合用户体验五要素的内容，按照产品设计的逻辑拆解。
（1）战略层：
确立产品的战略定位，主要指确定产品面向的用户和产品目标。
举个例子：
从用户角度，提供给非专业人员的通用型工具产品和提供给深耕某一业务的业务团队的工具产品，其产品设计是完全不同的；
从产品目标，对于badcase排查，产品的目标是提供case记录管理平台，或是提供系统工具，系统自动排查问题，也是完全不同的产品设计思路
（2）范围层
需求不能无限延伸，需要明确版本迭代的节奏，以及每一版本的目标，包含的内容和功能。
在badcase项目中，第一版本我们选择上极简版，以提供case排查工具的地址集合为主，支持排查结论的记录，通过第一版本线上平台的使用进一步收集需求；
在第二版本中，以系统自动定位问题为主，工具查询服务为辅，badcase排查的半自动化。再细节一点便是我们提供的工具都是什么，有什么功能，能满足什么样的查询需求
（3）结构层
结构层包括信息架构和交互设计。交互设计和信息架构都强调一个重点：确定各个将要呈现给用户的元素的“模式”和“顺序”。交互设计关注将影响用户执行和完成任务的元素。信息架构则关注如何将信息表达给用户的元素。——引用自用户体验要素
也就是说，结构层确定各个将要呈现给用户的选项的模式和顺序，设计用户如何到达某个页面。并且要考虑他们完成事情之后能够去哪里，引导用户按照一定的方法和流程使用产品。
比如在任务型业务中，设计任务列表可以通过状态来区分，如“处理中”、“处理完成“，强体现任务消除的业务感
（4）框架层
产品的按钮、控件、文本区域的位置和顺序如何摆放，能安排用户便捷地在界面上产生交互。
如果说结构层是产品的架构，表达各个页面间的连接，那框架层便是单页面的交互，比如将重要信息放在最佳视域，或进行高亮。
（5）表现层
视觉体验，包括文字、图片的样式、颜色等。对于部分B端产品部门，不具备交互设计师，因此在产品设计上，一定要最大化地呈现自己希望的产品样式，切忌全凭FE发挥，很可能和PM心中预想的视觉效果存在很大差异。
在设计产品的时候，我有个很大的疑惑是，选用什么方式来呈现我的设计思路，能更快更好地与项目成员达成一致？
如果一上来就把原型中所有的页面结构都画完全，往往是比较低效的方法。在这里我们强调的是快速迭代，也就是选用最能表达产品设计思路且成本较低的方法来辅助说明产品设计想法。
我通常选用原型图的主页面+结构图/流程图，如果需要可以增加一页PPT辅助说明。这样在团队讨论的过程中，如果产品主设计思路ok，继续细化原型；如果主设计思路不ok，快速更换设计思路，也不耗费更多时间。
5、MRD撰写与评审
（1）项目背景、目标、价值
项目目标和价值是需要量化在MRD最前方，明确地让项目成员认可的内容。
（2）业务模块、流程、逻辑
描述业务上有哪些角色、如何操作及运转，通常会结合业务流程图进行描述。
（3）产品需求框架、列表、优先级
可以按端、按功能模块、按业务流程拆分需求，甚至考虑研发对象，不同的产品形态采取合适的方法即可。
举个例子，前端页面和页面上的功能逻辑可以拆分为两个需求模块撰写，这样FE可以单独开发页面，后端同学负责功能逻辑的研发。
（4）具体功能的需求描述
这里除了阐述需求描述外，强烈建议增加简单的功能说明，描述功能的具体作用。在后期翻阅回忆时，有非常强的参考价值。
（5）MRD评审技巧
MRD评审前，一定要详细介绍项目的背景和目标，达成一致后再进入需求评审；
评审需求时，首先要介绍需求框架，再进入细节。这一点同样适用于MRD的撰写。
由于目前项目推进阶段只到这里，复盘后总结了一些关于产品经理的一些思维方式
时间分配，抓大放小
产品经理面临来自各方的压力，时间进度抓的会很紧。我甚至花了一天的时间完成了60页的MRD文档，作为新人压力真的非常大。在这个时候，要明白各方关注的重点是什么，抓大放小，适当妥协。不要完美主义作祟，最后什么都做不好
主人翁意识
当PM被要求介入一个项目时，无论这个项目之前是否有owner，PM一定是要作为这个项目的owner 角色来思考和推进。
项目方案的逻辑，包括业务流程优化、产品解决思路都需要PM自己完成推演论证，不能人云亦云。
管理项目的进度，不断强调共同的目标，拉齐项目人员的认知，都是PM范畴的事情。
求同存异，合作共赢
由于各部门立脚点，合作中的矛盾和分歧是不可避免的。PM需要明确各相关方关注的重点，找到共同的利益点，说服、引领各部门人员朝着共同的目标努力。