來源：王小科的部落格
產品與技術人員在合作中，因為思維方式與視角不同，本身便存在著可能造成問題與矛盾的地方。
實際上，除非遇到非常糟糕的，不善交流並不善站在對方角度考慮的產品與技術方，一般的產品與技術相處還是很融洽的。尤其是當產品方是漂亮妹子，技術方是技術宅男，兩者之間更多的情況是水乳交融（起碼我當下在的團隊是這樣哈^_^）。
本文觀點是，產品與技術分離的團隊體系架構、完全由產品驅動的任務推進方式，本身可能導致問題，需要身處其中的人警醒，需要團隊的負責人明瞭。我也在文中，略陳自己的解決方案。
產品與技術的職能分離，是行業發展的必然結果。原因一是業務難度逐漸增加，從業人員期望專注於部分職能，從而提高效率；另外則因為個人能力的單一化，一般人並未受到過兩個專業領域的訓練。產品與技術所需要的能力與思維方式有相當大的差異，所以理所當然，對產品與技術進行了拆分。
所以，諸多網際網路公司形成了這樣的模式。產品方告訴技術方，應該怎樣改進產品，技術與產品溝通具體的解決方案。技術方進行解決方案的實現，產品驗證效果，如此迭代。絕大多數情況，這樣的拆分的確有利於團隊競爭力的提高。然而，職能劃分的副作用在很多情況也比較明顯，其中核心問題在於部分創新能力的缺失，我總結為如下幾種：
1，技術革新型創新：
假設，如果當年，福特僱傭了一個產品經理，讓她確定使用者關於出行的需求，他能得到什麼呢？他拿得到的，可能只是一輛跑得快外表拉風的馬車需求而已。產品無法考慮到“汽車”這個概念，這個概念的創始人必須為技術人員。
為什麼呢？
我們一直說，技術應該以產品的思維去考慮問題，但是產品則不合適通過技術的視角考慮問題。但是在高科技領域，在技術革新的階段，產品形態的創新首先需要技術壁壘的攻克，所以產品思路與技術幾乎完全融合在一起。根本性的技術革新，甚至由此帶動的產業整體革新是必然是由具備創新能力與意識的工程人員推動的。所以，無技術基礎的產品人員，更加適合推動技術架構與思路已基本確定的產品微創新與表層創新。
2，高技術深度產品改進創新，或者說以邏輯思維為主導的產品改進創新：
一般而言，產品的思維更多是柔性的，感性的，而技術的思維更多是理性的，邏輯的。然而，很多產品的某些方面，理性與邏輯思維佔據主導。產品方容易看到表象，但是無法分析深入，無法看到內在，我以“搜尋引擎排序”這項工作為例。
例如，產品容易提出，排在第一個的重要性比第二個大，第二個比第三個大。但是，並不能奢望產品獨立的提出DCG與NDCG模型。產品容易提出，你所關注好友喜歡的東西，往往你也喜歡，但絕不能奢望產品提出UserItem推薦模型。產品方可以提出Case，制訂初步的測評策略（甚至這項工作，也應該由技術方主導），但是，如果要讓產品放提出具體的排序權重計算方案，那幾乎是不可能的。
產品方，本身便不應該承擔這樣的職責。雖然從職能劃分上，這些更偏重是產品方的工作。負責排序改進的技術人員，必須通過產品反應的表層現象與基礎思路，不停深化，看到深入的使用者需求，看到背後的問題。如果在這些問題的解決方案上，被產品主導，不主動思考，就容易被表象趕著走，始終無法為系統帶來實質性提高。這實質是技術方的失職。
另外，搜尋引擎排序等效果改進工作。是一個細化排序因素，並根據不同情況，歸併排序因素的過程，是一個自底向上的過程。從完善排序因素到呈現在使用者體驗，週期很長，類似於壘塔，一步步走堅實才有好的最終效果。完全由產品主導，意味著過分的結果導向，會很容易打破這個過程，導致基礎不牢，所以在這個過程中，需要兩方折中，甚至說，更需要技術主導。
3，產品架構、技術架構創新：
產品方往往生存在工作流程的起點與終點。工作由產品推動，並由產品驗證。然而，真正跟產品、UED、運維、測試等所有環節都進行接觸，並深入瞭解系統架構的，更多的是技術方。所以，體系架構、技術架構上的創新，也必須由技術推動。多數網際網路公司，工程人員在這些方面的創新多數都被良好的鼓勵與支援。
4，商業模式等架構策略顛覆式創新，全域性創新：
周鴻禕說，如果要想做一個新產品，要試試看，能否讓“付費的不付費”，讓“封閉的變開放”等等，有架構層策略層創新，才能跟巨頭有得玩。但是，在中國恐怕從未有一個產品經理能夠主導這樣的創新，如果一個產品經理敢提出“將付費轉化為不付費模式”，恐怕不會受到上司支援，更不用說真正實行。馬斯洛需求模型告訴我們，人都有惰性，都害怕，都首先需要安全感，才敢大膽實現自己的價值。很多創新必須要免除KPI壓力，必須要具備即使失敗也不被責難的權利，才敢於被實施。何況多數產品經理，頂多只有產品經理內部的調配權，對於運維、BD都沒有多少話語權。如何進行此類創新？
這些問題嚴重不？在浪潮洶湧的網際網路大勢下，創新能力是企業非常重要的核心競爭力，而上述幾類的創新，都是非常重要的創新形式，往往可以決定一個產品線甚至一個公司的發展。
那麼如何解決？
第一個思路是，顛覆產品經理架構方式。一般而言，網際網路公司已經不會採用惠普、微軟等巨型公司的流程控制模式，所以，可以取而代之的方式一般有如下幾種：
1， 老闆模式：即，老闆推動創新，推動部分工作進行。典型的例子是360的一系列商業模式策略顛覆創新。360的很多成功都是源自於此。但老闆模式的弊端在於，“老闆牛則牛，老闆熊則熊”，反正“老闆說這麼幹”，那就這麼幹。（有點類似於專制體制與民主體制哈）除了老周等奇葩式牛人，中國網際網路採用老闆模式成功的也不多，因為老闆，往往太忙。而在中國，“產品經理模式”可以視為“老闆模式”的“縮水增強”版，即資源縮水，權力縮水、自主性縮水、膽量縮水、全域性觀縮水而時間投入增強、對產品線的熟悉增強。
2， 工程師模式：即，工程師主導創新，主導工作進行。典型的成功範例不在中國，而遙遠的大洋彼岸：谷歌與臉書。這兩個公司的巨大成功很大程度上得益於此。他們的工程師對產品有比產品經理更大的主導權利，產品經理說服不了工程師的，工程師可以不幹。這種方式不僅可以吸引到最優秀的工程師，並且也極大的發揮了工程師的潛能。但是，這是一種典型的精英IT文化，需要從業者不僅具備極高的專業能力（專且博），也要具備極高的自主管理、思考、創新的能力。在中國的當下，除了極少數人，多數都達不到。
第二個思路是，維持產品經理模式，輔之於工程師模式與老闆模式。即，“制度往往是死的，但是人是活的”：
1， 培養工程師產品意識，努力跨界：工程師並不要被職能束縛，工程師與產品經理，本身並存在著很多共性，存在著轉化的可能。我一直認為，很多數學模型與系統架構不過是產品思想從抽象到具體的對映。例如有了“買了同樣一個東西的人可能買其它東西”這樣的思想，才有了UserCF、ItemCF這些協同過濾方法，又有了，“熱門物品不具備太強代表性”這樣的思想，才有了改進的UserIIF與IUF模型。這些模型與思考都不是產品經理提出的，所以，技術人員要大膽拓寬自己的能力，多從產品層面考慮；
2， 幾類創新形式，不要由產品牽頭：上面提到的1-3類創新形式，牽頭者一定要有產品與技術兩頭的深度把握，一般不可由產品主導。不然“老實巴交的”，“聽話”的技術同學容易被帶到溝裡；
3， 老闆參與並主導模式創新：策略類創新，只有老闆與大管理者可以幹；
4， 鼓勵工程師自主創新：鼓勵工程師自主創新，需要實際的東西，實際的東西是什麼，大家都懂。
OK，that’s all.