在互联网时代高歌猛进的背景下，各行各业都或多或少有了子领域或细分，相应的，产品经理也可以根据所做的产品属性、行业、平台等有多种分类和名称，如社交产品经理、电商产品经理、移动端产品经理、数据产品经理、策略产品经理等等，而且各类岗位的技能要求会有差异，工作内容也不尽相同。
越过这些让人眼花缭乱的title和纷繁复杂的工作内容，我理解的产品经理是一个多种角色的集合体，是敏锐的发现者，是周密的设计者，是洞悉未来的规划者，是价值的创造者，还需是生动的讲述者，真诚的聆听者，好奇的体验者，积极的管理者...
想到这里，无论是做一个产品，还是一件事情，或是一个人，某种程度都是这些角色的集合体，所以“人人都是产品经理”，本质上是，人人都可以以产品经理的思维方式和做事方法来思考和实践。
那产品经理在修炼过程中都会遇到什么怪，表现出什么样的思维方式和做事方法才得到升级的呢？
1. 确定产品定位
回想曾经在学校课堂时做过的小项目，无论是写商业计划书还是项目管理计划书，无一不强调过，需要用一句话来表述清楚你的产品是做什么的，或为哪些人解决了什么问题。这三个小问题其实就分别对应了产品的三个要素：功能、用户和需求。
1.1 用户
三个要素不分主次，但从时序上来看，我认为排在第一位的应该是用户，即首先要明确是谁提出的问题，或谁面对的问题。
任何一个伟大产品的用户都是从一小撮种子用户开始的，经过几轮的试用和筛选，核心用户慢慢显现出来，首先要服务好核心用户，哪怕对整体的用户数有损伤，但是剩下的用户忠诚度更高，彼此距离更近。就像苏杰老师说的，宁愿让一部分人爱你爱的发疯，另一部分人恨你恨得要死，也不要让所有人都觉得你还OK，你是个好人，然后就没有然后了。
核心用户一定程度反应了产品的格调、性质，初看是产品在定位它的目标用户，但慢慢的，用户实际上影响了产品的基调和走向。核心用户定位得越精确，后续的设计，营销活动等就越有针对性。
无论一个产品是从0到1，还是从1到N，都不可能用一个解决方案解决所有的问题，所以总要有所为，有所不为。而一个产品的用户可能是多边的，比如电商平台的买家和卖家、平台方；招聘平台的求职者、招聘者和平台方；内容资讯平台的内容提供者、游客、广告商、平台方......不同的用户群体的诉求是有差异的，甚至是利益相左的，在这个时候，如何定优先级，如何取舍或平衡，是需要有一个基本原则和初心来做指导的，如果没有想清楚范围和限制，各类假设和依赖，那么在产品生命周期的各个阶段，总会出现迷失方向或冲突不断。
另一个角度理解用户是从客户和终端用户来看，有时客户和终端用户并不是同一个群体，比如现在市场上很多针对青少年的编程培训的线上线下课程，终端用户是少年儿童，而客户是他们的家长，所以在设计产品时，对于客户的卖点是强调培养逻辑思维、激发创造力、提升专注力、未来的竞争力等，而针对终端用户来说卖点就是简单有趣，解放天性，寓教于乐。
1.2 需求
需求即定义了产品要解决什么问题，每个用户群体都有很多问题和需求，而优先要满足是刚性需求，也就是要真实的、强烈的、高频的。
第一个问题要问自己，这个需求是用户【真正】需要的吗？是【用户】真正需要的吗？
有些需求是伪需求，是用户认为他需要的，而不是他真正需要的，比如著名的“用户想要一匹更快的马”，他或许只是需要更快的到达目的地，在这种场景下，“更快的马”就是伪需求，而一辆车才是真正满足需求的。还有大家都见过的“我觉得这样更好”，“我觉得这样更科学”，我不要你觉得，我要用户觉得。产品经理要充分的调研，并且设身处地在用户角度体会和挖掘他的痛点和深层次需求，如果团队争论不休，那最好是去问产品经理，如果产品经理争论不休，那最好再去听听用户的想法。
有时候即使是用户提的，那么也要考虑是属于哪一部分用户群体？数量多吗？是否有代表性？
第二个问题要问，这个需求有多强烈？不满足行不行？
需求的强烈程度是很难量化的，如果说不满足这个需求，用户也有其他可以接受的方法来达到目的，那么这个需求或许可以划分到“不那么强烈”中，比如要求上传身份证照片，同时又要输入身份证号，即没有身份证识别自动填充功能，即使自己输入一串数字也可以接受。再比如，网店的卖家在订单量不大的情况下，可以手写收货地址信息，但是随着订单量不断增多，手写就是一件非常低效且不可忍受的事情，必须要有便捷的打印功能了。
第三个问题要问，这个需求发生的频率高吗？
这个需求是像吃饭一样，一天发生多次，还是像男生剪头发一样，一个月一次，还是像春运，一年只有一次。有些需求对于2C来说是低频，对于2B来说就是高频了，比如说家政服务。频次决定了我们选择什么方案来解决，比如说，一个商品被申请售后服务的频次是一个月两次，那么人工来解决就足够，如果频次是一天有上百次，那么智能客服就可以上场了。
这几个问题的答案基本上决定，这个需求做还是不做，以及怎么做，对于需求的优先级评估也至关重要。我们都知道奥卡姆剃刀原理，选择能够解释或解决一个问题最简单的那种方法，保留真正核心的、刚性的需求使产品变得简洁而优雅，所谓完美不是无一分可增，而是无一分可减。
1.3 功能
功能是一个产品的核心，也可以说是产品的名片。设想在某一场景下，用户需要做某件事的时候，立刻就想到你的产品，那么无疑这款产品是成功的。比如突然头痛的厉害，着急去医院，就立刻打开了滴滴出行，检查完回到家，身体虚弱不想做饭了，打开了饿了么，等餐期间想看会小视频，打开了bilibili。
在设计功能前一般会借助生动的用户故事，其实就是在设想产品被使用的场景，不论这个场景有多小，只要够“典型” ，就有生存的机会。
根据使用场景可以大概确定产品的形态，是PC端，还是移动端，是APP，还是小程序，是2B还是2C，以及BS架构还是CS架构等等。
之前做小项目，我们在做竞品分析时，多数只关注了同类产品没有什么功能，或者有哪些缺点，但其实还应关注解决类似需求的不同类产品，把眼界放宽。就像有人说，打败新浪微博的不一定是腾讯微博，还可能是微信朋友圈，打败百度搜索的不一定是谷歌搜索，还可能是知乎，反正我现在如果想了解一个问题，会先想到知乎看一看。
对竞品的认知升级也拓展了我们的视野，其核心就在于把握住用户，或者说一个人，深层次的需求，参考人本主义心理学家马斯洛所著的《动机与人格》中所阐述，人的需求从低到高依次是生理需求、安全感、归属感、爱和自我实现。再细化可以找到很多需求甚至弱点，比如好奇、从众、同情、贪婪、虚荣心......
未来最成功的产品，是最懂人性的产品。
当然一个功能或产品是否能做，是否可做，是否值得做，还要考虑多种因素，比如团队的能力，意愿，市场以及政治、经济、文化等。
2. 需求的采集与分析
需求分析在软件开发生命周期中排在第一位，后续的可行性研究以及概要设计，详细设计都以它为基础。
曾经在学校时，仿佛大家都觉得技术相关的课程才是有含金量的，我也不例外，进入工作中突然有了不同的体会。比如当时不以为意的“软件需求工程”，记得是学院聘请了一位企业老师来讲的，那时只是按要求完成任务，并不知道有什么用处，但现在回想起来，这门课程包含的知识不仅对产品经理的工作有很大的指导意义，某些内容对于平时的思考分析问题也很有启发性。
我们的课本用的是Karl Wiegers, Joy Beatty的著作《Software Requirements》第三版，里面提到软件需求的三个不同层次：商业需求、用户需求和功能需求。
商业需求对应整个产品或公司的使命和愿景，往往是为了满足公司的战略需要，或达成商业目标。如果是公益企业，则是承担社会责任，提升影响力等；用户需求范围较小且具体，我们通过满足用户需求，解决用户痛点实现商业价值；功能需求对应更细节更具体的问题解决方案，需要通过成本和价值来分类和评估。
在实际情况中，或许三种需求并不总是相辅相成，彼此支撑的，有时候满足战略需要的需求会对用户不利，需要权衡内部需求和外部用户，避免做出伤害用户的选择。
2.1 采集方法
需求的来源可能是第一手的，即直接从用户处获得，也可以是经过其他人或机构加工的，两种方式得来的信息各有优劣。为了保证需求的真实可信，需要保证相当的比例是直接采集的，这样能更贴近用户。比如一些入职银行的小伙伴，即使不是业务员的岗位，也要去营业点轮岗，就是为了更接近他们的用户，更了解他们遇到的问题，说“这是一个用户遇到的问题”就不如“这是张大爷遇到的问题”更生动真实，记忆深刻。
采集的方法可以是用户访谈、调查问卷、或去网络上搜索用户的评价和想法等。我曾经作为受访的用户参与过一个APP的用户访谈，受访的8个人都彼此不认识，在主持人的引导下，做完自我介绍，之后主持人问大家的手机上都有哪些APP，使用的频率和场景等等。然后播放了跟APP相关的几个视频，询问大家有什么感觉，意见等。整体感觉氛围比较轻松，融洽，主持人或者说产品经理的交流方式令我很受启发。
因为人有复杂的思维活动，有感情和感受，所以说出来的话并不一定就是真正想表达的意思，举一个极端的例子，妻子经常看到酒鬼丈夫半夜醉醺醺的回家，说“你别回来了！”，其实妻子反而希望得是丈夫能清醒的早点回家，所以她表达的意思和真正的想法是完全相反的。回到用户访谈中，用户的回答可能会受当时的情境和感觉影响，而有欺骗性，比如周围有熟人在，不希望没面子，或者说感觉到敌意和批评，不能敞开心扉的聊了，想赶紧结束。
还有很多情况使我们得不到真正的答案，那么有一些问话和引导的方式非常值得借鉴。
1. 把“你会......怎么样吗？”变成“你觉得你的朋友会......怎么样吗？”
2. 把“你们需要......功能吗”变成“如果没有这个功能，你们是现在是怎么做的？”，以及“如果我们提供......功能，你们会用吗？”
3. 如果直接的问题用户想不到答案，可以进行情景引导，“你最近一次做......是什么时候？”，“那个时候是......感受或情况”
4. 把“为什么要......？”变成“为什么不要......？”等等。
生活中跟别人交流时，也可以适当转变思路，换一种说法可能会更高效的达到目的。
2.2 需求的分析与转化
让我印象最深刻的一句话是“用心听，但不要照着做”，“用心听”是和用户建立连接，推已及人的基础，充分的听用户怎么说，获取信息，帮助下一步的判断，“不要照着做”是指首先要经过对用户意图的理解，再给出权衡过的解决方案，而不是用户说什么，我们就无脑的做什么。
不管是用户或是其他需求方阐述需求，或是其他任何交流的场景，都可以从三个层次由浅入深来剖析理解：
观点与行为，目标与动机，价值观与人性。
观点与行为：即听他怎么说，并看他怎么做。就像乔布斯说，“消费者并不知道自己需要什么，直到我们拿出自己的产品，他们就发现，这是我要的东西”。再比如，用户要一份数据，我们假定了他会是用法A，但从实际行为来看，大部分用户确是用法B，那么我们就可以根据用法B，提供一个更便捷的功能。
目标与动机：通过行为了解或进一步分析用户的目的，结合团队或公司的目标，说不定能发现更好的方案。用户可能不清楚我们拥有的资源或限制，只有明确了最终的目标，和用户站在同一出发点，以结果为导向，才可能设计更贴心的功能。
价值观与人性：有些需求，多问几个为什么，最终总会挖掘到人性和价值观层面，不论种族、国家、甚至时代，人们最根本的需要是不变的。现在的市场越来越细分，人们的需求也从“多快好省”越来越往高层级的价值感，责任感，仪式感等等发展，产品或功能需要抓住本质的东西赢得用户和市场。
不仅是产品经理对用户，产品经理对接其他需求方，或是开发人员对接产品经理，都需要能透过现象看本质，有同理心和耐心。比如开发人员，不应该仅仅是实现需求文档上的内容，对于整个功能的背景要有了解，首先为什么要有这个功能？都要达到什么目的？能解决多少人的问题？怎么评估带来的价值？在实现过程中，一些分支流程和异常该怎么处理？开发人员应该主动思考并协助产品经理共同产出解决方案。
不论是在工作中还是在生活中，相信大多数人都不想做没有感情的编码机器或无脑的执行者，多想一下前因后果，以结果为导向，再加上一些人文情怀，会使自己的思维越来越缜密，行事越来越高效，与自己和这个世界相处越来越融洽。
3. 功能价值的评估
无论从资源还是目标的角度，团队都希望用最小的成本获取最大的收益，所以众多功能中，必然有性价比和优先级的比较，对照产品的目标以及商业目标，某个功能对哪些指标有提升作用，或作用多大，决定这个功能的价值。
有以下几个方面来评估一个功能的价值：
1. 广度：预计覆盖的用户数*单用户价值
潜在用户数和单用户价值要综合考虑，因为往往这两个因素不是正相关的。
2. 频度：需求的频次*单次的复杂度*单价
3. 紧急程度：一些突发事件的应急措施等
4. 可替代性：能否用现有类似的解决方案替代，或者说它是否够独特，能和现有方案互相补充
要分辨出哪些是基础功能，即必须要有的，比如电饭煲，必须要有煮饭功能；哪些是亮点功能，即用户一般不会要求，但是如果有了用户会很惊喜的功能。随着时间的推移，功能的分类可能会有变化，比如之前的亮点功能变成了基础功能。
在产品的不同生命周期，不同类别的功能比例是有变化的，比如在初期要优先做基础功能，成熟期资源丰富了之后，可以考虑做亮点功能。
低成本验证是一个高效的，筛选和验证功能价值的方法。原则是采用较小的投入，验证需求和市场，进而再做下一步决断。
除了功能性的需求，在设计和实现功能的时候同样要考虑非功能性的需求比如安全性、可扩展性、可移植性、可复用性，以及性能上的考量，QPS、吞吐量等。
4. 立项与研发
想清楚做什么了，接下来是立项组队与研发投产，产品经理要组建团队争取资源，即获得人力和物力的支持。在整个研发过程中，除了关注各项任务的进度，更要关注团队成员的个人成长，根据每个人的能力和兴趣，灵活调整，颇有挑战的任务和正向的反馈，会使团队成员在日常工作中获得更多成就感和价值感。有时候也要承担“程序员鼓励师”的角色，使团队更有凝聚力。
在研发的主场，产品经理会进一步规划下一阶段的方向和任务，确保在下一阶段的研发开始前，需求分析和功能描述已经清晰的在文档中。记得大学里一门课的老师，对文档要求十分之严格，从项目背景，市场调研到需求分析、可行性研究、概要设计和详细设计，再到测试，项目没有做出来没有关系，文档必须完整详细。在生产环境中，有时做不到文档的面面俱到，尤其是敏捷流程又提出“可用的软件，重于详细的文档”，但是在很多大厂，PRD（产品需求文档）并没有被废弃，因为PRD中会记录一个需求或功能的前世今生，使开发团队和其他团队在对背景和目标的理解上完全一致，避免了误解歧义以及日后的争论不休和返工。PRD里都要记录什么呢？
1. 这个功能是为了解决用户的什么需求
对一个功能来说，他可以解决的问题可能有多个，不同的人理解可能有偏差，在文档中把需求痛点和上下文清晰的记录下来，让大家都站在同一个出发点，会省去以后很多对问题的争论。同时也应该写明论证这个需求确实存在的依据，可以给后续的效果追踪提供依据。
2. 这个功能成功的指标是什么
在上线一个功能之后，会有对使用情况或实际解决问题情况的追踪，对覆盖人数，或召回人数等的对比和测试，来验证这个功能是否是有积极作用的。如果上了一个功能，反而导致效率或一些指标下降，那要重新评估该功能的合理性。
3. 这个功能的使用场景和流程
不同的使用场景可能有不同的流程，流程图是一个功能DNA里最重要的部分，针对每个场景画出流程图，可以清晰的给每位团队成员展示该功能的定义，开发人员根据流程去设计代码，也能够方便地发现可复用的模块。
4. 功能达不到预期的解决方案
可能有一些异常数据或者异常的使用流程，可能要找一些替代的解决方案或者友好的提示用户。提高产品的容错性和健壮性。
产品经理最好有技术背景，尤其是在评估工作量的时候更及时准确，与开发人员合作时可以保持语境一致，降低沟通成本。在设计demo和功能阶段要和设计师密切配合，优化流程和体验。
5. 营销与市场
营销是把产品推向市场的重要手段，在产品推广前，需要在市场调查阶段，对所定位市场的占有率，饱和度等有所了解，确定盈利模式，以及后续的利益分配。
杰弗里·摩尔在高科技产品领域的技术采用生命周期理论对其他很多产品依然有重要参考价值，在产品的生命周期中，用户被分为创新者，即喜欢冒险和尝试新鲜事物的发烧友、早期使用者，即较早使用产品的种子用户、早期大众，即在产品推广一段时间之后愿意尝试的人、晚期大众，即产品占领了大部分市场后开始使用的人、和落后者，即对新事物没有热情，或不大愿意改变的人，其中前两个阶段被分为早期市场，后三个是主流市场。
在同一个市场中的用户差距较小，调整运营策略即可，最大的鸿沟来自于从早期的小部分用户进入主流市场，要在主流市场中找到一个切入点或细分的空白市场，结合公司的战略和目标，集中火力，再逐渐扩大范围。
我的理解中，参考以上产品生命周期，用户的生命周期也可以大致分为：成长期，活跃期，静默期，衰退期。
成长期：刚刚成为产品的新用户，在探索发现阶段
活跃期：使用频率，在线时长等达到了一个合适的阈值
静默期：相当长的一段时间内没有与产品互动
衰退期：根据过去一段时间内的历史数据，一些指标呈下降趋势
不同的产品对用户的生命周期的定义不一样，要根据实际的数据来不断调整，比如静默多久算处在静默期，在静默期的用户怎么判断是否已经流失，或许要对某些case采集一些标签，对整体的预判才会更准确。是属于拉新、促活还是留存，针对不同生命周期的用户有不同的运营策略。
最后
产品经理还最好有一些市场敏感度和创新意识，一定程度拒绝“存在即合理”。有“秒变新手”的态度和成为“专家”的能力。
无论当下是什么title，在什么岗位，做什么事情，我们都有多重角色，应该有多个视角，忠于内心，保持天真，创造价值和意义。路漫漫其修远兮，吾将上下而求索。
参考
1. 《人人都是产品经理2.0》.苏杰.电子工业出版社.2017-5
2. 《Software Requirements, 3rd Edition》.Karl Wiegers, Joy Beatty.2013-8
