優秀的產品經理，必須翻越這三座大山
作者：Patty（點融網Lender端產品經理）
使用者體驗or業務發展，功能賣點or技術實現效率，要口碑還是要資料，to be or not to be，每一次的抉擇，都會伴隨產品經理力排眾議，堅守內心產品原則的一份堅持和兩利相權取其重的妥協。
作為一個資深產品經理，這幾年工作中遇到的挫折和收穫，數也數不清。看到用戶數的不斷增長和好評我會猶如打了雞血，聽到夥伴的質疑和用戶的指責我也會在回家地鐵上默默掉眼淚，後悔當初的選擇。對於新入行的童鞋，我這個老鳥只有一句話：產品經理這個職業猶如生活，
一、需求收集和挖掘階段
產品每一個反覆運算、每一個功能點，其實都是產品經理堅持和妥協後的結果。首當其衝，產品經理就需要面對 “使用者價值”（即人們常說的用戶體驗）和 “商業價值” 的平衡與取捨。
需求是產品經理每天都要打交道。產品設計是為需求服務的，需求分為功能層，即業務需求，和體驗層，即視覺、人機交互和文案三方面的體驗。
需求一般都來源於哪裡呢？又如何判斷優先順序呢？
人們常說是使用者的需求為產品第一需求，其實這個有些偏頗。第一個產品都是為公司或團隊的總體戰略服務的，
舉個栗子：淘寶不是一開始就有貨到付款。支付寶已經很好地滿足了用戶的支付問題和對商家的信任問題。隨著使用者量的增加、中小城市尤其是對網路和網購不發達地區的滲透，貨到付款才應運而生。除了戰略、目標使用者群體，當然這個功能的上線，依據的還有資料的挖掘與分析，用戶的回饋和競品的發展。
需求評估的本質是價值評估，一般是如下幾點：
① 受眾的大小，即核心價值還是延伸價值；如百度地圖最核心的就是找路線，有了這個才有後面的打車和找飯館等具體細化的場景化需求。
② 用戶使用頻次，高頻次打低頻次。
③ 還有就是依賴程度了。
以上這些評價指標都可以用資料指標來判斷：
① 資料指標中更多應該使用相對值來評估功能的價值。絕對值容易被操控，如市場部被供應商買了垃圾流量，這時候我們用人均啟動量、日均流覽等來判斷更為高效。
② 資料解讀要更為謹慎，如下面這個很多地方都看過的栗子。
作戰指揮官由此認為，應該加強機翼的防護，因為分析表明，那裡"密密麻麻都是彈孔，最容易被擊中"。但是統計學家卻有不同觀點，他建議加強座艙與機尾部位的裝甲，
需求評審會：我們該堅持和放棄什麼
試錯是必經之路。一些開發和項目經理在需求（PRD）評審會時，常常會質疑你的設計和產品需求提煉的產品功能，他們的口頭禪是 “我是用戶，我就不會用這個功能，我會 xxxxxx”，這個時候千萬不要急，慢慢道來，你的設計的背景和場景是什麼，達到什麼目的，要是有前期資料依據那就更有說服力；若是這個是他一家之言，你可以直接忽略他的言論，因為他只要一發散，就容易到了花很多時間討論和會議主題毫無説明的討論。
不要懼怕衝突，和摩擦。每個產品參與者都有自己的立場和著眼點，專案經理希望功能點越少越好這樣交付週期會寬裕，運營人員希望產品功能越靈活越好，這樣行銷活動種類豐富，但又希望操作簡便。 本文由80後勵志網整理編輯，轉載請注明來源，連結位址：
https://www.201980.com/lizhi/zhichang/14092.html
因此我們在需求文檔前需要明確：
①使用者物件；
②核心功能點和達到的目的是什麼，即是什麼和為什麼；
③評價這一功能效果的資料指標是什麼，即價值是什麼，大的有時是戰略目標，有時只是某個時間段內的產品小目標，兩者都要有資料可以體現，如月投資人數、網站日二跳 UV 數、又或是周 投資額）；
④設計這個功能點的原因是什麼，做依據的歷史資料；
⑤如果要減少一個功能點，我會捨棄或是降低哪個功能點的優先順序，連續問自己 2 次。這一點是我自己習慣用的，因為我是一個愛 “貪多” 的產品經理，大家看看就行。
這些準備好後，我們在評審會開始時就將前4點闡明，這樣評審會參與者們也會對需求有個宏觀的認識。進而我們就可以對產品功能、流程和交互做進一步說明。
評審階段的言行
不要出口傷人，侮辱人格的髒話是嚴禁的，你可以語速快，聲音適當抬高，但務必就事論事的探討爭議點。若讓他人不開心，可以會後給予解釋和道歉。其實在每一次撕 X，“打怪升級” 過程中，我的口頭表達能力，說服能力，臨場反應、決策判斷能力都在提升。等你積累到一定段位元，在產品相關人員中建立了 “威望”，你會被他們接納，你所說的會讓人更信服，這是需要一個過程的。
PRD 評審會是 review 你的產品邏輯、使用者使用場景和 demo 稿，是非常有針對性的，不要一味當成了辯論賽，靠三寸不爛之舌來定輸贏。如果實在爭論不下，可以這個問題放一放。如果必須有個結論，我的建議是，技術實現角度一定要信任技術人員，用戶體驗設計就聽取設計人員的專業建議，因為一切的爭論都會在後期用資料來論證。
需求評審會一定要開發人員和測試人員參加，僅是開發 leader 或是專案經理都不行，因為只有在一線做執行的開發和測試人員，才能將真實的現狀和所需時間回饋出來，他們思考的細節點有時候是超越產品經理的。
開發工時的評估
我的經驗是作為 PM 結合需求方的意見和運營推廣時間給予一個排期，當然開發團隊肯定是會認為這個時間比較緊張（幾率高於80%），他們需要重構一些東西，還需要依賴其他團隊的開發成果，另外還需要拆解下。當然前提是其他團隊的產品經理的東西不會優先順序更高插進來，等等。這時候需要耐心聽取下開發 leader 和專案經理的排期，剛開始磨合一般要多溝通幾次開發排期，因為往往你以為只要只有一個改動點，後面到了預期時間又發現其實在開發看來是好幾個改動點，這個是需要一段時間的磨合。
對於交付時間點的妥協前期也是無法避免的。等你瞭解了整個開發團隊的技術能力、開發效率、誰擅長哪一個功能模組，3~4個反覆運算後就會對開發時間週期有個很好的把控。
這裡還需要提的就是，幾個版本的 PRD 和 demo 稿，甚至是 api 介面定義等都需要文檔留存下來，需求和設計會變更和更迭，文檔也需要即時更新。如果人員更迭，這些文檔可以更快幫助新人上手工作，也可以為後期產品優化提供前期考量的思路和著眼點。當然你在準備工作年報甚至是面試、演講或出書時，這些歷史文檔都是你曾經努力和成長的記錄。
本文由80後勵志網整理編輯，轉載請注明來源，連結位址：
https://www.201980.com/lizhi/zhichang/14092.html
二、反覆運算階段：反覆運算品質和反覆運算速度
很多人都說產品經理是需要天賦的，要有產品sense，點子多腦子活絡的人很適合產品經理，我個人的感悟是點子和想法的確在很多時候都是可以使產品起死回生的，但在產品經理職業發展的初中級階段，點子本身沒有什麼，都需要扯皮和談判來明確其價值。很多人會想到，少人會做，更少的人做成。
產品經理是需要跟進開發過程的，每一次反覆運算都感覺是和時間賽跑，時間和資源都是有限的，很多時候我們幹著產品經理的活還得操著項目經理的心。建議大家都用紙筆劃一個時間軸（專業一點可以用甘特圖），什麼時間點輸出什麼，並用 outlook 的日曆功能做提醒，這樣到了某個時間點確認交付的東西，不會有遺漏。如 12.3 出交互稿，12.5 出視覺，12.9 出 api mock，12.16 完成開發並送測，將這個時間軸分享給這個產品的所有干係人，這樣大家都會對產品進度和時間進度有所把控。
來到點融我感觸最深的就是，這是一個工程師文化很濃厚的團隊，工程師會對自己和團隊的技術能力和成果感到非常驕傲和自豪，大家目標很宏大，但是卻又腳踏實地的在一點點的摳細節，加班加點的在趕功能。
很多創業公司的業務部門經常會拿產品功能和技術缺失來作為理由解釋業務增長的下滑和瓶頸，我曾經服務過的一家公司，初期產品功能非常少，也創造了大促一天 1800 萬的銷售額。這個數字是普通一天銷售額的十幾倍。舉這個例子不是為產品找藉口，只想說產品功能有時候就是錦上添花的部分，有了核心功能就上線驗證，去看資料變化和使用者回饋，才能為下一步產品功能走向確定目標。
還有一點非常重要！無論進度多趕的專案，發佈前，請一定要內測！一定要內測！一定要內測！重要的事情說三遍。產品經理一定要參與測試，要驗收後才能上線！這是血的教訓。
曾經我跟進的一個對外合作的小專案，由於那時候 landingpage 頁沒有開發環境和 STG 環境來測試，需求方和開發都覺得時間緊急且專案小，先趕上線再線上看下使用體驗是否有需要調整，這下可怕的噩夢開始了。第一次主站的註冊頁面 banner 沒有根據使用者行為做替換，趕緊撤下了 debug，原來這個 landingpage 頁沒有調註冊 api。第二次，我們點擊 Landingpage 頁面上面的按鈕無法正常獲取優惠券，又一次趕緊撤下了 debug，原來這個頁面的參數少了一個，開發工程師又要修改，我們是一週一個 release，這樣等於導致 delay 了 2 周，由於中間隔了 2 周時間較舊，導致這個活動對外合作方又得重新通知線下推廣管道的管道商，這還需要花近 2 周時間，等於這個活動實際和預期的上線時間差了 1 個月時間。
不同設備的適配性測試也是需要的。現在很多的產品都是 mobile first，看似 pm 的工作更聚焦，其實這無形中包含了很多的工作量，平板還是 mobile，是 iOS 還是安卓，是 native 頁面還是 H5 頁面，是 iPhone5 還是 iPhone Plus 的螢幕尺寸，產品功能和體驗都需要上線前後進行測試和檢查。
除此之外，還需要性能測試，尤其是伴隨一些促銷等運營側的功能。高併發的情況是否考量？應急的預案是什麼？若競爭對手攻擊該如何處理？這些不僅僅是運維同學的事情，也是需要 Pm 加入一起準備的。一個產品經理的職業生涯，沒有遇到過駭客攻擊、競爭對手打擊和上線後功能的回滾都是不完整的。
三、職業發展和人際交往
選擇做產品經理，除了面對反覆運算、功能和需求的糾結，也有職業發展上、人際交往上的的篤定和掙扎。
做產品是需要強大體力和旺盛的精力來支援的，最近的我白天常常需要 5~6 個小時參與大大小小的會議中，需求溝通、需求或文檔評審、資源溝通、與專案經理的、交互稿視覺稿跟進、與老闆彙報進度、跨部門爭取資源、只有下班了同辦公室的同事都走了的時候，我可以安靜的整理下思路，寫下文檔，總結下自己的不足與收穫。白天開會晚上加班寫文檔想必也是很多產品經理的日常寫照吧。當然這也和我剛入職，和各部分還需要時間磨合有關，時不時我也在告誡自己需要提高效率，調整與不同部門的溝通方式，對於掌控力很強的專案經理我只需要 PRD 評審會溝通好就行，對於產品線和專案眾多的開發和 UED 們，我需要時不時帶著零食和笑話去 “慰問” 下他們。
互聯網改變了你我的生活，也讓我們聽到了不同的聲音，看到了多變的視角。什麼極簡主義、金線論、反反智主義、鈍感力，每一個觀點每一種文化都有其面具性和立場罷了，這個世界是多元的，正因為這些觀點和立場有其發聲的權利才顯得互聯網時代的開放和可貴。作為產品經理，或是作為互聯網時代的一份子我們都要多聽多看，學會理解、善待和接納。面對複雜，保持歡喜。
延伸閱讀：
本文由80後勵志網整理編輯，轉載請注明來源，連結位址：
https://www.201980.com/lizhi/zhichang/14092.html等你積累到一定段位元，在產品相關人員中建立了 “威望”，你會被他們接納，你所說的會讓人更信服，這是需要一個過程的。
PRD 評審會是 review 你的產品邏輯、使用者使用場景和 demo 稿，是非常有針對性的，不要一味當成了辯論賽，靠三寸不爛之舌來定輸贏。如果實在爭論不下，可以這個問題放一放。如果必須有個結論，我的建議是，技術實現角度一定要信任技術人員，用戶體驗設計就聽取設計人員的專業建議，因為一切的爭論都會在後期用資料來論證。
需求評審會一定要開發人員和測試人員參加，僅是開發 leader 或是專案經理都不行，因為只有在一線做執行的開發和測試人員，才能將真實的現狀和所需時間回饋出來，他們思考的細節點有時候是超越產品經理的。
開發工時的評估
我的經驗是作為 PM 結合需求方的意見和運營推廣時間給予一個排期，當然開發團隊肯定是會認為這個時間比較緊張（幾率高於80%），他們需要重構一些東西，還需要依賴其他團隊的開發成果，另外還需要拆解下。當然前提是其他團隊的產品經理的東西不會優先順序更高插進來，等等。這時候需要耐心聽取下開發 leader 和專案經理的排期，剛開始磨合一般要多溝通幾次開發排期，因為往往你以為只要只有一個改動點，後面到了預期時間又發現其實在開發看來是好幾個改動點，這個是需要一段時間的磨合。
對於交付時間點的妥協前期也是無法避免的。等你瞭解了整個開發團隊的技術能力、開發效率、誰擅長哪一個功能模組，3~4個反覆運算後就會對開發時間週期有個很好的把控。
這裡還需要提的就是，幾個版本的 PRD 和 demo 稿，甚至是 api 介面定義等都需要文檔留存下來，需求和設計會變更和更迭，文檔也需要即時更新。如果人員更迭，這些文檔可以更快幫助新人上手工作，也可以為後期產品優化提供前期考量的思路和著眼點。當然你在準備工作年報甚至是面試、演講或出書時，這些歷史文檔都是你曾經努力和成長的記錄。
本文由80後勵志網整理編輯，轉載請注明來源，連結位址：
https://www.201980.com/lizhi/zhichang/14092.html
二、反覆運算階段：反覆運算品質和反覆運算速度
很多人都說產品經理是需要天賦的，要有產品sense，點子多腦子活絡的人很適合產品經理，我個人的感悟是點子和想法的確在很多時候都是可以使產品起死回生的，但在產品經理職業發展的初中級階段，點子本身沒有什麼，都需要扯皮和談判來明確其價值。很多人會想到，少人會做，更少的人做成。
產品經理是需要跟進開發過程的，每一次反覆運算都感覺是和時間賽跑，時間和資源都是有限的，很多時候我們幹著產品經理的活還得操著項目經理的心。建議大家都用紙筆劃一個時間軸（專業一點可以用甘特圖），什麼時間點輸出什麼，並用 outlook 的日曆功能做提醒，這樣到了某個時間點確認交付的東西，不會有遺漏。如 12.3 出交互稿，12.5 出視覺，12.9 出 api mock，12.16 完成開發並送測，將這個時間軸分享給這個產品的所有干係人，這樣大家都會對產品進度和時間進度有所把控。
來到點融我感觸最深的就是，這是一個工程師文化很濃厚的團隊，工程師會對自己和團隊的技術能力和成果感到非常驕傲和自豪，大家目標很宏大，但是卻又腳踏實地的在一點點的摳細節，加班加點的在趕功能。
很多創業公司的業務部門經常會拿產品功能和技術缺失來作為理由解釋業務增長的下滑和瓶頸，我曾經服務過的一家公司，初期產品功能非常少，也創造了大促一天 1800 萬的銷售額。這個數字是普通一天銷售額的十幾倍。舉這個例子不是為產品找藉口，只想說產品功能有時候就是錦上添花的部分，有了核心功能就上線驗證，去看資料變化和使用者回饋，才能為下一步產品功能走向確定目標。
還有一點非常重要！無論進度多趕的專案，發佈前，請一定要內測！一定要內測！一定要內測！重要的事情說三遍。產品經理一定要參與測試，要驗收後才能上線！這是血的教訓。
曾經我跟進的一個對外合作的小專案，由於那時候 landingpage 頁沒有開發環境和 STG 環境來測試，需求方和開發都覺得時間緊急且專案小，先趕上線再線上看下使用體驗是否有需要調整，這下可怕的噩夢開始了。第一次主站的註冊頁面 banner 沒有根據使用者行為做替換，趕緊撤下了 debug，原來這個 landingpage 頁沒有調註冊 api。第二次，我們點擊 Landingpage 頁面上面的按鈕無法正常獲取優惠券，又一次趕緊撤下了 debug，原來這個頁面的參數少了一個，開發工程師又要修改，我們是一週一個 release，這樣等於導致 delay 了 2 周，由於中間隔了 2 周時間較舊，導致這個活動對外合作方又得重新通知線下推廣管道的管道商，這還需要花近 2 周時間，等於這個活動實際和預期的上線時間差了 1 個月時間。
不同設備的適配性測試也是需要的。現在很多的產品都是 mobile first，看似 pm 的工作更聚焦，其實這無形中包含了很多的工作量，平板還是 mobile，是 iOS 還是安卓，是 native 頁面還是 H5 頁面，是 iPhone5 還是 iPhone Plus 的螢幕尺寸，產品功能和體驗都需要上線前後進行測試和檢查。
除此之外，還需要性能測試，尤其是伴隨一些促銷等運營側的功能。高併發的情況是否考量？應急的預案是什麼？若競爭對手攻擊該如何處理？這些不僅僅是運維同學的事情，也是需要 Pm 加入一起準備的。一個產品經理的職業生涯，沒有遇到過駭客攻擊、競爭對手打擊和上線後功能的回滾都是不完整的。
三、職業發展和人際交往
選擇做產品經理，除了面對反覆運算、功能和需求的糾結，也有職業發展上、人際交往上的的篤定和掙扎。
做產品是需要強大體力和旺盛的精力來支援的，最近的我白天常常需要 5~6 個小時參與大大小小的會議中，需求溝通、需求或文檔評審、資源溝通、與專案經理的、交互稿視覺稿跟進、與老闆彙報進度、跨部門爭取資源、只有下班了同辦公室的同事都走了的時候，我可以安靜的整理下思路，寫下文檔，總結下自己的不足與收穫。白天開會晚上加班寫文檔想必也是很多產品經理的日常寫照吧。當然這也和我剛入職，和各部分還需要時間磨合有關，時不時我也在告誡自己需要提高效率，調整與不同部門的溝通方式，對於掌控力很強的專案經理我只需要 PRD 評審會溝通好就行，對於產品線和專案眾多的開發和 UED 們，我需要時不時帶著零食和笑話去 “慰問” 下他們。
互聯網改變了你我的生活，也讓我們聽到了不同的聲音，看到了多變的視角。什麼極簡主義、金線論、反反智主義、鈍感力，每一個觀點每一種文化都有其面具性和立場罷了，這個世界是多元的，正因為這些觀點和立場有其發聲的權利才顯得互聯網時代的開放和可貴。作為產品經理，或是作為互聯網時代的一份子我們都要多聽多看，學會理解、善待和接納。面對複雜，保持歡喜。
延伸閱讀：
本文由80後勵志網整理編輯，轉載請注明來源，連結位址：
https://www.201980.com/lizhi/zhichang/14092.html
