好久沒有肆意揮灑寫一篇文章了。上一次這麼痛快寫文，還得追溯到17年。今天看了一眼後臺數據，註冊用戶量已經躍升到了1348735人。內心激動之下，覺得還是很有必要稍作整理。坦白說，我個人的產品經驗還不是很豐富。自去年4月從51job離職到現在，獨立負責整個產品項目，也僅有1年多的時間。行業內，往往把從業1年的產品稱之爲菜鳥。菜鳥賽季的我，其實還是蠻幸運的。沒有老闆和總監的堅定信任，我是萬萬不可能以零經驗來獨自負責一款APP從0到1的工作。打造一款百萬級用戶的產品，曾經是我剛入行時的一個目標。現在，歷經10個月的努力（18年7月14號上線），我們站在了這一量級節點。雖然這個速度並不是很快，但是零廣告投入能夠做到這一切，我很開心。
【洞察用戶】
如果讓我來面試一位產品，我可能不會問他，“北京市的加油站有多少”、“怎麼把大象運到樓頂”這類問題。我的第一個問題，肯定是：你怎麼理解你要服務的用戶？很多互聯網人喜歡炫技，丟出一大篇的用戶研究報告，然後把Persona告訴面試官。這種沒有自我提煉思考，僅僅展示數據的用研，並不是好的用研。無法把數據背後的洞察貫穿到產品設計中去。一句話來說，沒有真正理解用戶。舉個例子，假如我們瞭解到，藍領用戶的畫像是，平均7個月跳槽一次，平均月薪2000-4000。看到這個數據，你怎麼理解藍領用戶和白領用戶在求職上的差異呢？很多人估計會不加思索說，有什麼差異，都是投簡歷唄。如果這樣想就有誤了。通過剛剛提供的用戶畫像，我們知道，藍領的跳槽非常頻繁，忠誠度低，薪資水準不高。這種特質會帶來什麼呢？試想一下，一個人一年要跳槽兩次乃至多次，薪資要求不高。那麼他在低薪要求提供的跨職能工作的可行性下，是不是有更大可能從事多種類型的工作呢。比如第1份工作是服務員、第2份是超市營業員、第3份是快遞員、第4份....藍領羣體不像白領，一份產品工作，從助理到總監，可能貫穿整個職場。藍領用戶的廣闊求職彈性帶來的產品啓發是，我們在給他們設計職位推薦引擎時，首要追求不是職位匹配的精準度，而是求職多樣性。所以去年我們上線了一個關聯職位功能，用戶在找服務員時，我們會給他推薦營業員、店員、收銀員等多職能工作。從這個例子我們可以看出，產品是做什麼？產品是提供需求的解決方案。深刻理解需求，深刻洞察用戶，不停留在數據表面，是非常非常重要的。一個工作經驗少、文檔寫作弱的產品，通過後期學習，可以慢慢變好。但是如果不理解用戶，即使原型畫得再溜，用戶研究報告寫得再華麗，也是無濟於事。不同行業的產品，其實差異極大。這種差距不是因爲技能庫的經驗無法複用，而是對行業、對用戶的理解難以移植。好的產品經理，真的是一將難求。以前經常有人問我說，想做產品但是不會畫高保真交互原型怎麼辦？我的看法是，放棄那些花裏胡哨的東西，除非你是想做UX而不是產品。找一個感興趣的行業，把行業競品的應用商店評論完整擼一遍。我相信面試的時候，會更有話題聊的。
【決策判斷】
說到底，產品是一份從事創造的工作。雖然我們在做需求的時候，往往需要做足功課，比如數據分析、用戶調研，大公司還會使用A/B測試工具，來輔助產品做出決策。可是即使我們做了所有這一切，也不會有人告訴產品，功能上線後，效果一定很好。決策判斷力對於產品來說，實在太重要了。有沒有什麼辦法可以提升做需求可靠性呢？我個人比較喜歡的一個思想工具是張一鳴曾經在微博上提到的，一共4個問題：
1、做這個功能有什麼確切價值？
一款產品會有很多的數據指標。產品經理在進行需求決策時，如果盯着一些細枝末節的數據，那麼似乎每個功能都很有價值。所以我們在判斷某個功能是否有確切價值時，要基於兩點。①是否與核心指標緊密關聯；②功能可能覆蓋多少用戶？
產品無論怎麼調整，核心指標往往就那幾個。關注核心數據，就可以避免捨本逐末。所有的版本迭代，都是圍繞核心指標而走的。增長黑客這本書，好像把這個指標稱之爲北極星指標，我覺得是很有道理的。
功能覆蓋的用戶量，我覺得不需要太多解釋了。吭哧吭哧做了半個月上線，結果只有少數用戶感興趣，我想沒有哪個團隊能夠接受這樣的局面。
2、這個功能一定重要/有什麼問題嗎？
孫子兵法通篇都在講一件事：不可勝者在己，可勝者在敵。先勝後戰，贏了再打。借鑑到產品領域，就是產品經理時刻要在心裏想着，我這功能是怎麼死的？先把缺點不足處想清楚，再去考慮它的價值。
這一步的好處是巨大的，它會幫助產品經理剎車，讓我們做功能時變得更剋制。剋制是PM們的必修課。如果做不到，就會胡亂加功能，導致產品非常冗餘，體驗極差。我們總監經常掛在嘴裏的一句話是，我不需要你一年做多少功能，但我希望每個功能都很好。
我個人的體會是，有時候相比做需求，砍需求的能力往往更重要。可做可不做的時候，就不要做。
3、你是如何確信這個功能價值的？
任何功能都不要主觀臆斷。要有依據。我現在無論是跟開發講需求還是寫需求用例，都會把需求背景講的非常清楚。有時候往往會有幾百字的着筆。爲什麼這麼在乎？一方面是避免拍腦袋，方便後續跟蹤需求時，可以清晰知道當時做出決策的依據。另一方面，則是讓開發清楚知道背後的事實，讓溝通理解更順暢。
4、有更好的解決辦法嗎？
這一步其實是最難的。它需要你跳出當前現狀，打開視野，避免稟賦效應。不是有句話麼，設計不是選擇A或B，而是尋找更優的第三方案。回答好這個問題，要求產品有很強的系統思考能力，目前我也在積極修煉。
【溝通與抗壓】
產品經理的日常，往往是這樣幾幅畫面：
畫面1：老闆把你喊到辦公室，給你一些指示，大部分時候，會讓人心裏一涼：咦，這個功能上線後確信不會被用戶打死？於是你得和他耐心溝通，有時候，還得苦苦哀求。
畫面2：設計師一條微信消息把你從改變世界的美夢中敲醒，併發了一個50米大刀的動圖讓你細細體會。於是你屁顛屁顛跑過去跟她說，這個活動頁配色不夠活潑，顯得過於老氣。完了還得多誇獎一句，你這頭髮扎得真可愛。
畫面3：程序員與產品經理的故事，簡直就是一部互聯網血淚史。有時候我細細想想，如果一個人要我按照他的意思走路並且絲毫不能出錯，有時甚至讓我換一條路。我想，旁邊有多大石頭就揀多大。把走路換成做產品，道理是一致的。在公司的部門、職級劃分中，產品與技術往往不是一個部門，職級也往往一致。這種時候，你如何調動技術？更何況產品經理改需求也是職業通病，難以避免。所以，我學到的一點是，工作要交給他們，委屈交給自己。不要和技術發生爭吵，卡耐基《人性的弱點》告訴我們，辯論也許會讓你一時痛快，卻解決不了問題。
一款產品能夠上線，往往是多方力量的綜合產物。作爲這款產品的主要推動者，要保持和各方的充分交流，這樣可以顯著避免衝突。有時候，自己失誤了，大大方方承認，誰讓自己沒做好呢？被老闆或者同事責難了也不要緊，一個人有多大成就，就得承受多少委屈。
寫到這裏的時候，我發現文章還有很多點還未提到。然而過長的篇幅實在影響閱讀體驗，所以到此落筆吧。寫文章的過程，是梳理思路的好時機。過去兩年，賬號沒有更新過什麼文章。今年努力一點，多寫寫，就這樣吧。