昨天我们系统的聊了 如何识别那些注定要失败的产品 ，今天我们再来聊聊产品经理这个话题。一位智能硬件的产品经理，在和我谈论起他的老板和他沟通的关于产品工作的时候，说他的老板要求他多去跑市场，要深入一线了解用户的需求和未来市场的发展趋势和方向，要策划未来一段时期内的产品路径，各个阶段的产品应该如何切入市场，如何保持与竞争对手的优势。
作为一个产品经理，主要的工作职责不是在意这些文档、进度方面的工作，不要把主要精力放在各种细节性的讨论上。
于是，他跑了很多市场，找了很多的材料，和市场、销售部门的同事一起规划了很多的产品线，定义了面向不同细分市场的产品型号，满怀热情的期望这些产品能一举占领市场。
但在把产品推向市场的过程中，爆发出很多问题，常常发现有些产品功能做出来和他的初衷有很大的偏差。产品开发团队也总是抱怨产品需求不清晰，部分功能不是重叠就是开发难度太大，常常发生各种变更。产品上市以后，品质、客服的同事则投诉处理不完的投诉，和无法追溯的产品指南。
这位产品经理迷惑了，他的工作内容应该包括哪些方面，是产品的定义和策划，还是包括整个产品的各种功能说明，交互逻辑以及整个开发、测试和上线后的一系列工作？到底哪些事情产品经理可以决策，比如一个功能的交互设计，谁真正具有决策权？
很多产品经理可能都经历过类似的场景，产品总是很难如期上线，上线了又没法保证不出问题，他们身兼数职忙碌于各种需求处理各方面的问题，却经常换来上下游的诸多抱怨：
- 运营说：他们的需求不是被你拒绝就是被拖延；
- 开发说：他们不是赶你的需求，就是改你的需求；
- 老板说：不是听你说资源不够，就是上线要延期。
那么到底是什么导致了这些状况，你是否曾亲历这些陷阱？
01、只能画原型的产品经理
产品经理这个看起来很高大上的头衔，曾经有人说他是CEO的预科班，但现实中的产品经理则自嘲为打杂的原型仔。
和想象中不太一样的情况是，多数情况下的产品经理，当被授权一个项目的时候，事实上已经是被老板们“圈定在某一个具体的项目”中，并且是被明确要求在一定的时期内，利用有限的资源把原型画出来，把产品做出来。
至于对产品的前因和后果以及诸多环节往往难以参与度并不多，更谈不上发挥所谓的专业影响力。
这个时候的产品经理，思考如何把“项目落地”变成了唯一的工作。至于广义上的产品成功，已经超过了它职责和权限的范围，极容易出现一种产品（经理）与市场、用户脱节的现象。
这种现实情况，导致很多产品经理拿到需求的第一直接就是打开axure软件，开始画原型，写需求，并逐渐形成了工作惯性。
也使得很多产品经理越发觉得自己的本质工作就是打开axure，所以他们花了很多精力来研究怎么用axure画出最漂亮的高保真原型，甚至一部分产品经理认为，他们的工作就是这样，一旦超过被要求超出axure之外的工作，这份工作就超出了产品经理的职责范围。
我不知道，这是否应该算是从业者们的悲哀。
但是真正的产品经理从来不是原型仔。
任何产品从最开始的一个想法，再到需求痛点的分析挖掘，产品定位和架构设计，以及具体的交互逻辑设计，在这个漫长的从0到1的过程中，需要产品经理具备过硬的基本功和良好的产品sense，同时还需要强大的协调、组织能力，使团队形成统一的合力才能真正把产品落地。
在这个过程中，我们所谓的“专业技能”的比重实际上没有想象中那么大，需要解决的问题远超传统意义上的需求分析和PRD文档，这些工作只是确保产品落地过程中的必要条件，多数情况下都不是关键过程。
真正的产品经理，也许不是产品的发起者，但他必须深刻理解发起这个产品的前因后果，产品的商业模式和企业的战略目标。
他必须能有效的找准产品的定位和切入点，深刻的理解目标用户，和未来的发展方向和布局，必须要能与真正发起人达成深刻的一致性理解，这种理解来自于产品经理本身向上的管理，也来自于发起人的向下沟通与授权。
产品经理必须担负起设计者和推动者的角色，深度的参与和主导产品的实施方案，甚至能准确的把握每一个体验性细节，但又不至于深陷于过度设计的泥潭。
他在组织中起到衔接供、给的双方的作用，推动和管理整个产品全生命周期的各项事务。作为供、需之间桥梁，产品经理必须要能够疏通整个“供应（价值）链”的关系，通过恰当的措施确保各个环节的信息质量，并最终实现用户的价值体现，以及企业目标与用户目标的平衡。
画原型，写文档，只是完成产品落地过程的一环，而不是全部，希望所有产品经理能够勇敢的突破这一“专业边界”，找到更广阔的发挥空间。
02、充当“传声筒”的产品经理
我们首先来回顾一下产品经理的日常工作流程。
一般情况下都是承接上游（业务方或者直接领导甚至老板）提过来的需求，然后整理输出一份需求文档或者原型图，再分发到下游的设计、开发和测试工程师，进行各项被拆解后的工作任务，当这个功能或者产品被开发出来经过测试验收以后，就可以交给销售或运营人员实现企业的利润转变。
这个过程，当把各方面的流程理顺以后，像极了生产线的流水作业，产品经理在整个流水作业过程中努力的传递工作任务，做完一个功能接着下一个功能，和生产线组装一个产品没有什么本质上的差异。
也正是因为这样，产品经理的工作很容易被形容为“传声筒”，把上游想要实现的功能，写成一份文档，交给工程师开发成一个功能。
可能有些情况下，接到上游的业务需求后需要先做一个方案汇报和评审，但总的过程几无二致。
原本在需求落地的过程中，很多工作本身并没有那么复杂，但随着这个“传声筒”的尴尬定位出现，造成了很多不必要的沟通成本。产品经理与业务方由原本的协作共赢变成了甲乙方的“业务外包”，事情开始变得复杂。
定位的不同，带来情绪的改变。业务方越发的想要坚持自己一线业务专家的“解决方案”，产品经理则试图从技术、成本、进度、体验、流程等多方面的角度来佐证产品方案最优解的可行性。
产品经理仿佛夹心饼干一样，对上游协调方案，对下游下调进度。
满足于传声筒的危害是显而易见的，想象一下福特汽车的故事，如果只是依照用户说的去做，可能就没有福特的出现。
事实上，用户并不是不知道他们想要的是什么，而是在他们没有找到更好的方案之前，固执的认为过去的经验是最佳的实践，从而拒绝改变，拒绝接受门外汉的产品经理所提供的方案，他们不愿意尝试是因为产品经理们还没有能够证明如何能够摘掉传声筒的帽子。
传声筒遭遇的第二个质疑和挑战来自技术团队。
通常来说，业务方提出的任何方案，他们只会考虑自身的要求，他们没有意愿去权衡方案给其他业务部门带来的影响，更没有能力去上从整体业务系统的实现角度考虑，为了满足这个要求要付出的成本。
这就导致，他们的方案看上去很不错，但实现起来很困难，甚至可能需要整个系统大改造。
所以，一味的听从用户和业务方的需求（特别是老板的要求），没有弄清楚用户真正的意图，很可能投入了巨大的开发成本，但结果并没有让业务方感觉到满意，白白浪费了公司的成本和资源，尤其对于小公司这样的损失是非常严重的。
所以，说“NO”的能力，是产品经理自我突破的关键过程。
只有当你能够对功能需求说“NO”，对市场机会说“NO”，你才能够真正定义正确的产品，才能使产品的立项更准确，也才能够以结构化的工作流程，来推动上下游的有序推进，保障产品的市场竞争力。
03、被老板替代的产品经理
这种情况普遍存在于初创企业，或者传统企业的转型过程。老板们通常觉得自己有一个很好的点子，配上几个程序员，就可以把一个产品轻松的拉上线，不需要产品经理是他们的信条。
这也是为什么我们常能见到一些企业，聊起用户和市场时口若悬河，当你加盟后真正开展产品工作时，发现既没有规划，也没有原型，一切都是口口相传，需求基本靠“吼”，剩下的就靠工程师自行脑补。
然后随着创业的进程，各项工作的陆续开展，老板们发现他们需要更专业的人，用更专业的途径把他们心中的蓝图真正推动起来，转化为可见的实际产品，这个时候，产品经理会成为解决一切问题的神人，简直天神下凡一般的什么活都能做，似乎什么事情都懂。
我一个朋友，就刚刚进入一家这样的公司。
他的老板似乎什么事情都想拉着他讨论一番，不管是研发的周期，还是运营活动的策划，还是销售的招投标方案，他的工作也变成了随时需要停下来和老板探讨各种产品方向性问题。
这位朋友时刻都感受到来自老板内心由衷的重视，老板的所有宏图、大坑小坑都希望这个产品经理能一股脑的摆平搞定，带着满身的兴奋，期待着我这位朋友给他解决掉战略规划、产品设计、项目管理、运营策划、质量监控等等几乎所有问题。
这就是坊间流传的“用CEO的标准招了一个产品经理”，也是很多人所说的产品经理是CEO的预科班的原因。
结局其实也在预料当中。
在经过一段时期的蜜月期间后，老板发现他的期望根本不匹配。产品经理后悔入错坑，老板后悔看错人，四目相对无语诉衷肠。
我们需要承认一个现实。多数情况下，产品经理都不太可能是决定公司生死的那种人，因为所有的企业本质都是业务所驱动的，越是熟悉业务的人，越具有主导权，当然越是离钱近的人，越容易有话语权。
我们去研究BAT等所有大企业，我们就能发现一个公司的所有资源和运作模式都是为了优化企业的业务而设计的，越熟悉业务的岗位越容易做出精准判断和决策。这个人，对创业型的团队来说，无疑只有作为创始人的老板。
所以，很多产品经理们的工作不幸就变成了打杂、监工，很多的产品需求就是老板的需求，产品经理的日常就变成了与老板、与业务部门斗智斗勇的连续剧。
实际上，产品是解决用户问题的一个方案和工具，对企业来说，它是企业经营过程中的一项重大，需要一个一个合理有序的规划，也需要一个逐步完善的过程。
当老板们能够理性的看待产品诞生的过程，能够意识到伟大的产品从来不是灵光闪现就可以降临人世，产品经理的工作就能够开始条理化和规范化。
不是人人都可以轻轻松松的成为产品经理，更不是每个点子都可以简简单单的成为伟大的产品。
产品经理这个角色不应该被过度的解读，成则人人捧若神明，败则如过街老鼠人人喊打，这不是一种理性的态度。
对产品经理来说，不断提升自己的境界，不断了解老板的思维方式，将成为优秀产品经理们最重要的能力。
作为产品经理的你，需要掌握如何轻松的和老板沟通的技巧和经营，既要让老板参与到产品开发的过程中，又要控制老板可能对产品产生的伤害。
04、“四面楚歌”的产品经理
以“CEO预科班”或自诩或自嘲的产品经理们，试图用肩负对整个产品生命周期的责任来推动各项的工作落地前进，他们对努力确保所有计划都能够如期甚至超乎预期的达成充满了自豪，为用户提供高价值的产品和体验，是产品经理的工作核心驱动。
这种强烈的目标感在带来的荣誉感的同时，也带来了巨大的压力。他们似乎像刺猬一样，挑战着各方的规则，业务上他们总想敦促改善流程，技术上不满足现有技术所达到的体验和品质感。
他们甚至在某些拿不住足够可信的数据面前，挑战既有的规则，试图从单纯的用户角度入手来解决用户的问题，有些时候他们甚至完全不顾为此付出的成本。
这种不管不顾的工作方式极大的冲击了现有的业务体系，造成了上下游的极大震撼。继而引发不满和冲突。一旦最终的成果低于预期时，则挑起冲突的产品经理往往显然万劫不复的境地。
这些冲突包括产品本身的设计问题、工程师的能力问题、项目的总体资源问题、上下游的权责利益问题以及不对等的认知问题（有些人把反人性的狗血认为杰出的设计，有些人把抽象的逻辑视为最终的产品成功并以此规划资源），所以我们常遇到简单与复杂的设计冲突、快速与缓慢的进度冲突，以及成本冲突，利益冲突等等局面。
相对来说，产品经理（或者说有一定的从业经验之后）都会形成一套自己的思维体系和产品理念，或多或少会形成自己的产品价值观，对用户需求和市场反馈也形成了一定的判断标准。
可能某些需求和改进，作为产品经理也深度思考过，之所以现在还没有做，是因为在整个迭代计划里，还有更重要的需求要处理。但是，产品经理经常难以和业务方描述清楚支持整套系统的后端服务逻辑以及巨大的投入成本，因为在业务方甚至BOSS们看来，“这个需求很简单”。
产品经理还需要经常花费很多的功夫说服技术端甚至设计师们，按照产品的思路和要求完成产品的设计和开发。
自从“人人都是产品经理”流行起来后，似乎谁都可以套用“我是从用户的角度”的说辞对产品提出多或少的看法和意见，不管什么意见，只要加上“用户体验”四个字作为前缀，好像就合理得不得了。
实际上，“用户体验”往往会变成“我的体验”，也就是根据自己的经历、认知来判断“用户”的使用体验。
这种“信息的不对称”，导致的迭代计划与业务出现偏差，项目计划与业务部门的期望有冲突，需求的价值系数与商业目标存在偏差。
不仅如此，产品经理来将面临着另外一个重大考验，那就是来自组织设定的目标与提供的资源和信息之间的不匹配。
几乎每一个组织都是想做的项目很多，可用的资源总是不够。但产品经理很少能直接控制为达成目标的必备资源。
产品经理的最大压力，就在于他们要向老板（投资者）争取到人力、物力等资源来实现一个未知的梦想。
产品是一项高度依赖他人、依赖特定资源共同完成目标的工作，不管是用户的研究，需求的挖掘和业务流程的梳理，还是视角效果的呈现、技术的具体实现和质量的保障，从来都不能只是个人的努力工作就可以达成。
产品经理就像小马过河一样，在没有淌过这条河之前，你永远不知道哪里是陷阱，哪里会碰壁，而且当你再次踏入一条河流的时候，你又将再次面对同样的未知世界。
作为产品经理不但要在专业技能上提供优秀的解决方案，还需要很好的协同跨组织、跨专业的工作，以保障项目的落地。推动他人共同完成工作成为了一项非常考验各种软实力的职场技能，用管理的术语来说，个人的职责经常和权力不完全匹配，组织也很少能提供与责任相一致的正式权威，特别是在传统的职能化组织。
产品经理们需要通过一次又一次的任务达成来建立自己的影响力和权威，来推动各项工作的进行。 任何创造性的活动本就伴随着枯燥艰苦的劳动，当我们还需要在压力和噪音的环境中，权衡来自各方的利益，协调他人的工作，这种焦躁的情绪与日俱增，由此很容易带来一系列的问题，“冲突”伴随我们的日常。
让接触到产品的所有相关方，理解并认同产品的每一个迭代逻辑、产品目标，以及为此消耗的资源成本（特别是隐形成本必须高度被关注），是展示一个产品经理功底的关键时刻。除去专业的技能之外，你可能还需要足够的耐心和耐力，以及圆润的技巧。
如何打造一个符合产品特性的组织环境，成为产品经理的一项高阶技能，这不但涉及到合理的产品开发流程，也涉及到如何匹配恰当的资源，也包括老板们的雄心和见识，它们最终都统一体现为组织的产品文化。
