产品经理模式之弊论

　　产品与技术人员在合作中，因为思维方式与视角不同，本身便存在着可能造成问题与矛盾的地方。
　　但实际上，除非遇到非常糟糕的，不善交流并不善站在对方角度考虑的产品与技术方，一般的产品与技术相处还是很融洽的。尤其是当产品方是漂亮妹子，技术方是技术宅男，两者之间更多的情况是水乳交融（起码我当下在的团队是这样哈）。
　　本文观点是，产品与技术分离的团队体系架构、完全由产品驱动的任务推进方式，本身可能导致问题，需要身处其中的人警醒，需要团队的负责人明了。
　　产品与技术的职能分离，是行业发展的必然结果。原因一是业务难度逐渐增加，从业人员期望专注于部分职能，从而提高效率；另外则因为个人能力的单一化，一般人并未受到过两个专业领域的训练。产品与技术所需要的能力与思维方式有相当大的差异，所以理所当然，对产品与技术进行了拆分。
　　所以，诸多互联网公司形成了这样的模式。产品方告诉技术方，应该怎样改进产品，技术与产品沟通具体的解决方案。技术方进行解决方案的实现，产品验证效果，如此迭代。绝大多数情况，这样的拆分的确有利于团队竞争力的提高。然而，职能划分的副作用在很多情况也比较明显，其中核心问题在于部分创新能力的缺失，我总结为如下几种：
　　1，技术革新型创新：
　　假设当年福特雇佣了一个产品经理，让他确定用户关于出行的需求，他能得到什么呢？他拿得到的，可能只是一辆跑得快外表拉风的马车需求而已。产品无法考虑到“汽车”这个概念，这个概念的创始人必须为技术人员。
　　为什么呢？
　　我们一直说，技术应该以产品的思维去考虑问题，但是产品则不合适通过技术的视角考虑问题。但是在高科技领域，在技术革新的阶段，产品形态的创新首先需要技术壁垒的攻克，所以产品思路与技术几乎完全融合在一起。根本性的技术革新，甚至由此带动的产业整体革新是必然是由具备创新能力与意识的工程人员推动的。所以，无技术基础的产品人员，更加适合推动技术架构与思路已基本确定的产品微创新与表层创新。
　　2，高技术深度产品改进创新，或者说以逻辑思维为主导的产品改进创新：
　　一般而言，产品的思维更多是柔性的，感性的，而技术的思维更多是理性的，逻辑的。然而，很多产品的某些方面，理性与逻辑思维占据主导。产品方容易看到表象，但是无法分析深入，无法看到内在，我以“搜索引擎排序”这项工作为例。
　　例如，产品容易提出，排在第一个的重要性比第二个大，第二个比第三个大。但是，并不能奢望产品独立的提出DCG与NDCG模型。产品容易提出，你所关注好友喜欢的东西，往往你也喜欢，但绝不能奢望产品提出UserItem推荐模型。产品方可以提出Case，制订初步的测评策略（甚至这项工作，也应该由技术方主导），但是，如果要让产品放提出具体的排序权重计算方案，那几乎是不可能的。
　　产品方，本身便不应该承担这样的职责。虽然从职能划分上，这些更偏重是产品方的工作。负责排序改进的技术人员，必须通过产品反应的表层现象与基础思路，不停深化，看到深入的用户需求，看到背后的问题。如果在这些问题的解决方案上，被产品主导，不主动思考，就容易被表象赶着走，始终无法为系统带来实质性提高。这实质是技术方的失职。
　　另外，搜索引擎排序等效果改进工作。是一个细化排序因素，并根据不同情况，归并排序因素的过程，是一个自底向上的过程。从完善排序因素到呈现在用户体验，周期很长，类似于垒塔，一步步走坚实才有好的最终效果。完全由产品主导，意味着过分的结果导向，会很容易打破这个过程，导致基础不牢，所以在这个过程中，需要两方折中，甚至说，更需要技术主导。
　　3，产品架构、技术架构创新：
　　产品方往往生存在工作流程的起点与终点。工作由产品推动，并由产品验证。然而，真正跟产品、UED、运维、测试等所有环节都进行接触，并深入了解系统架构的，更多的是技术方。所以，体系架构、技术架构上的创新，也必须由技术推动。多数互联网公司，工程人员在这些方面的创新多数都被良好的鼓励与支持。
　　4，商业模式等架构策略颠覆式创新，全局创新：
　　周鸿祎说，如果要想做一个新产品，要试试看，能否让“付费的不付费”，让“封闭的变开放”等等，有架构层策略层创新，才能跟巨头有得玩。但是，在中国恐怕从未有一个产品经理能够主导这样的创新，如果一个产品经理敢提出“将付费转化为不付费模式”，恐怕不会受到上司支持，更不用说真正实行。马斯洛需求模型告诉我们，人都有惰性，都害怕，都首先需要安全感，才敢大胆实现自己的价值。很多创新必须要免除KPI压力，必须要具备即使失败也不被责难的权利，才敢于被实施。何况多数产品经理，顶多只有产品经理内部的调配权，对于运维、BD都没有多少话语权。如何进行此类创新？
　　这些问题严重不？在浪潮汹涌的互联网大势下，创新能力是企业非常重要的核心竞争力，而上述几类的创新，都是非常重要的创新形式，往往可以决定一个产品线甚至一个公司的发展。
　　那么如何解决？
　　第一个思路是，颠覆产品经理架构方式。一般而言，互联网公司已经不会采用惠普、微软等巨型公司的流程控制模式，所以，可以取而代之的方式一般有如下几种：
　　1，老板模式：即，老板推动创新，推动部分工作进行。典型的例子是360的一系列商业模式策略颠覆创新。360的很多成功都是源自于此。但老板模式的弊端在于，“老板牛则牛，老板熊则熊”，反正“老板说这么干”，那就这么干。除了老周等奇葩式牛人，中国互联网采用老板模式成功的也不多，因为老板，往往太忙。而在中国，“产品经理模式”可以视为“老板模式”的“缩水增强”版，即资源缩水，权力缩水、自主性缩水、胆量缩水、全局观缩水而时间投入增强、对产品线的熟悉增强。
　　2，工程师模式：即，工程师主导创新，主导工作进行。典型的成功范例不在中国，而遥远的大洋彼岸：谷歌与脸书。这两个公司的巨大成功很大程度上得益于此。他们的工程师对产品有比产品经理更大的主导权利，产品经理说服不了工程师的，工程师可以不干。这种方式不仅可以吸引到最优秀的工程师，并且也极大的发挥了工程师的潜能。但是，这是一种典型的精英IT文化，需要从业者不仅具备极高的专业能力（专且博），也要具备极高的自主管理、思考、创新的能力。在中国的当下，除了极少数人，多数都达不到。
　　第二个思路是，维持产品经理模式，辅之于工程师模式与老板模式。即，“制度往往是死的，但是人是活的”：
　　1，培养工程师产品意识，努力跨界：工程师并不要被职能束缚，工程师与产品经理，本身并存在着很多共性，存在着转化的可能。我一直认为，很多数学模型与系统架构不过是产品思想从抽象到具体的映射。例如有了“买了同样一个东西的人可能买其它东西”这样的思想，才有了UserCF、ItemCF这些协同过滤方法，又有了，“热门物品不具备太强代表性”这样的思想，才有了改进的UserIIF与IUF模型。这些模型与思考都不是产品经理提出的，所以，技术人员要大胆拓宽自己的能力，多从产品层面考虑；
　　2，几类创新形式，不要由产品牵头：上面提到的13类创新形式，牵头者一定要有产品与技术两头的深度把握，一般不可由产品主导。不然“老实巴交的”，“听话”的技术同学容易被带到沟里；
　　3，老板参与并主导模式创新：策略类创新，只有老板与大管理者可以干；
　　4，鼓励工程师自主创新：鼓励工程师自主创新，需要实际的东西，实际的东西是什么，大家都懂。
　　注：本文为《架构之争，体制之惑》系列文章的第一篇，作者王小科笑笑
　　VIA：虎嗅网