優秀的產品經理，都做好了這7件事

【人人都需要的產品思維課】《人人都是產品經理》作者蘇傑帶班，教你頂尖產品經理的思維方式。戳此查看

本文長度為8000字，建議閱讀16分鐘

由於環境原因，我們接觸到的產品經理似乎總是「特別的」，以至於這個問題困擾了許多人。產品經理到底是什麼，我現在做的事情，真的是產品經理要做的事情嗎？

作者 / 枯葉

來源 / 公眾號 枯葉咖啡館

談到產品經理的工作，「雜，亂」，是最常聽到的定義，包括我本人也在許多場合提到了產品經理的工作內容很雜。

這有兩個原因，其一，我們並沒有掌握這些看上去雜亂任務背後的共性，其二，我們懶惰，相比長篇大論的陳訴以及費盡心思的沉澱，回答雜只需要一個字。

用雜亂來定義產品經理的工作內容，就如同用寫代碼來定義開發， 用畫圖來定義設計師一樣，只是一種自嘲的回應，並不是真正的定義。

這是一個工作的循環，一共是7個環節，分別是接受任務，分析，設計產品，交付產物，跟進進度，驗收發布，結果分析。我們來簡單講講每個階段的工作性質。

這裡提到的接受任務，原則上是產品經理一系列工作的起點，這些任務便是我們的需求。

正式工作環境里，我們的需求大部分通過任務性質被下發給我們的，這一點即便是產品負責人，產品總監也不例外，區別只是我們的任務不一樣而已。

以產品總監為例，我們會接受到要啟動某個新產品的任務，而這個任務或者是由企業上層決定，或者是由戰略決定，或者是由市場決定。

其本質上更多的是任務，而不是想做什麼就做什麼。我們來看看幾種典型的任務：

當然，除了上級的直接要求以外，我們通過對市場，對用戶的了解，也能發現一些問題，發現一些機會，而這部分內容，也同樣是任務性質的，只是我們自己扮演者任務分配的角色。

於我個人而言，我其實很排斥「想法」，更多的是喜歡以「任務」的概念來驅動項目，想法過於偶然了，具備十足的不確定性，同時又過於廉價，誰沒有幾個想法呢？而任務卻不一樣，具備一定要達成的潛意識，我們接受任務或者下發任務時，都持有必須完成的心理.

分析是一個大類的環節，這樣的稱呼大概會讓你感到迷惑，我們先來看看那，分析階段都包含了那些事情。

市場調研，用戶調研，需求調研，技術調研，數據分析，kano模型，馬斯洛需求層次，用戶畫像等等.

在分析階段，我們運用各種各樣的方法來完成對任務的分析，是的，我們所知道的許多看似很高端的名詞，大概都是在分析階段的某種方法論。

產品經理是個強思考的角色，這裡的強思考主要就體現在分析階段。

分析階段在任務接受之後，我們分析的目的是如何去達成任務。

分析的目的在於尋找達成目的的方法，而不是去尋找拒絕任務的理由

很多時候，我們在分析時會有錯誤的思路，我們會下意識的去尋找能夠幫我們拒絕執行任務的理由，這是一種潛意識，是我們需要克服的困難。

我深刻的知曉許多任務，在我們接受時，就已經存在不可執行性，從一開始就註定了失敗的，但很遺憾，我們對此無能為力。

就像是士兵一樣，服從是軍人的天職，達成任務便是我們產品經理的天職，儘管他多麼的離譜。

要知道，許多偉大的事情，都是在不可能完成的情況下被完成了。

產品經理接受的任務，極具挑戰性質，80%以上的任務都是屬於不可能完成的任務.我們的角色，本就是將不可能變為可能，將可能變為現實.

所以，你還在排斥任務嗎？或者你是否做好心理準備， 迎接一個又一個的不可能完成的任務。

再來說到具體的各種方法論，如同我們剛才列舉的許多方法一樣，其目的都是為了幫助我們分析。我們已然清楚分析的目的是什麼了，那如何分析便是這些方法論發揮作用的時候了。

這些方法論並不神秘，只是包裝過於華麗了，我們簡單列舉幾種分析方法吧。

市場調研

我們在獲取需求時，最先做的就是市場調研，簡單的來講，就是去分析任務所對應的目標市場，具備什麼樣的特點，需要什麼樣的服務。

需要注意的是，此處調研對象是「市場」，比如出行市場，IT市場

用戶調研

任何一個產品都是被某人所使用的，我們藉助市場調研明確自己要做什麼服務以後，就需要做用戶調研了。

用戶調研的落腳點在於某人，正確的講，應該是某類性的群體

技術調研

技術調研是在有一定想法以後，我們找上開發人員，簡單評估一下技術的實現成本，如果某個idea的實現成本 過高，我們可能就要重新想想方案了，許多產品經理在設計產品時，會忽略技術實現難度及成本，這是不可取的。

在應用層面，大部分的需求都是不需要強行攻關的，比如我們要實現支付功能，但並不是一定要自己開發一套支付系統以及安全系統，直接接入第三方就好啦，當然資金量很大時，我們的收益足夠平衡我們的成本時，就很有必要自己開發了。

kano模型

kano模型是作為劃分需求優先順序的方法被創造出來的。

需求總是很多的，但前人經過研究，提取出了需求的共性，並總結成了需求的五個類型。

使用這個方法，我們可以很輕易的判斷某個需求屬於何種類型，再藉助該類型需求的價值以及效應，最終來判斷出某個需求的優先順序和重要性。

產品是被精心設計出來的，這是我所遵循的產品觀念，在我體驗一款新產品時，我會嘗試站在對方的角色，來思考。

如果是我來做，我會如何設計呢？

當我們結束了分析階段後，我們會根據自己掌握的信息，根據自己分析所總結出來的信息，來設計產品。

我們所使用的每一個參數，都是精心設計的，不僅僅是參數，一句提示文案，也是可以被精心設計的。

只是我發現許多產品落地很差，這點在設計上可以充分體現出來。

於分析階段相同，設計產品也有諸多的方法，並且經常被我們使用到，只是很多時候，我們並不曾注意到。

設計產品的方法：結構設計， 業務設計， 流程設計， 原型設計，情感設計，MVP設計原理等。

產品經理行業，由於外界盛傳的0門檻或者門檻低，導致許多朋友尚未準備好，就進入到這個行業，再加上目前尚未出現通用的技能體系，在實際工作中，許多leader ，許多產品老人，都尚未將自己的經驗沉澱，最終的結果，是比興奮更為巨大的迷茫。

迷茫：

其實沒有那麼複雜，這個行業遠比我們想像的還要接近事物的本質，你所欠缺的只是應用的技能，以及對技能的熟練度。

在產品設計階段，我們的差距更多的體現在思考面積的強弱上，我們掌握的設計方法越多，便越能設計出好的產品。

最合適的就是最好的。

在不同的時間，不同的階段，不同的環境里，我們需要使用不同的設計方法，這就需要我們不斷的充實自己，不斷的學習。

設計方法之間是不存在正確或者錯誤的， 這完全取決於我們是否在合適的地方，用了合適的方法。

因此，我們無需因為自己設計出來的產品被排斥，被冷淡，而動搖自身的信念，也無需為了失敗而感到沮喪。

我們所欠缺的，其實只是方法，那便學習方法就好了，不需要漫無目的的學習。

這些方法並不在已有的產品相關書籍里，而是在於傳統行業的金科定律里，相對歷史悠久的傳統行業，互聯網作為一個行業而言，顯得無比稚嫩。

現在大家所認識的kano模型，金字塔原理，馬斯洛需求層次，沒有任何一個方法論是屬於這個行業原創的，均是來自於對前人知識的學習以及再應用

要知道，早在互聯網之前，人們就已經設計出了許多精美的」產品「，我們其實早已掌握了產品設計的」精髓「，我們也早已接觸了數之不盡的」產品「。

一段文字，一本書，一部電影，一場真人遊戲，乃至我們所使用的碗筷，衣物，都是被作為」產品「被設計出來的。

因此， 你，無需感到畏懼，也無需感到迷茫。

我一直信奉團隊至上的觀點，個人的力量無論多麼強大，也需要團隊的支撐。

我們在工作中，常常感嘆，有一位助理多好，那就能幫我們分擔許多工作了。

我們希望有位助理，或者有人協助，本質上是對個人能力的一種危險預警，潛意識在告訴我們，你不行了，你需要團隊。

正確處理團隊關係，高質量提供交付產物，是我們獲得團隊幫助所必須要付出的代價。與不同角色合作，需要交付不同的產物，需要記住的是，沒有誰是誰肚子里的蛔蟲，也不要寄希望和誰心意相通，正如我們無法揣測BOSS的想法，放之他人，也是相同的。

在我們與團隊合作的過程中，90%以上的分歧，不愉快都是因為產品經理沒有嚴謹的對待自己交付的產物。

原型圖和需求文檔 是我們最基礎的兩份輸出產物，可直到現在，仍然有許多產品經理以思維，思考的名譽，剝削產物的意義。

產品經理確實是一個強思考的行業，但這不代表我們不需要執行，不需要輸出。不需要將我們的思考過程交付給團隊。

我把我應該做的做完，我就成功了，置於對方有沒有做完，抱歉，這不是我的責任，可我們真的知道自己應該做哪些事情嗎？

絕大部分的時候，我們是不知道自己要做哪些事情的，這是這類角色的一個特性，似乎沒有人為我們安排明確的任務，於是，我們出現了各種問題，各種花式秀矛盾，如果我們是開發人員，我大概會這麼說。

你不是來寫代碼的，你是來寫bug的。

我們來簡單羅列一下要交付的產物：原型圖，原型全景圖，需求文檔，變更記錄，業務流程圖，數據流向圖，迭代故事，材料準備，溝通，調整。

並沒有完全列舉完，我並不想去堆砌交付產物，這似乎沒有價值。

交付產物並不是越多越好，而是越有效越好。

以需求文檔舉例，我們可以看看自己寫的需求文檔，是否方便研發閱讀，是否有歧義，是否已經將功能大部分都覆蓋了，一份好的需求文檔可以極大的增加團隊效率，減少低效時間的耗損。

我曾關注過一個現象，相同的團隊，相同量級的需求，實際開發中所消耗時間的差異高達 60% 期間，發生變化的只是需求文檔更為精緻，交付產物質量更高。

仔細想想，平時耽誤團隊時間的，不恰恰是因為需求描述不清晰產生的溝通成本，調整成本，以及由於需求顆粒度不夠導致的變更成本嗎？

而這些問題，只是需要提高我們交付產物的質量，就能有效解決。

所謂的交付產物 是指接力的介質，產品經理所需要做的事情做好了，然後慎重的將我們的努力交給我們的團隊。

這是一個很莊重的儀式，很嚴肅，是對團隊的尊重，也是對自己的尊重。

在野外，我們獵殺了一頭野豬，大概有100kg，我們嫌棄搬運太重了，就只切了一條豬腿，帶回部落，大概只有10kg。當我們再回到狩獵地時，被獵殺的野豬已經被其他野獸吃完了。

野獸就是我們所接受的任務，由於嫌棄麻煩，我們很粗暴的對待自己的原型圖，很粗暴的對待需求文檔，對待我們的交付產物。

似乎是沒有時間，實際上只是因為我們偷懶，而且還是很不聰明的一種偷懶。

如果用正確的方法畫原型圖，寫需求文檔，你會發現，這樣才是最大限度的偷懶。

現在你知道如何面對交付產物了嗎？ 他並不難，只是需要我們額外的細心，額外的認真，同時，也需要我們尊重團隊，尊重自己。

切忌將產品經理等同於思考者，我們除了強思考以外，也是團隊中的一份子，思維固然重要，團隊力量卻遠勝於個人的思維

想的再多，做不出來，有什麼作用呢？

產品經理需要跟進版本進度，毫無疑問，我需要再強調一下，只有思想，只有想法，是無法做好產品經理的，我們不缺少想法，每一天我們都有許多想法，成出不窮。

2011年，在我第一次創業時，認識了一位灰色產業的朋友，他告訴了我一個很棒的想法，他想要消滅錢包，消滅現金。

人們每天買東西要帶錢包，多麼麻煩，還要找零，現在手機那麼方便，做個軟體出來，直接掃一下就能付錢，多方便。

光是手機付費還不夠，金額太高，用手機也不方便，我們還得帶個手機，最好還是刷身份證，刷臉，這樣什麼都不用帶，要付錢的時候，掃一下臉就好了。

很遺憾，他不是馬雲，也不是馬化騰，他只是一位不那麼普通的普通人，現在，人們手機支付已經非常方便了，平時的生活中，我也很少再用現金了。

移動支付產品經理的想法與我這位朋友的想法並沒有什麼不同，但將想法實現出來卻是截然不同的兩個概念。

想法固然重要，但也只是重要，真正起到決定因素的，還看我們的做法。

當我們把產物交付給團隊以後，我們的事情並沒有結束，你需要留意一下，此時你的身份已經變化了。

你的產品從交付的時候開始，出現了變化， 此時，團隊就是你的產品，團隊效率就是你的產品質量。

如果一個團隊中沒有更高的角色，那產品經理就是這個團隊的leader，產品負責人就要對這個產品負起責任，還要對這個團隊負起責任。

早會，需求卡片，周會，進度跟蹤，風險報警，日報，周報，需求調整，需求管理，資源協調。

這些是我們最常看見的在交付後的任務，儘管我們在交付產物之前，有做技術調研和需求評審，但這並不能保證在開發過程中出現需求障礙。

實際上，無論我們的技術調研和需求評審做的多麼細緻，總會出現意料之外的問題，這是因為我們的開發同學，在技術調研和評審時，只能根據大概情況進行預測，而在執行時，卻會考慮的更深更全面。

在研發階段，開發會遇到一些較為複雜的需求，會消耗較多的時間，此時，我們就需要根據開發的反饋進行再評估。

慎用技術強攻關，大部分的產品並不是以技術決定勝負的，超過80%的團隊，並不需要過於強硬的技術，尤其是小團隊，初創團隊。（技術性項目例外）

在我接觸的許多項目中，再也沒有任何一個方法比修改產品方案更快捷了，當出現研發障礙時，修改需求方案，能夠節省1天至1個月以上的時間，這需要我們每天跟進跟進研發進度。

仔細想想，我們真的有必要花費這麼大的成本去實現某個功能嗎？

當我們參與到進度跟進時，會收穫許多的調整，為了避免出現需求不統一，也是為了提高交付給測試同學的產物，我們還需要對需求進行有效管理。

需求管理

這並不是一件簡單的事情，需要我們掌握一些方法，比如嘗試用excel來編寫需求文檔，並且在需求文檔的撰寫過程中，遵守一些規範。

資源協調

我帶產品團隊時，會經歷兩次驗收，這裡提到的驗收是整體驗收，我並不是很提倡在開發過程中頻繁打包，但我也很理解許多團隊，都會頻繁的打包驗收。

當開發階段結束後，測試介入前，產品經理有義務進行一次驗收，目的是確保主要功能邏輯與需求符合，沒有遺漏需求功能，可以稱之為需求驗收。

當測試結束後，產品經理還需要再進行一次驗收，目的是確保產品無明顯Bug，能夠正常使用，此時，才是真的產品驗收。

需求驗收

有時，我們需要做好心理準備，也許開發實現的功能與我們的想像的有所區別，甚至南轅北轍。

我們首先需要確認一下，有沒有需求遺漏的，通常情況下，會有開發漏做了部分功能，此時，我們就要判斷這部分功能是否可放到下個版本迭代，還是當前版本非常重要的功能。

面對一些實現效果與預期效果不一致的功能，我們還要冷靜的分析判斷，開發這樣的調整，能否接受，如果能接受，那就要根據調整結果，來修訂我們的交付產物。

原則上，我們希望儘快的切換軌道，需求驗收是一個階段，更多的卻是一個節點，我們要把關，但也要靈活，盡量避免過多時間的反覆調整。

如何判斷哪些需求調整是可被允許的，哪些需求遺漏是可悲允許的，便是我們在這個階段所需要鍛煉提升的技能，MVP原則在這個環節也是適用的。

產品驗收

確保產品上線沒有明顯BUG，不只是測試同學的職責，也是產品經理的職責，當然，我們無法像測試同學一樣細緻，成體系，成規範的進行模擬操作。

但我們卻可以從自己的角色出發，確保主要路徑不出明顯bug，我們需要保證業務是正常的，核心功能是能被使用的，大部分使用場景是沒有明顯Bug的。

同時，產品驗收階段也是我們對需求邏輯的最後審核階段，我們的業務邏輯，功能邏輯這樣做是否正確。

這需要我們站在用戶的角色，真實的進行體驗，可以說產品驗收時，我們便是這個新功能的第一位真實用戶。

當我們已經完成產品驗收了，此時，我們就會通知開發同學。沒有問題，可以打包了。

打包的意思是將已經驗收的程序獨立生成安裝包，在android平台，我們往往需要打多個渠道包，每個渠道一個唯一的標示，這樣我們就能知道我們的用戶都是從哪裡下載的。

當然，發布一個版本可不是這麼簡單的。

產品發布

從硬性角度來講，我們要為產品發布準備一些材料，比如更新文案，上傳安裝包以供審核，特別是IOS平台，要預算3-7天的時間進行審核，且可能審核被拒絕。

從軟性角度來講，當我們發布一些特殊的版本時，還需要配合運營的規劃擬定發布策略，必要時，可以封包待發布。

即，我們將可發布的版本準備好，但卻不真的發布，等待機會成熟，再進行發布。

為什麼在一些重要節慶日，成熟的產品都能準時準點的上線特殊版本呢？比如聖誕節版本，如果延期一兩天，是否表示這個版本的時間完全浪費了，畢竟聖誕節可不會等你兩天。

特殊的版本，我們往往會提前將安裝包準備好，進入封包待發布的狀態，只要等待某個特定的時間，便可以直接發布版本。

這是最後一個環節了，也是最容易被大家忽視的環節，我們習慣性的將希望寄托在下個版本，寄托在下個功能，卻很少對結果進行分析。

當我們產品已經發布了，此時要注意觀察相應，觀察數據，通過實際市場結果，我們再來思考和評估。

這個功能是否被用戶所喜歡，用戶使用情況怎麼樣？有沒有提高的方法？