一個互聯網產品團隊，核心角色是產品、運營、研發、UI/交互。這四者之間的關系分兩種：
需求提出方和滿足方的關系，比如產品向研發和設計師提需求，運營向產品提需求。產品和運營就是需求提出方，研發和設計師就是滿足方。
相互依賴和配合的關系，比如產品和運營。這兩個角色想要做好自己的工作，就必須與對方持續、緊密的配合，缺了誰也不行。
但是在產品和運營協同工作的過程中，會出現很多復雜又難以解決的問題，分別舉例如下：
運營認為，產品不重視運營，但運營卻要為產品背負責任：
為什么PM做功能從來不和我們討論，他們懂用戶需求嗎，懂行業嗎？功能上線后用戶罵聲一片，就讓運營出來安撫一下、解釋一下，其實就是擦屁股。
好容易有幾個版本的效果好，PM就在群里郵件里開心的寫著效果評估。其實那是因為運營的核心用戶在挺我們啊，是我們為新版策劃了活動啊，功勞都是PM的了？
為什么運營提的需求總是優先級最低的？提一個需求還按必須給什么效果預估，沒上線怎么預估，這不是形式主義忽悠人嗎？
產品認為，運營總是沒起到應有的作用：
運營什么時候才能不盯著KPI做活動，數據倒是上去了，怎么不看看留存呢？就知道有獎送禮什么的，把產品搞的烏煙瘴氣，一點氛圍都沒有。
為什么運營就不能具備一些基本的產品思維，別再提那些不著邊際的需求了，這和用戶直接反饋有什么區別，害得我們還要花時間去解釋為什么不做。
我們需要的是爆點，不是小打小鬧。運營你說你懂行業朋友多，那就多請一些大腕來活躍啊，幫著傳播推廣啊。
以上描述雖極端，但很有代表性，相信很多公司的產品和運營同學都有過類似感受。因此，讓這兩個角色配合默契、有序運轉、形成合力，并不容易。下面就聊聊產品和運營這亦敵亦友的關系。
原因是什么
產品和運營配合出現問題的根本原因是：兩者目標不一致，導致從出發點到具體執行都是兩條平行線，不能擰成一股繩，就無法形成合力。由此可見，將產品和運營的目標統一，是解決這個問題的核心點。
為什么會存在目標不一致的現象呢，因為屁股決定腦袋。從組織架構的角度說，很多公司的產品和運營分屬兩個團隊，由兩位不同的老大負責。
既然團隊和老大都是兩個，那么目標肯定也是兩個，否則就無法衡量這兩個老大和兩個團隊的價值。比如，兩個人炒一盤菜，一人負責切，一人負責炒，那色香味俱全是誰的功勞，味如嚼蠟誰又是幕后黑手，就很難分辨了。如果兩個人互相推脫責任，就進入到扯皮階段了，很難根治。
一般在團隊分工時，都會避免工作內容和目標有重合，保證團隊或個人的獨立性。這樣做的目的是保證員工的個人發展空間，也便于清晰的衡量工作產出，暴露所存在的問題。
綜上可知，因為團隊分工的問題，導致了產品和運營的目標不統一。除此之外，兩個團隊的架構，還會帶來其他負面效應。比如兩個老大為了爭奪話語權，出現對峙的情況。這種狀態的起因是私利，而非工作，勢必會影響到決策的合理性，最終影響產品的進展。
如何解決
說到這里，想起自己在百度的經歷。第一年時，產品和運營是分開的兩個獨立團隊，原因見上文。雖然整體上還算正常，但也會出現各自為戰的情況，運營做活動、核心用戶和內容策劃；PM為了不斷提升轉化等數據，做著各種產品優化。單獨看任何一方的工作都是正常合理的，但兩邊同時來看就能發現交集和協作很少。
第二年時，為了孵化獨立的新項目，優化了團隊架構，每個新項目都成立獨立團隊，每個團隊都有一位PM作為負責人。雖然每個團隊都不到十個人，但所需角色都有，比如產品、運營、研發、設計，麻雀雖小五臟俱全。
在這個小團隊里，雖然每位成員分工不同，但關注的目標是一樣的，只是大家通過完成自己的任務去達成這個目標。比如，
運營在運營種子用戶、建立對外合作、準備預熱活動等
PM在優化操作流程、提升流量轉化率
研發保證按照需求和時間點完成開發任務，并且盡量少出BUG
UI設計師力求頁面效果不僅滿足PM的功能需求，也符合運營的預期調性
不僅如此，在每天的晨會（站會，10分鐘）和每周的例會（1個小時）里，大家會拋開自己的分工，一起加入產品的討論。雖然經常會有不靠譜的建議，但這才像一個團隊。
但這個模式也有缺點，就是只適合5-20人的小團隊。如果人數增加到30人，就肯定行不通了。原因是：
首先，一個老大直線管理這么多人的成本和難度很高，溝通和信息互通也不會那么通暢。如果老大和員工之間再增設一個層級，變成金字塔式架構，就更復雜了。
其次，如果是30人的團隊，那么產品和運營的人數也會增多，比如各5個，這就意味著產品和運營分別成立了二級團隊。獨立的小團隊變成大團隊，又會出現上文中所說的目標不統一，各自為戰的情況。
所以，如果可以拆分成小團隊，或者本是小團隊的公司，可以嘗試上述的方案。一旦團隊規模變大，就不再適用了，這也是業內都很羨慕團隊「小而美」的原因吧。
當然，大團隊也不是無解，可以通過扁平化的團隊架構，來緩解產品和運營配合不好的問題。比如一個總監同時管理產品和運營團隊，這兩個團隊分別有1個經理級中層，再各帶一個小團隊。這樣的三層團隊設置，從層級上來講是可以接受的，承擔30人的團隊也是沒問題的。
誰更有話語權
說起產品和運營的關系，就不得不說話語權的問題。這兩者一定會存在強勢和弱勢的關系，不可能有一碗水端平的狀態，只是強弱差或大或小而已。當然，誰都希望能主導項目，但是有時候并非是自己能左右的。
決定一個團隊是產品驅動還是運營驅動，有兩個因素：
團隊基因。團隊基因主要是創始人團隊帶來的，所以基本等同于創始人基因。從一個公司，到一個小團隊，這個規律都適用。
所以，要看一個團隊是什么角色來驅動，主要看老大。如果老大是PM出身，公司很有可能是產品驅動；如果是技術出身，那么運營的角色一定是很弱勢，不被重視。因為技術人員一般不重視也不懂運營，兩個角色實在是離得太遠。
產品屬性。通俗的說，就是看是什么產品了，不同類型的產品就是適合不同的團隊架構，也決定了角色之間的話語權。
一個工具型產品，肯定是產品驅動的，比如天氣、筆記、拍照類app，即使渠道的作用很大，但也不會成為驅動方；一個O2O產品，肯定是運營驅動，比如團購、到家類app。
所以，如果要看一個團隊里哪個角色更有話語權，哪個角色是主導地位，就從上面兩個因素中就可以看出。
該怎么配合
團隊架構就說到這，那么產品和運營應該怎么配合，才是合理的，是可以發揮雙方合力的。我認為，分為產品上線前和上線后兩個階段。當然，可能沒有這樣純粹的階段，但有這樣的狀態。
上線前：
第一步：產品的功能規劃以及發展方向，都是老板的決策。在決策完成之后，應該告知團隊全員，項目的背景、方向和規劃，讓大家充分了解信息，對于后續執行的過程是有幫助的。
第二步：之后執行環節的規劃，就是產品和運營協同工作的開始。比如，受眾人群、功能特點、版本節奏、運營規劃等，應該雙方一起參與討論，得出一個大概的框架和計劃。
第三步：按照框架計劃，大家開始分頭行動。產品去畫原型，定功能細節；運營做準備內容、流量渠道和核心用戶，以及策劃上線后的爆點。在這個階段，產品和運營可以暫時分離開，不必有頻繁的協作。但由于有了前兩步的鋪墊，在分頭行動的過程中，雙方也了解對方的計劃和進展，所以信息是互通的。
第四步：上線前的準備階段，之前分頭行動的產品和運營的雙方，就要再次回到一起，交出之前的作業。也就是大家為產品上線所做的準備，進展、遇到問題和后續計劃是什么，拿出來互通和討論。問題都解決后，就可以上線了。
上線后：
進入到產品正式運轉階段，產品和運營再次結合在一起協同工作。在這個階段需要高頻次的溝通，以及互相推動彼此的工作。
運營，主要關注用戶反饋。
在做好內容、用戶、活動、渠道等運營工作的同時，向產品及時和詳盡的通報用戶反饋，讓團隊了解用戶對產品的反應。
關注用戶需求，轉化為產品需求，推進PM上線。
提出可以大幅提升運營效率的工具需求，推進PM用產品的方式解決。
產品，協助運營的規劃和執行工作
除了修復BUG和完成產品需求之外，要關注運營的反饋，因為這是產品投入到用戶群體之后的反應，是印證之前決策的過程。
要關注運營遇到的問題，是否可以通過產品的方式解決。主動與運營同學溝通，給出解決方案并推動研發完成。
還需要關注運營措施是否合理，是否對產品的目標有推進作用。如果發現偏離目標，或者唯KPI的行為，要及時溝通并推動改進。
當然，在產品上線前后可不只是做這些事，上面只是提到需要產品和運營配合的節點。由于每個項目的情況都很復雜，所以上述事項肯定也不全，只能是作為一個思路，舉例說明。
為什么不少運營想轉PM
其實產品和運營的關系，描述起來非常簡單。產品負責功能設計，也是研發和設計師等支持滿足方的接口；運營負責維護、拉動和推廣，機器不能解決的問題，都需要運營來解決。
在我看來，產品和運營是兩類不同但平等的職位，所需人才的類型也是不同的。但為什么現在很多新人更愿意從事產品工作，甚至已經做運營的同學也希望轉做產品，主要是因為「產品經理被神話」而帶來的供求不平衡造成的。
主要原因是李開復、周鴻祎等明星Boss，都公開宣稱自己是產品經理，把這個職位的工作內容描述的過于理想化，這樣就吸引了更多優秀的年輕人投身到這個領域。另外，公司深受影響，更重視產品經理這樣的崗位，愿意花更高的薪水去請這樣的人才。
在這樣的供求關系帶動下，優秀的年輕人愿意加入，感覺職位高大上且薪水高；公司也愿意高價請人，認為產品經理重要，且只有高價才能請來。這就是有些運營人員希望轉做產品的原因。
其實，產品經理當然也要從基層做起，甚至從打雜做起。有很多PM已經從業一兩年了，還在團隊里打雜救火，或者做一些邊緣化的事，這都是很正常的情況。
寫完了。
作者：韓敘
來源：運營狗工作日記
本文由作者@韓敘 授權APP干貨鋪子轉載發布，未經原作者同意，請勿轉載。
相關推薦閱讀（鏈接）：好運營要會貼標簽！
APP干貨鋪子官網：www.appganhuo.com
