產品經理們從每個項目中都總結出什麼？

01-18

總結經驗教訓是最好的成長機會，分享者往往是收益最大的人，同時分享同時是展示自己的好機會，請大家暢所欲言。
包括產品設計，產品運營，產品迭代都可以聊一下，成功為什麼，失敗又為什麼？

說幾點簡單的感受：

1、一個項目失敗的根本原因，往往是根本就「沒有需求」。

大至bat，小至創業公司，我認為失敗的原因，最大概率的都會是這個點，大公司的vp最喜歡結合行業趨勢然後做戰略調整，這樣的調整一般來說是符合董事會對大方向的預期的，但卻不一定吻合生態，吻合場景，很多時候，需求和玩法都是管理層臆想出來的，沒有數據支持，邏輯也不是說的特別清楚就直接上了，我相信，這樣的事情，很普遍。

只可惜在一個錯誤的方向上，怎麼努力都是失敗的，而且投入的資源越優秀反而會陷的越深。

2、在需求正確的方向上，UI設計不會是項目失敗的最重要原因

見過不少入門的PM特別在意UI，特別是做App的同學，很專註於追求極致的體驗，但我所見過的這類產品，年終的命運都是被砍掉，因為交互和UI的炫酷，並不是直接決定用戶留存的原因，我們看下各大成功的產品的歷史，可以發現早期的它們基本都丑的不可直視，交互和UI的優化基本都是非常成熟之後才做到高分。

一個產品能否存活，基本上取決於它能否在痛點場景一擊中的，性能和效率都要比UI重要的多（少數需求重心基本在UI上產品除外）。

有句老話：幸福的家庭都是相似的,不幸的家庭各有各的不幸。

產品也是這樣，不同產品總結出來的失敗或成功經驗非常多樣，會發現，只對該場景下或那個發展時期適用，自己想借鑒，亂套必死。

題主希望看大家總結，無非是想怎麼少走彎路，多走正確的選擇。我嘗試抽象，回答看看。

看題目的用詞，應該是說互聯網產品。互聯網產品（項目）又分兩類：

A.任務項目

即被分配負責一個產品和項目

B.自發項目

包括創業做產品和在公司中自發立新產品

先來說第一種：任務項目

首先要強調的是，「總結」是階段性動作，拿到項目了解清楚需要總結，啟動後每個周期需要總結，完成或未完成階段性目標需要總結，甚至每天自己都可以自省總結。而不是等項目死掉了才來哀悼總結。

任務項目需要總結：

1.產品對公司的戰略地位

既然老闆已經把產品分配下來，ta肯定對這個產品有一定的思考。作為之後的負責人，你要完整了解清楚公司或上司老闆為什麼要做這個產品。

有的產品就是用來防禦，你卻以為是主力產品，動輒說要建大生態，大平台，就是作死；

有的產品需要發展成現金牛，你卻不以為然，那麼你遲早被幹掉。

戰略地位的分類有空再細說，在大公司里的情況更加複雜，這裡不展開。

2.你的角色

PM就是PM，還有什麼角色？PM的角色差異可大了。你不僅僅是一個產品策劃者，要做好一個產品，還需要承擔更多。從以下幾個方面體現：

2.1 誰是真正的產品經理——老闆or你

如果老闆想得非常清楚且你也相信他的判斷，那就好好執行；如果ta其實沒有想得很清楚，作為產品負責人的你，一定要承擔起這個甜蜜的責任；

2.2 推手——資源範圍

包括推廣資源、開發設計資源，下屬等，是老闆已經給到你，還是需要自己爭取。有的產品本來可以發展得大，但以為資源就是眼前那麼多了，受到制約；

2.3 項目管理

項目的進度管理，有的公司有項目經理協助，但實際上，產品負責人必須了解並監控著，時間窗口非常重要。

都說產品經理最有發展成CEO的潛力，因為要承擔並做好的事非常多，需要自己思考，自動補位和撲火，當然了，需要有側重地撲。這裡列不完，有空再增加。

3.產品定位是否準確

項目開始時，根據公司戰略、市場分析、用戶分析，應該對這個產品有一定的定位。在項目進行中，需要不斷審視和放眼看市場，這個定位對不對。

4.中期目標是否有偏差

確定長期戰略目標，定出中期目標，需審視是否有偏差。比如長期目標是做全球用戶量第一的陌生人社交app，中期目標是3年內中國用戶要達到3億，海外用戶5000w。

5.分析所有影響因素，分解數據單元

需要知道這個產品所處的環境及要會影響目標達成的核心和非核心因素。

舉個栗子：

這樣一直分析到最小數據單元，就很清晰各個環節的影響因素。當然，前提是分析得對。

6.短期目標是否選好點

分析了解各個因素後，還需要根據上述情況，定出優先順序。比如現在的短板是老用戶流失，而這個問題最影響中期目標的實現，則這個月的產品優化方向是向著這個目標改進的。

7.執行是否順利

要知道很多時候什麼都沒錯，就是死在執行上，可能是人，可能是流程。

100.自己是最大瓶頸？

歸因理論指出，人們普遍把失敗的原因歸結到自己以外的因素上，把成功的原因歸結為自己。

有見過一些作出小成績的產品經理認為自己就是神，產品成功完全是因為自己。其實需要知道，自己的成功在於把對的判斷和對的環節有機串聯起來了，不如總結下，是怎麼把事情做對的，如何找到規律，擴展或複製。

如果盡了最大努力，做好了所有環節，也認為做了正確的判斷，都還是沒有好結果，那麼問題可能是出在自己身上，有能力或眼界的限制。多尋求幫助，終身學習。

第二種：自發項目，包括創業做產品和在公司中自發立新產品。做這類產品真的就是操著CEO的心，做著打雜的事，不省心的事不要太多。

簡單粗暴總結：

1.戰略規劃

1.1市場是否夠大

1.2是否剛需，不是的話，使用頻次是否能高

1.3盈利模式

1.4產業鏈分析

1.5競爭對手及自身核心競爭力

2.執行層面

2.1人

2.2做什麼、不做什麼

2.3怎麼做最能借力

哎呀太長了說不下去。結束語就這樣好嗎

其實最好的總結是在實踐中思考，知乎得來終覺淺。

從接觸互聯網再早一些的時候，已經開始接觸一些項目了。大大小小做了很多的自主項目、創業項目、實習公司的項目。今天在知乎看到一個問題，內容是『產品經理們從每個項目中都總結出什麼？』，不禁就想總結一下，也介紹介紹自己之前的項目經歷。

先把我總結的幾條放在最前面，排名不分先後。

1.任何產品都是一個大工程，絕對沒有想像的那麼簡單。只有真正去做過產品，才會體會到產品、交互、視覺設計、開發等有著無窮無盡的問題，產品經理也絕不是提提想法，指指方向這麼簡單。

2.文檔的重要性。尤其是小團隊，做項目非常不看中文檔，包括現在的我自己。但事實上，永遠不要高估你自己的判斷力，很有可能你今天信誓旦旦做出的改版明天你自己就要推翻，你也很難保證你口頭說的改動人家就能完全理解和記住，認真改文檔去吧，做好版本管理。

3.考慮所有情況。尤其在交互設計上，你給出的原型稿一定要包含所有的狀況，包括極端情況、用戶看似不可能的操作等，不要等著開發哥哥過來問你。

4.精益原則，即儘快拿出最小化可用版本，驗證產品業務模式之後再快速迭代。這會比花費大量時間去做設計、詳盡的開發要有效、科學的多，因為光靠想，有太多問題你永遠也預料不到。

5.有的時候，你的產品不是要顛覆某一個舊事務，而是只要在不引入新問題的前提下，只要提供任何一個便利，就足夠了。

6.產品形態、功能和邏輯模式是最重要的。剛入行的新人一定要不要過份追求極致體驗和極致視覺，往往那些東西會極大地佔用時間，拖慢進度，甚至最後東西都沒做出來，項目就要就要結束了。

7.不要把自己當做用戶典型，也不要輕易否定別人的想法。除去明顯的硬傷，一切都要以事實為準，因此調研、訪談和測試都不是走過場的，都是十分重要的。

8.不要把競品當白痴。經常有人說某某產品的產品經理腦子進水了吧，開發出這樣一個功能。基本上，剛入門的產品經理你能想到的問題，競品早就考慮過了。而且很大程度上，讓你來做，連做的和目前競品一樣你都做不到。

有其他想到的再慢慢補充。

下面是講故事時間，有些內容已經專門寫過文章分享，覺得無聊就可以不看啦。

時間順序，由淺到深來隨便聊聊吧。

2012年

學生創業

簡介：參與學生創業團隊，身份為綜合部成員，公司產品為一款車載 RFID 系統。當時還是剛升到大三，主要在團隊中的工作是參加挑戰杯創業計劃大賽，由於能力和閱歷的限制，自己的貢獻是比較少的，更多的是製作文案，設計PPT 等。

我本人已經於13年離開團隊，離開的原因是公司正式脫離學校，需要全職員工，而我個人打算繼續讀研深造。公司目前依然存在，已經得到想當的投資，幾個當時留下來的創始人都過的還不錯，非常充實。

我現在回過頭來看學生創業，是很複雜的心情，後來也有很多人問我關於學生創業的想法。這次創業，是我第一次真正參加一個創業團隊，並且真的有好幾個前輩放棄了高薪工作留下來拼搏。總的來說，學生創業是一次很好的試錯機會，因為都沒有太大的經濟壓力，學業對我們來說也不是什麼難事，在學校做一些想做的事，是很難得的。但是反過來說，學生創業真的很難成功，因為學生本身不穩定（考試、就業、升學，還有心理變化）、不成熟，導致團隊很難黏合到一起，也容易出現各種分歧；學生眼界狹隘，能力有限，很多學生（大牛不在此列）創業都容易陷入自我意識過強的境地，覺得自己很牛逼，但其實，和真正走出社會的人相比，說是過家家一點也不過分。

項目上，如果在校內創業，一般都會和學校有很多的諸如場地、資金和人員的糾纏。尤其是那些做的好的團隊，除了在創業方向上會不斷受到學校干擾以外，還經常要應付檢查、彙報、參評各種獎項的雜事，這對創業都是極大的干擾——不僅干擾項目進程，更是干擾成員的軍心。

因此，通過這一階段的創業和項目，對我而言最大的收穫就是一定要儘早脫離學生的眼界和氛圍，投入到真正的實戰當中。

2012年

隨心驛站項目

簡介：這是我在本校發起的一個快遞集散中心，主要是整合了校園周邊雜亂的快遞情況，實現一體化操作流程。通過在校內租用了一個場地，將所有快遞統一代理，並提供代管、寄件等服務。我在一起設計完基本業務模式，安頓好店鋪之後離開團隊（此項目歸屬於上面那個創業公司項目，離開原因同上）。

驛站已成為當時所在創業公司的一個核心項目之一，目前與阿里巴巴菜鳥物流達成合作，相關技術被運用到阿里小郵局，目前已有南京多所高校採用。

（註：離開團隊後的成果已與我無關，包括與阿里的業務合作，系統級開發等）

從這個項目中，我開始逐漸了解到摸清用戶需求是一件多麼重要的事，我也正是從自己身邊覺得不方便的事開始去改變。學校附近的快遞情況紛亂，無論是便捷性、安全性和取件體驗都是非常差的，那麼通過和學校溝通集中代理快遞的方式，就可以很大程度上解決這些問題。同時，由於物流終端環節人工成本是最大的開銷，那麼利用互聯網技術，開發一些智能產品，可以極大地提升效率。

另一方面，我發現項目的邏輯、流程規劃十分重要，很多想法和收穫都是從實際運作當中獲得的，而這些都是靠空想不能得到的。

2013年

愛尚黑莓

簡介：愛尚是我和兩個小夥伴一起創辦的黑莓社區。同時，我還負責以社區為名義的進行了一年多的黑莓開發工作，以及與黑莓總部的一系列溝通協調。

愛尚是目前國內最大的BlackBerry 10社區，註冊用戶超過一萬，日均 PV 在十萬左右。全社區無廣告，用戶反響較好。

這次項目是我和兩位在社會上多年打拚的前輩一起做的，更多的也是他們在帶領我前進，從這個項目和他們身上我學到了很多很多。從這個階段開始，我正式向產品經理的職業方向邁進。

興趣是最好的老師，這句話真的沒錯。當時三個人因為喜歡黑莓手機而聚到一起，看準了BlackBerry 10 OS 發布前的空隙，一方面在國內組建了愛尚黑莓社區，另一方面則搶先開始進行該新系統下的 App 開發——因此看準時機也是非常重要。有的時候，選擇小眾路線會給你帶來更多的收穫，畢竟一個初學者立即投身於 iOS 和 Android 大潮，是很難出頭的。

2014年

東大通

簡介：東大通是我和同學們一起創辦的東南大學本地社區，主要有活動發布、校內問答和二手市場三個板塊，我的主要工作是對網站進行了第二次的交互及功能改版。

總的來說這個項目應該算是失敗的，到目前為止，用戶數非常少，而且在產品定位和功能上也有很多問題。但是我真心很感激這個項目，讓我從一個門外漢向初學者邁進。在項目中，我主要是繪製新版網站的交互稿，基本是天天被視覺設計學姐罵的狗血淋頭。我第一次認真地考慮，除了主要功能之外，每個頁面對於不同情況下的狀態都是要逐一設計的；每一個按鈕的不同效果，不同操作，都是要說明的；每一個控制項對於極端情況，都是要重點考慮的。

在實際自己設計之前，我從來沒有想過一個產品居然有這麼多複雜的方方面面。而通過這個項目，我不僅熟讀了 iOS、Android 和通用的網頁設計規範，更是對整體項目設計流程有了一定的把握，幫助我向產品設計師邁出了第一步。

來人外賣

簡介：來人外賣是我和幾個小夥伴一起做的第三方眾包模式外賣派送解決方案。簡單來說，就是用戶既可以點餐，也可以充當派送員，賺取外快。

這個項目目前已經暫時放棄了，原因在這篇文章（初創項目失敗個案分享：為什麼走不下去了？）里有我個人的總結。

這是我從頭到尾自己來繪製一個產品的全部內容的項目，當然，以現在的眼光來看，我做的很不夠，考慮的也很不細緻。

Change

我是一個閑不住的人，有想法就想去做出來試試。經過前面這麼多項目經歷，無論是暫時成功的，還是失敗的，都給我帶來了無窮的財富和珍貴的經驗。所以呢，接下來我又和幾個夥伴一起嘗試一個新的項目，敬請期待。

分享兩點成功經驗吧，無論對於做產品還是別的都適用，如果有人贊我再來補充實際案例。

1.把得了方向，hold住執行

2.有邏輯，有優先順序

很多人會覺得說了等於沒說，但道理是淳樸的，就看做不做得到了。

過30贊同了，我來補充一個運營案例，用來印證第一點。

曾經階段性負責過一個產品上市，產品上市時已經投入大量資源，在渠道鋪得極廣，曝光高於同類產品的情況下，新進用戶數遠低於其它產品。但由於此產品具有很強的戰略意義，於是團隊又低調的拉入我與另外一名資深同事再嘗試一次推廣，這次推廣就沒有那麼多的費用了，所以挑戰是有的。

首先，需要分析上一次失敗的原因，我總結下來有兩點：傳遞了錯誤的利益點所以無法打動用戶、執行層面太差以至於有意向的用戶也無法獲得更多信息並轉化（用戶見到推廣活動頁面，即使感興趣，需要六七步才能獲得有效信息並進行轉化！）

於是，我們重新定位了用戶群、基於用戶需求重新梳理了利益點，並用非常清晰的語句表達；同時，與所有渠道重新開始談判、規劃，要求所有的活動形式都明確用於拉新，所有的頁面設計必須符合一致畫風，突出唯一的利益信息，流程都能按我們的需求優化，轉化跳轉不能超出3步，大多1~2步能完成。而且，所有的渠道都需要按我們的節奏上線和推廣。

最後的結果是，這一輪的小規模上市推廣相比上一次大規模投入時，完成數三倍於KPI，絕對新進人數增長N倍，而且轉化率比之前還有提升。

能取得這樣的結果，方向、執行缺一不可。方向對，沒執行，無法落地；執行好，方向不對，使不上勁。

工作經驗不多，總結一些個人經驗教訓～

需求收集：

1. 收集需求時，要問「目的是什麼」，而不是「這個你是否需要」，因為對他們來講，有總比沒有好，但對產品來講，只會更加複雜更加難以使用。

2. 收集需求時你收到的大部分可能都是方案，可能是「這裡給我加個一個功能，這裡跟我加些數據」之類的，而你要做的，就是弄清楚是為什麼你想要這個功能？你想要解決什麼問題？你提的方案有沒有問題，有問題的話，我有沒有更好的方案等等，一定要弄清楚，需求是產品的根本。

3. 要驗證每個需求，需求我分為三類：單一的獨立需求（易解決），單一的但牽涉多方的需求（很可能某個需求背後其實牽涉多個模塊，多個系統，難解決），最後一個就是其實需求根本就不存在。

4. 收集的需求，可能是屬於某個模塊優化類的，如果你不了解，那麼你一定要想方設法把這個模塊弄清楚，問技術，問設計，問相關的各方，不要覺得不好意思會打擾別人，每個地方都要弄清楚，你最終目的就是做好優化方案，如果沒弄清楚，你的優化方案則會是漏洞百出，後期會讓大家對你產生很多質疑及不信任。

產品規劃：

1. 做產品時要不斷與上游及下游角色溝通。上游是上級，及時進行產品進度彙報及需要協調的資源等等；下游是設計，開發等，對於設計，就要溝通一些頁面寬度，還有此次項目是否會進行設計的大幅改動等等，對於開發，可能有些項目是基於已運行的項目基礎之上，所以開發會把某些模塊直接套用過來，這個要溝通清楚，避免後期做無謂的勞動。

2. 產品規劃時先別考慮技術的問題，因為這樣會讓你思考時會有很多顧忌，不利於規劃思路的拓展，但有些你你認為確實很複雜的地方可跟技術提前溝通。

3. 要替開發人員想一下，對於後期要變動的模塊，提前溝通一下，做成可配置的，具體怎麼做，可以跟開發聊聊。

4. 規劃產品時，邏輯一定要清晰！非常重要！放的每個按鈕及模塊要有用意，最好是有數據支撐。（產品宣講時這個會考驗你）

5. 產品規劃時，記住用戶的數據不能動的（不要因為後期計劃刪減功能導致用戶數據丟失）。

關於axure原型設計的一些：

1. 像PPT一樣，先把每個頁面建好（填充大概內容，如線框圖和文字），再把頁面和邏輯流程對應好後，最後再開始進行單個頁面的規劃。

2. 多使用母版，後期原型改動時會省很多時間。

3. 原型規劃時要當作最終版來考慮，不要想著「這個文案宣講時讓運營來想」，「這塊的邏輯宣講時讓再和開發溝通一下「等等，產品宣講時，最終呈現一定是你思考後最完整的原型，每個模塊，每個位置的文案，每個鏈接都要規劃好，不要有遺漏。

4. 原型設計時，盡量不要出現彩色，直接用黑白灰等色塊來進行強化或者弱化的說明。

5. 柵格化；不需要顯示柵格線，但要控制每個模塊的位置間距，保證整個頁面的規整，易於瀏覽，也方便後期UI的設計。

6. 交互要精確！一定要自己過一遍，開發是按照原型的交互做的，做錯的話，可能會影響整個系統，切記。

7. axure用處最大的功能是」動態面板「和」母版「，變數沒用過，精通「動態面板」和「母版」的使用，你會節省很多時間。

產品宣講：

1. 產品宣講前，要過自己這一關；自己在內部或者向其他PM演示一遍，保證自己的方案沒問題，提高自己自信。

2. 與大多數人討論，與少數人確認。

3. 會議中如果出現某個地方邏輯有問題，或者方案存在問題，要當機立斷進行決策，不要猶猶豫豫。（需要經驗和提前做過很多思考，提前想過plan B）

4. 會議記錄。產品宣講可能不止一次，因為邏輯上開發想的會更全面，所以要重點記錄每次更改的原因，一是能讓你回顧項目時能夠考慮更全面，二是方便以後要查詢到當時更改產品方案的原因。每個人對產品的任何疑問，你都能夠做出合理的解答，這就是產品經理。

5. 產品宣講經常會出現偏離主題的情況，適當時會緩和氣氛，但大部分時間，你要進行控制，避免會議拖沓，還有，聽眾注意力有限，時間長了會走神，所以中途可以休息10分鐘。

6. 產品宣講會受到很多質疑，比如為什麼這麼設計？這個你有數據支撐嗎？這是用戶需求？你有多了解用戶？呵呵？你要在之前想好應對策略，比如「這樣設計的目的是xxxx，之前我們也想過其他方案，但都有許多問題，比如xxxx，目前這是最優方案」。其實，技術提出質疑並不是你的方案很差，而是他不希望看到一個不成熟的方案，這樣的方案後期易變更，他希望這個方案是你認真思考後的結果。

7. 前台界面運營會提出很多疑問，後台邏輯上開發會提出很多疑問，這些都要做好預判。

8. 有時候公司流動性大，開發人員很多都是新人，對產品沒有任何了解，這個需要講解的更為細緻，所以需要注意。

產品開發推進：

1. 保持密切溝通。資料庫建好後，每位開發人員都被分配的有自己負責的模塊，所以說他們並不清楚整個產品的結構和邏輯是什麼樣子，碰到問題時，有時會按照自己的想法去做，所以需要密切溝通，保證最終不會偏離設計。（這很重要）

2. 怎麼溝通呢，如果有空閑時間就和開發聊聊天，如果時間緊的話，就每周定個時間，統一解答開發時碰到的問題。

2. 講方案時，對開發提出的疑問要講清楚，必要時也要講下業務價值，如數據，緣由等等，要說明這個模塊在流程上是很重要的一環，希望他能認真對待。

3. 需求變更；這是所有人都不願意見到的事情，如果出現了，要保證的第一條是，你的變更方案一定沒有問題（在你所控制範圍內），另外要立刻和研發主管溝通，關於涉及到的修改模塊，增加的工期等等。

產品測試及上線：

1. 產品上線前，要把產品的邏輯流程和需要重點測試的地方和QA講解清楚。

2. 每次產品修改的地方都要抄送一份給測試，最好當面溝通。

3. 測試很重要，產品經理精力有限，所以很多產品的問題需要測試來發現，所以多聊聊吧。

4. 上線後發封郵件感謝大家。

產品優化：

1. 控制需求，分清楚優先順序，分批向技術部門提交。

2. 撰寫郵件時，要寫清楚，哪些位置需要修改，不要漏掉一些，抄送給相關人員。

其他：

1. 多學些技術，《head first系列》是本好書。

2. 多研究些開源軟體，電商社交CMS等等，對理解產品結構有很大益處。

基本上，失敗的，都是把"一廂情願"這件事，做到了極致。

永遠不要覺得自己做的產品是很完美的。但是很多人做完一款產品功能設計的時候就覺得自己產品是十分完美的

產品經理最重要的是從項目中總結兩點：

1、方法

2、結果

因為在NB的產品經理也沒辦法保證100%成功，如果一個產品經理能夠有50%的成功率就已經非常NB了。所以我們需要從每個項目中總結，這個項目我採用了那些方法和手段，希望解決用戶那些問題，但實際產生的效果是什麼？然後總結為什麼預期的結果和實際結果之間有差異，如果是產品能控制的那就改進，如果是產品不能控制的那就搞清楚原因，是外部條件不成熟還是內部條件不成熟，如果是條件不成熟，預計什麼時候能成熟，然後項目就可以總結之後歸檔了。

產品經理最怕的就是不知道為什麼要做這個項目，同時缺少一個可量化的指標，做完了不知道這個項目問題出在哪了。

我有一個口頭禪「好的產品經理是錯出來的，不是學出來的！」

1.儘快以低成本試錯。

2.儘快推向市場，獲取真實用戶的反饋，而非閉門造車。

3.根據用戶需求和反饋，持續改善。

4.市場調研是浪費時間，功能取捨體現產品經理的決斷力和對人性的理解和思考。

5.不求全，但求擊中要害。

6. 產品即廣告，外觀設計和功能設計、易用性就是廣告，廣告預算都放在產品上，而非媒體上。好產品是和用戶心靈的交流，用戶會自然傳播產品，尤其是在移動互聯時代。

7.要有堅持，不必隨波逐流，產品系列形成品牌是個長期的過程。

8.產品開發是個充滿風險的歷程，永遠有B計劃、C計劃，還要有止損退出的勇氣。

9.技術為用戶需求服務，不要成為技術的奴隸。

10.目標要遠大，產品以長期收益為目標，短期至少現金流要平衡。

-------------------------------

補充一點和執行有關，

產品經理要有殺伐決斷的權力，那種跪求研發的產品經理肯定是什麼地方錯配了，或者掛羊頭賣狗肉，呵呵。

將聽吾計留之，不聽吾計去之！

從底層PM的角度說兩句。

底層PM重在執行力、推動力，離開這兩點別的工作都是耍流氓。

所以底層PM應該本著一種「打雜心態」來協調和推進整個項目。下面我解釋下什麼是"打雜心態"

比如，設計同學在工作時，除了按要求設計產品，其他事情都不屬於他的工作範圍，也就是他的「雜事」。在技術同學編碼時，除了編碼這一本職工作之外，其他事情也屬於「雜事」。非其本職的工作可以算作「雜事」，因需求的模糊而去找PM溝通也可以算作「雜事」。

在產品迭代的各個階段，都有相應的階段主體，他們的工作對這個階段的迭代，起著決定性的作用。在需求初定階段，可能PM是主體，但在開發階段，設計與技術同學就變成了主體，進入了測試階段，測試同學當然就是主體。如果一個階段的主體為太多的雜事所累，那他進行的這部分工作情況當然不會很理想。

作為跟進產品迭代每個階段的角色，PM必須在迭代進入特定階段的時候，盡量協助充當這個階段主體的同學，為他們免去儘可能多的雜事，換句話說也就是替他們「打雜」。

一方面，我們可以規範迭代流程，給每個迭代階段都留出充足的時間，讓他們遊刃有餘地處理手頭的工作；另一方面，我們也可以通過及時準確、一次到位的溝通，來避免一而再、再而三地交代需求細節所造成的時間浪費。

說到具體工作上，可以有以下幾點：

1.科學設置迭代周期長度

產品迭代一般是以周為單位，每個周期為一到兩周。這樣的時間設置最為接地氣，也最為科學，短於一周，時間太緊，很可能導致每次迭代都做很少一點功能草草了事。長於兩周，工作在時間上難以把控，很容易造成迭代不能如期完成，難以形成穩定有效的規範。

2.將信息傳達落實到紙面

任何工作能落實到紙面上，盡量落實，並讓大家周知。例如，每次需求評審都使用原型與文檔輔助講解；會議記錄整理後用郵件發出；BUG通過jira等項目管理應用統一提出等等，一方面避免了口頭溝通易忘的風險，可以幫助各部門同學記住重要信息，另一方面也可以藉此規範迭代流程，明確各自責任，以防出現問題時大家互相推諉。

落實到紙面上的信息，比如已經確定的產品策略、開發排期等等，如非極其特殊的情況，盡量不要更改。即使只更改過一次，也會讓其他部門同學覺得「這個人不靠譜，已經敲定的事還變來變去」，次數多了你以後把排期糊牆上也沒人鳥你了。

3.優雅地跟進項目進度

前面我們說到了，對其他部門工作的跟進，不等於監督他們的工作，即沒必要整天追著設計和技術同學問「XX需求怎麼樣了」。

如果一個團隊里有多個PM，盡量根據產品線分配人手，各產品的事找相關的負責人，專人專事，明確責任；

將本周期內的需求逐條整理，歸納成一份列表，每晚用郵件分享當天的迭代進度，標註出當天該列表中需求的責任人和完成情況；

綁定開發用的環境，隨時跟進最新的開發進度，等等。

4.建立應急機制

項目需要有一套應急機制，比如開發或測試沒有如期完成，影響了下一階段的工作，此時應該如何做，是砍掉部分相對不重要的需求，還是犧牲上線時間，視具體情況而定。

5.適當貢獻碎片時間

在兩輪迭代周期之間，通常會有周末之類的空閑，這個時候PM可以做些收集用戶反饋，整理下期需求之類的工作。畢竟就算在工作時間，我們也會偷偷刷微博，而工作時間之外我們也不可能完全放開自己的工作。

暫時就想到這麼多，以後對底層工作有了新的理解再來更。

很多互聯網公司的產品經理其實並不是真正的產品經理，小公司更如此。產品方向和戰略他們基本是不參與的，拿到任務後僅僅是執行決策和跟進項目開發，項目的好壞他們是不承擔責任的，這樣就很難讓產品經理從根源上思考負責產品線的意義。對於一個項目完成後如何總結的問題。我個人任務有三點是值得牢記的。

1.老闆的需求不都是對的

很多產品經理的任務是老闆給的，老闆讓幹啥就幹啥。從來不考慮老闆的需求是對是錯。所以，等公司投入了很多人力、物力的時候，錯的就更加的厲害。結果可想而知，不僅坑了老闆，坑了團隊更坑了自己。如果把自己在項目進展中的分析傳達給老闆，幫助老闆不斷的調整是真正產品經理要做的。

2.彙報與總結

很多職場人是不會彙報與總結的，接到一個任務就是執行，不彙報的原因可能是因為沒有結果，所以就一拖再拖，很不重視彙報，當有了結果的時候可能已經不是當初制定的方向了。所以，理解公司戰略是非常重要的，不能拿來就做多半錯的幾率比較大。

寫博客不是對每個PM的要求，但是好的PM都是寫出來的，寫博客其實就是對自己的總結。比如，我們了解的馮大輝，純銀，鬼腳七，白鴉都是寫作高手。但是我發現很多PM很少寫，甚至就沒有自己的獨立博客。試問，連一個獨立博客都沒有，沒寫過博客（微博和微信不算）的PM如何做好PM。

3.責任

責任與執行必須與PM掛鉤，缺一不可。對項目的執行、把控推動項目強有力的執行是PM的基本要求。但是責任卻是可以讓項目做好的關鍵。很多PM根本就是執行，做好做壞是不承擔責任的，這樣的職位要求，能出好的產品才怪。所以，我的建議IT公司的產品經理最好是這家公司的聯合創始人。

身為一個在實習的PM，每天用三個小時的時間上下班，但是寫了PM日記。我的日記內容是，把所有PM應該犯過的錯誤得犯一遍，然後改正，然後記下來！

人性。

基本上不知道成功在哪裡，但知道失敗在哪裡……成功是運氣和努力，失敗是配合及能力……

PM是失敗堆起來的……

說說我的親身經歷。從單純產品經理轉變為產品經理與項目經理於一身後。學會了更多元的看待如何推進產品的成功。產品經理的視角更多關注產品本身，比較少關注產品受限的資源，原先總是覺得團隊開發的產品總是不盡如人意。轉變為項目經理後，我釋然了，很多現實情況不允許你的產品一步到位。各類的資源（團隊、時間、投入等）總有太多的受限因素。現在我學會了如何在有限的資源下做產品的核心，學會了產品功能與所投入資源的平衡。能夠更好與團隊溝通需求，團隊也更能把握產品的方向。

但由於兩個職位所關注的方向還是有比較大的差異，因此兩個職位於一身對個人有很大的挑戰，將耗費非常大的精力。

對的大方向，配套專業的人才與軟體，找到了借力方，自己的雖被口頭認可，但真正執行時候已借力方為主，架子沒完全搭起來，就要掙錢的項目會怎樣...

只能致哀剛死去的小貓貓了：

fuck。。。這次又沒中獎。。。

不想當CEO的PM不是好汪汪