距離上期發表已經差不多一周了，估摸著觀眾老爺也差不多能消化上篇的內容了，下面筆者將會奉上本文的下半篇。enjoy~

上期筆者講述了在產品開發工作前期的準備工作，這個階段的產出物已經有了UML用例圖和簡單的流程圖，當然競品分析報告還是得留檔。如果高階職級需求，MRD和BRD也在這個時候輸出了，講述產品潛力和價值，為你的產品爭取更多資源。

而在這個階段，該確定的需求已經確定了，沒確定的需求被擱置，到最后估計就這么不了了之。是時候大干一場了。

少年，亮兵器吧！

3. 需求輸出

3.1 業務流程

承接上文所講的業務邏輯，這里復述一次。用戶用例簡述了參與業務的角色，以及發生這些業務的場景，接下來就要細化各個業務的流程了。關于流程圖工具的話，win用Visio，mac用Omnigraffle，也可以用在線的Processon等等，什么用著順手用什么，也有見過有的產品崗的同學用Axure之類的原型設計工具。

舉個例子，還是滴滴打人。

以核心功能的流程展開。用戶填寫需求表單，表單內容包含目標的相關信息，比如常駐地址、身高體重、衣著相貌等，設定任務到期時間，并在提交表單后支付費用，訂單生成后投放到訂單池中，打手可看到訂單池中的訂單，并進行競標，用戶可查看打手的歷史戰績和自我介紹。

關于費用，在早期可設置固定的活動價。但在產品運作了一段時間后，可把支付動作放到挑選競標打手時，打手可以按照需求情況定期望價格，用戶也可以挑選性價比高的打手，保障雙方的利益。由于需求性質特殊，打手有可能無法順利地執行任務，此時打手可以選擇放棄任務，并說明原因，訂單狀態變更為關閉，用戶可以選擇重新發布此項任務。如果打手按時完成了任務，此時需要提交相關證明，用戶在確認后，解凍資金打入打手賬戶，同時可以評價該打手。如果由于需求沒有說明清楚，打手沒有按照要求完成任務，則訂單進入特殊流程，售后介入，調查實情，并調節糾紛。

其間發生的多種情況，都應當考慮到，早期實施MVP時部分發生特殊的問題，可以通過線下處理來解決，等到流程規范時可排期設計加入到產品功能當中。

在這之前的工作流程中，主要參與的人員有商務、運營、用研還有產品，在下述流程中，交互設計師、視覺設計師還有開發和測試都會加入?？赡苡械耐瑢W會覺得，這個時期技術人員加入會不會早了些，因為還沒涉及實際的開發。但實際情況是技術人員加入后，可以協同進行一些業務功能上初步的思考，部分功能可能會因為開發難度較大，需要一些研究時間或者短時間內根本難以實現，這時候可以及早的駁回需求，避免在后續開發過程中補救，產品結構改動過大。

3.2 信息架構

一般來說，一個正常規模的產品，光靠一個頁面是解決不了用戶需求的，如果MVP版本的產品確實功能比較單一，也應該考慮日后迭代的功能增加，使得MVP可塑。這時候就需要梳理信息在整個產品中的分布。

那么，信息架構設計到底該怎么做？《用戶體驗要素》中，給出了信息架構分類的方法：自上而下或自下而上。

• 自上而下。從產品的戰略目標出發，按照滿足目標的功能出發，按照分析出的細化需求分級，一層一層地將每個模塊拆解。本文講述的工作流程比較適用這種方法實施的。這種思考方式有明顯的優點，產品從整體到落地，都不會脫離最初的目標，而拘泥于細節。
• 自下而上。此類方法關注的是具體的功能點，使用此類方法將會需要小組頭腦風暴來思考功能點，并整合歸類，組建功能模塊。產出的產品更加細膩，但可能會失去產品的根本目標，導致產品定位不準確，功能雜糅瑣碎。

有一點要注意的是，在輸出思維導圖時要清晰干練，不要把所有功能點都羅列出來，不然就失去了思維導圖的意義。下面這張圖是在早期研究網易LOFTER時繪制的一張信息架構圖，作為反面例子。如果一個產品的架構較大，可以按照功能板塊逐個分析。

（在新標簽頁中打開，即可查看大圖）

3.3 交互設計

關于交互設計，在產品設計中從信息架構的布局開始，就包含了交互設計，比如在電商類目導航設計時，同類的或可相互搭配的商品會分為一類，這樣分類更符合用戶的預期。企業實際招聘時，會要求產品崗能力范圍包含了改善用戶體驗并做出有效的交互設計。

產品設計早期，要保障產品基本的可用性。大致包含了一下幾方面：

• 高效：幫助用戶高效的完成沒目標任務，減少流程中的步驟。
• 有效：用戶需要完成的任務對于用戶是有幫助的。
• 易用：減少認知和使用成本，使產品好用好記。
• 容錯：允許用戶犯錯，并設計相對應的補救措施。

交互設計大師尼爾森層發布過「十大可用性原則」，比筆者分析的更具體，觀眾老爺可自行搜索查閱。相關書籍推薦《About Face4交互設計精髓》，該書講解了多種產品形態的交互設計，涵蓋范圍非常廣，幾乎適用全場景，可作為工具書使用。

這個階段最重要的就是產品需求文檔的撰寫和原型的設計，在敏捷開發中，大多數產品崗同學都會選擇原型圖+標注的形式來輸出。但對于要和甲方或者老板的溝通的時候，可能會設計一個高保真原型，和產品需求文檔分離開，無論哪種方式看具體工作情況來選擇，最理想的狀態還是文檔和原型一起設計，如下圖概覽和客戶端模塊。工具用的Axure，關于工具類介紹，請移步筆者公眾號另外一篇文章《產品汪的作戰工具》。

4. 產品落地

4.1 項目管理

一般互聯網公司的項目負責人會身兼數職，產品經理兼項目經理，技術負責人兼項目經理，或者干脆是老板。如果產品崗沒有實權也應該把握項目進度的節奏，在前期產品規劃中，考慮到項目實施的難度，量化項目進度，也就是大多數產品經理會說的“節奏感”。

首先會有一個明確的運營目標，要在一個階段內達到什么樣的一個指標，這點決定了產品早期的功能是有限的，早期項目盈利狀況可預計但不可見，項目配備人員也有限，尤其是開發人員，要把握好產品迭代的節奏。

前文說道，在早期運營、商務、市場人員已經介入到項目需求分析中來在，這時候他們可能會提一些對于產品未來的運營方針，要求在早期版本的加入更多可盈利的功能需求，這可能會因為一些利益問題導致團隊內部矛盾，下面團隊協作和需求管理會講到。還有一點要注意的是，關于項目延期，有些時候可能不是執行團隊內部的問題，也可能是決策者規劃的失誤，所以不要亂扣鍋子，擾了士氣。

圖片來自網絡

4.2 團隊協作

一個項目能否成功，和團隊協作有著密切的關系。大家從五湖四海而來，為了一個目標奮斗，總歸是斗志滿滿的。但身而為人，都是有缺陷的，不光是來自職業技能上的，還有性格這類相對隱性的屬性。作為產品經理，應該好好了解團隊成員的履歷，擅長做什么，不擅長做什么，性格怎么樣，這點很重要。

從工作流程上來講，產品崗的工作處在開發、設計還有運營的上游，前期沒有過多思考導致需求總是變更，而且是本可以避免的的需求變更，會消耗同事們的斗志，尤其是開發老哥們，半夜被叫起來改BUG本身就疲憊了，第二天來上班還被告知需求變更，之前的努力都白費了，這種心情觀眾老爺應該也會理解。運營為了完成KPI，可能會提出一些需求，比如一個復雜的社會化分享功能，導致產品定位模糊，這時候需要好好溝通，如果可行在版本迭代式加入驗證想法，如果不可行，也不要當面回絕，可以和運營同事一起思考找出替代的方法。產品經理的同理心不光要用在產品受眾身上，還要用在你同事身上。

世事洞明皆學問，人情練達即文章。這點，沒法分享具體的經驗。

不到萬不得已，別懟。

4.3 需求管理

需求管理直接影響到項目的排期計劃，多數執行型產品經理沒有話語權，經常會被需求牽著走，導致自己工作很累，還經常背黑鍋。這時候就要好好管理需求，這和前文團隊協作也分不開，拿到需求的時候先分析，從以下幾點思考：

• 用戶體驗：在產品早期，這類需求基本會被無視，只保障基本的可用性。
• 技術難度：現階段技術支持直接影響一個需求能否做。
• 商業價值：對于C端產品而言，這點會和用戶需求沖突，典型的問題就是廣告。
• ROI：即投入產出比，需要估計項目投入成本以及能帶來的價值

然后更具這幾點來排列需求優先級，需求評估說到底就是價值評估。有很多突發的情況就是，老板一拍腦袋想出了一個好點子，這種時候，私下里找老板溝通，問清該需求的來源，如果老板執意要做，那就按照老板的想法來吧。(逃

需求管理需要納入需求池，一些被擱置的需求如果不做好記錄，可能會被遺忘。下面圖表為業內比較通用的需求池模板：

在主動采集需求的時候，做好需求來源的記錄，分析具體情況，深挖背后的需求。在被動接收需求的時候也盡量讓需求提出者描述需求，可能需求提出者在填寫表格的時候思考清楚了這個需求有沒有存在的必要，這個方法能節約產品經理分析垃圾需求的時間。

4.4 用例測試

把測試環節單獨拿出來講，是因為產品經理在寫產品需求文檔的時候可能考慮不到很多細節，或者一些特殊場景，一般思考的是單元用例，而集成測試時會發生很多突發問題，比如一些刪除操作引發的關聯變動。

測試人員作為專業挑毛病的人則會思考的更縝密，技術出身的測試人員邏輯思維也要強于一般產品經理。早發現，早治療，趁著產品開沒進入開發環節，趕緊補充細節需求。比如，一般運營后臺或者B端產品，會有系統使用者權限管理，日常使用中總會出現各種情況，總有一些是產品經理遺漏的。這時候就要泡杯咖啡，虛心請教下測試同學。下列圖片例舉了部分特殊情況，沒有提供解決方案。

經過了一輪輪的任務對接，改完了一堆bug，也美化產品UI，驗收了產品，終于到發布產品這令人激動的時刻了。但在正式發布前，還有準備工作要做。

5. 發布上線

5.1 灰度發布

灰度發布常用于驗證產品是否符合用戶心理預期，觀察市場對產品的接受程度，只向少部分目標用戶發布產品，并根據反饋在短時間內做出快速調整，游戲行業的公測就是典型的灰度發布，是一種常規化的流程。有些時候部分不能確定的功能會選擇在這個時候做AB測試，甚至是ABCDE的測試。一些空白市場的創業者常使用這種方式，用MVP低調地驗證商業可行性。

還有一點就是，產品在開發環境和測試環境經過了多輪測試，也不可能保證產品完全沒有BUG?；叶劝l布在某種意義上，是用線上環境做測試。

5.2 使用說明

B端產品在產品上線前需要需要對商務、銷售、運營和客服進行集中培訓，光靠ppt講解和產品演示還不夠，需要撰寫用戶使用說明書，不光是內部人員要了解，還要讓目標用戶理解產品的操作。一些面向農業等目標用戶受教育水平低的SaaS產品，則會在產品設計時最大化產品的易用性，使得用戶能夠快速上手產品。

而對于C端產品，撰寫的用戶說明手冊則不會是面向用戶的，需要用戶查看使用說明書來使用的C端產品基本就可以宣判死刑了。如果產品一些功能是創新的，史無前例或者有一定的使用成本，一般都會選擇加入引導流程，來引導用戶使用。移動端產品則可以在開屏頁加入新特性說明或者功能說明。

圖片來自網絡

5.3 運營策略

互利網發展了數年，產品運營的方法論層出不窮，AARRR模型的運營方法論在業內比較受認同，這里著重介紹。

AARRR模型為獲?。ˋcquisition）、激活（Activation）、留存（Retention）、收入（Revenue）、傳播（Referral）的首字母縮寫。引用某度詞條對該模型的解釋

獲取用戶（Acquisition）

運營一款移動應用的第一步，毫無疑問是獲取用戶，也就是大家通常所說的推廣。如果沒有用戶，就談不上運營。

提高活躍度（Activation）

很多用戶可能是通過終端預置（刷機）、廣告等不同的渠道進入應用的，這些用戶是被動地進入應用的。如何把他們轉化為活躍用戶，是運營者面臨的第一個問題。

當然，這里面一個重要的因素是推廣渠道的質量。差的推廣渠道帶來的是大量的一次性用戶，也就是那種啟動一次，但是再也不會使用的那種用戶。嚴格意義上說，這種不能算是真正的用戶。好的推廣渠道往往是有針對性地圈定了目標人群，他們帶來的用戶和應用設計時設定的目標人群有很大吻合度，這樣的用戶通常比較容易成為活躍用戶。另外，挑選推廣渠道的時候一定要先分析自己應用的特性（例如是否小眾應用）以及目標人群。對別人來說是個好的推廣渠道，對你卻不一定合適。

另一個重要的因素是產品本身是否能在最初使用的幾十秒鐘內抓住用戶。再有內涵的應用，如果給人的第一印象不好，也會“相親”失敗，成為“嫁不出去的老大難”。

此外，還有些應用會通過體驗良好的新手教程來吸引新用戶，這在游戲行業尤其突出。

提高留存率（Retention）

有些應用在解決了活躍度的問題以后，又發現了另一個問題：“用戶來得快、走得也快”。有時候我們也說是這款應用沒有用戶粘性。

我們都知道，通常保留一個老客戶的成本要遠遠低于獲取一個新客戶的成本。所以狗熊掰玉米（拿一個、丟一個）的情況是應用運營的大忌。但是很多應用確實并不清楚用戶是在什么時間流失的，于是一方面他們不斷地開拓新用戶，另一方面又不斷地有大量用戶流失。

解決這個問題首先需要通過日留存率、周留存率、月留存率等指標監控應用的用戶流失情況，并采取相應的手段在用戶流失之前，激勵這些用戶繼續使用應用。

留存率跟應用的類型也有很大關系。通常來說，工具類應用的首月留存率可能普遍比游戲類的首月流存率要高。

獲取收入（Revenue）

獲取收入其實是應用運營最核心的一塊。極少有人開發一款應用只是純粹出于興趣，絕大多數開發者最關心的就是收入。即使是免費應用，也應該有其盈利的模式。

收入有很多種來源，主要的有三種：付費應用、應用內付費、以及廣告。付費應用在國內的接受程度很低，包括Google Play Store在中國也只推免費應用。在國內，廣告是大部分開發者的收入來源，而應用內付費目前在游戲行業應用比較多。

無論是以上哪一種，收入都直接或間接來自用戶。所以，前面所提的提高活躍度、提高留存率，對獲取收入來說，是必需的基礎。用戶基數大了，收入才有可能上量。

自傳播（Refer）

以前的運營模型到第四個層次就結束了，但是社交網絡的興起，使得運營增加了一個方面，就是基于社交網絡的病毒式傳播，這已經成為獲取用戶的一個新途徑。這個方式的成本很低，而且效果有可能非常好；唯一的前提是產品自身要足夠好，有很好的口碑。

從自傳播到再次獲取新用戶，應用運營形成了一個螺旋式上升的軌道。而那些優秀的應用就很好地利用了這個軌道，不斷擴大自己的用戶群體。

通過上述這個AARRR模型，我們看到獲取用戶（推廣）只是整個應用運營中的第一步，好戲都還在后頭。如果只看推廣，不重視運管中的其它幾個層次，任由用戶自生自滅，那么應用的前景必定是暗淡的。

不同產品每個環節需要做的工作差別很大，本文主要講述產品崗工作流，關于運營相關工作不詳細展開。

6. 反饋分析

6.1 用戶反饋

用戶反饋是采集用戶需求的重要來源，一般直面用戶的是運營和客服，這類二手需求在解讀時需要考慮具體情況，這時候上文提及的需求采集表就發揮了大作用，然鵝日常工作中，運營和客服都不愿意寫這么繁復的表格，每天需要解決這么多用戶的各種問題已經很心累，還要加上額外的需求采集的工作，可能會造成情緒問題，如果發生這種情況，可以適當的調整信息采集的內容格式。作為產品設計者，產品經理應不定期的輪崗到用戶運營或客服，如果公司業務是做B端產品的，那應該和BD去拜訪客戶，了解最真實的需求，這種一手的需求會給產品經理培養同理心帶來很大的幫助，也防止在需求轉述的過程中造成偏差，影響產品設計。

對于運營策略，筆者沒有做過具體的運營執行，沒有建設性意義的建議幫助各位觀眾老爺，搭建運營支撐系統的數據分析模塊可以參照幾款大廠的數據統計系統，Google Analytics、Mixpanel、騰訊分析、百度統計、GrowingIO等。筆者會在后續文章中詳細描述如何在數據BI系統中減少開發成本，提高運營參與度。

說在后面

到這里全文就結束了，復盤了從業這幾年的經驗，抽時間寫了這篇心得。

筆者才學疏淺，若觀眾老爺有什么高見，還請猛烈拍磚。

雙擊666，訂閱走一波~

我們下次再見。

相關閱讀

《長文 | 如何從0到1搭建產品（上篇）》

作者：水果籃子，公眾號：老楊陪你來說事兒

本文由 @水果籃子 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自PEXELS，基于CC0協議