一個需求從誕生到面向用戶，需要經歷重重錘煉，才能完成其不平凡的一生。
需求的來源在《需求從哪里來？》一文中已經進行了總結，在這里主要說拿到需求后面的事兒。先上圖，看圖說話。
往往產品拿到的需求並非“真的”需求，首先需要了解需求的來源和背景，並和提需求的相關人員進行核對，了解用戶的真實意圖，再結合自己的分析，轉化為真實可做、切實可行的需求。
對於產品經理來說，我們更希望提需求的人向我們訴說自己遇到了什么問題，想要解決什么問題，想要達到什么樣的效果，而具體怎么解決這個問題，以什么方式解決，產品需要更多更全面的思考；而不是提需求的人一上來，告訴產品經理我就要這樣這樣做，但是為什么這么做卻講不明白。
在對需求進行簡單的分析之后，產品經理定下來具體需要做的需求，並針對每個需求輸出一個大致的解決方案，如有需要可以將解決方案提供給需求方。這樣，需要做的需求，如何去做這個需求都是很清楚的了。需求分析完成之后進入需求設計階段。
需求設計階段，如果是簡單需求，有了思路之后就畫原型寫文檔做就可以了，但如果是復雜需求，忌一開始就一股腦畫原型，返工的概率太大了。面對復雜需求，初步的需求分析和解決方案並不能支撐我們流暢的完成整個需求，我們需要做更詳細的需求分析和流程設計，我一般會使用流程圖或者思維導圖進行詳細的需求分析和流程設計，設計完成之后再進入具體的原型設計和邏輯設計。先捋清楚，可以事半功倍。
產品經理完成需求設計，輸出原型和需求文檔之后，組織進行需求評審，各方需要就產品經理拿出的Demo進行討論，指出存在的問題。在需求評審會議上，需要完成兩件事情，一件是需求討論定稿，另一件是需求評估排期。
需求評審之后，需求推進到產品研發階段，此時產品經理已經可以開始准備后續版本的需求了。一般涉及到APP版本的迭代，版本周期在一個月左右；Web或者后台版本的迭代，版本周期則在一個周左右。在研發出方案的同時，UED會出UI，測試會寫測試用例，然后進行兩到三輪的測試版本迭代，完成本次大版本的開發和測試，測試完成之后就可以評審上線了。
版本發布評審的會議上，首先需要評審的是當前版本未解決的BUG是否需要繼續解決，影響較小則可以適當進行遺留；其次是版本升級之后對於各方的影響需要各方知曉並在版本上線后出現問題能夠有效應對，比如某一功能上線可能會導致流量暴增，那么運維、運營、客服和研發相關人員就需要在上線后做好相關的支持；最后是版本發布的具體時間，一般為了不影響用戶體驗，版本發布時間多為晚上十二點左右，發布時需要研發和測試都在場，上線后需要進行一輪冒煙測試。
很多公司會采取灰度發布的方式，以確保大版本的升級不會出現較大的影響生產環境的問題，將可能發生的負面影響降到最低。放一只“金絲雀”投石問路，不至於出現問題全軍覆沒造成不可挽回的損失，大大的降低了這種可能性。
灰度沒有問題之后，就可以將版本全量發布出去。至此，需求正式上線面向用戶，但需求的使命並未就此結束，產品經理需要對上線需求進行持續跟蹤，以便於更好的改進產品、服務用戶及為企業創造最大的效益。