端午三天，一直和好基友混在一起，没事唠唠嗑。
说着说着，就讲到了开会这件事情上，接着就说到为什么开会期间一定要有领导坐镇，最后就讨论为什么产品经理进行需求评审的时候，自己总是不能一次拍板……
首先，他给我举了个例子：
营销科和教训科因为该谁出题而不断撕逼。起因是应公司领导安排，需要一个科室牵头出一套方案，给员工进行营销培训，结束后需要答题留存，问题就出在该谁出题上。
- 教训科认为：该培训是公司要求且有针对性的，而我们只管培训不管业务，营销科是市场一线，对每个理论了解十分清楚，熟知每条业务线，相对自己部门更加专业，因此，应该营销科出题。
- 而营销科认为：如果我们出题，还要你教训科有什么用。本身教训科就是主管员工培训，连这点知识都不懂，还怎么培训。如果我们出题，是不是还得我们批卷，你们就是给我们找麻烦添负担，而且我们本身业务繁重，根本没有时间来给你们出题。
这下来了，公说公有理婆说婆有理，两个科长丝毫不让，怎么办？
如果你是产品经理，现在在现场，如何处理？
哥们和我说，最后是老大在现场，听明白前因后果后，当场决定让教训科牵头，出一个人到营销科一边看人出题，一边学习理论，然后将试题拿回来，给学员培训用。
他说，这就是领导的作用：
不管对错与否，按照指示办事，即使是错的，也能快速知道原因，相比扯皮拉筋也是一种更优解。如果你们产品经理能比别人高半级，很多事情都能解决了。
反过来想：作为产品经理，需求场景不够明确，在特殊的情况下，我们是做还是不做？
如果真的认真讨论起来，还不是领导一句话的问题。
但是产品经理又能做什么，如何提高领导倾向性的决策？
回到我们这个话题上，我们产品经理经常会遇到这种类似的问题。如果产品经理遇到这个可做可不做的，技术觉得没啥用，而且实现又麻烦，或者是因为某些原因被迫砍掉一部分需求，又因为这个原因，变相弱化了其他需求，你该怎么办。
每个产品经理都想做正确的事，可是我们90%都是试，而且大多数的结果都是不理想的，不可能每个功能做出来都是用户喜欢的，所以最终总是要有人来决断一下，但又不可能每个细节都要领导来拍板，那只会显得你无能，因此，你得学会决断。
产品经理是需求的定义方，无论是对内还是对外，都是关键的一步。需求来源于场景，有场景就有问题核心，抓住了这个核心，实现方式就顺利而出
一、高人一等来自于你对问题有更深刻的理解
只有你懂了，才能让别人闭嘴；只有你通了，才能指点江山。因此，每当你决定做什么前，提前问问自己，这个是不是符合真实场景，核心问题是什么，你的解决方案是什么。
repeat：真实场景、核心问题、解决方案
当我们做完一遍的时候，基本上表层的问题就能解决，但是更深层次的问题，这些还是不够。不少同学，可能连第一步都无法走完，甚至连真实的场景都没搞清楚就开始设计功能。原因就不去深追究了，根本还是欠缺一些思考。
补充一下：场景是越挖越深的，越深越宽，呈倒三角的模式。每个阶段解决当前场景下的问题，不断积累，才能把一个功能做大做全。不要总想着，一口吃个胖子或事一劳永逸这些，场景调研和功能设计，总是相辅相成的。
接着，要不断问自己为什么，让别人问为什么。一个人的理解是有局限的，完善的意义就在于知道了你之前不知道的事情，所以你就知道的更多。
repeat：自己问自己、别人问自己
二、学会即时的决断
这点主要针对设计中的变通。比方说你做了功能，在开发的过程中，技术提出了另一种类似的方案，甚至提出了你之前没想到的点，甚至有更好的方案。
这时，应该考虑这样做的结果会是什么。如果在同样的情况下，不会造成用户理解负担，用技术认同的方案也是可以的。在多数情况下，我们做的功能，需要得到市场的验证，一旦实现后，我们要考虑能不能获得自己想要的结果。
妥协、调整、合作都是可选的解决方式。关键在于你怎么决断，如果一味的认为自己是正确的，结果打脸，别人也不会认同你。小问题，轻风险，能在接受范围之内，学会一定的变通，可以更好的解决对立的冲突。
再延展一下，当你看见了问题，第一时间指出、延后的指出、不去指出是一门项目管理中的学问，取决于你想达成自己的利益还是想实现项目整体乃至公司的利益。（不多说了，嘿嘿）
三、建立责任范围
我想，做作为产品经理最大的悲哀莫过于：该是自己做的的事情做不了吧。
曾经在一个会议上，领导询问该功能的设计初衷，结果一个设计师抢先回答了这个问题。产品经理还没来得及解释实际的场景，便收回了话语。我想，如果当时是我的话，会在人家说完后，重新补充一下实际场景和对接设计的初衷，至于最终结设计结果如何，可以转给领导来进行批断。
该是你做的，你一个也不能落。涉及到需求、设计、实现，需要你确定的前提，你必须得让每个人清楚的了解。你得让他人清楚你在这项工作中，扮演什么样的角色。
举个例子，在需求定义的时候，你就是定义的核心，其他人想要改，必须要经过你，擅自改动，你一定不能同意，甚至是黑脸打回拒绝；尤其是在项目后期，未经决策和批准，实现结果与预期不符，直接将问题记录，陈清利害，找相关负责人予以解决。
如果事实证明了自己需求定义和功能设计不够完善，那也要重新走一遍变更流程，并在项目中记录实际清咖滚，因为对方在项目中应该提前表明，而不是到了后期，板上钉钉的时候，才知会出来。
学会维护产品经理的职责范围，有助于让你建立更多的自信。做或不做，不再仅仅是因为一句话，而是有产品经理这个角色的协调，有产品经理的推动。这样才能让别人理解你，让别人更加相信你。
做个老好人，那还是初级的产品经理。
我看过的总监，那“怼人”真不是盖的，哈哈！！！