初级产品经理养成记

　　新年快乐！笔者将通过本文复盘一下从事半年SaaS产品经理（招聘方向）的心得和感受。
　　SaaS是一种软件交付模式，简单理解，比如宿舍集体供暖，住户有需要就按月/季缴费取暖，不用操心暖气片升级、烧暖气等问题，则暖气就是SaaS产品。这里面又分to C（给普通消费者，如百度网盘、石墨等），to B（给企业，如财务系统、招聘系统等），笔者从事的方向便是后者。
　　所以以下的分析仅定位于SaaS 初级pm。笔者将从＂我理解的产品经理＂、＂产品经理能力＂、＂产品工作中的原则事项＂展开分享。
　　一、产品经理是一帮什么人？
　　发现问题、定义问题、分析问题、解决问题、验证问题。这几乎构成了世间所有逻辑和道理。回归职场，其实很多职位都很注重这样的思维方式，比如律师、咨询顾问……而产品经理，就是其中的一种。
　　在我看来，产品经理的日常工作就是重复这样的循环。落实到具体工作，产品经理需要获悉用户的需求，做好需求的分析管理，通过设计产品功能解决用户的需求，并且跟进反馈。
　　一句话来概括：产品经理就是采取最合理的解决方案并推动团队将其落实为具体功能或产品来满足用户需求的人。
　　二、产品经理的能力
　　产品经理需要的能力有很多，梳理如下：
　　其中个人觉得最重要的三个能力为：
　　1. 深入思考，把事情想得清楚
　　这个能力最重要，也最基本。能把一个事情想清楚，分析到问题的根本原因，这对之后的设计、推进起到至关重要的作用。如果对于需求或逻辑、问题一知半解，往往会在各种评审会被diss得体无完肤，并且做出的产品往往不能解决真实问题。把问题想清楚并不容易，我认为需要至少做好以下三件事：
　　（1）结构化思考问题
　　《金字塔原理》告诉我们要自下而上思考、自上而下表达，思考问题要MECE（完全独立、相互穷尽）。＂用户体验五要素＂告诉我们产品是从微观到宏观再到微观、从抽象到具象、从战略到表现的过程。
　　产品工作中亦是如此，宏观到产品战略、产品价值观，微观到字段设计、交互控件选择和定义，过程中需要结构化梳理需求、功能脉络。就像我们画画一定要先画轮廓，再画眉毛等细节。
　　（2）多问为什么，厘清用户、场景、需求
　　针对一个问题多追问用户或CSM，才能不停留于问题表面，避免根据表面需求进行产品设计而没能解决真实业务问题。
　　比如，用户说要一个打孔机，这其实是表面需求，追问下去发现用户真实需求是想在墙上打一个洞，这时候产品解决方案就不是制造一个打孔机，而是解决在墙上打一个洞这个问题。
　　（3）全局性思维
　　遇到问题，在定义和分析问题的时候，要基于业务进行全局性思考，不能停留于片面。
　　比如，某客户的A功能有问题了，这时候并不是找测试、开发求助的时候。＂该客户其他同事的A功能有问题吗？＂、＂是全部客户的A功能都有问题了？＂、＂A功能出现此问题多久了？＂、＂A、B功能相似，这个问题 B功能出现了吗？＂……
　　这些问题思考清楚，定位到是代码问题、业务问题、还是权限问题……再去找开发测试寻求帮助。否则直接去找开发提需求，一问三不知，会被打死。
　　2. 项目管理，推动项目落地
　　产品经理负责整个产品的生命周期，产品经理需要推动团队来将自己的解决方案落地，所以这需要产品经理有强烈的主人翁精神，不断push项目的进行。
　　在了解需求、用户的时候需要主动调研和分析用户需求及客户业务；在交付的时候需要不断跟进问题解决问题，并且组织各种评审和宣讲、反讲；项目后期追踪进度，把控风险点，并且做出各种决策……
　　此外，产品经理还需要跨部门协调资源，在和其他团队有合作的过程中要兼顾双方的进度和排期，权衡好方案。
　　3. 对新事物敏感，快速理解并整合
　　产品经理经常接收需求，由于是SaaS业务，所以很多需求是客户个性化的，并且有很强的业务背景，这就需要产品经理能够快速了解该客户或行业的业务，厘清并还原场景，从而做出决策。
　　SaaS厂商提供的解决方案依赖于对行业、业务的深入理解。互联网行业千变万化，随时保持对行业、市场和业务等的敏感度，才不会被对手击垮。
　　三、产品工作流中的原则事项
　　将之前的产品工作流抽象一层，可以得到如下四个步骤：
　　接下来，笔者将分别总结各步骤的产品原则和注意事项。
　　1. 产品定义
　　（1）回归场景，挖掘真实需求
　　回归场景，不能YY场景，这是产品工作的地基，不然设计出的功能或产品不能解决用户实际需求。大到模块设计，小到字段和控件选择，都要有场景承接。
　　除了之前聊到的多问＂为什么＂，最近受益于有赞pm分享的场景七要素：用户、环境、时机、目标、动作、介质、任务。比如＂拥挤的大堂中，参会者为了进场，找到签到二维码，掏出手机打开微信扫描二维码并填写报名信息后进场＂，场景描述完听众产生＂画面感＂，这样不仅方便听众理解，也能还原真实场景。
　　（2）分清楚边界范围，切勿杂糅场景
　　遇到类似的事物或问题人们很善于分类或合并，这本没错，但是需要注意边界，比如＂取消任务＂和＂终止任务＂其实是两件事，别揉在一起考虑。
　　（3）多维度管理和分析需求
　　需求管理要考虑需求做不做、优先级怎么样。通用方法比如紧急-重要二维坐标、kano模型等。此外还需考虑需求与本次迭代目标（比如产品价值观、迭代预期是mvp还是1-n、着重提升用户体验等）的关系。另外还要权衡好用户价值和商业价值。
　　个性化需求需要看需求大小、复杂程度，商业利益等来决定业务战略处理方式，以此决定是做成配置项解决还是单独付费开发等。
　　2. 产品设计
　　（1）不为歪曲需求设计功能
　　经常会遇到用户用A功能做B操作，并提出B操作的需求，这时即使需求合理也不应（在A功能）满足，而应该引导用户用B功能解决此需求。
　　之前搬家，货拉拉司机和我说很多乘客因为货拉拉运费便宜，所以将货拉拉当作出租车用（不拉货，只拉人），用户如果提出的需求不是拉货而是乘坐需求，这些需求则不应该在货拉拉满足，而应该引导乘客去坐出租车。
　　（2）全业务链路思考问题
　　B端和C端产品有一个很大不同点，B端产品往往涉及到多个角色，业务流程需要多个角色协作才能闭环，比如筛选简历、审批职位等。所以在考虑需求、分析问题的时候要全链路思考影响点、需求是否冲突等问题，避免遗漏场景。
　　（3）从场景出发设计，而不是由设计反推场景
　　拿筛选简历（HR给筛选人发送简历，筛选人给结果）来说，正确的思考逻辑是HR发送完简历后其需求是什么？得到结论是要追踪和管理任务，这时才去设计任务模块。而不是因为以前有或者产品一般做法都有任务模块就去做，然后反推HR对于任务管理和追踪的需求。
　　（4）以用户需求为核心，不要受限于现有框架
　　在设计功能时，一个功能的有无、流程的流转等考虑，取决于用户的需求有无和体现，而不应受限于系统有何限制、成本如何、借助现有能力能否无code实现…后者不是做决策的根本原因。
　　（5）要学会做减法
　　对场景和需求理解不够透彻清楚，很容易做加法。随意加功能会给用户带来打扰，开发成本也变高，所以要想清楚场景需求，然后设计功能，而不是觉得这个功能用户会喜欢就加上，然后反推出一个不清晰的场景。
　　还有个维度是需求合理但是优先级不高。比如不属于闭环需求，这时候在做MVP时就先减去这个需求。
　　3. 推动交付
　　（1）结构化展示、清晰表达
　　自上而下、结构化输出，并且清晰表达，既能想得明白也能说得明白，这是产品经理必备的技能，也是多加练习便可掌握的。听众和读者也是产品经理的用户。
　　（2）非暴力沟通，理性交流
　　产品经理经常与多团队对接，并且随时会遭到需求或设计等的质疑和提问，产生分歧，这很正常。这时要理性并用同理心进行沟通（一起寻找最佳方案），不能抬杠（专找对方不正确的地方）。
　　《非暴力沟通》告诉我们，评判、比较、强加于人等都会产生暴力情绪，这时候我们要避开这些，表达自己的观察（事实）、感受、需求和请求，用逻辑和理性解决问题。
　　（3）关注进度，积极推动项目
　　以主人翁心态推进项目，团队是合作，不存在不好意思。同时也需要针对随时出现的问题，多方面权衡评估给到结论和决策。项目推进过程中要发现潜在风险，做好排期和buffer。
　　4. 跟进反馈
　　（1）保持强数据意识
　　产品研发过程做好埋点和log，方便后续分析数据，来验证用户问题是否解决，比如页面跳出率是否下降了，成功发起任务占比是否提高了，来指导后续工作，复盘之前设计。
　　（2）主动了解用户反馈
　　产品或功能上线了，要关注产品运营效果。分客户、分角色了解反馈，做到心里有底和工作流闭环。