本篇以一個菜鳥賽季產品經理的視角，從“道”和“術”角度展開討論。

• “道”即世界觀——怎么看待產品經理的世界；
• “術”即方法論——怎么做好產品經理（之我見）。

道：怎么看待產品經理的世界

什么是產品經理？產品經理需要具備哪些能力？

引用我最贊成的關于產品經理定義：驅動和影響設計、開發、測試、運營和市場等人員，推進產品周期的經理人。

具體來說，產品經理通過市場調研、競品分析、用戶調研等手段，產生了若干idea（需求的雛形），經過需求評估和管理后，將需求具象化為產品需求文檔、原型交互圖。接下來，翻譯給研發（RD）開發實現；聯系測試（QA）測試開發結果是否符合預期，驗收無誤后聯系打包開小流量實驗；跟著DA（數據分析師）一起看實驗結果是否正向，正向就擴量直至上線發版，否則評估是否下線；產品上線后和運營一起demo出產品策略，包裝showcase，為銷售提供支撐。

總體而言，從需求產生到最終落地，產品經理需要全程參與，是產品的主要負責人。

某種程度上，干著老板的活，操著老板的心，但是沒有特權，甚至全司的RD都是老板，坊間稱為“無授權領導”。

（圖片來自網絡）

在產品經理參與產品完整生命周期的過程中，少不了和各方打交道，因此王堅把產品經理比喻成老板、用戶、開發之間的翻譯。

這個非常好理解，產品經理要做的就是用簡潔易懂的語言，把用戶需求翻譯給老板，以爭取資源；也翻譯給開發，以描繪開發需求的價值；必要的時候把老板的意思翻譯給開發。

（手動狗頭）

至于產品經理需要哪些能力，《神一樣的產品經理》的能力模型是我比較認可的：

聚焦到商業產品經理，最重要的能力如下圖：

Strike a balance：產品是平衡各方的產物

1）策略效益和開發成本的平衡——產品經理和開發的平衡

談及PM，就不得不說到PM和RD之間“不可調和”的矛盾。

產品經理和開發之間的矛盾，是策略效益和開發成本之間矛盾的外在表現。

一個預期能帶來豐厚收益的產品策略，如果因為導致開發成本過高而難以落地，也不能算得上是一個好的策略。畢竟在瞬息萬變的互聯網世界里，敏捷開發快速迭代是生存的首要技能。

舉一個簡單的例子：

埋點記錄了事件發生的界面、具體事件、時間動作發生的具體對象，對于產品經理做歸因十分有幫助。換句話說，有了埋點，往小了說，產品經理可以知道用戶是在哪個環節的哪個區域進行了怎樣的觸發；往大了說，整體鏈路上各個環節的用戶流失情況可以盡收眼底。

極端的一種設想情況（當然這種情況沒有實操性）下，通過分析用戶進入沉浸流界面后滑動屏幕的觸發埋點位置，判斷用戶使用的是左手還是右手，依此調整接下來屏次轉化button的位置。

理論上，埋點越詳細，產品經理在數據后臺生成的的用戶行為輪廓越清晰，歸因越嚴謹。但是，增加埋點密度的同時，意味著開發成本的極大提高，而且后臺數據量也會爆炸上升，數據存儲和處理要占用的資源可能超出承受范圍，這時候就得回歸到一個重要問題上來：是否有做的必要，ROI是多少？

最終，在策略效益和開發成本之間取得一個平衡，那就是只對頭像、名稱、來源、轉化按鈕、蒙層、吊起小程序等位置設置埋點。

同樣的道理，產品經理在考慮極致性的時候，也得考慮可行性。

聽說過一個極端的反面案例，一硬件廠商PM讓RD設計傳感器識別用戶虹膜顏色，依照識別結果動態調整點擊按鈕的算色。這種需求聽起來很極客，但實際上幾乎沒有實操的可能，實在是為難程序員。

產品經理OS：我不是，我沒有，別瞎說?。▓D片來自網絡）

話說回來，當有了明確的產品構想，成本過高不能成為阻礙構想落地的“死線”。

王堅做阿里云，前期摸索虧損了不少錢，受到不少非議，好在馬云清楚意識到云計算是未來，堅定地站在王堅這邊：每年對云計算投入10個億，連續投十年。事實證明，盡早布局云計算是正確的。

當然，不是所有公司都有阿里的財力，也不是所有公司負責人都有馬云那樣的眼光和魄力，最有實操性的還是在策略效益和開發成本之間取得平衡。

2）用戶體驗和商業變現的平衡

互聯網的模式大致可以總結為：互聯網公司為用戶提供問題解決方案或者效率提高服務，用價值吸引用戶，并在海量用戶盤子上構筑商業模式，通過會員、廣告等模式盈利，回過頭來更好地服務用戶。

其中，用戶體驗的重要性無需多言。當用戶體驗更好的時候，流量自然會增加，信息分發的上游和下游有更多的觸角，用戶得到更好的體驗。

比如美團的外賣業務滿足了用戶便捷飲食的需求，通過口碑推薦、超時賠付吸引了越來越多的用戶，又因為用戶基數大、需求旺盛的緣故吸引了越來越多的商家入駐，反過頭來帶給用戶更多的選擇。

此外，互聯網本身就具有邊際成本（單位新增產品帶來總成本的增量）低的特點，而隨著用戶和商家數量的快速增加，營銷成本被分攤，美團就擁有了更多整合變現資源的空間。

貝索斯的“亞馬遜飛輪”

商業變現是公司生存的前提，尤其在資本活力萎靡的今天，過去那種拿張PPT就能融錢的日子一去不復返，變現能力的重要性日益彰顯。

早期QQ吸引了海量用戶后，卻苦于找不到合適的變現模式，馬化騰甚至考慮把騰訊打包賣給廣東電信局。從一開始的QQ秀到現在的微信朋友圈植入原生化廣告，騰訊逐漸摸索出適合自己的變現道路，盈利規模不斷攀升。騰訊畢竟是幸運的，更多的企業倒在了沒能找到合適的商業變現問題上。

“圍繞生意展開的主義”（圖片來自網絡）

用戶體驗和商業變現能力都是互聯網企業生存的前置條件，二者似乎又站在了對立面上：

對于以廣告模式變現的企業，只考慮用戶體驗，最好永遠不要給用戶下發廣告——沒有廣告企業生存不下去；企業拼命下發廣告觸達用戶，恨不得十屏視頻有九條廣告——用戶使用體驗太差，就會選擇離開，沒有了用戶，企業也失去了存在的價值。

如何破局呢？

答案是在用戶體驗和商業變現能力之間達到折中。

比如上述例子的難點歸根到底可以聚焦成一個問題：adload設為多少，可以保證在不過分影響用戶體驗的前提下，實現高廣告收益？

實際上，演化成一個優化問題，邊界條件涉及兩方面指標：用戶側的留存、日活、停留時長等；商業側的廣告主消耗、CVR、CTR等。

strike a balance

有一說一，用戶體驗和商業變現能力之間的平衡狀態應該是一段動態可調整的區間，而不是單點。

比如學生放暑假了，就可以適當放寬游戲行業廣告的頻控，以期合理收割一波收益；發現素材普遍存在作弊雷同的情況，就把這類廣告頻控收緊一些，對用戶的打擾減少的同時，也能倒逼廣告主優化廣告素材（多說一句，對廣告位的爭奪有點像拍賣，以后有機會再討論）。

給用戶體驗和商業變現分別設定底線，互為鐐銬，在雙方底線上探索資源分配的最優解。究竟怎樣進行折中，就看公司秉持怎樣的策略了。

Why-what-how 的思維順序

讓我們閉上眼睛認真思考一個問題：面對一件陌生的任務，我們一般是怎么操作的？

是不是不管三七二十一，先做起來再說，畢竟“良好的開端是成功的一半”。于是，我們花費了大量的精力，經過無數艱難險阻，終于擺動出一點模樣。這時候，往往陷入到新的麻煩中：我當初要的是什么？我為什么要做這些？我的努力是不是白費了？！

這就是典型的how-what-why思維順序，即率先考慮方法，其次是方法施用的對象，最后才回到此番折騰的意義上來。

有類似經驗的朋友不難發現，“做出來的”和“想要的”之間，往往存在巨大的位錯；而被迫返工，帶來的是驚人類似的資源浪費和意志損耗。

在我們接受到的傳統教育中，推崇的是行動的巨人，強調甚至過分強調的是著手去做的重要性。尤其是在無從下手的時候，我們接受的普遍智慧是：那不妨隨便動手試試看。

這其實是一個巨大的誤區，“良好的開端”并不著眼在“開端”上，而在“良好的”上；后者的意思可以理解為深思熟慮、充分準備，短語的意思變成了想好了行動的意義并獻上執行力，成功的概率大大增加。行動的巨人沒有強大的思想，多半只是貿進的龐然大物；哪怕由于時間緊迫不得不先動手操練，也有必要及時回歸初心，“知道為什么出發，才能走得更遠”。

與how-what-why相對，我們應該有一種更為高效的行事思維，也就是Why-what-how。

一篇科研論文，先是對課題所處行業做背景介紹，引出自己工作的意義（why），接下來一組圖表明自己為了實現意義，做了哪些工作（what），最后附上實驗方法（how）。在寫文章階段，優秀的科研工作者（當然我不是）會花甚至一半的精力來寫introduction，為的就是說服編輯同時說服自己。接下來描述的具體工作是有價值的，這是文章發表的基石。

大道相通，做事時秉持這套思維，能夠極大降低返工的概率，獲得更大的收益。

“你是想繼續賣糖水，還是和我一起改變世界”，這句話為喬布斯為蘋果拉來了時任百事可樂公司總裁的斯卡利

參加公司實習轉正面試時，樣式部門負責人問了一個問題：西瓜視頻feed流的長視頻前貼廣告，怎么提高用戶點擊率？

我不假思索地把我認識世界里所有炫酷的樣式優化幾乎全答上去了，其中包括視頻下方廣告轉化按鈕的延時出現、算色和動效。這時候，他問我為什么要做樣式優化，我答為了原生化減少用戶反感、增加轉化入口……

沒等我答完，他追問：實現這些的目的的前提是什么？見我沒有回答，他繼續說：是用戶能夠看到。長視頻的使用場景以橫屏全屏播放為主，也就是說我在視頻下方位置進行的所有優化，用戶都看不到，完全是無用功。

現在回頭看，這道題是面試官挖的一個坑：給到的需求不一定全是有價值的需求，需要多問幾個why，深挖需求背后隱藏的價值。對于這個需求，應該先調研用戶橫豎屏看長視頻的比例、切換至橫屏的時機分布，然后評估需求有無必要進行，有必要的話再考慮算色動效這些具體的方法。

人是善于自驅的動物，多思考背景、意義，會有更足的動力啟程，一定比盲干上算得多。

借鑒他山之石

實習期的末段的一天下午，在公司內部做AB測試的平臺上，看到一個很有意思的問卷調查。征集的是對測試平臺的滿意度和改進意見，可能考慮到大家在平臺都有急活，很可能不耐煩地叉掉問卷，所以問卷被設計成叉選后變成小窗停留在角落，點擊后恢復。

我心血來潮地想，對于按點擊收費的開屏廣告而言，這個樣式是不是可以借鑒一下？

當時小范圍調研了一下，大家都有隨手叉選開屏廣告的習慣，并且相當比例的同事表示有時候進行叉選操作的同時發現廣告內容是自己感興趣，想要再仔細看，不過為時已晚。

更往前一步，如果用戶有同時瀏覽不同屏次內容的需求，是不是可以廣泛采納浮窗樣式？需求調研一直到實習期結束，回到學校沒多久，發現新版微信采用了浮窗了樣式，側面印證了當時的想法并不是天馬行空。

微信浮窗樣式

從AB測試平臺一個不起眼的問卷調研產生靈感火花，推及浮窗新樣式，可見借鑒的力量有多么強大。

借鑒并不是一件簡單的事，得有敏銳的嗅覺，察覺出有借鑒價值的新事物新現象，深挖背后邏輯，發掘更多可能性。

舉個例子：微信做了小程序，各家也紛紛布局小程序、快應用。

如果深挖一步，就可以看到這個現象的借鑒價值：小程序對于用戶的價值之一就是無需下載應用就可以玩起來，也就是坊間說的“先讓用戶爽了再考慮留存”，反映了用戶的“偷懶”心理——最好拿來就能玩，don’t make me think，中間所有的鏈路環節，通通不要。

思考到這，可以嘗試借鑒小程序對用戶心理的迎合：在游戲類廣告里加入試玩元素，無需跳轉下載，先在界面里試玩。用戶有良好的體驗后，試錯成本不復存在，下載概率大大提高，起碼對游戲本身有了了解。

當然，這對游戲本身的質量和獲客成本的預期有比較高的要求?！跋韧婧笙螺d”和某些頭腦靈光的瓜果小販“甜過初戀，不甜不收錢”是一個路數，對傳統販賣套路是降維打擊。

坦誠清晰

從生活小事說起，前段時間看了《非暴力溝通》，里頭提到非暴力溝通模式的四個要素：

書中原本的表述是：

• 準確清晰、客觀地描述觀察結果；
• 對于觀察結果的感受；
• 表達抽象的需求/價值觀；
• 提出具體到可以直接行動的請求。

非暴力溝通模式被封為圭臬，從模型要素可以看出，其出發點和落腳點都是再清晰不過的客觀事實。這樣的溝通模式人們樂于接受，又有著力點去推動建立親密關系，在職場上表現為工作有的放矢，淘汰無效環節。

有趣的是，在現實生活中，經?？梢钥吹奖┝贤ǖ挠白樱?/p>

對應上面提到的非暴力溝通模型，女生直接表達感受，模糊表達了“哄我”、“道歉”的抽象需求，卻把最重要的第1步和第4步忽略了。這時候，男生往往云里霧里莫名其妙惶惶不可終日，兩個人的關系無形間被推遠了。

這就是一個勁讓對方猜的惡果。

如果足夠坦誠清晰，很多問題并不能稱得上是問題，“哦，剛剛微信上找我的女生啊，我以前的同學，問我你的口紅色號呢，要不你和她說說？”

話說回來，如果女生就是不肯講原因不肯提具體要求，甚至質疑：你在和我講道理嗎？

2333，這道題太難了，遠遠超出我的能力范圍……

互相揣度的習慣，大抵上來源于我們的傳統文化強調的“含蓄”，具體體現為“話不說透”、“點到為止”的生存智慧，連山水畫也講究云遮霧繞的朦朧美，這些文化符號潛移默化地影響了我們為人處事的風格。

在企業實習的三個月，最直觀的感受是效率就是生命，而含蓄是效率的天敵?；迷S嵩的一句歌詞，“我們的含蓄是對生命的極大浪費”。為了保證效率，與人處事必須坦誠清晰，有一說一，沒一不說。

我有一個朋友（滑稽），剛實習的時候，他不習慣在群里瘋狂艾特別人，即便是拉的會有人遲到，也是私聊問到哪了、啥時候上線；沒聽懂不好意思麻煩別人，他自己默默查資料；找程序員下發字段，按照慣例沒有標明限定的附加創意，結果新來的打包同學給不支持的附加創意也下發了字段，導致返工……總之，時而不坦誠，時而不清晰，時而既不坦誠，又不清晰。

經過一段時間歷練才明白：同事都很忙，不在群里艾特或者加急一下，可能根本想不起來還有會議；公司尤其是互聯網公司大家都很熱心，都愿意解答疑惑，多請教能少走不少彎路；把所有細節標注清楚不留死角不僅是對自己負責，也是對同事負責。

沒有實現不了的請求，只有說不出口的請求；沒有所謂的不好意思麻煩別人，只是不希望被別人麻煩的封閉思想在作祟。身處互聯網，應該open-minded，清晰了當表明訴求，會有事半功倍的奇效。

敏捷

瞬息萬變的時代適者生存，足夠敏捷，才能在未來生存。

對產品經理而言，掌握“抓準需求-快速demo-丟進市場搜集反饋-迭代更新”的全套能力是生存法寶。不斷試錯，才能不斷成長。

信息時代賦予我們許多便利，各領域開源庫一應俱全，硬件軟件工具用遍得等到下輩子，只要想清楚為什么出發和想要去哪，就可以快速制作出模型；模型哪怕很粗糙，丟給用戶和市場去砥礪。

“小步快跑”遠比“閉門造車”來得好得多。當然，照之前提到的，設計好跑步前進的目的地和路線也至關重要。

可能是因為缺乏安全感的原因，人們都喜歡追求大而全，一個具體表現就是樂于收藏整理一大票工具網站的帖子，同時有一大票高贊回答在網羅堆砌所謂干貨。

收藏了會用嗎？

要用的時候能找到嗎？

找到以后會用嗎？

與其追求出于害怕錯過而收藏的那一點安全感，不如學習怎么快速搜索資源，怎么快速上手新事物，需要的時候拿起來用就好了。

人應該做工具的主宰，而不是相反。我們這些“普通的大多數”可能根本沒辦法做到“想起就能拿，拿來就能用，用了就能用好”。那么，不妨把相關領域的帖子的內容快速過一遍，建立一個大致框架。

談到工具想起一樁往事，實習期間旁邊的小前輩向我要一個APP數據分析網站，我一股腦把收藏的七麥、極光、艾瑞、易觀等10多個網站的帖子發給她，被問到這些網站有什么區別時竟然答不上來。她刪繁就簡隨機挑選了一個，十分鐘后生成了一份好看的數據報表，實現了她使用分析工具的目標。當時的感觸是：做那么多無用功干嘛，敏捷真好。

聚焦是敏捷的表兄弟，過于發散是不可能敏捷的。

不管能力幾何，精力總是有限的，找準一兩個點，鉆透了才能感受“大道至簡”、一通百通。

術：怎么做好產品經理（之我見）

數據導向

之前提到過，對產品經理數據能力要求越來越高：通過搜集數據和信息，經由邏輯分析得出解決方案，以數據驗證方案的有效性，一切基于數據。

在公司里，數據會由專門負責的程序員落到hive表，產品經理需要會寫sql從表里取數。在W3school網站里摸索半天，sql基本的增刪查改語句能過一遍，實際使用難點還是做不同表的join。

有了數據之后，就可以做邏輯分析了（說實話這一塊我還沒怎么接觸，以后有機會詳細寫）。

對于程序員小哥負責的數據獲取，菜鳥賽季的產品經理最好也能學一些爬蟲語句，熟悉數據是怎么來的、怎么存儲，大致怎么分析。

“別人家”（多語言呼叫中心）炫酷的可視化圖（圖片來自網絡）

組織會議

1）介紹人員

公司越來越普遍地從按部門架構轉型為按項目架構，這就導致參與新項目的各方之前并沒有實際接觸和了解。產品經理在會上先簡單介紹項目成員的基本情況，包括所在部門，職能，負責過的相關項目，讓大家對彼此有一個初步認識，及早確定會上與不同方討論的側重點>。

2）介紹需求背景

用三兩句話描述需求背景，然后展開（建議使用講故事的形式），接著講述需求的預期收益和具體實施方案。從小處講起，大家能有更直觀的感受。

3）頭腦風暴，記錄

頭腦風暴是會議的核心環節，直接決定了產出結果質量高低。

職能不同的小伙伴，關注點也不盡相同，在討論時產品經理除了引領發散以外，還要兼顧各方訴求。

一般而言，研發會關心需求的實操性、開發鏈路是否順暢，比如數據落表格式的一致性；用戶型產品經理注重能否帶來用戶平均停留時長、次留率等用戶側指標的提升；數據分析師則更關心同類需求實驗是否正向。預判小伙伴們可能存在的疑問并提前做好功課，也是會前必不可少的工作。

另外，會上做好記錄。

4）確認排期

討論完需求細節后，確定各方排期，保證需求能按照自身的排期走，或者根據各方排期調整需求的排期。如有必要在各方需求池填排期表，也做好記錄，防止遺漏。

5）會后同步to-do

開完會并不是萬事大吉，為了防止小伙伴們遺忘，及時同步會上確定的to-do及時間表，可以嘗試使用甘特圖，并設好提醒鬧鐘。

甘特圖示意（圖片來自網絡）

包裝showcase

Showcase和平臺的關系是：平臺用資源為showcase背書，showcase用模板效應為平臺賦能。有了好的示例產品，包裝起來show給用戶或者廣告主，能獲得口碑或者收益上的回報。

對個人而言也是如此，本質上參加面試就是在向企業推銷我們“這款產品”，“賣點”的多少、好壞，直接影響面試結果。最直觀用來展示“賣點”的就是自己的簡歷，建議用STAR原則包裝項目，附上做過的產品分析報告和個人網頁（如果有）二維碼，多用具體數據表征成就。

設計埋點（以廣告埋點為例）

埋點構成

埋點分類

埋點設計步驟

1. 確定廣告樣式和交互：包括素材的類型是圖片還是視頻，圖片的話是大圖還是組圖，視頻的話是橫板視頻還是豎版視頻；樣式有哪些更改；附加創意（表單提交、電話撥打、應用下載等），以及它們的觸發情況。
2. 確定需要的數據及埋點。
3. 確定每個埋點的字段和上報格式。

五方驗收

五方指哪五方？

客戶端QA、廣告側PM、廣告側DA、廣告側QA、客戶端RD。

具體流程

• 客戶端QA：按照埋點文檔的每個場景上報埋點；
• 廣告測PM：確保功能交互、埋點交互，確保QA驗證的埋點場景正確且沒有遺漏；
• 廣告測DA:確保上報埋點字段正確；
• 廣告測QA：確保上報埋點正常落庫，并記錄五方存在的問題；
• 客戶端RD：解決五方驗收中出現的問題。

一個需求的一生

流程補充說明：

• 1）產品需求文檔需要包含需求背景、預期收益、需求方案、埋點、實驗方案；
• 2）用戶側評審時，需要向用戶側RD講清楚需求，讓他們給出排期；
• 3）找DA確認新增埋點格式；
• 6）根據UI出稿，在平臺錄入新樣式，并報平臺產品經理審核；
• 7）case評審由端上QA主持，解決開發測試中存在的所有細節問題，需要PM參加；
• 8）可以訂閱發版日歷；
• 9）實驗郵件發給打包，抄送全組；
• 12）評估實驗需要充分理由，嚴謹歸因。一般半個月還負向或者正向不顯著的實驗，就可以考慮關停；
• 15）擴量、縮量、關停、推全量，均需要回復最初的實驗郵件。

一點題外話

這篇不成熟的帖文，謹作為遲到的暑期實習總結。

給看到的各位開了編輯權限：對它有任何不滿意的地方，歡迎留言。我們把它當成一款產品，一起迭代更新。

作者：謝杭烽；公眾號：杭一白

本文由 @謝杭烽 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議