運營人，眼中應具備的產品觀
Warning: Invalid argument supplied for foreach() in /data/cxweb/www/gupowang.com/public/article/view.html on line 71
【來源 | 人人都是產品經理】
【編輯 | 姑婆小俊哥】
一直強調的一個理念是：所有的運營都屬于產品運營。脫離對產品深入理解的執行容易偏離真正的目標，譬如做渠道推廣不僅要考慮流量的采購成本，也要了解轉化的路徑，后續的用戶行為，才能評估渠道的根本價值。
什么是好產品
并不認同“即使是屎一樣的產品，運營也要在上面種出花”這種話，這是產品設計責任的推諉，是對運營資源的極度浪費。
有一個經典的命題：
在運營的回答中，可能是“有口碑的產品”、“用戶量和DAU都很棒的產品”、“像微信這樣牛逼的產品”、“很賺錢的產品”。
這些回答有兩層根據：
-
所描述的理由在一定程度上代表了這個產品活的很不錯；
-
深刻經歷過反面的坑，越發覺得這才是我想運營的產品。
好產品有一些共同的基本特性，諸如滿足用戶需求、體驗好等。但在運營的眼中，這些標準并沒有卵用，因為它區分不了。
每個產品都會做需求分析：設計和體驗好是標配，關鍵差別是需求滿足的方式和程度不同，導致產品自帶的勢能不同。
從運營的角度來反思，“好運營”的產品才是好產品。
怎么算“好運營”：
-
用戶教育成本低；
-
所見即所得；
-
營銷支持到位。
串聯起來的意思是“用戶可以清晰便捷地參與產品體驗，滿意，并適當樂意地參與了互動和傳播”。
“好運營”反應了需求滿足方式合理，運營低成本撬動高增長。
當然，這不代表運營就投入少，而是根據階段性目標，投入產出比合理。
一般而言，運營缺少產品經理的專業視角，把控產品的根據主要來自用戶的反饋，數據的精細分析，增長需求，以及積累下來的運營理念。
運營如何參與到產品的把控
上面從運營角度對產品提了三點判斷，基于這三點來，來理解運營如何參與到產品的把控中。
用戶教育成本
教育成本，實際上就是新用戶的成本，包含了幾層含義：
01 用戶角度的產品定義
在宣傳時，我們容易將產品的專業概念與給用戶定義混淆；或者在產品的宣傳文案里羅列技術性功能，文案立場的考慮要慎重，否則就無法第一時間激發用戶了解的興趣和想象。
02 用戶對產品預期
首先是產品的設計理念上，尤其是核心服務是否直觀的體現，符合宣傳預期。
如果你不是行業的唯一生物，那么制定規則的時候要慎重：請勿將規則創新當做產品創新，反而讓用戶產生不適。
03 引導首次體驗
在理念上體現為是否有足夠的內容、數據，和及時的響應，對用戶傳達產品的活躍度，高效率。
教育成本問題集中體現在用戶的前置環節，在運營執行層面上很容易得到反饋：
-
建立用戶基地，收集最底層的反饋，判斷產品問題集中的類型是BUG、體驗還是根本理念問題。
-
數據觀察，如果教育成本高，那么留存率，核心業務的點擊和使用數據都會明顯的低。不必產品上線，就盲目外推，只盯著下載和注冊成本數據。
運營也許不知具體設計和改良產品，但必須可以判斷得出產品問題的方向。
所見即所得
指的是產品的服務體驗足夠明顯，即需求滿足。舉個簡單的例子，工具類的產品如企查查、車來了，查詢結果便是需求，很直接；UGC類的社區是良性增長循環，早期內容少，人少，體驗性就差。顯然，前者的運營難度要小。
這個例子更多是模式的選擇，不算狹義上的產品把控問題，只是說明了“所見即所得”對運營難度的影響。
那么可以總結出運營的均衡點：當核心服務的邊際成本并不會隨著用戶增長而增長，問題便迎刃而解了。
譬如UGC社區，當運營機制和環境完善后，用戶增長，UGC也會自然增長，不再需要增加人力投入，從而平衡。與增長黑客中的PMF理念異曲同工。
回歸到運營層面，注重2點：
01 服務周到，覆蓋率和體驗度
1. 產品不可能滿足所有用戶。譬如“企查查”可能會有部分企業信息沒有收錄，電商平臺有用戶搜索不到喜歡的商品，“學霸君”里有用戶搜不到的題目。
覆蓋度的缺失可能給新用戶帶來致命的逆向心理，就要通過數據去跟蹤這類行為的比例和路徑，產品上做引導、推薦等，并優化點擊使用率，降低因為覆蓋率導致的用戶流失。
如果是平臺式的產品，譬如社區、C2C服務，通常是搞定關鍵一端，甚至動用技術手段實現自動化。譬如C2C圖片社區，會通過抓取美女頭像、圖片自動生成用戶和內容，來解決早期問題。當然這個只能算運營搬不上臺面的小技巧。
2. 體驗度表現在通過手段來優化可能引發用戶中斷服務的環節。
舉個例子，技術社區CSDN在UGC問答版塊中，當用戶提問后，將歷史問答通過計算推薦給提問人。在一定比率上降低提問者等待時間，提升滿意度。
包括報錯頁面、加載頁面、概念說明，都是引發用戶恐慌和煩躁的地方，則需要詳盡的添加文案、引導或自動跳轉。
綜合而言，這些都是從運營的轉化漏斗分析來反向推動產品優化。
02 需求的挖掘
譬如電商平臺的商家端，一開始只有上下架、編輯管理、財務結算等功能，而后隨著用戶數增長，就需要挖掘商家的營銷需求，可以對買家分層、靈活的促銷支持等。
通過熱力分析、互動分析留意用戶的集中行為，譬如用戶頻繁點擊“經驗”明細，可以分析嘗試圍繞經驗設計活動。
運營需要有敏感的數據觀察，并對用戶行為的因果有分析思維。
營銷支持
這應該是運營提的最多的需求，涉及的類型挺多：互動功能、積分、分享、邀請、活動等。
對于產品經理和技術來說，不一定屬于核心業務的優先級，但確實運營賴以生存的武器。
從運營的角度講幾個要點：
01 場景結合
很多現在標配的營銷功能已經沒有紅利了，不是放個入口就能數據就蹭蹭上漲。
拿分享功能來說，如何在合適的路徑嵌入，對應的利益刺激，流量回流時用H5互動還是直接下載，甚至與“有獎邀請”結合發揮作用，值得精細化設計策略。
02 降低技術成本
提需求時，充分了解技術的難度和周期，維持核心規則的前提下，多考慮第三方工具和折中方案，甚至通過第三方引入增加合作資源。
03 文檔和跟進
技術或者是產品，有時候并不能充分、時時了解營銷產品的關鍵意義，就需要有對應的說明文檔。
并且永遠要堅信“上線無BUG才是真的無BUG”，測試環境下，以及技術口中的無BUG僅當參考，所以盡量提前上線或小規模測試。
運營眼中的產品人
運營是產品的共同家長，但每個孩子的天賦和成長形態，也許家長并不能知曉，可能會短視、會求成、或者只管一畝三分地。
產品經理像管家，對產品整體來協調監管，并控制每個需求的技術支出。運營吃變壯，產品經理幫塑形。
不可或缺
前面一直強調運營把控產品，這是對運營提的要求。而實際上，產品經理的同樣高度關注數據、轉化、用戶行為，他們有用戶分析的專業知識，對用戶行為的因果關系更了解，把控產品的整體設計，并對部分產品數據負責。
產品經理的另外一個能力是幫助運營將抽象的需求，化作邏輯清晰的產品需求，并產出可視化模型。并協調設計和開發資源，跟進需求上線。
在一定程度上，產品經理就是運營手中的阿拉丁神燈。
亦友似敵
好的產品經理喜歡研究產品和用戶，所以他們并不會排斥運營需求，甚至也會喜歡運營工作。但他們煩運營：
-
異想天開、盲目提需求，不考慮產品擴展性和整體規劃；
-
像出頭鼴鼠一樣臨時提需求，改需求；
-
不懂產品技術原理，對牛彈琴。
同樣，產品經理也“討人厭”：
-
無視運營需求，自作主張的設計和該需求，并引以為豪XX產品也是這樣做，拜托，明顯用戶心理不一樣好不好；
-
一味壓低運營需求的優先級；
-
有沒有做測試啊，居然BUG這么多。
如何配合
大多數情況，運營多用戶增長，活躍和留存數據負責，產品經理對產品迭代、需求上線、測試負責，不同公司架構不同，導致關注目標不同，這無可多言，只說說日常配合。
-
能力均衡和同理心。運營要了解產品原理和流程，有主動研究體驗產品細節的精神，提需求的時候采用有理有據，而非一問三不知。產品經理要熟悉在營銷環境下，用戶行為的變化等，雙方能力平衡的時候，才能有同理心，降低溝通成本。
-
產品文檔。產品經理產出完整的產品迭代功能、參數說明，運營需知曉查看，一方面清楚產品的優化程度，對應不同的推廣計劃、宣傳文案，應對用戶溝通；另一方面，不會提無謂的運營需求，并產生需求變更的口角。
-
需求評估。當需求數量過多，優先級無法統一時，就需要有需求的溝通例會，來達成一致。
-
溝通方式。產品經理除了默默看數據外，可以聽取運營的反饋，針對運營問題主動提產品的改進意見，和自動化的產品方式來降低運營成本，甚至形成例會文檔。運營收集到的用戶反饋和問題總結，務必以文檔形式呈現，雙方約定文檔的格式。
-
互KPI思維。提倡在良性的環境下，了解對方的KPI或目標，相互推進。
譬如產品經理的KPI之一是降低用戶流失率，從運營角度，在無服務頁面增加其他服務入口，而非單一文案，既可以降低流失率，還可以提升業務數據，產品經理也樂意參與。
彼此非作惡，只因對產品疼愛的方式不同，交換提升彼此的技能，相互配合對方的工作方式，明白彼此的語言。
融洽的關系
總結下運營和產品的關系。我們強調運營要有產品觀：一方面，策劃和執行運營手段時，要充分考慮產品的屬性，衡量綜合成本，并反哺產品的改進。
另一方面，尊重協作和產品原理，有大局觀，不要做只能通過吵架來解決需求的運營。
喜歡是擁有，深愛是克制。
—— END ——
文章評論(0)