產品管理的挑戰
記錄一位新人做產品的經歷，感受下其中的挑戰。
1
Y 是做產品運營工作的，新入職一家公司，工作很賣力。
她想做精細化運營，但公司沒有一個產品策劃。我很想推動做這個事情，如果要做的話，只能自己來當產品策略了，不過先要說服老闆同意這件事情，你覺得可行嗎？她說。
我不瞭解你們業務，適不適合做這個事情。你要覺得合適，可以試一試。我說。
第二天。老闆同意我的想法了，不過他要讓我出一個 PPT，跟他彙報下，Y 說。我說，挺好的呀。高興之餘，Y 有些犯愁了。從來沒做過產品經理，不知道該怎麼設計產品，問我有沒有需求模板參考。
我說，老闆哪有心思看需求文件啊。你的 PPT 任務只有一個事情：讓他認可這件事，然後你就可以啟動這個專案了。把你的方案思路，流程，目標，預期，風險，有條理地說清楚就可以了，不需要詳細地說明你的方案。不然光做這個事情，就得花很長的時間。
沒多久，Y 跟我說，老闆說 PPT 不是他想看的東西，想要看到具體實現方案。那就做吧，我說。好歹向前進了一步。規劃可以寫得大些，切入角要小，找到最容易突破的那個點。確保做完第一期，有明顯資料增長。這樣，也容易拿到老闆信任，繼續往下做。
老闆說我的方案不是他想的，Y 有些沮喪。剛入職兩個月，想做出成績，所以積極地提了新方案。但現在感覺跟老闆溝通不暢。
搞清楚老闆的想法很重要，這跟理解使用者需求是一樣的。如果你真不知道老闆怎麼想，最簡單的方法就是直接問他了。總是揣摩的話，你的方案改一次才能確認一次，不得累死。反覆改的話，老闆更會不高興的。
Y 說忙死了，有好多事情都要處理，每天都要加班很晚。
我說，如果不能確定每件事情都能做好，就做最重要的那一件，其它的先不要管了。
每個事情都很重要，她說。
我想起了業務方提需求場景
每次排需求時，先要收集業務方需求，每個業務方都要先排出優先順序，彙集完不同業務線的需求後報給領導，再定最終優先順序。收集需求時，業務方總是至少提 7 個需求，優先順序都是 A。我說，按 1-2-3-4 排序提，提 3 到 4 個就好了。因為，最終能有 2 個需求排進去就不錯了，不然還增加了所有人的篩選成本。
業務方總想的是，我提了一堆的需求，你總得給排進去1個吧。關注的是量，卻忽略了重點：提出高價值的需求。
2
方案基本通過了，Y 開始設計產品。為了趕工，Y 利用中秋節放假的時間加班，畫原型和寫需求文件。她之前沒有用過 Axure，還問我在哪裡下載 Axure。
節後，Y 發給我一個截圖， 上面是 3 個檔案：兩個 Axure 檔案（原型圖+流程圖），一個 Word 需求檔案。問我有沒時間，跟她溝通下這三樣東西。我說，發給我，晚上看吧。
到了下午。Y 說，剛跟老闆對完，老闆說太簡單，想要的一個 CRM。她正在收集 CRM 相關的資料，繼續改。他們公司並沒有 CRM。
在於功能，不在於名字吧，我說。
老闆希望的系統是很全面的，我的這個只是其中一個小分支，給他的感覺他說是那種比較簡單的活動，Y 說。
由小到到大是個過程，管理下老闆的需求。我說。
老闆的理由是需要給技術說清楚，之後要做的系統後臺大概是什麼樣子。目前的設計是會讓技術誤判工作量的。這個從小分支功能到多項內容包含在這個系統裡，後面實現會難嗎？Y問我。
系統工程自上而下設計是理想的，我說。求大白解釋一下，Y 說。
如果有人想當馬雲，按馬雲走過的路來設計自己要怎麼走，這是不可行的。我說。
我之前一直以為需求是明確的，我是負責使用者增長的運營。我需要的就是一個可以滿足我配置策略的後臺，能大規模做使用者營銷。但是剛剛和老闆對完，才發現，老闆想要的一個CRM。現在在想怎麼挽救老闆心中的人設，他現在肯定在想我的這個後臺怎麼這麼簡單。Y 表示無奈。
做好自己能做的就好，我說。
3
Y 要跟研發過需求評審了。
她說，原型比較簡單，沒有加互動，就那種點一個按鈕就展示另一個，還沒有學會。老闆覺得互動也很簡單，不好使用，要重新改。
老闆喜歡什麼樣的，那種就好了，我說。
她說，原型是不是職業 PM 看起來很不行，標籤應該怎麼圈選下才清晰和好管理呢？
能幫開發理解就是沒問題的。你老闆覺得互動要好，就讓互動設計師做。我說。內部的後臺產品是沒必要花時間在這個上面的，特別是資源緊張的時候。
我覺得我畫的呢？她繼續問。我說，慢慢來。
你的評價是啥？可以點評下嗎？她還在追問。我感覺到她很在意原型，但這個並不是產品的重點，沒有回她。在第一次用 Axure 之前，我都是用 PPT 畫原型，不同的工具影響效率，但不影響表達。君子不器，是同樣的道理。
Y 宣講完了需求，說自己被前端噴了。被噴是正常的，對方說的對就記錄採納。
我做成複選框了，但是他們說要改成可配置頁面，Y 說。我說，覺得不對的爭議，大的就先放一放。把主業務講完，再回過來看。
被噴是，覺得不是產品經理。你一般是怎麼主持的呢？Y 問我。多理解對方，再講東西，我說。
咋理解，比如？Y 問我。前端可能因為實現成本高，不想做。或者不認可，因為不常用。我說。
Y 說自己的流程是這樣的，首先我先講下這個後臺的流程，大家有問題可以流程過完後地起再問，然後我就開始講了。但別的人給我說，前端問他，你就是這麼過需求評審的嗎？
你是這麼過需求的嗎，Y 問我。
我說，背景-目標-需求：
-
流程。
-
功能範圍。
-
實現方案。
Y 問，我剛才的那個方案可以嗎？我說，應該是比較理想的，一次講完，中間都不問。
4
前天，Y 問我，知道分桶實驗嗎？不知道，我說。
她總是會問我一些產品相關的新詞彙，總是有一些我都沒聽說過的。
從她第 1 次詢問我產品設計到現在，快 3 個月了。希望她的第一版產品能儘快上線。
產品最大的風險是沒有成效，比如，使用者得不到增長，業務得不到增長。其它的風險都是間接風險。抓住這一點，意義在於每一次的輸出在於求所得，並不在於求完善。完善是一個演進的過程，需要每一個點的連線，持續有效。蓋爾定律總是有效的。
需求與資源需要平衡，運營，產品，設計，研發，每個角色要理解並繫結在同一目標上，做好自己能做與值得做的事情，而不是為了付出辛勤勞動幹活。
產品管理的極限是對人的管理。人的管理有兩面：自我的管理和他人的管理。
自我的管理影響的是在組織中發揮的作用，始終明確業務的目標，知道事務的優先順序，做出合理的安排。
他人的管理與組織架構沒有關係，他人可以是上級領導，可以是上游的運營，下游的技術，也可能是你的下屬。瞭解對方的長處，清楚他的短處。從對方角度看問題，有利於明白現狀，做出合適的決策。
文章首發於公眾號-野獸說（monster_talks）,歡迎關注，檢視更多產品內容。