在一個產品從設計到上線的過程中，產品經理大致需要經歷：「需求設計」-「產品內審」-「工程評審」-「開發過程」- 「產品驗收」-「測試過程」-「灰度發布」-「全量上線」這幾個流程，我剛開始實習時，對於自己在各個流程中應該扮演的角色認知其實是很模糊的。所以，這篇文章主要講解各個環節的內容、目的以及產品職責，希望對產品新人能有所幫助。
一、需求設計
簡單來說就是寫PRD，這部分大家都比較熟悉，就不作展開。
二、產品內審
產品內審即產品經理內部的評審，有可能是同級互評或者上級評審。一般是辨別需求的真偽，設計的合理性。有時也會有多個項目PK的情況。
產品內審的目的其實就是讓你的產品同事為你的產品方案把關，保證最終輸出的PRD的下限。通過產品內審的需求，即認為該需求在產品內部達成共識，這個需求就不再是”xx產品經理的需求“，而是”產品部門的需求“。產品經理的一大禁忌，就是在工程評審時（產品內審已通過），在研發和測試面前，產品經理之間互相質疑需求的合理性和嚴謹性。
在這個環節中，產品經理主要要做的是將自己”為什么要這么做“”為什么不這么做“表達清楚，合理聽取意見，會后改進文檔。
三、工程評審
工程評審是產品功能涉及到的研發和測試們評審需求的環節。有以下幾個目的：
一、讓工程師了解需求，遇到疑惑隨時提問
二、前端、后端等不同研發工種間討論如何配合實現
三、測試同學了解需求，便於寫測試用例
我剛開始實習時，對於工程評審是十分恐懼的，很擔心在會上被研發或測試同學當面質疑，或者找出PRD里的漏洞。同時，我是屬於思考比較慢比較穩的類型，所以臨場反應往往很慢，當他們提出問題，以及問我解決方案時，我往往會停頓很久，導致場面十分尷尬。
經過N多次評審后，我慢慢解決了這個問題，我的經驗是：
一、轉換心態。當開發或者測試提出疑問時，不要覺得他們在”質疑“你的需求或者產品能力。大多數情況下，開發更關心的是如何實現，測試更關心的是如何測試，而不是去推倒你的需求。所以，當他們提出疑問時，不要將它理解成對你個人的一種質疑。這樣，有助於你更加輕松地掌控場面。
二、工程評審前先對需求。評審前先找前端/后端負責人對大致對需求，這是很多產品新人容易漏掉的環節。
設想一下，如果你在工程評審前，已經跟所有涉及的開發都溝通過產品的可行性，那這個工程評審不就跟走過場一樣輕松了。
當然，為了效率考慮，我們不可能這么做。但是跟主要的負責人簡單對下，還是可以做到的。將文檔發給負責人，簡單約個時間，對一下技術可行性，以及部分細節。這樣，你相當於在工程評審前獲得了負責人的背書，在評審時，遇到問題，有可能負責人會出面提你回答，何樂而不為。
三、評審過程中遇到問題，可以會下解決。無論你的文檔寫得多嚴謹，終究會有一些技術細節或者特殊情況難以考慮周全。在會上被同事提問，又無法及時想出解決方案時，完全可以跟大家說，我會后想一想，再補充在文檔里。不是所有問題都必須在會上解決。
在工程評審環節，產品經理的職責是充分表述需求的內容，涉及到的風險點，解答疑問，協調確定實現方式，會后完善文檔。
四、開發過程
工程評審完就消失的產品經理是不負責的。在開發過程中，產品經理的職責就是為工程師順利開發解決一切困難！比如涉及到跨部門溝通、配置問題、資源問題等等，產品經理都應該第一時間站出來，推進解決問題，讓工程師集中精力開發，這樣你才能成為工程師們值得托付的產品經理。
同時，要定時的查看產品完成情況，如果產品驗收時是你第一次見到產品，這個風險是非常高的。最好是能在開發過程中，時不時去開發的電腦前看看半成品，避免產品偏離你想要的方向。
五、驗收環節
有些公司驗收環節是在測試環節之后，這兩個過程各有優劣。
產品經理先確認產品功能、UI符合要求，再讓測試同學測一些細節，可以節省測試同學在測試過程來回於產品校對，但是產品經理由於驗收的產品只經過研發自測，可能存在較多問題，所以可能會花費較多時間；
測試先介入測試，測試完成后產品發現不符合預期，重新調整，測試，測試資源是有一定浪費的。
產品驗收的目的是確保研發出來的產品符合產品經理的預期，避免上線后回爐重做的事故。
在這個階段，產品經理的職責是檢驗產品功能是否符合PRD描述，主流程能否跑通，關鍵功能是否正常。注意避免陷入細節之中，那是測試同學要做的事前。
六、測試過程
測試過程是測試按照測試用例，全面測試產品功能、可用性、可靠性的過程。在這個過程中，會涉及到產品、測試、研發三方的溝通，但是主要是產品來拿主意。哪些缺陷可以忽略，哪些未實現功能可以下版本再做等等，都需要產品經理合理衡量決策。
在完成測試服測試后，一般會進行線上白名單測試，即將功能發布到線上，對測試同學白名單可見，線上去測試功能確保萬無一失。線上配置一般只有產品經理或運營才有權限，需要配合配置。
七、灰度發布
產品新人常常搞不清「灰度發布」和「AB測試」兩個概念。
「灰度發布」更多的是一種基於安全性、穩定性考慮的發布策略。比如我線上版本是3.49，即將上線3.50版本，那么我們可以先灰度10%的用戶，發現各項數據正常（業務數據、服務器），無用戶反饋異常，則可以加量至30%，50%，直至全量。如果中途遇到問題，則可以取消灰度。
「AB測試」則是一種測試方式，例如我們在考慮圓形按鈕和方形按鈕哪個效果更好時，就可以采用AB測試的方式，測試組10%的流量是圓形按鈕，對照組10%的流量是方形按鈕，觀察點擊數據。
此外，產品策略、數值設置（特別是游戲）也有經常用到AB測試，觀察不同數值設置的效果。
這時候我們就不能說我們在”灰度“這個策略了，因為我們實際上是將兩個策略進行比較，是一種試驗，並不是在從A策略過渡（灰度，即從黑到白，從低級到高級的過渡）到B策略
灰度過程中，產品經理需要留意上線數據是否有異常，有異常時及時回滾。
八、全量上線
終於到最后一環了。全量上線后產品經理就可以觀察數據是否符合預期了，調整策略，持續觀察，准備下次迭代內容了。