產品經理的核心就是提出一個好的想法+把這個想法實施，分別對應了道和術，因此本文作者從這兩個角度談一下自己的收穫。
2018年是我開始做產品經理相關工作的第一年，也是成長飛速的一年。前六個月和朋友一起到騰創業公司，在做區塊鏈遊戲產品，有了從0到1的產品落地經驗。後半年在LinkedIn做PM實習，在growth team做用戶增長相關的產品功能，系統輸入了很多方法論，也從各位前輩身上學到了很多。希望把第一年的一些感受寫下來，也算是有始有終，當然畢竟新人才疏學淺，如果有說的不合理的地方還請各位前輩指點啦~
產品經理的核心就是提出一個好的想法+把這個想法實施，分別對應了道和術，因此想從這兩個角度談一下我的收穫。作為一個PM，我們應該怎麼思考問題，日常工作中又有哪些技巧可以促進工作。
產品經理之道
1. 定義衡量產品的效果要能從CEO的角度出發
- 做一個feature是一定需要衡量其成功指標的，需要回答的問題是成功會是什麼樣子的。而從CEO的角度出發要求我們首先思考，這個feature和整個公司的戰略目標之間有什麼關係。一個產品可以有很多成功指標，思考單獨的產品和公司的聯繫可以給諸多成功指標排列優先級和重要程度。
- 第二，從CEO的角度出發要求我們在定義產品成功的時候除了關注自己的數據增長，也關注是否給別人的指標帶來了負面的影響。一個用戶一個時間段也許只能幹一件事，因此你做的一個新功能可能影響別人的功能，這也是我們理解tradeoff 的一個角度。
- 與之相類似，從CEO的角度出發要求我們從“投入回報率”的角度去衡量產品效果，因為同樣的一個工程師一個時間段也只能幹一件事。也許這個產品功能在A/B test的效果很好，但是帶來的數據將增長整體可能不如另一個你沒有測試的idea，因此不是單純的數據增長就是我們最想達到的狀態的。
- 最後關於衡量效果要求我們不斷深入問“為什麼”，你可以說這裡做這個事兒可以提高用戶體驗，可以拉動某個數據，可是為什麼要拉動這個數據呢？這個拉動/優化是一次性的還是可持續的呢？反覆地，不斷地深入挖掘原因才可以理解產品，從而提高決策的準確率。
2. 產品迭代中最重要的是學到一些可以複用的經驗
迭代這個概念應該已經是老生常談了，記得我剛開始做功能的時候，會和老闆討論，哎呀我這個點擊率不高是不是因為這個卡片的視覺效果不好，如果更新一下設計是不是會好一點。感覺這也是新人產品經理的通病，天天抓住一個UI設計不放，執著研究各種交互細節。這其實不是所謂的迭代。
迭代的核心除了拉動數據更重要的是“學到一點新東西”，通過這個迭代不僅數據變好，PM的決策能力應該也相應的提高。為了學到新東西，我們在做迭代的時候就應該有一些假設，從假設出發然後通過迭代去驗證假設，從而收穫新的關於用戶，關於產品的理解。
更新UI設計等應該是在MVP的時候就應該做到盡善盡美的，尤其是一些“你明明知道可以拉動一些數據”的UI更新，比如顏色更鮮明，大小更大。這些事既然知道一定可以提升效果，那為什麼最開始不做呢？因此迭代的時候需要迭代的是一些你覺得可能會有效果的東西，而不是你覺得肯定有效果的東西。
迭代的三個步驟應該分別是定義問題，驗證假設，功能優化。首先就應該明白我現在做一個優化需要回答的商業問題/戰略問題/產品問題是什麼，然後對這個問題有哪些可能的答案，如何設計實驗去驗證，再基於這些結果優化。
3. 數據驅動思維更關注你能對這個數據做什麼
好像所有的PM面試中，都會問你做這個功能需要看哪些數據或者你之前做過的功能數據上效果怎麼樣，數據驅動基本上快變成一句正確的廢話了。確實在寫需求文檔的階段，我們就需要明確成功指標，上線以後也會去看數據反饋。
大家最喜歡的就是看PV/UV/CTR(點擊率）這些“行為指標”。行為指標確實可以直接反應用戶的行為，可看了以後呢？你知道PV不行，CTR很低，然後呢？你並不能做什麼，也並不能知道真正的原因。
因此所謂的數據驅動是要讓數據能夠指導決策，或者說actionable numbers.
比如：日活跌了，應該先想有哪些渠道可以促進日活，再去分析。數據驅動不是有一個數據就夠了，應該能夠向前&向後思考，向前思考這個數據會由哪些行為影響，向後思考這個數據的漲跌意味著什麼，我應該做點什麼。所以PV這樣的指標通常是用來反饋用戶行為的，而非我們用來定義產品效果，或者驅動產品決策的指標。
為了做到數據驅動，我們首先要對數據有一個基本的預期，比如你猜到做這個功能可能促進日活，那能夠促進百分之幾呢？越明確的預期越可以便於後續的衡量決策等。其次我們要對可能影響用戶行為的控件進行足夠的埋點，比如：這個頁面上某個按鈕點擊率低可能是因為用戶覺得另一個圖形看起來也可以點擊，就去點另一個了。
埋點的時候不能只考慮直接相關的，也要把一些擾亂因素融入進來，這樣當數據出了問題時才可以有理有據找理由，想解決辦法。最後數據驅動還要求我們在設計功能時就知道如何能用數據驗證，去思考一些量化指標以及如何獲得相關的信息。
4. 對產品負責意味著要有明確的觀點和作出決策的能力
都說產品經理是產品的第一負責人，但這個負責到底是指什麼呢？
我剛開始的誤區就是在最初定義了產品功能以後，與各方溝通，監督整個開發全過程就好了。但後來才發現產品經理的負責不是隨叫隨到，有什麼問題都去解決，而是在每一個出現問題的時候都可以作出明確的決策。
為什麼需要有明確的觀點和決策？
因為很多時候產品開發過程中面臨的問題是妥協（tradeoff），工程師資源不夠時間不夠，設計師覺得你這個方案不好看等等。太多的小問題會影響最終的產品形態和開發進度，在這個過程中誰來做決定想辦法呢？
毫無疑問是產品經理，而他如果沒有明確的立場就會被各個利益相關者牽著鼻子走，最後做出來的產品可能就完全不是最初設想的樣子。記得我剛開始實習的時候面對各方的質疑就毫無還擊能力，很容易鬆口。但產品經理是最瞭解產品的人，有義務有資格也必須去拍版。
那如何擁有這樣明確而果斷的決策力呢？
有句話我很喜歡：
fell in love with your problem rather than solution.
決策力需要建立在明確的立場上，需要你明確你要的是什麼。大部分時候你要的不是某個方案，而是去解決用戶的問題，滿足用戶的需求。因此一直關注你要解決的產品問題/用戶問題，能夠讓PM在繁雜的大小決策中保持態度和觀點。思考問題這個過程本身也比最後呈現出來的方案有意義。
產品經理之術
1. 好的需求文檔需要有清晰的故事和完整的記錄
產品經理不用寫代碼也不用畫設計圖，好像只能寫個需求文檔。這個文檔確實不如代碼/設計稿有直接的生產力，但是質量好壞直接決定了產品開發的進度和效率。好的需求文檔應該完成兩件事兒，首先講好一個故事/願景，其次說明白你要怎麼做到。而衡量的標準就是別人不用問問題，也可以知道你在做什麼，甚至是覺得“嗯，我在幫這個PM完成一項好偉大的事業！”
講一個好故事也就是常規的寫作套路，說明白要解決的問題，如何衡量等，也就不再贅述。而如何解釋清楚你要做什麼則是一門藝術了，我認為需要針對產品計劃和開發進度分類。
比如：產品上不能只寫你現在要做什麼，需要有一個roadmap告訴大家以後可能還要做什麼，因此可以在首次開發的時候就plan ahead。其次開發進度中要記錄timeline，去督促大家在時間節點前完成，同時也記錄沒有完成的理由，用於反思等等。
需求文檔最大的特點應該是“變化”，它需要根據開發的具體情況不斷的變動，因此最好的文檔不是最初去寫一份完整的文檔，而是記錄了產品開發過程中的大小事件，這樣對於整個團隊都能降低溝通成本，提高效率，也便於日後反思回顧。
2. 最好的溝通永遠需要超額溝通，over-communicate
產品經理除了寫文檔還在做的事兒大概就是開會以及與各方溝通了，因為經常和美國的同事打交道，老闆第一天就跟我說要overcommunicate。溝通的技巧有很多，為什麼溝通對PM格外重要，可以通過溝通達到什麼效果呢？
首先是保證項目不延期，不出錯。大型的產品涉及太多部門的太多人，misunderstanding太常見了，因此需要我們時刻記住通知/同步所有人。其次溝通包括逼迫別人作出決策，比如：要開發一個功能，工程師可能要先去調研一下可行性等等，每當有這種pending issue的時候，產品經理需要push別人去得到結論。
不可能事必躬親只有保證他人也也能做出合理決策才能最大化產品效果，所以我覺得產品經理溝通的終極目標就是在沒有了你的情況下，你的團隊也能完成產品的開發。讓大家都理解產品的前因後果，不要讓別人就像給你幹活的，應該讓大家覺得我們是在一起完成一項偉大的事業~
最後，對於我而言產品經理最酷的一點就是這份工作似乎讓我變成了一個更好的人，這個好與精英/完美無關，純粹是通過與不同人一起協作解決用戶問題，加深了我對世界，對自己的理解。也許產品經理的出發點是去解決用戶的問題，但具體工作則更是每個PM關於自己的一場修行。
Product that stands at the intersection of humanity and science makes me a better person. 共勉
本文由 @Shixian 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議
閱讀更多 人人都是產品經理 的文章
