产品经理的定义比较多，当下语境中产品经理一般是互联网大厂中做项目规划的人员，定义扩大化泛指it系统开发对接需求并转换成开发要求的人员。故事听起来很有意思，感觉像是在创造产品甚至创造世界的一部分，实际上一半是理解世界，一半是借助时势造就产品。找朋友要了几个推荐的产品经理相关的书籍，自己顺便买了几个比较常见的，慢慢悠悠看完了感觉好像也没看明白个啥，但还是想把读后的想法理理思路汇总成文章。
产品经理有很多定义，这些定义涵盖了产品经理的工作内容，大部分的定义都源引早期的产品市场经理，与it软件开发并没有直接关系，然后发展到软件产品经理再到互联网产品经理，产品经理的概念逐渐被绑定。回归产品经理的本源，实际上是对一项产品的负责，包括了功能性的部分，也包括市场性的部分，通过功能性的产品属性实现市场性的产品价值。在传统市场产品、传统软件it领域和互联网的产品属性，可以看到产品经理本身在业态中的生态位置。
产品的形态定义了产品经理的职能范围，传统产品对应的是很具体的功能以及具体物理产品的市场活动，虽然可以进一步把市场职位和产品职位在市场marketing这部分进行区分，但对于讨论产品经理的变迁起点这样逻辑起点已经足够。产品随着社会发展，一些产品成为非具体物理产品，产生出了it软件这种产品形态，产品经理进一步的与商品的物理属性抽离，抽象出了需求提出与需求确认的工作内容，而市场部分则从产品经理的范围内好像被拿走了。在超大型软件项目中，早期以功能开发为主，做的大而全，只有在最近十年产生软件即服务的saas概念后，传统软件领域的产品经理才又一次涵盖了更多的市场属性。产品经理的最终形态，被当前互联网产品经理角色重新定义，俞军老师的书中给出了一些解释。当互联网产品经理又一次直面市场需求并对需求负责的时候，it产品经理的定义逐渐与产品市场经理回归一致。至此，所有的产品经理同源发展而出，最终回归了相似的公司组织架构中的定位。
it产品经理只有在it公司是产品经理，在非it公司更多的是it产品经理。这句话可能一眼看不明白，这也是一些行业内扯淡的事情扯出来的，某一个集团公司的业务部门表示产品经理的定位或者title名称只能是业务部门对应岗位使用，而it部门的产品经理不能叫“产品经理”只能叫“it产品经理”。这种情况并不是很少见，在业务层面无论是tob、toc还是tog业务，无论是对内还是对外提供系统服务，都有可能存在这种现象，业务部门越强势越会把需求的决策权收于业务，这样it产品经理就被压缩成了项目经理。
一个正常的产品经理，应该有需求的提出和需求确认的权利，应该有实现需求相配套的资源调用的权利，延展而出的是对于需求对应的业务提升的责任，然后才是所谓的业务理解和需求规划。这样反过来确认的产品经理的定位，可以看出一个真正的产品经理，即使是一个很差的产品经理，也是具有产品经理属性而不是由产品经理工作内容和技术需求而确认的。在大型非互联网公司中，业务导向比较明显，业务部门是承担了市场的责任进而获得了产品规划的权利，可以进行需求的提出与需求的确认，一般it项目开发预算支出也是由业务部门进行承担，自有人力资源使用通过内部协商，项目外包和人力外包通过预算资源都可以有效扩充。
互联网产品经理是时代的产物，it产品经理也是。产品经理可能是个体力活而不一定需要技术，产品经理可以参与世界的创造但是大部分产品经理并没有那么伟大的工作意义。对于个人而言，在产品经理这条路上选择去哪里做什么产品经理，远比在一个不需要产品经理公司做好产品经理工作要重要，当然安心做好体力活也是另一种个人选择。
MECE，是Mutually Exclusive Collectively Exhaustive，不重不漏是个基础的分析原则，在很多地方都有提及。在产品经理的各种材料中，给出了很多框架，最常见的是基于人口学特征的分析框架，区分男女老少受教水平什么的。这类的方法，看来看去就像一个checklist的任务清单，如果有一个针对性的就方便一点，如果没有对问题有针对性清单就不重不漏的都考虑一遍也行。不重不漏的分析强调遍历可能性空间，但是可能性空间不是自我显现的，只有不断提升生活经验才可以更好的扩展可能性空间。o'o'o
对于复杂的问题分析，需要进一步提升认知能力，对于多元的影响分析对个人的要求还是蛮高的。很多人都在讨论自己驾驭不了的复杂问题，现实生活中简单的二元问题和线性逻辑能讨论明白的都很少。早年间有个老师推荐了一套书《Handbook of labor economic》，里边就讲了很多分析的故事，比如教育和收入关系，个人能力导致前两者关系系数被高估，怎么通过分析方法对个人能力导致的bias进行剥离等等。当时没好好看，也就看了这么一篇完整的内容，印象深刻，这个问题研究逐步深化，原有研究没有注意到的其他问题也更多的被挖掘出来，促进了分析进一步完善的发展。阅读这类行为和现象的研究，都会促进分析能力的提升。
姑且把产品经理的技能归为硬技能和软技能，其中硬技能是技术类，软技能是抽象理解认知力之类的东西。界面设计，ui交互设计，原型图制作都可以划分到硬技能中，其中一部分类似于工具使用可以学习掌握，另一部分归于审美的东西有时候也没什么办法提升。软技能更多是提升业务理解的部分，包括流程图梳理和ab-test设计等等。
产品经理有时候对于界面和交互的需求非常弱。作为一个6年名义上的产品经理，除了打开过墨刀别人的东西自己就没用过原型图软件。唯一参与的设计，是一个弹窗，用ppt在原软件上截图上插进去一个文本框。并不是觉得这样是应该的，但是有些名义上的产品经理确实没什么设计要求，或者他们看你也没啥设计能力这部分就分流出去了。
流程图真的是很有意思，做着做着业务逻辑就梳理清楚了，不过我也没做多少。这玩应是做么也能做，做的清晰明了好看有点麻烦，也有点难。一旦接受了丑了吧唧也能接受，就可以痛痛快快的开始搞流程图了。再进一步的思维导图对于产品逻辑来说帮助不大，如果是非标准化的图看习惯了流程图会做得花里胡哨的。
灰度测试是连接已知和未知的桥梁。建立在经验总结上的可测试假设，通过测试数据进行分析给出结论，可以是复杂的模型也可以是简单的统计结果。据说某大厂有上百人所谓的经济学家团队，就是搞计量分析的。也有反对的声音认为归纳不应该绝对占领主导，演绎分析应该占有它该有的地位，深度的理解和一些抽象分析不是简单的数据驱动结论可以代替的。虽然不直接相关，对于数据分析的讨论可以参考哈耶克的《知识的僭越》。
敏捷是最近非常火的概念，主要是因为产品经理对应的it产品开发，所以天然与敏捷讨论分不开。敏捷体系中包括了devop的相关东西，也包括了敏捷思维和看板工具，如果再进一步也可以包括okr的拆分与对齐，甚至包括了okr对应的工作流理解。现代的产品经理天然是具有数据反馈交互优势的，不像早期的产品经理由于数据的可获得性不理想，没有办法快速验证并进行产品调整。敏捷的一系列抽象指导思想因此天然契合在产品经理身上。不过当前很多时候，产品经理没有认识到这一点，敏捷更多的体现在项目经理进行项目管理的应用之中。
大部分的产品经理材料，讲述的都是产品经理在本职上的晋升路径，只有《产品方法论》跳出了一般产品经理的逻辑讨论不同产品阶段和形态对于产品经理的匹配，以及更多的延展讨论。当代的产品经理更多的是接住了时代的红利，伴随着新的互联网产品形态共同成长，大量基础的产品经理作者并非那么开创性的工作，也获得了相当不错的物质回报。
对于一个真正有长期规划的产品经理，选择一个适合产品经理的产业方向，是个具有较好成长空间的生态环境，比个人的努力更加重要，毕竟顺风顺水躺赢比靠自己靠谱多了。能够挑选出长期发展空间量化的产品经理，真正能够有能力对于行业有这样把握的产品经理，这样的行业理解也已经是产业级水平，用来驾驭具体产品难度不大。
大部分的产品经理没有能力超越具体项目和从业行业，有目的的选择自己成长的方向，更多的还是看运气。一个普通产品经理的第一份工作导致的成长路径定向，行业的薪资空间有限，产业的成长瓶颈明显，不考虑个人的水平上限的情况下，有太多条件制约了一个产品经理成为一个优秀的产品经理。这也是大部分产品本身的原因，毕竟大部分的产品本身也是普普通通的产品，产品经理不能超越当前的产品束缚进行跨越式的折腾，后期的成长空间大概率被当前产品锁定。
综上，产品经理的成长主要看运气，作为一个肄业产品经理近期阅读的一个总结。
reference
902 005 产品经理手册 很多案例细节，没仔细看，讲了很多营销推广
902 005 产品经理的设计思维- 以成果导向驱动产品创新的成功实践
902 005 产品思维 - 从新手到资深产品人 - 刘飞 有体系，可操作清单
902 005 决胜B端 - 产品经理的升级之路 待办清单，具体案例没看
902 005 幕后产品 - 达到突破是产品思维 有抽象讨论，讨论了高级产品经理的内容
902 005 人人都是产品经理 2.0 比较全面琐碎
此外，还有一些敏捷、看板相关的材料没有整理进来
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。