產品和運營真的是相愛相殺的一對兒，有時候你會看到他們做在一起討論活動方案，有時候你又會看到他們在老板面前互相推卸責任。那么作為產品經理，到底應該如何對待擺正位置，與運營攜手共進呢？

產品設計時要考慮運營可行性

在一款產品從0到1的過程中，產品經理對產品有著幾乎絕對的掌控權。但是當產品從1到N時，產品經理請你認清自己的定位，擺正產品和運營的關系。尤其是互聯網產品，運營和產品崗位的良好配合，才會讓產品體驗和公司業績齊頭并進。

這里我不得不提目前國內產品經理的現狀：大部分的產品經理以原型設計、項目管理為主要工作，而忽視了真正產品經理應該關心的事情：用戶分析、需求確認、以及產品上線后的營銷運營方案。

產品的最終目的是讓用戶用起來，進而幫助用戶解決問題或提高用戶解決問題的效率，這是產品存在的意義。因此產品設計時，就要考慮運營屬性，而產品運營時，也不能忽視產品特質。

在實際崗位中，國內很多App及Web公司，有專門的產品規劃崗位，負責產品需求的調研、產品線的規劃及對產品上線后運營的思考與效果估計。

在京東、百度等互聯網公司，新產品線需要產品經理提交BRD（商業需求描述）或MRD（市場需求文檔）來描述產品愿景。你可以簡單的把這些文檔看成一個產品的可行性分析，實際上它們在促使產品設計更多地考慮到產品營銷與運營。

成功的產品，一定配有成功的運營思路

互聯網產品，往往希望通過UGC（用戶生產內容 ）的模式，激發互聯網用戶的參與度，提升產品的黏性和延續性。

一款互聯網產品，在剛上線想要脫穎而出，一定會有特定的用戶需求或用戶場景，并解決了特定用戶的實際問題。在擁有這樣的產品特質后，用戶逐漸聚集，形成話題和討論，從而實現用戶量和內容量的雙激增。

但是隨著用戶量和內容的不斷增長，你會發現即便是垂直領域的用戶，也會有不同的類型與維度，用戶需求被再次細分，你想要滿足更多更精細的用戶場景，于是你會不斷的增加分類、或是新功能。

這時，運營的作用開始彰顯。他們會不斷地挖掘和分析用戶產生的內容，做內容整合和分發，從而創建內容的新類別。在這個過程中產品和運營會逐步發現，內容太多了，分類只能方便用戶尋找想要的內容，那對于沒有明確的內容需求的新用戶，要怎么辦呢？

給用戶做推薦和推送。

如果是一款非常垂直領域的App，那么大多數情況會直接在首頁放一些推薦位來進行產品推薦，再配合一些應用場景的彈框跳出、日常的運營推送，就可以有效地提升用戶對App的打開率，和新用戶的轉化率。

▲ 小紅書的內容推薦和喜馬拉雅的首頁推薦

如何是一款有社交屬性的產品，那么通過社交關系進行內容或產品的推薦將變得極其順暢，將社交圈內的用戶信息進行對比，相同點可以成為推薦的大方向，而差異點可能成為吸引用戶的意外驚喜。

▲ LinkedIn：在首頁推薦用戶和工作機會

如果是一款用戶群體大而泛的App，那么需要引進一些基于關聯分析或用戶習慣的自定義推薦機制，通過對用戶歷史使用記錄的機器學習，挖掘內容與內容之間的內在聯系，從而定向推薦一些“用戶感興趣”的內容。

▲ 今日頭條：通過用戶瀏覽記錄和手動屏蔽進行定性推薦

因此在產品被用戶用起來之后，你會開始考慮如何讓更多的人用？如何讓用戶用得更久？如何讓用戶用得更好？

產品經理已經無形中開始站在運營的角度思考產品的方向，互聯網產品的成功，離不開一位有運營思路的產品經理。

產品的使用者（用戶），也包括運營人員

相較于社交類App，內容類App近幾年異軍突起的原因，大多是因為站在風口抓熱點，拿獨家信息換大流量。因此相較于社交類App，內容類App的持續運營顯得尤為重要，這類公司的運營部門也獲得更多的內部話語權。

消息、或者資訊、或者內容，自人會說話以來，就無法被機器完全替代。內容的創造和串聯都離不開人工，而內容的傳播和推廣也離不開人工的篩選和潤色。因此，針對內容類App，產品有很大的責任把運營人員的能力發揮到最大化。

當運營人員成為產品的使用者時，他們甚至可能使用頻率會比普通用戶高上數倍，而產生的價值和普通用戶也有天壤之別，你需要特別重視運營人員的使用場景，同時也要具備甄別運營需求的優劣的本領。

在給運營做運營需求時，要靜下心來和運營討論用戶場景，站在運營的角度思考需求是否必要，以及如何進行設計。要讓運營提出明確的需求和預估運營效果，當產品設計出來之后，也要和運營再三確認是否符合運營的想法。

除此以外，運營的需求往往涉及用戶使用的前端和運營人員使用的中臺，因此很多運營需求的設計，要優先考慮運營人員如何高效工作的產品目標。比如：CRM系統如何對數據進行排序展示和導出？用戶私信如何實現群發？前端如何埋點中臺如何查詢？運營人員權限如何分割……

中臺的產品設計不要求太多美觀，但是需要產品經理格外細心有條理，才能讓運營人員用起來得心應手，提高整個團隊的效率。

運營需求不是一味的滿足，也不是一味的放縱

有的產品經理在設計產品時，有時候會陷入一種誤區：讓運營自定義的東西越多，就是越為運營考慮。

錯！如果讓運營自定義越多的內容，無形中給運營增加了越多的工作時間和壓力，同時也會讓產品的體驗變得沒有那么穩定。就如同押寶一樣，過多地把產品體驗效果壓在運營的能力之上。

不僅如此，給運營太多的發揮空間，有時候需要技術人員開發更多的中后臺功能。而開放自定義功能給運營后，你可能會發現運營并沒有高頻率地去更換自定義的模塊。這不僅浪費了開發資源，也給平臺的穩定性帶來更多變數。

就App的首頁來說，動靜結合，是一個不錯的選擇。利用一些算法來做推薦和展示，同時又保留一些運營可以自定義的模塊，讓用戶有一定發揮的空間。如此一來，既不用擔心由于運營人員的變動而導致的用戶體驗波動，也可以讓運營在產品的基礎上，做一些運營活動。

在和運營討論使用場景時，也不是聽之任之，運營需要什么就做什么。要反復確認功能上線后的運營思路與預期效果，并且在每次運營功能開發上線后，對此復盤和改進。

“不能強求沒有Bug的程序，畢竟代碼是程序員一行一行寫出來的”

你也不要強求每個產品功能都是爆點、都能解決用戶/運營需求的，畢竟產品和運營都是人做出來的。少一點急躁，多一點耐心。

本文由 @?JiLL 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖作者提供