這篇文章首先總結的是自己對產品設計流程，以及流程中各個環節的認知，在以後的文章中，還會逐一對各個環節中的細節深入總結，從而達到系統性梳理自己認知體系的目的。
上圖是依據自己對產品的認知所畫的流程圖，在我的認知中，產品製作主要分為三個階段：
1.需求調研：
通過面對面訪談，收集需求卡片等方式，對某類或者某行業的使用者，進行密集的調研，收集並總結他們在工作或者日常生活中所遇見的一些問題或是建議，找出其中共性的部分，將其總結為某種需求，最終選定其中乙個作為核心問題，而解決這個核心問題的功能，將會是日後產品生存的根基。
2.產品立項與研發
依據使用者的核心需求，提出產品設想，並做好相應的市場調查與可行性分析。在通過決策層評審後，將設想細化成產品原型，提交到ued與研發部門，製作出相應的產品並投放市場。
3.產品市場化：
商務部門依據產品設定的目標使用者群體，對產品進行包裝和宣傳，在完成銷售任務的同時，與產品經理一起積極收集使用者反饋意見，協助產品經理校正與迭代產品，保持產品與市場的同步。
其中產品設計與研發，又可以細分為五個階段：
產品立項：主要包括商業需求文件(brd)，市場需求文件(mrd)以及產品需求文件(prd)的製作，通過brd獲得資源支援，mrd驗證產品設想，prd提交產品模型，確保產品方案的可行性和可操作性。
產品研發：包括使用者體驗的設計以及具體的功能實現。
產品測試：通過一些的測試，確保產品的質量，及時發現產品的bug,加速產品的迭代。
產品上線：在產品通過上線評審後，通告與協調相關部門完成產品的上線工作。
產品運營：協助產品經理輸出相關的產品文件，以及和產品經理一起策劃相關的營銷活動。
有人曾經問過我，為什麼這樣來劃分整個流程，好處與壞處是什麼？
其實工程學上來說，這種模式屬於典型的「瀑布模型」：
好處在於：
各階段劃分的非常清楚，進入下一階段後不會被上一階段的事情所負累。
很適合利用此流轉對產品進行增量的迭代；
壞處在於：
需求變動頻繁的話會很痛苦；
各階段之間屬於序列連線，版本跨度控制不好的話，會經常出現ued忙的要死的時候，研發很閒，研發忙的要死的時候,ued很閒的情況，團隊利用率不高；
最嚴重的是要是立項沒立好，或者立錯了方向，基本死翹翹。
因為自己做產品做的比較多，需求一般自己把控，而且大多要求快速迭代，所以個人覺得這種研發模型，非常適合網際網路產品的開發，這些年來自己一直都是使用這樣的套路在研發產品，倒也用的順手，對比以前在founderrd的時，公司用的cmm3標準，個人最大的感受就是：敏捷。
所以如果把控的專案，需求不由自己把控，而且質量要求很高的話（比如銀行或者電信類產品），相信上述流轉將不適合您現在的產品或專案。
今天先總結到這裡吧，接下去自己對各個環節的一些認知和心得，更深入和詳細的總結，希望自己能夠至少保持一天一篇的反思與總結。
產品管理 職責
工作職責 1.使用者與市場需求收集，分析競爭對手產品，提煉歸納產品需求，輸出產品發展計畫和階段性目標 2.負責產品基礎功能與支撐系統的功能策劃，輸出可行性產品方案與互動原型，並撰寫產品需求文件 3.組織產品與技術評審，負責協調資源推進產品開發進度 4.產品開發完成後負責驗收，並且持續對產品提出優化及...
產品管理設計
雖然說許可權管理模組是最早接觸的模組，但是公司不重視後台管理系統，所以許可權管理也只是簡單實現了選單的控制，並沒有太多的深入，而產品管理才是第乙個真正實現的完整模組。大大小小經歷了三個專案，產品管理也是一直在不斷更新完整中，從最開始直接將屬性名作為不同產品區分的標識，到後面的完整規範的商品表設計，可...
產品思維 產品管理系列文章
在2015年，由於工作關係，筆者進入了一家投資公司，做起了產品經理。今天，筆者就將產品經理的思維做乙個總結，既讓讀者能夠對產品經理思維有乙個認識，也是筆者對產品經理的認識提高乙個層次。1 產品思維 解決使用者痛點的思維 產品經理對於產品的思維，就是為了解決使用者的需求問題。乙個好的產品，既要體現出產...