01觀察市場發現需求,去偽存真,評估市場容量，初步指定具體的業務方案和具體的產品方案
1.1、任何一種服務的誕生都源於一種人類需求，人們需要溫暖和安全感於是開發了房產，人們需要更好的生存於是做出了各色各樣的美食，人們需要更方便的社交於是發明了微信，人們需要被尊重於是就出創造了法律，人們想要超越自我於是就去創業了…so,一切的需求都源於人類的欲望。
1.2、不管你現在在任何一家公司，這個企業的創立之初可能都源於你的老闆最先發現了一種人們需要的東西，於是開始圍繞這個需求做出了一系列的服務和解決方案，然後一條條一項項的業務線就產生了。
1.3、當然有些需求也可能是「偽需求」和「空想需求」這些都是不成立的會阻礙後期的產品服務開發，辨別高頻剛需的真需求才是關鍵。
1.4、前期做市場調研的時候不只是光調研目標用戶的需求這麼簡單，同類的競品同樣需要調研，如果這個需求的市場充滿了競品企業已經是競爭白熱化而且已經供過於求那麼就成了一片紅海，即使做了也生存堪憂。
02使用思維導圖構建最初的產品框架，並設計製作產品原型圖，不斷推敲和構思，將核心業務與友好的交互完美結合
2.1、如果具體的需求文檔已經沉澱下來，那麼接下來產品經理可以使用思維導圖甚至手繪的方式去初步構思一款新產品的核心欄目構架,這個過程是一個創造的過程,也可以對比競品的產品形態進行創新設計。
2.2、設計初步產品形態的過程非常複雜燒腦，既要有嚴謹的業務流程化思維、商業化的營銷思維，又要有非常友好舒適的產品交互形態，每個流程都顯得比較自然流程且富有趣味性，這時你要完全把自己當做這款新產品001號玩家，用批判且辯證的思維邏輯去完善它。
2.3、如果你所在的是一家垂直方向的網際網路公司那麼恭喜你，你所做的產品會長期的跟隨市場進行更新迭代，如果是一些量產定製的外包公司那就是另一種工作狀態，因為你的需求是甲方設定好的，可能不需要仔細琢磨和長期的市場調研挖掘深度需求，原型設計只要滿足基本需要後交稿即可。
2.4、如果整個研發產品的開發周期比較急促，那麼根據需要，原型使用低保真的就行，如果有足夠的時間去仔細雕琢，還是建議使用高保真的原型，因為整體的產品思路和交互細節能夠表達的更加清晰透徹。
03原型評審溝通，需求功能流程梳理，技術人員評估開發可行性方案
3.1、在這個階段產品經理要組織評審會展示講解自己的產品細節了，不要太著急馬上寫prd文檔因為目前的原型版本的不確定性非常多，和大家溝通評定後沉澱下第一個版本是非常重要的，這決定著後面的工作節奏。
3.2、評審會過程中公司裡幾乎所有的項目成員都會參與，每個人看待你的產品的角度也不同：老闆&領導會以業務為主線以成交為目的去看待這款產品,比較注重產品的業務生產力和營銷；
技術開發人員比較看重產品中的功能細節、開發難度、資料庫表的構架，所以給技術溝通的時候不要講廢話直接說功能點；
美術UI設計人員比較看重產品中的交互方面、視覺主題、個性化的皮膚控制項和瑣碎的小圖標等等的，這方面要根據公司整體希望展現的精神面貌來設計，產品經理最好也把自己的想法說清楚；
運營和銷售人員希望深度了解公司業務中的營銷活動，具體話術，和配合產品中操作的一些細節，和產品業務解釋性的操作性的東西，因為他們可能接觸客戶的機會非常多，所以對操作流程化的講解和企業產品業務對接層的細節比較關注。
3.3、評審會很可能不是一次兩次就能定版的，過程中伴隨著臨時的欄目增加或刪減，這個時間根據溝通情況而定，最後如果頂版本就可以開始評估項目開發周期接著就開工了。
04原型定版後編寫PRD文檔和繪製流程圖，定製版本迭代的詳細規劃
4.1、PRD的原則就是不漏不缺、表述清晰。怎麼做到不漏不缺清晰明了呢？主要的方法就是做模版：通過不斷地迭代和完善從而達到自我規範的目的；
4.2、都哪些人會看prd文檔呢？：技術研發人員和測試人員為主的讀者人群；這些人比較講究理性思維，喜歡迅速切入核心問題並全局規劃，不喜歡囉嗦重複的東西，所以我們編寫時需非常直觀。
4.3、寫作PRD文檔一定要總結逐漸形成自己獨特的風格不斷積累就能越來越專業：個人原型的風格、PRD的語法沉澱、各類型的項目邏輯的沉澱；
4.4、每個團隊有不同的PRD模板，企業通常是Axure原型+流程圖就行如果遇到問題再約溝通即可，現在公司都比較喜歡敏捷開發、快速迭代的方式，若前期評估得超長的開發時間那基本上沒人能接受的了，我們需要陳列出所有需求，區分好優先級，按功能模塊和業務邏輯把需求拆解，並制定前幾個版本的迭代規劃。
05與程序架構師深度溝通產品功能和數據傳遞的技術細節，配合定製項目代碼框架與資料庫框架
5.1、項目正式開展實施首要的就是和技術老大UI老大們溝通，而技術要最先落地的因為這是一切的框架根基，有了技術框架後面的細枝末節才能有條不紊的進行開展；
5.2、研發工程師關心的問題主要是底層的代碼設計，這個非常關鍵，產品經理甚至要大體構思好後面許多個版本的一些關鍵功能和參數，研發需要根據這些關鍵信息設計項目工程的底層資料庫表結構和關聯關係，功能方面主要是後端業務邏輯層代碼框架的基礎。
5.3、細節方面主要體現在哪裡？舉例說明：例如產品欄目中有一個可以點讚的紅心按鈕，收到點讚的用戶會增加自己的積分或者引起其他參數值的變化，小小的細節功能在技術人員看來就是牽一髮而動全身，非常敏感，如果產品經理在某個版本中砍掉或者臨時增加一個關鍵功能的參數，對於整個程序構架而言很可能就是一周的工作量；
5.4、產品經理與研發溝通也是個挺重要的問題，有些企業比較重視研發，話語權相對比較重，產品經理的很多需求都無法真正落地下來，有很大的取捨，更有甚者會和技術產生溝通障礙發生矛盾，所以很多看起來很簡單的功能點一定要和技術多次確認才行
06與UI深度溝通產品視覺主題風格與界面互動設計中所用到的細節元素
6.1、產品經理和構架師明確底層的項目框架後那麼後面基本上就可以穩步前進了,這個時候要做的就是和UI聊整體的產品視覺交互了;
6.2、視覺交互方面很可能UI有自己的一些想法甚至已經有了整體的構思，但是做為產品經理，你要把自己的想法闡述給UI，因為整體產品的視覺和操作體驗是最先接觸用戶的，哪怕僅僅一個登陸註冊的流程也要好好推敲一番，力圖達到便捷、安全、美觀。
6.3、不同的產品有不同的視覺基調，如果是一款社交產品那麼功能性可能要弱於趣味性的設計，就拿註冊過程來說，如果註冊一開始就需要用戶填寫超過兩項的參數，那將會有30%以上的人很可能會因為討厭這種繁瑣性直接終止使用，哪些體驗性好的產品往往都是會給用戶一小段體驗的時間，當發生點讚或者評論的行為時才出發註冊流程，甚至會分2次到3次觸發不同參數的註冊流程；
6.4、有可能老闆也會參與其中，他更加注重產品的自營銷能力、自傳播能力，甚至會讓加幾個廣告位置，對於這些產品經理一定要有取捨才行，在不影響體驗的同時增加產品的多樣化營銷功能。
07技術研發接近尾聲後進入整體測試環節，主要在業務流程、跨平臺兼容性、系統抗壓能力的測試，運營人員填充物料
7.1、開發過程可能會經理3到6個月這個根據初版的工作量了，很多企業的初版產品只會把核心功能做出來，其他輔助的功能放在以後的版本中迭代，整體時間很可能在3個月之內就要趕快進入整體測試環節了，因為市場變化太快拖不起的；
7.2、測試過程，主要是產品的性能方便是否流程且抗壓力強、大大小小細節的bug紕漏、不同顯示屏界面的適配，各類系統兼容性等問題，而公司老闆更加重視產品應用中的各類業務線的流程是否通暢，各個流程節點是否打通；
7.3、在這個環節中技術和UI都比較忙，為了趕上線時間，都要加班加點把bug和臨時的改動的UI元素進行修補，這個環節快的話2周到3周，如果測試中遇到的麻煩比較多可能也得半個月一個月的；
7.4、運營人員在這個階段也要配合植入很多用於測試的用戶數據甚至模擬用戶去頻繁操作，同時錄入很多用戶展示的運營數據物料等，各個環節和服務進行模擬運營並測試push流程；
08研究制定市場推廣方案，開始準備產品上線運營
8.1、發布app時需要大量的物料比如內容文案、各種尺寸的宣傳圖片、各種線上和線下活動，如果你做的行業比較特殊那可能還需要一些資質證明的文件，很多資質在研發產品之前就要開始弄的；
8.2、和市場部門人溝通推廣方案評估推廣預算，例如在哪些應用市場上架首發和在百度競價推廣等媒體渠道投入推廣，產品剛上線時數據可能不會很理想甚至無人問津，那就需要想辦法找第1批種子用戶了，其中也比較複雜；
8.3、產品的的一些欄目中的線上活動要和市場銷售人員密切溝通，安排好活動的各個關鍵節點，設法提升用戶的參與度從而提升下載量和曝光量，各界的網際網路公司在營銷這方面簡直是用了渾身解數，甚至直接投入巨量成本讓用戶免費試用，培養用戶的使用習慣，諸多案例不勝枚舉；
8.4、市場是檢驗一款好產品最佳的環境，好的產品是有一定的自增長屬性的，這也需要和龐大的運營部門打好配合：客服、文案、售前、售後、商務BD、銷售顧問等都要緊密配合打通完整的業務流
09用戶數據分析、市場數據分析、積極回應用戶反饋，收集深度需求不斷迭代更新
9.1、產品上線運營後，產品經理的主要工作就是分析產品中的運營數據了，產品應用的下載量、日活量、月活量、註冊量、用戶在不同欄目的使用頻率和時長、啟動次數這些都是非常重要的；
9.2、還有用戶的行為數據，用戶都使用了哪些功能，哪些流程他們經常只操作了一部分。產品新上線後，必然會有用戶評論，來自社交平臺、新聞自媒體和應用市場的聲音都要密切關注，多聽聽別人的聲音，多和用戶溝通，不斷收錄好的意見反饋去迭代改良。
9.3、用戶畫像就是從這個階段開始不斷成型的，各類數據反映了不同年齡段不同工作不同性別的用戶人群他們的消費行為、看待某個事物的觀點、操作習慣等等,這都會成為產品後期不斷增強的重要信息。
9.4、我們把產品的各個必經的階段分成了9個模塊來梳理，但是真正落實下去的時候未必會這麼工整嚴謹的進行，有很多事情是不可預測的，例如你所在的企業希望更快捷的開發流程，直接砍掉了許多事項，直接低保證原型，簡單開個會開發碰一下就直接開展了，一邊開發一邊設計其他的產品原型，而且公司裡也不是只有產品一個人說的算，過程中會遇到諸多阻礙，有些同事幹著幹著就沒影了，有時候會把一些活安排給外包，這需要我們靈活應對。