产品经理岗位杂谈
零、序
受互联网寒潮影响，互联网公司的股价跌妈不认，为了规避政策打压导致年包打骨折的风险，新近入职了一家传统企业，面向市场上轰轰烈烈的传统企业信息化转型，我司也在自建业务系统，搭建技术团队。
某日我司有一位产品同学问了我个问题，如何成为一个专业的产品经理。
回想起之前的工作里，无论是初入职场的实习生，还是刚工作1-2年的新同学，或多或少的都会带着这样的一个问题工作。
而从我个人的经历来讲，刚毕业的时候从一个软件行业的UED设计师转行到互联网做产品经理。一味的认知产品经理要对用户体验负责，于是苦练原型图，用Axure画个原型还得带点击交互的，还得找地方发布。
兜兜转转6年过去了，我也逐渐的从工作中慢慢悟到了一些东西，也跟着高人学到了很多，但始终感觉我都懂，但我讲不出来，野蛮成长之后是缺乏成体系的沉淀，于是决定决定借着这个机会写一写自己的思考。
谨以此文，献给初入职场的产品小盆友们。
一、产品经理的历史
想要聊如何成为一个专业的产品经理，我觉得首先需要定义什么是一个产品经理，通常，互联网行业聊起产品经理时，总会提到几个前辈大神，乔布斯、张小龙、俞军、王兴、周鸿祎等等。
但关于产品经理这个岗位的定义，各个领域都有各个领域的解释，如汽车销售领域通常管自己家销售叫做产品专家（阿里产品p7的title），快消制造业行业通常管快消品的owner叫作产品经理。
甚至，IT软件公司对产品经理的职能边界定义和互联网公司对产品经理的职能边界定义也不同，造成这种情况的原因之一，是产品经理的岗位的历史颇为悠长，在拜读了俞军老师的产品方法论后，借花献佛的讲一下产品经理的历史。
1、消费品时期的产品经理
这是产品经理最早的雏形，1926年，宝洁推出了一款新的叫卡玫尔的香皂，但销量并不是很理想，其原因之一是在这之前宝洁有一款非常畅销的象牙牌香皂。对于一个成熟企业，营销的资源一定是天然的倾向在畅销品上以保障业绩的达成。而新推出的卡玫尔香皂，自然被分到的资源就变得较少了。
这时，尼尔·麦克尔罗伊（Neil McElroy）站出来，他认为必须有一个人为了一个品牌负责，解决在职能管理制度下，各自为战的情况。他自然也成为了世界上第一任产品经理（品牌经理），事实上，他的决定非常成功，卡玫尔香皂的销售情况最终也获得了良好的提升。
在那个时期的产品经理，与现在的快消品行业的产品经理毫无二致，这个岗位的人应对对某一个产品（快消品实物产品）负最终责任，其岗位职能包含明确产品定位，做产品营销，做渠道拓展，横向拉通各资源部门支持自己来达成目标。
时至如今，产品营销与渠道拓展的职能，在绝大多数互联网公司里已经被迁移到Marketing部门，但流传至今的是最早设立这个岗位的初衷，即为某个产品的最终结果负责，仍旧是目前互联网公司产品经理的最核心的定位与职能。
2、软件时期的产品经理
2.1、早期软件时期的产品经理
在信息技术的早期，PC绝大多数情况下都是面向企业经营使用，在那个时期，“产品”由原有的香皂变成了又代码构成的各类软件，最大的变化在于用户群体的变更，软件的受众群体更多的是企业，目的十分明确，相比而言，需求也相对清晰。
在这个时期，产品经理的核心职能之一是跟进甲方，探究真实的问题场景，给出对应的解决方案，并拉通内部的相应资源做好项目的实施落地跟进。
这个时期的产品经理侧重的职能和现在的PM（项目经理）更为相似；同时，产品经理需要跟进甲方客户，探寻需求，给出解决方案，这一部分的职能，仍旧是目前B类产品经理（尤其是SaaS型公司）的核心职能。
相比于快消品时期的产品经理，对产品的最终结果负责、拉通各协同部门、追踪过程，这一部分呢工作职能得以保留。
2.2、中后期软件时期的产品经理
其实俞军老师的书里并没有把软件时期的产品经理拆分开，只是讲到了随着软件企业的成长，组织体系的进一步健全，同时伴随着民用PC的普及，类似瑞幸杀毒软件等民用软件的普及，也推动了产品经理的细化分类，基于此，我仅在此浅谈下自己的理解。
- 市场产品经理
该岗位更侧重于收集市场与客户的需求，发现潜在的机会点，这一职能在后续的互联网大厂中，伴随着职能细化，逐渐的独立到用户研究职能范围，但对于产品经理，发现市场需求与客户需求，仍旧是互联网产品经理的一大核心技能。
- 产品经理
给解决方案，给产品设计，通用化的解决行业中的一类问题，包装软件为一个标准产品等，与目前的产品经理的职能基本一致；
- 项目经理
事实上，项目经理（Project Manager）和产品经理（Product Manager）已经完全是两个体系的工种了。日常工作所关注的点，核心能力模型也接近不一致。
3、互联网时期的产品经理
3.1、互联网早期的产品经理
互联网的爆发，尤其是移动互联网的爆发，带来的是全民产品经理的风潮。随着家用电脑、互联网、手机的普及，使各类软件、App成为人人均可接触的常见事物，大量的App激增，带来的是产品经理的需求激增，整个市场变成了一个供远小于求的状态。
从boss直聘上随手找一个App产品经理的JD，通过岗位职责和任职要求来抽取关键字，产品规划、设计界面、信息架构、需求调研、产品设计、流程跟进、数据复盘、竞品分析、Axure、visio、xmind。将这些关键字按工作方向汇聚，可以看到互联网产品经理的工作范畴，完全囊括了软件产品经理的方案设计相关的工作，同时也具备了一部分市场产品经理的工作职能，以及注明了要求具备事后复盘review的能力。
供远小于求的市场格局，造成的就是很多职场人无论是通过培训班还是自学，拼命的转型进入这个行业；对于校招生来讲，充裕的线上流量，成熟的数据分析方法论与A/B test能力，也让初入职场的同学同样具备了当“好”产品经理的能力。
这是产品经理最好的时期！
3.2、互联网中末期的产品经理
随着市场上各头部公司的App的成熟，网民数量的增长停滞，马太效应加剧。以前靠个想法就能做个App融（骗）资（钱）的情况基本不存在了。近乎所有领域都由蓝海转为红海，各大头部公司都开始做深耕精细化运营动作。而业务趋稳与营收增速放缓，带来的就是人员缺口变小、能力要求变高，这就进一步加剧了互联网行业的内卷。
而更为可怕的是，与早期的内卷相比，当下的内卷并不仅仅是同行业的比拼，比谁更年轻高潜，比谁更能加班。当下的内卷变了花样的导致了互联网各岗位之间的边界越来越模糊，开始出现近似岗位横向能力与工作职能侵蚀的状况。
换言之，即设计抢用户端产品的活儿，研发抢B端产品的活儿。
简要的把一个互联网公司业务组织职能流程拆解一下，业务实际工作中发现问题 → 运营输出规划与需求 → 产品承接需求并给出方案 → 需求实现（设计承接方案并给出对应的交互与UI设计 & 研发承接方案并开发上线）。以上述流程来看，在业务/商业的理解和落地实操角度看，产品不如业务同学；在日常公司运转的机制设计上，产品不如运营同学；对于方案最终的落地实施，UED与研发具备着极强的专业性，产品也没有办法介入。
自从阿里巴巴的设计总监青云提出用户体验设计师的概念并加以实践后，UX设计师的职能就已经开始逐渐侵入部分产品的工作领域了。包括用户需求的洞悉，用户画像的梳理，甚至用户行为数据的处理与分析，这些属于C端产品应该做的分内之事，UX做起来也并没有太大的问题。但设计师本职工作中的无论是原型的设计还是UI稿件的设计，产品经理做起来都不如设计师得心应手。
对于产品同学来讲，你能干的我也能干，但我干的你干不了。这感觉是判了产品同学的职业生涯的死刑。
二、产品经理能力模型
回顾了产品经理的历史，从勇于打破职能管理制度无人担责而诞生的产品经理，到互联网行业早期风生水起的产品经理，再到目前行业衰退，招聘市场一片冷冷清清四处挤满了“被毕业”的产品经理。
产品经理还是那个产品经理，但产品经理却不再是那个产品经理了。
从寒冬中历练生机，在困境中发现机会，在时节不佳的当下，更应当清晰的知道产品应当具备何种能力，提升自身的竞争力。
1）专业能力
专业能力，即支撑这个工作的基本职业能力。
对于那些门槛在门外边的职业，如律师、教师、医生等等，国家已经通过律师执业证书、教师资格证、执业医师资格证这些国家级的考试帮我们进行了初步筛选。
而类似销售、行政、hr等门槛在门里的岗位，虽然并没有一个“准入”的执照，但这并不代表这些岗位是随便进入的，或者说这些岗位所有人干的都是一个样。
由于互联网早期的产品经理的需求激增，导致了人人都是产品经理的假象，大量从业者涌入带来的后果是让整个行业的平均专业水平被拉低，进一步的让外界认为产品经理是不需要专业能力的。
但是对于所有门槛在门里的工种，入行易做精难，隐性的专业能力让这种行业的同学的精进变得更难了。
接下来就我个人对产品的理解所需的专业能力大致讲一下。
1、产品设计力
研发的产出物是代码，设计的产出物是设计图，销售的产出物是售卖结果，通常意义上讲，产品的产出物是产品文档PRD。
产品文档是为了解决业务问题与业务、运营、研发沟通的媒介，一份好的产品文档可以让大家快速了解产品的背景、诉求、目标、解决方案、异常情况处理、历史兼容处理等多块内容。
写出一份优质的产品文档的核心能力即产品设计力，换言之是对问题的解决方案的能力。对于绝大多数初入行业的产品同学来讲，基本都停留在解决详细问题的阶段，业务/客户提一个需求，根据需求给出一个方案，写一篇PRD，画一个交互图，给出一些逻辑流程图。然后开需求评审，跟对应的研发同学讲这次要做个什么什么功能。
这是一个产品的基本功，对于产品新人，尤其是0-3年的产品同学（P5），考察的重点很多时候都会在基于一个特定的业务场景，针对一个特定的业务需求所给出的解决方案的合理性。是否解决了原始问题，方案是否简洁高效，逻辑是否合理自洽。
随着需求/系统/场景的复杂度与产品覆盖面的广度等上升，对于产品解决问题的能力的要求越会越来越高，一款只有10来个人使用的本地的Markdown编辑器软件里另存为功能（覆盖面小，系统复杂度相对简单）和淘宝双十一的购物车活动促销展示（覆盖面极大，系统复杂度极高）这两个需求，对于产品解决问题的能力要求可谓天差地别。
当然，到了P9的高P们几乎不再写产品文档了，这不意味着他们失去了产品设计力，而是对他们的要求从产品的设计上更加进了一步，要求他们对行业，对业务的理解更为深刻，不再是解决问题，而是系统化的解决问题，甚至提出问题。
2、业务理解力
按照正统的理解来看，业务理解力下的各项应该是拆出来独立写的。但是在我的经验来看，我更倾向于将所有与业务理解相关的能力项先进行一波合并。无论是对于需求真伪的判断，还是对于需求优先级的判断，以及更深层次的对业务的理解深刻后发现潜在的机会点的能力，其实都需要十分强大的业务理解力。
2.1、分析问题的能力
有人提需求，就一定要满足实现吗？答案当然是不。但是真的能够清晰认知到何种需求是伪需求，却是摆在产品同学面前的一个非常大的难题。
通常来讲，在一篇PRD的开章就是项目/产品背景和目标，往后才是用户故事、解决方案、原型、策略、流程等等具体实施的细节。这同样表明，在一个产品实施的全链条中，涉及到需求与实施的上下游各位同学，其实也一样需要确定这个需求是个真实的需求，只有在共识了需求的背景以及目标之后，才更好的能够拉通全链条的同学一起努力工作达成目标来解决问题。
在分析一个需求的合理性这件事上，涉及到业务的商业模式本身、业务的当下现状、事件/问题的影响范围、是否很多业务场景复用等太多参考因子。例如新用户引导这样的一个场景的需求，对于一个企业IM的聊天页面来讲，大概率是一个伪需求，IM作为非常标准且常见的功能，不了解其核心功能的用户属于极少数的；但是对于一个复杂的2C应用，如金融类的App，客户需要用到的流程和功能相对来讲会多一些，同时由于平台较难直接接触到C侧客户做答疑辅导，当功能不易用且客户不知道该如何操作导致卡顿时，往往会导致用户流失，这时这个需求大概率就属于一个真需求了。
更为科学的体系化的对需求真伪分析的方法论，未来有机会再展开单独讲一下。在这里，只说一种非常简单高效的判断方法，即，如果这个需求能够给相对来讲较多的用户产生真实的价值，那么大概率是个真需求；反之，如果某个需求无法给任何人或组织产生收益（用户体验的提升、效率的提升、成本的节约等），那么这个需求大概率会是个伪需求。
无论是初创型公司、还是BAT级的成熟头部互联网公司，产品研发资源都是相对短缺的，在“锅盖比锅少”的状况下，解决问题是目标，但解决了一个不是问题的问题，则是极大的资源浪费，是产品同学的失职。
2.2、需求规划能力
首先，这是通常意义上讲的需求优先级的判断，当多个需求摆在面前时，哪个需求更重要需要优先解决，哪个需求可以延后解决，就是需求优先级的判断。需求优先级的本质是需求对业务产生的影响或价值，核心需求的是对业务现状和未来的理解。
首先，用一张图来区隔全部的需求，任何一个合理的需求都会落入以下图中4个象限中的一个。
- 重要且紧急的需求（右上角象限）
当一个需求发生的时刻是如果没有这个需求对应的功能，业务将无法继续进行，或者会造成大量的业务损失时，这个需求应当是立刻被支持的，即重要且紧急的需求。典型如线上bug，或政府政策影响限制（社区团购生鲜商品不允许破价，广告投放不允许出现”最“等违规字眼），或定量分析后需求带来的收益（ROI）极高时，该需求即应当被定义为重要且紧急的极高优需求。
一个需求即重要又紧急，当然要被定性为第一优先级P0的需求；
- 不重要且不紧急的需求（左下角象限）
与之相反的，即使需求合理，但其影响面小、收益率低，即重要度相对较低，且当下并非最痛最急迫的事情，则应列入第三优先级P2。
而当随着业务的变化，随着时间的推移，该需求可能甚至有可能会变为伪需求作废，但也有可能会变成重要度高或紧急度高的需求，甚至变为重要且紧急的P0级需求。
举个例子，某车辆租赁公司的官网，提供了用户租赁后的说明协议。而这个说明协议本身就在App内的租赁流程里有同样版本的展示，在用户进行租赁时，就会被引导查看，因此，官网的租赁协议的入口隐藏的较深。这时，有法务同学要求将租赁协议的入口放出以解决可能存在的潜在的法律风险。
不能讲这个需求是个伪需求，但无论是用户是否具备自主查看的能力（即使入口很深，但依旧存在），还是在主流程上是否覆盖了需要存在的用户协议（即租赁App的租赁行为过程中引导浏览用户协议），实际这个需求只是在解决一个非常小众且收益率较低的问题。
在这个时刻，这个需求即是非常明显的不重要且不紧急的需求。但随着时间的发展，有可能是出现了重大的用户纠纷，也有可能是出现了政策的变动等管控需求。将用户协议暴露出来让更多的用户能够更快的看到，其紧急性就会上升。
- 重要但不紧急与紧急单但不重要
通常存在争议的是重要不紧急与紧急不重要到底哪个更需要被优先解决，但与分析需求真与伪一样，这并没有一个非常标准的答案。需要PD在当下的业务节点进行分析。
例如外卖骑手的送达时间估时不准确，正常情况下实际与推算相差10%，其造成的影响是线上的体验不佳，看上去是个重要但不紧急的事，但如果在运力不足的情况下，或在特定的时间节点如午餐晚餐高峰期时，伴随着履约时间增加，10%的误差同样会被放大，叠加消费者的心理预期增高，其造成的影响会被放大；同时，如果竞品的估时准确，给到客户的心理预期准确，这会进一步造成客户的流失，那么这个需求的优先级就会很高。
另外的例子，在某些小体量公司里会存在类似这样的需求，在xx大促中需要一个定制的数据报表以便于业务快速调整策略，看上去是个紧急但临时的需求，且即使无法给出可视化报表也可以通过数据同学自行查阅MySQL或其他方式来解决。也许随着时间推移，大促结束该报表就会被搁置，这个需求就会变成一个带有特殊业务场景的临时性需求，会被弃置。但如果大促战线拉长，又或大促的形式与机制得以保留，只是费用的力度、覆盖范围等等的调整，那么报表的需求会变成一个长期的需求，又因为会涉及到对活动的调整，重要性得以提升，变成一个重要且紧急的项目。
可以看到，并不存在一个通用性的对重要但不紧急与紧急单但不重要的优先级的判断标准，在实际的业务运转的过程中，如何更好更准确的衡量这两部分需求的先与后，是一个随着对行业理解加深，与公司各部门磨合加深默契提升而不断成长的事情。
2.3、发现问题的能力
传统软件公司时期的IT团队的同学，很多时候的工作都是在贴近客户，听取客户的需求，给出解决方案。这种情况下基本都是在一味的接收非常清晰明确的需求，给出解决方案。
到了互联网时期，成熟的分工让整个需求链条变为了用研/数分/客服/BD/运营 → 产品，即有诸多需求是通过所谓的“业务”过来的。当然也存在产品同学直接通过客服听线、一线调研等行为获取需求，但往往这种情况下所看到的也往往是需求的表面，但这其实是产品同学发现问题的能力。
对于纯粹的AB面均在线上的互联网公司来讲（即交易/获客发生在线上，履约/活跃也发生在线上），通过观看用户行为数据埋点来洞悉可能存在的潜在需求，这也是发现问题的能力。
曾经有个产品高P分享过一个讨论，提出问题重要还是解决问题重要？当时场下讨论纷纷，这个开放性的问题也没有任何定论。我个人的认知是，对于高P来讲，提出问题更为重要，提出问题，代表看到了某个行业或某个业务里的潜在的问题，能够发现机会点。而对于初中级产品来讲，解决问题更为重要，一个相对清晰的目标，能够通过解决问题来达成，实现企业内的个人价值。
伴随着产品同学的能力升级，重复的只是在做解决问题的事情，在某种程度上讲其实是落入了执行的陷阱里，不思考为什么会出现这样的问题，不思考未来可能会出现的问题，一味的基于原始需求/业务问题给出解决方案，个人是否有成长不谈，永远也解决不完的业务需求也会把产品同学挤压到极限。
主动发现问题一方面可以帮助产品同学提前规避未来可能发生的紧急需求堆积导致的整体节奏失调，也可以防患于未然提前解决未来可能出现的问题。针对发现问题的方法，抛砖引玉的给出一些大致的方式。
在面向消费者的2C互联网领域，产品经理无法接触到广泛的真实客户（使用者）。虽然以小米为代表的一部分公司，通过内测、内部论坛、反馈渠道等可以获知到真实客户的原始需求，但毕竟不是全部的客户。
通用的方法是，利用用户行为埋点数据进行用户行为的分析，并从中找到卡点，一些指标如黄金购物流程、平均停留时长，单页面流量流向等。通过对数据的分析，可以帮助产品同学在海量的用户群里快速找到共性的问题，再结合用户访谈与灰度试点等方式达成产品的优化。
从2B或内部系统来看，虽然用户群体较为容易接触，但作为生产力工具的应用绝大多数的时候客户需求并非真的是真实的原始问题。客户/业务所提出的需求往往有其特定的业务背景与时间背景，如果一味的听取业务需求不加以自己的思考，很有可能会落入持续不断的被提需求→解决问题的循环。
提升发现问题的能力的方式，无非是在天然具备业务全局视角的前提下，主动理解业务，主动发现业务流程中的卡点，主动思考，探寻发展的机会点。
结合分析问题、需求规划、发现问题这三点来看，业务理解力是产品的核心竞争力。任何公司、企业都是以盈利为目标的机构，任何在公司、企业内的雇员都是以帮助企业盈利为目标的价值体现。
相比于研发、设计类专业型的岗位，产品不写代码，不画UI图，不售卖东西，难以用直接的产出物来量化价值，如果只是在做翻译业务问题变成研发能够理解的语言这件事，研发向业务靠拢一步，或者业务稍微了解下研发的原理，这中间就不再需要产品的存在了。
所以在在日常工作中，我对于产品同学的考核更为看重的是他在一个大的业务背景下所做的事情的why和how。前者代表的是产品是否有更深刻的思考需求/问题的本质，后者代表的是解决需求/问题的手段。
3、项目管理能力
前文对产品经理历史的介绍中也提及了，软件时期的产品有一个非常重要的职能是项目推进与落地。虽然现今的成熟组织内有PMO的专项人员在做项目管理的事情，但项目不落地就代表事情没结果，产品经理是一个靠结果说话的岗位，那么一些基础的项目管理能力，也是一个产品经理的必备技能。
3.1、资源协调
项目管理是一门非常专业的学科，个中复杂不做详说。仅从产品经理需要涉及到的点来讲，产品是一个需求实现的组织者发起者，需要对结果负责。产品不会自己产出代码，也不会自己产出设计图、测试用例。这一系列的工作都需要其对应的专业人员来做对应动作。
项目发起时，首先需要的就是产品经理对自己的项目有深刻的调研，有充足的理解，对方案有足够的把握与信心，这样才能够在与兄弟部门沟通时，针对对方所关心的问题给出明确且合理的答复，说服别人投入到这个项目上。
当资源紧缺的时候，面向能够调动资源的更高层，描述清晰项目的重要性以及当下的情况，预期，才有可能完成资源的协调保障项目的稳定落地。
3.2、项目规划能力
项目规划有相对通用的方法，其核心的目的是通过科学化的方法，将一个产品项目按阶段按责任人拆分，厘清上下游的协作关系，拆解一个长时间的工作为短周期的多段工作，以便更好的进行整体的管控，降低风险。在何种时间点拆解里程碑，在何种情况下需要对时间风险做预警，这些依旧需要产品对这个项目的成本评估恰当以及与相对应资源的协调妥当才能够做出更好的规划。
通常，我们使用甘特图来进行项目过程的拆解，以帮助自己以及项目组成员来更清晰的了解里程碑，依赖关系等。
4、运营能力
有人讲，产品是爸爸，运营是妈妈，两者合力才能更好的把产品变成一个更好的产品。这里提到的运营能力并非真实的去对产品做运营，而更偏向于运营的设想、规划与实际交付。一个产品从零到一，从出生到消亡，产品作为对应的负责人，理应对这个产品在生命周期内的所有行为负责。在产品设计之初就应思考清晰产品未来的落地发展机制，在真实落地后是否如期运转。
在我工作的第一阶段，做的是集团孵化的创新项目，团队规模比较小，各职能之间的衔接紧密。而且在创业期时，绝大多数项目节奏都极快，第一天走市场见客户（社区团购类项目）看业务，当天晚上总结复盘出需求，第二天上午出方案，下午上线，晚上继续走访。整体没有走过完整的流程，项目方案设计的时候也很少会考虑上线后的运营逻辑。
到后来进入成体系的公司工作后，动辄百万级用户量的产品在没有思考清晰产品运营机制的前提下轻易上线极其容易出现问题，于是开始思考产品落地后的运转的问题，上线后如何做内部人员的培训（BD、客服等），对外如何做用户引导，如何观测灰度用户的数据，路径等等。
产品的运营力更倾向于针对产品本身能否按照预期发展的思考规划的一种能力，所关心的东西更贴近与产品的本身，而非产品运转过程中的业务动作（如千牛这款产品，产品更关心的是通过产品的改动，是否让商家在千牛上如预期的使用改动的功能功能解决了某些问题，或通过产品的改动的本身引导更多商家来使用千牛获取更高的收入，MAU等指标），而活动细则设计，费用规划等业务运营动作则理应交由更为专业的团队来承接。
当然，随着整个互联网越来越卷，现在越来越多的产品开始具备基础的业务运营能力，如操盘活动，制定规则机制等。
5、归纳总结、复盘能力
世间任何事情没有无缘无故的成功，也没有无缘无故的失败。一次两次的成功可以说是因为运气好，一次两次的失败也可以怪罪于时运不佳。但产品是一个科学的工作，靠感觉去做事情无异于靠天吃饭。通过归纳总结与复盘，可以更好的帮助产品同学对一段时间的工作有一个科学的检视。
业务是一个将抽象变具象的落地部门，产品则是一个具象变抽象的支持部门。点对点的去分析思考问题极度容易掉进业务的“陷阱”里，变成出方案的机器人。及时的反思近一段时间的工作，一个产品上线了，如果如预期发展，是产品设计的好，还是运营做的好；是灰度用户选择的好，还是引导链路设计的精巧；是时间、环境等巧合，还是真的抓住了核心用户的核心诉求，解决了核心痛点？如果并未达成预期，问题点在哪里？产品设计出现纰漏？推广力度不够？
定期的归纳总结与复盘并不一定要拘泥于形式，但这种意识和动作，可以帮助自己更好的看清一段时间内的成功与失误，可以更好的帮助自己发现上一段工作/生活中的遗憾，帮助自己更好的在未来一段时间成长。
6、沟通能力
我记得以前和一个RD朋友聊天，他说他宁肯做非常资深的程序员亲自写功能代码，也不愿意做团队管理或者介入产品的工作。
原因很简单，与机器打交道是1和0，但与人打交道，往往是1和∞。在沟通过程中对方的利益，成本，甚至是当下他的心情如何，都会影响这一次沟通的结果。有些时候沟通到最后发现感觉就是鸡同鸭讲，闹到最后双方不欢而散。
我相信很多产品同学在职场学会的沟通的第一课就是如何开好一个需求评审，面对比自己年长、资深的程序员，主导一个会议，希望与大家达成一致推进项目，但却被研发问到专业领域的问题该如何处理时不知所措。这其实是沟通力尚不足的原因。
对于产品而言，横向要与业务拉通对齐，共识业务目标与解决方案；产品落地过程中还要与研发、UED、测试等诸多岗位来沟通确认项目细节以达成目标。如果“不幸”负责的是一个类似交易、调度等流程型中后台模块，还要牵扯复杂的上下游系统。
沟通能力怎么提升呢？回到本质来看沟通，沟通一定是建立在双方认知的前提下，针对某一个事情进行商讨，以双方都能够理解的语言体系进行对等的交流，最终达成一致。比如销售在面向客户进行保险销售的时候如果一味的在聊保险设计，费率等等专业的字眼，就很难和客户达成共识，往往好的销售会针对客户的收入、家庭、焦虑源进行点对点的切入，进行针对性的介绍，往往会促成交易。
同时，沟通的过程也需要站在对方的视角看问题。举个例子，我负责订单系统，下游的数仓团队的产品同学过来跟我讲说需要我数据入仓的时候符合吧啦吧啦什么标准，这样后续数仓的数据质量就会很高。假定这个例子发生在一个很成熟的企业，有成熟的机制流程，那么还好。如果是一个初创型的企业，我又恰巧是一个不是很了解全链路的产品，我的第一反应就是，你数仓的数据质量好，对我有啥好处？我手里还有一大堆的产品工作没有做完，业务团队还三天两头的催我某某功能上线，我为什么要费精力去配合你？这就体现出了在沟通环节中，如果是需要对方配合的，那么首先需要判断对方是否在这件事情上受益，如果不受益，那么他为什么要配合做这件事，是否有相关的规则约束来推动他配合？
沟通能力技巧是一门需要长时间修炼的学科，唯一的方法论也只能是更多的去了解沟通双方的处境、诉求、知识体系，以一个对方更容易理解的方式去进行交流。
2）通用软素质
很多招聘上都会有类似这样的要求，抗压能力强、学习能力好等等，也有很多单位/公司/企业等等价值观里会有一条叫做拥抱变化，这些都是所谓的通用软素质，这一部分的能力不区分行业岗位。单纯的从产品的工种特性来看，有一些通用软素质会显得更为重要。
1、ownership
之所以把ownership放到第一位去谈，更多的是是认为一个产品的最基本的职业素养是责任。从历史上诞生产品经理这一职位的原因来看，产品经理是一款产品的最直接的责任人。
一款产品出了问题，如果是bug那么我们认为需要研发和测试来负责，不美观体验不好可以说是设计师的责任，但责任归责任，对于产品经理这个owner来讲，任何问题都可能导致这款产品不如预期般发展。
责任心的缺失都会让一个产品经理对产品变成一种很无所谓的状态，得过且过，能用就行是一个产品经理对自己工作的最大的失职。这里讲ownership并非是想PUA产品或者把所有的压力和苛责都堆在产品经理身上，而是一种执着、投入、负责任的精神。
有一些鸡汤讲，出了一件事，月薪500的说这个事跟我有什么关系，月薪5k的说这个事跟我没啥关系，月薪20k的说这个事我可解决不了，月薪50k的说这事我来解决。我们不去争论挣多少钱干多少活对与不对这件事，但是对于一个产品来讲，起码要做到这件事我解决不了这个阶段，而非“不知道不了解”，“这个事跟我没关系”，“麻烦你找xxx吧”的甩锅三连。
ownership如何锻炼如何提升，我也并没有太好的办法，或许有一些人对于事情的投入的源动力是热爱，那么尽可能的在某件事上找到他的意义，找到他的价值，对其产生热爱，也就会自然而然的有了更多的责任有了更多的ownership。
2、好奇心
好奇心也是我在面试校招产品的时候相对来讲非常关心的一项软素质。
常有人说小孩儿对世界是永远充满好奇的，而经历了填鸭式教育之后，会抹杀好奇的天性。我不针对这个结论做任何评论，但如果人的成长动力是来源于压力，那么过程将会很痛苦。但如果是来源于兴趣，往往会激发出人更超乎想象的能量。
好奇心是什么？是牛顿看到苹果掉到地下后的疑问，是瓦特看到水壶烧开水后壶盖一直在向上冲时的思考。对于互联网这种需要时时紧跟前沿技术与时事的行业来讲，需要每一个身处其中的人都不断的学习进步；而产品经理作为横跨了诸多学科，需要诸多信息支撑其做决策的岗位来讲，拥有一颗好奇心，对各种前沿技术都能够加以了解，则显得更为重要。
我也不知道怎么样去提升一个人的好奇心，只能祝福产品同学们充满童心，做一个快乐的孩子。并将对世界的热爱转变为由兴趣出发的自主学习动力，提升自己的学习力。
3、学习力
这里谈到的学习力，并非是简单的看学习的成绩结果如何。我曾在校招面试、实习生面试中发现很多的同学，他们对于学习力的理解就是GPA有多高，拿过多少多少的奖学金。然而在谈到对产品、对互联网公司的理解的时候，有一批孩子会一脸呆滞，另一些会好一些的能够说出来产品经理是画原型，给研发对接，然后上线，互联网是用网络的能力做一些东西，比如淘宝等等；鲜少有人能真的说出来产品经理是在用业务的视角思考技术，用技术的方式去做业务。
当然并非要对一个应届甚至尚未走入职场的孩子有如此高的要求，但市场就这么大，28原则太明显了，既然想迈入这个领域从事这个职业，如果连最基本的理解都是空缺的，也并没有能力与办法学习到这些东西，缺失自己的思考。又如何和其他人竞争呢？
有人讲，初高中是教给人知识，大学是教给人学习的方法。我以为，学习的方法很重要，但学习的意识和主观性更为重要。
步入职场后，尤其是从事产品这样一个偏社会性科学的工作，每天需要接触的事情有太多太多是以前大学学校里老师教授没有讲过的，甚至有一些事情与遵循逻辑、实验、数据等等的形式科学或自然科学的标准方法论相差甚远。
又很不幸的赶上mentor很少会有以一级指导力的方式去言传身教的去指导应该怎么做，有些同学会想尽一切办法找资料了解学习；而有一些则直接得过且过，学多少算多少，能干成啥样干啥样；甚至还有一些会打退堂鼓，学起来太难了干脆不学了。每一个同学的产品职业生命到底能走多远，其实在这一刻就已经能够看到了。
学习力，无外乎就是自主学习的意识与态度，是对一个未知领域的信息收集的能力以及收集后的思考的意识。
4、抽象力
基本上所有的产品经理的JD里都会有一条叫良好的抽象能力，而绝大多数正规化体系的产品培养计划里也有一条是培养抽象力。
wiki百科给抽象的解释如上图，无论在任何场景、学科下，抽象都是在把多个问题、实体变成一个相对来讲具有一定共性的东西。
在实际业务动作中，是否有多个场景存在相似可以被归纳成为一类通用的问题；多个看上去不一样的需求背后是否是同质的问题；各种看上去繁冗复杂的需求背后的核心逻辑是什么？
以CMS（内容管理系统，本文特指面向电商活动页搭建）来举例子，无论淘宝、京东、闲鱼、亦或是国美、当当这些App，其活动页面来来回回的就那几种形式，即商品、图片、文字堆积并在页面上形成不同上下顺序差异所构成的页面，并对其中部分区块进行可点击的交互。抽象下来看，整体的结构就是页面-模块-内容-交互。那么在接收到业务提出要做一个xx专场xx活动页的需求时，我们能否将这类需求汇总抽象变成一个页面搭建的系统以解决同质化的开发需求？
产品功能可以抽象，商业模型亦可抽象。滴滴打车、美团外卖、淘宝电商，看上去是三件完全不同的事，但其本质均是平台吸纳运营供给方（司机、骑手&餐厅、卖家），通过一定的机制分发给客户提供服务，S2B2C。当然，在实际的业务运行过程中，不同商业模型在其运转过程中所关注的重点一定会有所不同，在淘宝电商当中基本不会出现司乘安全的问题，同样在滴滴打车过程中也基本不会存在卖假货的问题。
抽象不是万能的，但抽象可以更好的帮助我们对产品的建设进行良性的提升，对于产品同学来讲，面对需求时多想想深层的逻辑，多思考需求背后的东西，对抽象力提升是一定的帮助的。
5、同理心
我不是一个很好C端产品，甚至我都不敢称呼自己是个优秀的产品。核心原因就是我自知自己并没有太好的同理心，写这节的时候真的是内心惴惴不安。
同理心，顾名思义，是指尝试（在想像中）将自身置于他人处境或所在“位置”的能力，在用户侧产品的能力模型里，同理心的优劣会直接影响产品同学的能力评定。
举一个实际的例子，小米手机早期一直在以发烧、性价比等字眼来进行手机的设计与售卖宣传。随着手机的性能趋于饱和过剩，消费者，尤其是年轻女性消费者开始对手机卡不卡不在那么关心，诸如红米K40 Rro这样的手机所主打的卖点如游戏性能强、配置高等并无法打动这些消费者。
随后小米Civi的诞生，让我对小米这种直男审美的设计有所改观，恰逢给老婆买备用机，这两台手机都实际入手购买过。在老婆的视角对比之下，K40的颜值、重量、手感完全不如civi更贴合女性的需求，而civi上所使用的的CPU，内存确实略有阉割，但站在她的使用体验及诉求来看，手机性能如何并不重要，重要的是不要太重，外观要好看，拍照要好看。
小米Civi的成功是基于产品经理优秀的同理心，能够心思细腻的更设身处地的为用户思考，而非以逻辑、商业、架构等等冷冰冰的东西去衡量产品的优劣与价值。没有好的同理心不可能做出好的产品，俞军老师说过，产品价值=(新体验-旧体验)-替换成本。产品的底层逻辑是可以支撑产品更好的跑起来，但终究是里子。好的商业模型和与深厚的资源背景最后被体验打败的例子太多了。当年横扫市场的飞信，逐渐默默无闻直至关停，无他，从用户视角看，体验太差了。
不能说K40 Pro失败，其和小米Civi的差异，是目标用户不同、需求不同，挖掘这些需求的本质，需要产品经理站在客户的视角看问题，以同理心去发现客户的核心诉求，才能更好的打造符合用户需求的好产品。
除了产品以外，销售也是一个需要有非常强同理心的职业。我在买车的时候碰到了一个具备很强同理心的销售，他很敏锐的发现我对于车的诉求无外乎加速性能，制动性能，降噪，高速稳定性，对自动驾驶相关的并没有太关心，之后他带我试驾在高速上急加速，急刹车，带我体验高速行驶的稳定性与降噪能力。对比某特斯拉销售一味的在讲自动驾驶如何如何，这个销售更好的抓住了我的诉求，并打消我的顾虑，最终促成了交易。
沟通能力是技巧，同理心是支撑更好的沟通结果的底层支柱，空有沟通技巧却缺少站在队方的视角看问题的同理心，沟通的效果往往还是会差强人意。
6、抗压力
阿里的用人观里有一条是“皮实”，何为皮实？面对挫折不屈不挠，碰到问题迎难而上。产品经理的职能决定了他要为业务结果负责，要集合力量达成目标。很多时候摆在产品的面前的路是一条没有被探索过的路，伴随在这条路上的，满满的荆棘与坎坷。
很多初入职场的同学希望做产品经理，有一些人是因为看到了一些文章讲产品经理是“小CEO”，那纵观中外商场成功的CEO们，乔老爷子被从一手创办的苹果离开，刘强东因为融资一夜愁白了头，王兴创建饭否失败。诸如此类的事情数不胜数，如果这些大佬当年因为一点点挫折就此沉沦，恐怕我们现在用不上iPhone，享受不到京东的极速达，吃不上外卖了。
面对事情理性对待，放平心态，这些话听上去简单，做起来难。或许随着时间的推移与阅历的加深，心态也就会逐步变得更平稳，面对事情也会更加乐观平和。
三、产品经理何去何从？
伴随着互联网的内卷与行业的冷静，许多产品经理陷入了失业的焦虑甚至危机当中，作为互联网大潮里的一名产品从业者，自叹自己没有生在好时候，互联网造富神话已经成为过去，当5年产品衣锦还乡已经成为梦想。
伴随着一茬一茬的新同学毕业，也伴随着整个行业的成熟度提升，当下的产品经理的成长速度之快，也让我们这种高不成低不就的老产品们心慌。逆水行舟，不进则退。只有一个办法可以让自己稍显心安理得，那就是被迫卷起来。
但谈到卷，那也要卷的ROI高一点，盲目的比拼谁的加班时长长，谁更能舔，私以为乃是下下策。市场需要什么能力模型的人，什么样的产品更吃香，如果不能对这个事情有更清晰的分析，也只能是盲目的瞎卷。
上文仅仅是我个人对产品经理的能力模型的理解与认知，或许伴随着市场的变化以及我个人的成长，我对这些能力模型的理解也会发生变化。但活在当下，对于上述的所有能力模型，我也时刻提醒自己做的更好，以保障自己的核心竞争力不落于人后。
共勉。