---

問題有點大，我就拿一個app項目來舉例全流程吧 ，從項目前中後來全面說明

項目啟動前

1.1產品定位

在項目的執行過程中，我們經常陷入一種情景，就是一堆人在一塊，討論的氛圍可謂是情緒高漲，A說這個地方的按鈕不行，B說這個地方應該像人家APP那樣做，C又說你們都不對應該是這個模塊不要換成這個云云。經常參加這種討論，會無比的耗費時間和體力，動輒好幾個小時過去，但一散會，發現什麼結果也沒得出來。多數情況下，一定是產品定位出了問題。執行的人一定要清楚的明白產品是用來幹什麼的，給什麼人用，才能正常的去討論具體細節。如果熱血沸騰、蹬鼻子上臉的的討論了好久，發現沒結果，發現會議的討論跑偏了，不妨回歸本質，想想我們的產品定位是什麼。

需求定義：

需求定義的分析包含目標用戶、使用場景、用戶目標三個方面。目標用戶是什麼類型的人會用你的產品；主要功能是指你的產品是用來幹什麼的，是工具是社交還是其他；你的產品相對於其他市面上的產品有什麼不同的地方，這就是產品特色

剛才明確了APP的適用人羣、主要功能和產品特色。市面上的招聘APP，有的是做獵頭的專門針對於希望跳槽的，你的APP的目標用戶是誰？基於特色功能分析和用戶痛點，分析出出產品的目標用戶是那些有想在具體位置找工作的人，比如已經定居北京後沙峪的人，希望工作在望京；當你剛剛搬家到回龍觀時，此時你面臨著換工作，你可能會傾向於找西二旗那邊的工作。

1.2需求分析

以上就是所有產品定位的內容。這些完成之後，緊接著的就是競品分析和用戶調研，一方面這是對我們的需求進行一定的驗證，另一方面也是我們直接接觸用戶的一個機會，看用戶存在什麼需求。

1.3需求篩選

早期需求篩選是個非常苦逼的事情，如果產品經理自己就是老闆，自己心裡很清除還行，如果不是很容易陷入海量的需求中拔不出來，討論著討論著就跑偏了，討論完之後好像什麼功能都需要，這個功能有用，必須加；那個功能太好玩了，用戶肯定有趣。這話總完全憑個人主觀臆斷的東西，往往都是當時聽起來貌似合理，但事後卻經不起推敲。所以我們需要始終把握住我們的產品定位和優先順序，萬不可盲目的在這個地方做很多無畏的犧牲和奮鬥（少做不經思考的、拍腦袋的、不經過大腦的決定）。

需求記錄表：

早起需求篩選期間，會出現很多這樣或者那樣的需求，有些我們不能立馬做出判斷說做還是不錯，這些點子有可能以後會成為我們產品迭代的啟發點，也會給產品的發展帶來更廣的思路。做好管理，尊重每一個人的想法，在出現模稜兩可時，記錄下載，對會議的推動和進展會有很大的幫助。二、商業價值

市場需求文檔和商業需求文檔，一般在大公司會得到比較成熟的體現。小公司往往多數都是老闆自己決定，老闆可能不會搞這樣或者那樣的文檔，但他自己肯定會去做基本瞭解，或者本身自己就很瞭解某個行業。這兩個文檔並不是多餘的，也不是累贅，如果在項目啟動前，能夠花一定的時間去深入瞭解行業和用戶是非常必要的。具體文檔細節在這裡不做闡述，網上有很多可以去借鑒的。

三、技術評估

作為不是技術出身的人，就不再這裡轉筆了。尊重開發人員，和開發相處融洽一點，會對產品的推推動非常有幫助。

項目啟動中

這裡不做過多說明，主要考察PRD文檔編寫，可以參考我的之前寫的，具體文檔源文件

可以關注我個人公眾號：痞M二點五 ，輸入1122 即可直接獲取

痞M二點五：產品經理如何寫PRD需求文檔（含源文件可領取）?

zhuanlan.zhihu.com

項目結束

一、APP數據

新增用戶：第一次啟動應用的用戶；

新增獨立用戶：全體應用的新增用戶的總和（去重）

活躍用戶：當天啟動一次的用戶即為活躍用戶，含新用戶和老用戶；

活躍獨立用戶：當天應用的活躍用戶總和（去重）

MAU：MAU（monthly active users）月活躍用戶人數。

DAU:DAU(Daily Active User)日活躍用戶數量。常用於反映網站、互聯網應用或網路遊戲的運營情況。

用戶留存率：在互聯網行業中，用戶在某段時間內開始使用應用，經過一段時間後，仍然繼續使用該應用的用戶，被認作是留存用戶。這部分用戶佔當時新增用戶的比例即是留存率，會按照每隔1單位時間（例日、周、月）來進行統計。

用戶留存率中的40-20-10法則：如果你想讓遊戲、應用的DAU超過100萬，那麼日留存率應該大於40%，周留存率和月留存率分別大於20%和10%。

次日留存率：（當天新增的用戶中，在往後的第1天還活躍的用戶數）/第一天新增總用戶數；

第2日留存率：（第一天新增用戶中，在往後的第2天還有活躍的用戶數）/第一天新增總用戶數；

第7日留存率：（第一天新增的用戶中，在往後的第7天還有活躍的用戶數）/第一天新增總用戶數；

第30日留存率：（第一天新增的用戶中，在往後的第30天還有活躍的用戶數）/第一天新增總用戶數。

另外就是APP的埋點數據，這個功能的點擊率是多少？這個功能有多少人打開，又有多少人使用了？有多少人在頻繁使用這個功能？等等，這些埋點數據要時常關注。結合數據變化來反思功能設計的問題，從而優化產品。

二、用戶反饋和評論

產品上線後，用戶的反饋和評論對於產品人員來講是尤為珍貴的材料，一方面這是你的真實用戶的直觀感受，另一方面他們再表達直接的需求。那麼，怎麼樣處理用戶的意見就顯得格外重要。用戶反饋什麼我們就做什麼，這是肯定不行的。很多情況下用戶表達的只是一種表面現象，要學會去挖掘用戶背後的需求本質。多去研究世界上一些革命性的產品，多去了解人。

當看到四處飛來的意見時，我們要學會思考，而不是全盤接受、全盤照抄。

是不是我們的目標？想想我們的目標用戶是誰。

使用場景是否成立？還是這只是極個別人的場景需求。

用戶目標是否正確？我們的APP是不是用來滿足用戶這個需求的？

產品定位還正確嗎？如果做了這個功能，還符合我們產品的定位嗎？

如果要做這個功能，那麼自身的項目資源是否能夠滿足？如果需要舉全部資源來做這件事情，那就要慎重再慎重。

三、需求提取

也許用戶的意見是個圓形，但經過分析之後，很有可能得到需求是個三角形。

客戶需求有顯性需求和隱性需求兩大類。我們通過市場調查得知的往往都是一些諸如「我要一匹更快的馬」這類顯性需求。客戶的顯性需求並不是客戶真正的需求。企業需要根據所收集的顯性需求信息進行深度挖掘和捕獲，以瞭解客戶的隱性需求是什麼，進而分析出客戶的真正需求是什麼（例如：用更短的時間、更快地到達目的地）。這就是一個需求分析的過程。

喬布斯所言：「我們的任務是讀懂還沒落到紙面上的東西。」實際上就是用戶隱性需求的深度挖掘。

各種產品文檔資料可以關注我的公眾號

痞M二點五

輸入1122即可，都是實戰資料

沒有之乎者也

---

多嘗試，多接觸，多發現機會。

---

領導拉了個微信羣，一定是有新任務了。

還是H5，但是跟以往不同，這次我的角色兼任項目負責人。就是說除了定義H5的需求與範圍，還要負責統籌項目進度和資源，在這個過程中與項目成員有效溝通直到項目上線。接到任務的時候沒有多想，更談不上通過項目管理理論管理項目生命週期，只是一個任務一個任務的往下做。

確認需求，是我要做的第一件事。先跟業務人員溝通，收集需求，並在自己認為不妥的地方提出修改意見，然後召集業務和技術人員共同討論技術實現的可行性以及工作量。這個項目有一個制約因素是技術人員由外包公司提供，所以涉及到一項很重要的技能：溝通。外包公司的對接人來來回回換了三次，每次都要重新對接需求；對方又比較強勢，經常發生溝通上有去無回的事情，搞得我很辛苦；不僅如此，對方的報價過高，超出了我們承受的範圍。與人對接對我來說不是什麼難處，積極友好的溝通是第一原則。其他時候就要靠著他人的幫助了。我的基本原則是不懂就問，需要做決定的時候第一時間向領導請示，所有溝通中的關鍵細節都向領導彙報。說到這不得不感激我的領導，讓我少走許多彎路，在關鍵節點的彙報和溝通證據的保留都是最後盡量少背鍋的保證。

在合同的溝通中發生了一點小插曲，對方公司始終不願給出評估的工作量，只是沒頭腦的報了一個價格，在我們的逼問中對方好像有些火氣不想做了。我們又找了一家公司，同步聯繫，給自己留條後路。最終由於都屬於一個集團公司，找到上面的領導斡旋，才說服他們接這個活。

合同的事情搞定之後就開始緊張的開發工作，這個過程中最重要的是保證各方的信息一致，業務方的想法第一時間讓技術人員知道，技術方的困難也要盡量解決，還有很重要的一點就是定期讓領導知道項目進度，不悶著頭工作是這段時間我學到的重要一課。

一個項目從立項到交付真的要經歷太多道工序，前端代碼完成後需要後端伺服器部署，調通介面再測試通過，還需要添加統計代碼。即使這些都能一帆風順，說不準內容審核後又要返工重做！所有這些，重中之重依然是溝通，積極且有效的溝通！對幫忙的人可勁兒讚賞，買杯咖啡喝起來，實在不行就用紅包來懟，人嘛，都是有感情的。大家開心的合作，共同達成目標。沒有誰與誰有深仇大恨，每個人都想做符合自己利益的事，看清楚相關方的需求和期望，盡量滿足就是了。

---

首先希望大家記住的就是，千萬不要以為產品經理是什麼高大上的光環，產品經理其實只是一種狀態，一種心態而已。

1、懂行

一眼就看出你是那個對的人是很重要的，所以平時要學會多留意互聯網業內的一些動態，包括行業發展的情況，對應產品的功能和競爭對手的差異等，尤其要了解你所面試那家公司的產品，最好都下載下來體驗過，能寫出一些分析類文字如競品分析，產品優化方案等就更加分了！

2、經歷

光能紙上談兵也只能說理論基礎打好了，還要有實戰經歷。還沒有去互聯網公司實習的同學要抓緊了，BAT的暑期實習招聘4月、5月馬上展開，所以在此之前有1-2份互聯網公司的實習還是加分很大的。

3、識人

過來人的幫助不僅能夠讓你獲取更多的內部信息和資源（很多實習機會都是內部消化的），還可以在關鍵的時候給你一些比較全面的輔導和指引。能夠讓你搶先一步得到機會！

4、包裝

得到了訊息，看到了機會，也有經歷之外，還需要懂得如何把最好、最真實的自己呈現出來，這就很需要個人修養了。簡歷方面在這裡就不多說了，有些同學會很別出心裁各種創意和健談，但是我覺得互聯網這麼踏實的行業你太花哨也不好，最重要的就是談得來，點到即止。

5、學習

互聯網瞬息萬變，速度太慢就很快死，所以不斷充實自己的知識體系至關重要。這個是核心哦，大家一方面要學會Xmind，Mindmanager，Visio，PS，Axure這些軟體，另一方面還要多看書，大家隨便去知乎或者簡書搜索」產品經理書單「就會出現一大堆了！

多去請教一線產品經理，他們在工作中總結積累的經驗對你也是很有幫助的。通過視頻或者去提問的方式，汲取他們的經驗，補充自己的不足。

我現在自己組建了一個自學團，平時也會組建一些實戰活動，歡迎加入我的自學團。

---

完整的項目過程是從需求調研到產品上線；產品經理的職責是全程參與整個的項目週期，注意這裡指的產品經理可能是一個也可能是多個。

一般情況下，只有在創業公司的產品經理或者是某公司的產品線負責人才會對項目全流程進行追蹤。大型公司的產品經理都是各自負責某一模塊，至於產品的上游工程商業需求分析、產品信息架構、功能架構都是由產品總監級別的人設定好後，再由其他的產品經理負責各個模塊的研發。

這是我很早寫的一篇文章，其中包含了產品經理的工作的相關內容。

路邊茶館：都說人人都是產品經理，你知道產品經理核心工作步驟是什麼嗎？?

zhuanlan.zhihu.com

看題主的意思姑且認為是規模不大的公司。一般這類公司為節省成本可能只有少數或者一個產品經理去負責某一個項目，當然項目也分為很多類，簡單說一下不同項目下產品經理的工作流程。

一、項目屬於自己公司的業務

需求調研：需求調研包括了商業需求調研和用戶需求調研，商業需求調研包括行業現狀、政策現狀，經濟現狀等（看公司具體需要）用戶需求調研包括用戶羣體、用戶價值、用戶使用場景、用戶體系分層等。

競爭分析：競爭分析包括所在行業的公司財力分析，商業佈局分析等等，需要輸出相關的競品分析文檔，這裡不詳細寫了，具體看我曾經的回答吧。

如何做一份出色的競品分析？?

www.zhihu.com

需求撰寫：如何將用戶需求轉換為產品需求也是很考驗產品經理基本功的，需求撰寫階段就是要將用戶需求轉換為產品需求。其流程是構建業務流程圖、產品信息架構圖、產品功能架構圖、原型圖、撰寫需求規格說明書。

業務流程圖構建一般使用visio工具來構建，產品信息架構圖、產品功能架構圖使用Axure 、Mindmanager、Xmind 等工具，原型圖可用Axure、Mockplus、墨刀、sketch等原型工具，需求規格說明書（PRD）是商業需求、用戶需求、產品需求的集合（側重產品需求）。目前很多人直接在原型圖上做注釋作為研發的參照依據。如何寫好PRD請參照我的一篇文章：

路邊茶館：產品經理如何寫好一份PRD?

zhuanlan.zhihu.com

需求評審、確定研發週期

與技術、測試相關人員對需求進行評審、有問題的地方進行修改，並確定項目研發週期。測試相關人員編寫測試用例。產品經理與相關人員製作需求管理模板並跟進項目進度；

產品測試、灰度發布

待產品開發完成後整體測試，並進行灰度發布進行內測，有bug及時提出進行修改。

產品上線運營

產品上線運營

版本迭代

產品經理根據產品的定位、戰略佈局、業務需要進行產品功能迭代

二、公司作為乙方為甲方研發項目

這類產品經理做的相對比較雜，例如做投標文案、寫PPT、畫原型、項目交付等等。

1、完善需求

正確引導甲方並完善項目需求，有時甚至甲方都不知道自己想要的是什麼。還需要產品經理去引導甲方完善項目需求。這裡就很考驗產品經理的耐心和處世技巧了。

2、撰寫需求

這裡的需求撰寫和上述提到的大同小異基本一致

3、按照合同內的時間完成開發測試

4、交付項目

有相關問題可以關注私信我，提供產品相關的學習資料。

---

推薦閱讀：