產品和運營這亦敵亦友的關系,是時候做一個了結了


          Warning: Invalid argument supplied for foreach() in /data/cxweb/www/gupowang.com/public/article/view.html on line 71
          8年前

          u=4206746374,2730583822&fm=21&gp=0.jpg

          來源 運營狗工作日記

          作者 韓敘

           

          一個互聯網產品團隊,核心角色是產品、運營、研發、UI/交互。這四者之間的關系分兩種:


          需求提出方和滿足方的關系,比如產品向研發和設計師提需求,運營向產品提需求。產品和運營就是需求提出方,研發和設計師就是滿足方。


          相互依賴和配合的關系,比如產品和運營。這兩個角色想要做好自己的工作,就必須與對方持續、緊密的配合,缺了誰也不行。


          但是在產品和運營協同工作的過程中,會出現很多復雜又難以解決的問題,分別舉例如下:


          運營認為,產品不重視運營,但運營卻要為產品背負責任:


          為什么PM做功能從來不和我們討論,他們懂用戶需求嗎,懂行業嗎?功能上線后用戶罵聲一片,就讓運營出來安撫一下、解釋一下,其實就是擦屁股。


          好容易有幾個版本的效果好,PM就在群里郵件里開心的寫著效果評估。其實那是因為運營的核心用戶在挺我們啊,是我們為新版策劃了活動啊,功勞都是PM的了?


          為什么運營提的需求總是優先級最低的?提一個需求還按必須給什么效果預估,沒上線怎么預估,這不是形式主義忽悠人嗎?


          產品認為,運營總是沒起到應有的作用:


          運營什么時候才能不盯著KPI做活動,數據倒是上去了,怎么不看看留存呢?就知道有獎送禮什么的,把產品搞的烏煙瘴氣,一點氛圍都沒有。


          為什么運營就不能具備一些基本的產品思維,別再提那些不著邊際的需求了,這和用戶直接反饋有什么區別,害得我們還要花時間去解釋為什么不做。


          我們需要的是爆點,不是小打小鬧。運營你說你懂行業朋友多,那就多請一些大腕來活躍啊,幫著傳播推廣啊。


          以上描述雖極端,但很有代表性,相信很多公司的產品和運營同學都有過類似感受。因此,讓這兩個角色配合默契、有序運轉、形成合力,并不容易。下面就聊聊產品和運營這亦敵亦友的關系。


          1.原因是什么


           

          產品和運營配合出現問題的根本原因是:兩者目標不一致,導致從出發點到具體執行都是兩條平行線,不能擰成一股繩,就無法形成合力。由此可見,將產品和運營的目標統一,是解決這個問題的核心點。


          為什么會存在目標不一致的現象呢,因為屁股決定腦袋。從組織架構的角度說,很多公司的產品和運營分屬兩個團隊,由兩位不同的老大負責。


          既然團隊和老大都是兩個,那么目標肯定也是兩個,否則就無法衡量這兩個老大和兩個團隊的價值。比如,兩個人炒一盤菜,一人負責切,一人負責炒,那色香味俱全是誰的功勞,味如嚼蠟誰又是幕后黑手,就很難分辨了。如果兩個人互相推脫責任,就進入到扯皮階段了,很難根治。


          一般在團隊分工時,都會避免工作內容和目標有重合,保證團隊或個人的獨立性。這樣做的目的是保證員工的個人發展空間,也便于清晰的衡量工作產出,暴露所存在的問題。


          綜上可知,因為團隊分工的問題,導致了產品和運營的目標不統一。除此之外,兩個團隊的架構,還會帶來其他負面效應。比如兩個老大為了爭奪話語權,出現對峙的情況。這種狀態的起因是私利,而非工作,勢必會影響到決策的合理性,最終影響產品的進展。


          2.如何解決


          說到這里,想起自己在百度的經歷。第一年時,產品和運營是分開的兩個獨立團隊,原因見上文。雖然整體上還算正常,但也會出現各自為戰的情況,運營做活動、核心用戶和內容策劃;PM為了不斷提升轉化等數據,做著各種產品優化。單獨看任何一方的工作都是正常合理的,但兩邊同時來看就能發現交集和協作很少。


          第二年時,為了孵化獨立的新項目,優化了團隊架構,每個新項目都成立獨立團隊,每個團隊都有一位PM作為負責人。雖然每個團隊都不到十個人,但所需角色都有,比如產品、運營、研發、設計,麻雀雖小五臟俱全。


          在這個小團隊里,雖然每位成員分工不同,但關注的目標是一樣的,只是大家通過完成自己的任務去達成這個目標。比如,


          運營在運營種子用戶、建立對外合作、準備預熱活動等


          PM在優化操作流程、提升流量轉化率


          研發保證按照需求和時間點完成開發任務,并且盡量少出BUG


          UI設計師力求頁面效果不僅滿足PM的功能需求,也符合運營的預期調性


          不僅如此,在每天的晨會(站會,10分鐘)和每周的例會(1個小時)里,大家會拋開自己的分工,一起加入產品的討論。雖然經常會有不靠譜的建議,但這才像一個團隊。


          但這個模式也有缺點,就是只適合5-20人的小團隊。如果人數增加到30人,就肯定行不通了。原因是:


          首先,一個老大直線管理這么多人的成本和難度很高,溝通和信息互通也不會那么通暢。如果老大和員工之間再增設一個層級,變成金字塔式架構,就更復雜了。


          其次,如果是30人的團隊,那么產品和運營的人數也會增多,比如各5個,這就意味著產品和運營分別成立了二級團隊。獨立的小團隊變成大團隊,又會出現上文中所說的目標不統一,各自為戰的情況。


          所以,如果可以拆分成小團隊,或者本是小團隊的公司,可以嘗試上述的方案。一旦團隊規模變大,就不再適用了,這也是業內都很羨慕團隊「小而美」的原因吧。


          當然,大團隊也不是無解,可以通過扁平化的團隊架構,來緩解產品和運營配合不好的問題。比如一個總監同時管理產品和運營團隊,這兩個團隊分別有1個經理級中層,再各帶一個小團隊。這樣的三層團隊設置,從層級上來講是可以接受的,承擔30人的團隊也是沒問題的。


          3.誰更有話語權


          說起產品和運營的關系,就不得不說話語權的問題。這兩者一定會存在強勢和弱勢的關系,不可能有一碗水端平的狀態,只是強弱差或大或小而已。當然,誰都希望能主導項目,但是有時候并非是自己能左右的。


          決定一個團隊是產品驅動還是運營驅動,有兩個因素:


          團隊基因。團隊基因主要是創始人團隊帶來的,所以基本等同于創始人基因。從一個公司,到一個小團隊,這個規律都適用。


          所以,要看一個團隊是什么角色來驅動,主要看老大。如果老大是PM出身,公司很有可能是產品驅動;如果是技術出身,那么運營的角色一定是很弱勢,不被重視。因為技術人員一般不重視也不懂運營,兩個角色實在是離得太遠。


          產品屬性。通俗的說,就是看是什么產品了,不同類型的產品就是適合不同的團隊架構,也決定了角色之間的話語權。


          一個工具型產品,肯定是產品驅動的,比如天氣、筆記、拍照類app,即使渠道的作用很大,但也不會成為驅動方;一個O2O產品,肯定是運營驅動,比如團購、到家類app。


          所以,如果要看一個團隊里哪個角色更有話語權,哪個角色是主導地位,就從上面兩個因素中就可以看出。


          4.該怎么配合


          團隊架構就說到這,那么產品和運營應該怎么配合,才是合理的,是可以發揮雙方合力的。我認為,分為產品上線前和上線后兩個階段。當然,可能沒有這樣純粹的階段,但有這樣的狀態。


          上線前:


          第一步:產品的功能規劃以及發展方向,都是老板的決策。在決策完成之后,應該告知團隊全員,項目的背景、方向和規劃,讓大家充分了解信息,對于后續執行的過程是有幫助的。


          第二步:之后執行環節的規劃,就是產品和運營協同工作的開始。比如,受眾人群、功能特點、版本節奏、運營規劃等,應該雙方一起參與討論,得出一個大概的框架和計劃。


          第三步:按照框架計劃,大家開始分頭行動。產品去畫原型,定功能細節;運營做準備內容、流量渠道和核心用戶,以及策劃上線后的爆點。在這個階段,產品和運營可以暫時分離開,不必有頻繁的協作。但由于有了前兩步的鋪墊,在分頭行動的過程中,雙方也了解對方的計劃和進展,所以信息是互通的。


          第四步:上線前的準備階段,之前分頭行動的產品和運營的雙方,就要再次回到一起,交出之前的作業。也就是大家為產品上線所做的準備,進展、遇到問題和后續計劃是什么,拿出來互通和討論。問題都解決后,就可以上線了。


          上線后:


          進入到產品正式運轉階段,產品和運營再次結合在一起協同工作。在這個階段需要高頻次的溝通,以及互相推動彼此的工作。


          運營,主要關注用戶反饋。


          在做好內容、用戶、活動、渠道等運營工作的同時,向產品及時和詳盡的通報用戶反饋,讓團隊了解用戶對產品的反應。


          關注用戶需求,轉化為產品需求,推進PM上線。


          提出可以大幅提升運營效率的工具需求,推進PM用產品的方式解決。


          產品,協助運營的規劃和執行工作


          除了修復BUG和完成產品需求之外,要關注運營的反饋,因為這是產品投入到用戶群體之后的反應,是印證之前決策的過程。


          要關注運營遇到的問題,是否可以通過產品的方式解決。主動與運營同學溝通,給出解決方案并推動研發完成。


          還需要關注運營措施是否合理,是否對產品的目標有推進作用。如果發現偏離目標,或者唯KPI的行為,要及時溝通并推動改進。


          當然,在產品上線前后可不只是做這些事,上面只是提到需要產品和運營配合的節點。由于每個項目的情況都很復雜,所以上述事項肯定也不全,只能是作為一個思路,舉例說明。


          5.為什么不少運營想轉PM


          其實產品和運營的關系,描述起來非常簡單。產品負責功能設計,也是研發和設計師等支持滿足方的接口;運營負責維護、拉動和推廣,機器不能解決的問題,都需要運營來解決。


          在我看來,產品和運營是兩類不同但平等的職位,所需人才的類型也是不同的。但為什么現在很多新人更愿意從事產品工作,甚至已經做運營的同學也希望轉做產品,主要是因為「產品經理被神話」而帶來的供求不平衡造成的。


          主要原因是李開復、周鴻祎等明星Boss,都公開宣稱自己是產品經理,把這個職位的工作內容描述的過于理想化,這樣就吸引了更多優秀的年輕人投身到這個領域。另外,公司深受影響,更重視產品經理這樣的崗位,愿意花更高的薪水去請這樣的人才。


          在這樣的供求關系帶動下,優秀的年輕人愿意加入,感覺職位高大上且薪水高;公司也愿意高價請人,認為產品經理重要,且只有高價才能請來。這就是有些運營人員希望轉做產品的原因。


          其實,產品經理當然也要從基層做起,甚至從打雜做起。有很多PM已經從業一兩年了,還在團隊里打雜救火,或者做一些邊緣化的事,這都是很正常的情況。


          寫完了。


          姑婆那些事兒ios快速審核服務 點擊 :http://www.3377on.com/zhuanti/3128.html

           

          大家都愛搜:互聯網資訊類類有話說App推廣運營經驗線下推廣活動推薦微信營銷姑婆專題姑婆圈ASO校園推廣地推ASO100渠道刷量校園運營團隊

           

          姑婆那些事兒(www.3377on.com)是互聯網推廣運營知識分享平臺,關注移動推廣(android,ios)運營,網站推廣運營、校園推廣及互聯網領域最新動態 。歡迎關注我們的微信(gupo520),新浪微博(姑婆那些事兒)。


          版權聲明:本文來源于互聯網,僅作分享學習之用,姑婆那些事兒負責整理推薦。文章僅代表原作者獨立觀點,不代表本平臺運營者觀點與立場。如有版權問題,請聯系姑婆那些事兒—小秘書(微信號:gpxms001)協商解決。

          收藏

          {{favCount}}

          個人收藏

          投稿請戳這里!投稿
          0

          次分享

          文章評論(0)

          {{ user.nickname }}
          發表評論
          登錄 進行評論
          加載更多 正在加載中... 沒有更多了