當產品和運營思維方式不同，該怎麼辦？
為什麼產品和運營總吵架，主要的原因在於兩者的思維方式不同，那麼面對這種現狀，我們該如何應對呢？
有沒有想過，為什麼PM和運營的觀點經常有分歧，對需求、優先順序的判斷總是不一樣的。
主要原因是思維方式和工作目標不同。思維方式，就是思考問題的出發點、思維模式等；工作目標簡單說就是KPI，這是通過管理和團隊架構來解決的，這裡不說了。
思維方式，PM是這樣的：
PM的思維是邏輯性很強的，因為產品的各頁面流程、功能模組和資料平臺是講邏輯的，
PM相比運營來說，更理智。在做一個決策的時候，需要有足夠有力的依據。比如，之前的資料可證明，或以競品為參考，總之必須有依據。
PM更關注投入產出比。如果你說運營也很關注，這沒錯。但PM的決策，會帶來後續的各種人力投入，研發、設計、運營等，這些都是成本。如果決策有問題，PM需要背鍋，所以這個成本會讓PM很慎重。
思維方式，運營是這樣的：
運營的思維方式是很發散的。大多數運營都需要是有趣的人，這樣才能做出有趣的活動、有趣的內容，以及和有趣的用戶打成一片。
運營會更為用戶著想，畢竟是總和用戶打交道，會不由自主的更偏向用戶的利益。但PM會更偏重產品本身的利益，保證反覆運算節奏和優先順序。
運營會有一個比較常見的問題，就是主觀無依據的推測。比如認為要新加一個功能，
思維方式不同，該怎麼辦？
因為我是做運營的，所以這裡就說運營人員該怎麼面對與PM思維方式不同的問題。
關鍵就是要「有理有據」。
運營提出一個想法，需要PM或研發的支持，肯定不能憑空描繪，畢竟答應你之後，就要開幹了。你是動嘴皮子，人家是搬磚幹活。所以在搬磚之前，
所以就得說服PM和研發，才能開始幹活。說服的方法，就是拿已經存在的東西作為參考，這是三方都會認可的。
「已經存在的東西」包括現有資料和對標案例。
1.現有資料，就是拿著自己產品的資料來做分析，印證出需求的存在，值得投入開發。
比如，
2.對標案例，就是拿相似的項目來做標杆，可以是自己產品的，也可以是別人的。
比如，上個月或去年同期的活動，因為形式是一樣的，所以可以做參考；再比如，競品已經上線的功能，看對方的效果，這也是實實在在的東西。
如果沒有對標案例怎麼辦？那運營就先搞起一個簡單版的，也就是我們常說的MVP。
舉個例子，你想做一個激勵核心用戶UGC的任務體系，是需要產品功能來實現的。這樣使用者就可以每週來按照任務貢獻內容，獲得積分或禮品，從而提升產品資料。
但對於PM來說，這個效果是未知的，是缺少理由和依據的。所以，運營可以先搞一個簡單版本測試一下效果。
比如拉50個核心用戶進群，發一個帖子告知活動的規則，然後看這50個人的UGC數量。如果沒有資料後臺，哪怕人工去數也是可以的。最終拿出活動的效果，可以認為50人在沒有產品支援的情況下能有200條UGC內容，每人4條。
可以推測出，如果產品更好用，展示效果更好，每人可以產出10條；然後把全部200個核心使用者都調動起來，就可以有2000條UGC內容。
這就是一個推理的過程，肯定不一定準確，但至少是有依據的，比運營空口白牙的去承諾要更有力。
其實大家都是為了產品更好，只是大家的知識背景、思維方式、所處位置不同，得出的觀點不同。要想更好的協作，就必須拿出「共同的語言」去交流。
#專欄作家#
如果沒有對標案例怎麼辦？那運營就先搞起一個簡單版的，也就是我們常說的MVP。
舉個例子，你想做一個激勵核心用戶UGC的任務體系，是需要產品功能來實現的。這樣使用者就可以每週來按照任務貢獻內容，獲得積分或禮品，從而提升產品資料。
但對於PM來說，這個效果是未知的，是缺少理由和依據的。所以，運營可以先搞一個簡單版本測試一下效果。
比如拉50個核心用戶進群，發一個帖子告知活動的規則，然後看這50個人的UGC數量。如果沒有資料後臺，哪怕人工去數也是可以的。最終拿出活動的效果，可以認為50人在沒有產品支援的情況下能有200條UGC內容，每人4條。
可以推測出，如果產品更好用，展示效果更好，每人可以產出10條；然後把全部200個核心使用者都調動起來，就可以有2000條UGC內容。
這就是一個推理的過程，肯定不一定準確，但至少是有依據的，比運營空口白牙的去承諾要更有力。
其實大家都是為了產品更好，只是大家的知識背景、思維方式、所處位置不同，得出的觀點不同。要想更好的協作，就必須拿出「共同的語言」去交流。
#專欄作家#