结合我自己的经历，我把原因总结为两方面。
另一方面是你只是略读一遍，像看新闻一样，没有深入理解其中的精华，在实践的时候也没有运用上。
本文的主要内容是初级产品经理工作过程中各环节的技巧总结，我写的时候尽量是从现有工作内容中抽离，没有涉及到我的具体业务，因此不同细分领域的产品经理都可以通用。
为了区分什么是技巧、技能、能力，我这里做了如下定义：
技巧：是为了快速提升技能的手段，是技能的一部分，是可以学习复制的技能：是具体的、全面的，是为了做好一项工作而需要具备的内容，是可以学习复制的能力：是技能内化后的结果，是举一反三的驱动力，很难复制，需要靠自己总结提炼
由此可见，要提升产品能力，可以先从学习技巧开始，再掌握全面的技能，最后提炼出通用的能力，如此循序渐进。
本文主要内容：
初级产品经理必备素质需求收集和过滤产品方案设计项目管理沟通技巧方法论建设一、初级产品经理必备素质
处在职场的不同阶段，聚焦点是不一样的。作为初级产品经理，需要明确自己的定位和目标，练好基本功，切勿好高骛远。
1.清晰的自我定位
初级产品经理一般完整的负责一个功能模块或一个系统，首先，需要对自己负责的模块充分的熟悉然后了如指掌，让所有需要跟这个功能对接的人知道，有问题只要找你就解决了，这也是逐步建立影响力的过程；
其次，熟悉了模块之后，再深入思考该模块不同竞品做的怎么样，自己产品所在哪个档次，距离最好的产品差距有多少，如何基于公司的业务提高该模块的竞争力；
最后，在掌握了自己负责的内容后，以点带面，不断完善加深对公司产品和业务的理解，才能获得更多机会承担更重大的项目。
以上三个过程是一个递进的关系，也是初级产品经理在不同工作阶段的不同定位。
2.明确的工作目标
二、需求收集和过滤1.需求池管理
产品经理对需求的管理就像厨师对食材的管理，厨师在众多食材中挑选合理的组合，加工成美味，产品经理在众多业务方提出的需求中进行组合设计，加工成产品功能。
好的需求池管理不仅是对需求进行过滤，也是对工作内容的精细化记录和总结，有利于有条不紊的项目管理和后期的复盘。我将对需求池的管理内容总结为三大部分：
判断并记录需求的真伪、重要性、紧急度、实现难度、业务价值、关联方记录当前每个需求的项目实现状态追踪需求实现后的用户及数据反馈情况
至于需求池的表格模板，我认为每个人的实际需求和习惯不同，也没有必要照搬别人的，只要覆盖了以上三大块内容，起到了需求池管理的作用即可。
2.优先级判断
优先级判断属于洞察决策层面的高级能力，不是工作技巧，它的变量太多，需要多方权衡，比如业务重要程度、紧急程度、工作量、性价比、是否匹配系统当前所处的阶段、对系统的影响大小，甚至领导强势程度等等，不同行业不同公司情况，用一套模型和公式是无法解决的。
我这里想强调的是，不必拘泥于具体的判断方法和公式，而是一开始就养成对自己需求池进行优先级判断的习惯，也许一开始判断的结果并不准确，会踩过一些坑，但随着对业务和行业的逐渐熟悉，判断会越来越准确。
所以我建议忘掉别人总结的公式，建立自己的判断标准，并不断调整优化这个标准。
三、产品方案设计
凡是属于用户可见可操作界面的部分为前端设计，不可见的逻辑及系统设计则为后端设计。
1.前端页面设计
交互设计领域人机交互大师雅各布·尼尔森博士，在1995年提出的尼尔森十大可用性原则，对二十多年后今天的互联网产品设计仍然影响深远。
对于软件类着重页面设计的互联网产品来说，我提炼了其中4点：
（1）简单易理解
包括了文案的简洁明了、功能玩法的易理解，在单个页面内减少过多不必要的信息。
（2）操作有反馈
当用户进行某个操作后，以合理的形式向用户反馈目前的状态，可能会发生什么。
（3）操作可回退
用户走的每一条路都不能是死胡同，应该都能让他回到原点。
（4）功能一致性
不同位置的相同功能保持一致，保证了产品设计统一，用户更易学习。
前端设计我只总结了以上4点，比较适用于产品原型的交互设计，但却是任何一个优秀的产品必不可少的核心设计原则。
2.后端产品设计
后端设计的细节太多，没法像前端设计原则一样进行高度归纳，我这里也是根据自己大大小小的项目经验逐条进行总结，内容不够系统，可以当做几个关键点设计的参考。
（1）MECE原则，相互独立，完全穷尽
这个基本原则相信每个产品经理都知道，它是一个能让产品方案条理有序、不遗漏、不重复的重要标准。我这里主要强调一下它具体体现在了什么方面。
产品方案对标业务需求：
我们假设这里的业务需求都是相对合理的需要实现的。那设计的产品方案需要对应满足这些业务需求，不能遗漏任何一个，同时也不能让产品方案内部出现重叠的功能，而是刚好完美的满足了业务需求，也使开发的系统内部达到软件工程上的最优解，这就叫满足MECE原则。
需求文档的书写：
（2）强化对状态的认知
对于一个后台系统，状态无处不在，灵活多变的业务需求是靠一张张数据库的表在记录的，除了业务数据的记录，状态是非常重要的基础。
订单必须有状态，用于区分不同业务环节；一个上线的活动必须要有状态，是进行中、已暂停、还是已下线；一个员工账号也要有状态，是启用中、禁用中还是已注销。
设计一个功能或系统通常需要先绘制流程图，而流程图中一个个状态的连接支撑起了整个功能设计的骨架，然后才是具体细节的设计。
如何正确的强化对状态的认知和理解，我大概总结以下几点：
状态的独立互斥：
这点与上面说的唯一判断字段有点类似，但实际不是一回事。因为状态是用于描述不同业务节点的，每个状态要与实际业务的关键节点进行一一对应，状态之间不能出现二义性，否则会出现多个状态对应同一个业务关键节点，不但会造成理解混淆，还可能使系统做具体判断时出问题。
这点其实也很好理解，一个具体业务的发展是有阶段性的，而状态就是在每个阶段取一个值，各个值连接起来就串联的业务，但如果状态的值取在各个阶段的临界点，这就很不好描述业务了。
比如一个运营活动，可以用“进行中”和“已下线”两个状态来区分发生和不发生两个阶段，这是合理的，但如果状态叫做“下线中”，这就不是处在一个稳定的状态，而像一个瞬时态，到底是上线还是下线，我们从状态命名中就感觉很模糊。
注意子状态和组合状态：
当业务相当复杂时，一个状态下面还可以设置子状态，比如单据的撤销状态，可以包括用户主动撤销、系统撤销、人工撤销，用于区分具体是怎么被撤销的。
而组合状态的意思是在用户侧展示的状态不单是订单表里存的状态名称，而是一个组合状态，比如在用户侧显示“已发货”，其实包含了订单状态为“创建成功”、支付状态为“已付款”、物流状态为“已出库”。
像比较复杂的保险订单状态，还会包含订单状态、支付状态、续保状态等，因此不能用一维的线性的来看待状态。
状态机的流转路线：
状态机图的确定，基本确定了系统和功能主体结构，各状态之间的起点终点、流转路线、判断条件决定了功能的玩法和限制，状态机图是梳理并对照实际业务的必备工具。
合理的状态有利于数据统计：
当状态的设计都按照上述原则进行，状态与状态之间非常清晰，这对数据统计是非常有益的，因为很多的数据统计都强依赖对状态的定义，如果你在做数据统计的时候发现很难准确的提需求，或者发现无法按照业务需要的维度来进行统计，可以反思下系统的状态是否合理。
3.预留拓展性逻辑
我之前经常遇到一种情况，当我做一个功能上线之后，业务方有时会再提一个与这个非常类似的需求，有时候仅仅只是改动很少的内容。
如果在第一次设计时并没有预留可能的拓展性，就算只是很少的改动，还是要排期开发和测试，特别是有的功能还需回归测试，非常浪费开发资源，而且影响迭代速度。
这时就考验在设计之初能否大概看出可能有的拓展性，在开发工作量几乎不变的情况下预留一些类似的逻辑，这样会非常便于类似功能的迭代。
举个例子，对于一个人工审核的结论页，有多种状态，每种状态下结论页的不同模块的元素、文案、以及对用户的触达文案，都是首次开发时配置好的。
首次开发时业务方提出有三种状态，上线之后业务方说要再加一种特殊的状态，如果事先在状态机中预留了待定的状态，只需要把该待定状态下页面的元素、文案、对用户的触达进行设置即可，改动的工作量很小，可以快速的上线。
不过值得注意的一点是，在预留拓展性时尽量保证首次开发的工作量影响很小，如果为了暂时使用不到的预留需求消耗过多开发资源，就有点本末倒置了。
最好的针对复制一份代码、预留一个状态这种相似功能进行考虑。
4.对变量的抽象
对变量的抽象是一种模块化思维，能够减少很多重复的工作量，提高后期的开发效率，我将分成两种情况来描述。
一种是当多个页面都用到同一个内容时，该内容应该被抽象为公共变量，供各页面调用。
比如一个常用联系人组件包含姓名、证件类型、证件号码、性别、出生日期这五要素，那么可以把这五要素设置成一个公共变量模块，在不同产品下单需要用到时直接调用即可。
如果有的产品下单时只需要用到姓名、证件类型、证件号码三要素，则可以把五要素的变量模块拆细为五个变量元素，这样可以达到最大自由度的组合。
另一种情况是两个页面绝大部分内容相同，只有几个元素有差异时，这几个有差异的元素应该抽象为配置变量，做成一个配置文件或者管理后台，这样在调整该配置时就不用再写代码。
有的同学可能对配置文件不太懂，它可以理解为一段未被编译器编译的配置代码，是对一个软件运行时状态的本地储存形式，可以实现对软件灵活的实时调整。
5.时刻考虑系统的灵活性
讲完两种基本的变量抽象方式，我再讲讲整个系统的灵活性。
如果你想修改一个banner图，必须要找前端开发从代码层面帮你换图，然后再发布，这时我们认为这个页面是非常不灵活的。
因此你把banner、标签、价格、尺码分类等等都抽象成了配置变量，就可以在管理后台灵活的调整这些内容，无需再发布，看起来非常灵活了。
但是当这个页面需要对不同商家显示不同商品时，你就需要再把这整个页面做成配置项，对每一个商家可以单独配置一套商品详情页。
接下来业务需求再进一步演化，每个商家想要自己去配置自己的商品详情页，这时你还需要把商品详情页的配置功能做成一个商家管理后台，让商家自己去灵活设置，这时候单是这个商品详情页就已经很复杂了。
如果每个商家还要对自己的员工分别配置权限，有的员工只能修改banner图和名称，有的员工可以修改商品sku、价格等等，那你还需要把这个商家的商品详情页配置功能结合账号权限再细分配置，让商家自己灵活勾选什么员工可以操作什么权限。
我这里只是简单的描述了一下电商平台商品详情页的配置演化路径，就可以看出，当业务需求越来越细化，对系统灵活性的要求就越来越高，也意味着系统的复杂程度越来越高。
为了尽可能充分的满足业务需求，我们需要时刻注意系统的灵活性，在每一版迭代的时候避免太多写死的逻辑。
6.总结遇到的异常流
每做一个项目，在上线之后可能都会遇到反馈的线上问题，特别是一些在设计时考虑不全的异常逻辑，会在用户真正使用的时候暴露出来。
做完项目遇到这种情况并不可怕，因为人无完人，产品经理不是神，设计之初漏掉一些异常流是很正常的，但如果每次项目都漏掉一些，或者同样的异常问题多次出现，这就是产品经理的问题了。
我们可以认为，在业务拓展没那么快的情况下，软件层面的设计的异常流是很有限的，只要遇到一个就把它解决掉，总会消灭干净的。
四、项目管理
项目管理之前应该先判断该项目的类型，不同的项目推进和管理的方式区别很大，根据项目大小与任务并行程度，我分为以下三类：
1.周期较长的大项目管理
对于单个部门内部开发周期较长的项目（超过2周），我总结有以下项目管理的关键点：
（1）提前沟通开发方案
一般较大项目功能比较复杂，因此整体方案设计时需要预先跟开发人员沟通，明确一些关键限制因素和影响点，避免需求评审时方案不可行，或者调整太大，在评审会上难以达成一致。
（3）对项目的强推动力
每日跟进关键点的结果，尽早发现风险（日报、周报、晨会等形式）。
（4）项目复盘总结
项目完成后回顾项目过程中哪些过程效率有待提高、哪些过程安排的不够合理，如何避免在下一个项目中继续出现。
2.跨部门跨公司合作的项目管理
（1）找到合作关键点
不管是跨部门还是跨公司合作，首先要明确对双方的关键利益点，并强调合作对对方的好处，才能获得对方的积极支持，否则很容易被踢皮球。
（2）书面确认详细事项
这一点主要是为了提高需求的确定性，明确双方职责，避免因为沟通没有记录影响项目开发进度。
3.多个小项目并行的项目管理
对于互联网的敏捷开发模式，超过两三周的大项目少有，多个小项目并行才是更常见的状态，这里的小项目其实是单个很明确的需求，粒度比较小，这种状态下产品经理一周可能同时在跟进十多个需求在开发状态，这对多项目并行的考验很大，我总结了以下几点：
（1）更合理的排期节奏
由于项目太多，为了避免同一天过多需求同时在开发或者在测试，在排期的时候尽量均匀的分布，这样保证在一些需求已经进入测试或已发布，另外的项目刚进入开发，避免某一天的事情太多。
（2）每日tips跟进每个项目的状态
（3）小需求归档
小需求上线一时爽，后期维护痛苦不已。每个小需求在开发过程中是独立的，但对于整个产品来说它是一个个的迭代，只有及时将这些迭代归档到对应的功能模块，才能后续方便的了解查询当前线上的产品规则是怎样的。否则后期连自己都忘了到底最新的迭代是什么，这个坑谁踩过谁就知道有多苦。
五、沟通技巧
与项目管理类似，沟通之前我们要对沟通的对象进行分类，不同沟通对象需要注意的事项是不一样的。
1.与合作方沟通
（1）沟通方式的合理选择
（2）催进度也有技巧
有依赖合作方确认的事项或开发进度时，催进度是最频繁的事。但是催进度需要包含几个关键因素才能起到好的效果。
首先是良好的态度，对对方的尊称是必须的，就算对方态度比较冷淡也需要保持着热脸贴冷屁股的热情，因为在工作中，合作的顺利完成才是最重要的，这也是职场人的必备素质。
正确的方式是“请问某某负责人，针对这个三点事项（一一列举），您可以在今天下午5点之前确认吗，麻烦您了”。
再次是要找对关键人确认，比如你一直跟对方的一个开发人员催进度没什么用，需要直接找到对方的产品或项目负责人，甚至是对方领导。
2.与需求方沟通
（1）搞清需求方的本质诉求
需求方可能是运营、销售、客服，他们会根据自己当前遇到的问题直接跟产品经理提需求。
大家都知道快马和汽车的故事，需求方需要一匹快马，我们是直接按他说的给他快马，还是思考他提出这个需求的本质诉求是什么，能否转化成另一个需求，是否还有更合理的解决方案？
如果来一个需求就做一个，缺乏对需求背后的思考，这不叫产品经理，叫需求实现师。
（2）明确产品和需求方的边界
当与需求方长期合作时，需要形成一个良好的沟通模式，明确各自的职责范围和边界。
比如与运营合作上线一个项目，哪些内容是运营需要明确的，哪些内容是产品可以有施展空间的，这个过程中，产品不能随意修改运营确认的规则，但也不能放任需求的不断变化，不能让运营直接干涉产品系统层面的影响。
优雅的把握好边界，相互尊重彼此的工作内容，能够减少很多扯皮，让合作效率更高。
3.与开发沟通
对于初级产品经理偏重于项目执行，日常沟通的对象最多的一定是开发人员，如果沟通太少，要么是你需求文档完美无缺（几乎不可能），要么是你不够主动。
（1）跟开发大佬和开发小弟沟通的区别
开发大佬就是某条线的技术负责人，在有重大功能迭代的时候，可能会需要先跟他对方案。
开发小弟就是除了大佬之外的开发同学，与他们沟通的核心技巧是要建立利益共同体，因为他们是具体做需求的人，你需要把需求的背景、实现后的价值讲给他们，以及上线之后的效果也要多同步给他们，提高他们的自豪感。
开发小弟也需要成功的项目来体现自己的价值，让他们感受到你们是一条线上，他们也会尽心尽力帮助把系统做的更好，开发过程中改点小需求也就不在话下了。
当然，这些技巧是要建立在需求文档质量合格的前提下。
（2）预期管理
产品立项时、项目开发过程中，对开发人员的预期管理是很有必要的。
这些都是实际的情况与开发人员预期情况产生较大不一致造成的。因此一些关键的事项，需要跟开发人员预期保持一致，我主要总结以下几点：
项目目标和价值：
比如一个非常重要的项目，需要在2周内上线，预计可以获取新增用户10万个，这些明确的项目目标和价值需要在立项时及时同步给开发人员，有时候你的重视程度会影响开发的投入程度。
风险和备用方案：
项目可能产生的风险和备用解决办法，在立项时也应该跟开发同学保持同步，一些外部的不可控因素可能会产生什么影响。
比如一个项目可能临时更换合作方这种突发事项，提前同步可以让大家心里都有底，不至于发生时产生太多不利于合作的情绪。
（3）跟开发的工作氛围建设
除了工作中，工作之余与开发同学经常一起玩，开开玩笑，建立良好的工作氛围和私人关系也很有必要，会让工作的合作效率更高。
也许一个小需求对于关系一般太严肃的开发来说需要排期才能处理，但关系融洽的开发可能随手就帮你解决了。
六、方法论建设1.建立自己的能力模型
2.注重思维方式的迭代
根据我个人建立的产品能力模型，相比于各种经验技巧方法论，我认为最底层的是思维方式，优秀的思维方式可以让你在面对不同工作内容时举一反三。
而产品经理到底要具备哪些思维方式？
本文由@拾二原创发布于人人都是产品经理。未经许可，禁止转载。