距離上期發(fā)表已經(jīng)差不多一周了，估摸著觀眾老爺也差不多能消化上篇的內(nèi)容了，下面筆者將會(huì)奉上本文的下半篇。enjoy~

上期筆者講述了在產(chǎn)品開發(fā)工作前期的準(zhǔn)備工作，這個(gè)階段的產(chǎn)出物已經(jīng)有了UML用例圖和簡(jiǎn)單的流程圖，當(dāng)然競(jìng)品分析報(bào)告還是得留檔。如果高階職級(jí)需求，MRD和BRD也在這個(gè)時(shí)候輸出了，講述產(chǎn)品潛力和價(jià)值，為你的產(chǎn)品爭(zhēng)取更多資源。

而在這個(gè)階段，該確定的需求已經(jīng)確定了，沒確定的需求被擱置，到最后估計(jì)就這么不了了之。是時(shí)候大干一場(chǎng)了。

少年，亮兵器吧！

3. 需求輸出

3.1 業(yè)務(wù)流程

承接上文所講的業(yè)務(wù)邏輯，這里復(fù)述一次。用戶用例簡(jiǎn)述了參與業(yè)務(wù)的角色，以及發(fā)生這些業(yè)務(wù)的場(chǎng)景，接下來就要細(xì)化各個(gè)業(yè)務(wù)的流程了。關(guān)于流程圖工具的話，win用Visio，mac用Omnigraffle，也可以用在線的Processon等等，什么用著順手用什么，也有見過有的產(chǎn)品崗的同學(xué)用Axure之類的原型設(shè)計(jì)工具。

舉個(gè)例子，還是滴滴打人。

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

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

其間發(fā)生的多種情況，都應(yīng)當(dāng)考慮到，早期實(shí)施MVP時(shí)部分發(fā)生特殊的問題，可以通過線下處理來解決，等到流程規(guī)范時(shí)可排期設(shè)計(jì)加入到產(chǎn)品功能當(dāng)中。

在這之前的工作流程中，主要參與的人員有商務(wù)、運(yùn)營(yíng)、用研還有產(chǎn)品，在下述流程中，交互設(shè)計(jì)師、視覺設(shè)計(jì)師還有開發(fā)和測(cè)試都會(huì)加入?？赡苡械耐瑢W(xué)會(huì)覺得，這個(gè)時(shí)期技術(shù)人員加入會(huì)不會(huì)早了些，因?yàn)檫€沒涉及實(shí)際的開發(fā)。但實(shí)際情況是技術(shù)人員加入后，可以協(xié)同進(jìn)行一些業(yè)務(wù)功能上初步的思考，部分功能可能會(huì)因?yàn)殚_發(fā)難度較大，需要一些研究時(shí)間或者短時(shí)間內(nèi)根本難以實(shí)現(xiàn)，這時(shí)候可以及早的駁回需求，避免在后續(xù)開發(fā)過程中補(bǔ)救，產(chǎn)品結(jié)構(gòu)改動(dòng)過大。

3.2 信息架構(gòu)

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

那么，信息架構(gòu)設(shè)計(jì)到底該怎么做？《用戶體驗(yàn)要素》中，給出了信息架構(gòu)分類的方法：自上而下或自下而上。

• 自上而下。從產(chǎn)品的戰(zhàn)略目標(biāo)出發(fā)，按照滿足目標(biāo)的功能出發(fā)，按照分析出的細(xì)化需求分級(jí)，一層一層地將每個(gè)模塊拆解。本文講述的工作流程比較適用這種方法實(shí)施的。這種思考方式有明顯的優(yōu)點(diǎn)，產(chǎn)品從整體到落地，都不會(huì)脫離最初的目標(biāo)，而拘泥于細(xì)節(jié)。
• 自下而上。此類方法關(guān)注的是具體的功能點(diǎn)，使用此類方法將會(huì)需要小組頭腦風(fēng)暴來思考功能點(diǎn)，并整合歸類，組建功能模塊。產(chǎn)出的產(chǎn)品更加細(xì)膩，但可能會(huì)失去產(chǎn)品的根本目標(biāo)，導(dǎo)致產(chǎn)品定位不準(zhǔn)確，功能雜糅瑣碎。

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

（在新標(biāo)簽頁(yè)中打開，即可查看大圖）

3.3 交互設(shè)計(jì)

關(guān)于交互設(shè)計(jì)，在產(chǎn)品設(shè)計(jì)中從信息架構(gòu)的布局開始，就包含了交互設(shè)計(jì)，比如在電商類目導(dǎo)航設(shè)計(jì)時(shí)，同類的或可相互搭配的商品會(huì)分為一類，這樣分類更符合用戶的預(yù)期。企業(yè)實(shí)際招聘時(shí)，會(huì)要求產(chǎn)品崗能力范圍包含了改善用戶體驗(yàn)并做出有效的交互設(shè)計(jì)。

產(chǎn)品設(shè)計(jì)早期，要保障產(chǎn)品基本的可用性。大致包含了一下幾方面：

• 高效：幫助用戶高效的完成沒目標(biāo)任務(wù)，減少流程中的步驟。
• 有效：用戶需要完成的任務(wù)對(duì)于用戶是有幫助的。
• 易用：減少認(rèn)知和使用成本，使產(chǎn)品好用好記。
• 容錯(cuò)：允許用戶犯錯(cuò)，并設(shè)計(jì)相對(duì)應(yīng)的補(bǔ)救措施。

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

這個(gè)階段最重要的就是產(chǎn)品需求文檔的撰寫和原型的設(shè)計(jì)，在敏捷開發(fā)中，大多數(shù)產(chǎn)品崗?fù)瑢W(xué)都會(huì)選擇原型圖+標(biāo)注的形式來輸出。但對(duì)于要和甲方或者老板的溝通的時(shí)候，可能會(huì)設(shè)計(jì)一個(gè)高保真原型，和產(chǎn)品需求文檔分離開，無論哪種方式看具體工作情況來選擇，最理想的狀態(tài)還是文檔和原型一起設(shè)計(jì)，如下圖概覽和客戶端模塊。工具用的Axure，關(guān)于工具類介紹，請(qǐng)移步筆者公眾號(hào)另外一篇文章《產(chǎn)品汪的作戰(zhàn)工具》。

4. 產(chǎn)品落地

4.1 項(xiàng)目管理

一般互聯(lián)網(wǎng)公司的項(xiàng)目負(fù)責(zé)人會(huì)身兼數(shù)職，產(chǎn)品經(jīng)理兼項(xiàng)目經(jīng)理，技術(shù)負(fù)責(zé)人兼項(xiàng)目經(jīng)理，或者干脆是老板。如果產(chǎn)品崗沒有實(shí)權(quán)也應(yīng)該把握項(xiàng)目進(jìn)度的節(jié)奏，在前期產(chǎn)品規(guī)劃中，考慮到項(xiàng)目實(shí)施的難度，量化項(xiàng)目進(jìn)度，也就是大多數(shù)產(chǎn)品經(jīng)理會(huì)說的“節(jié)奏感”。

首先會(huì)有一個(gè)明確的運(yùn)營(yíng)目標(biāo)，要在一個(gè)階段內(nèi)達(dá)到什么樣的一個(gè)指標(biāo)，這點(diǎn)決定了產(chǎn)品早期的功能是有限的，早期項(xiàng)目盈利狀況可預(yù)計(jì)但不可見，項(xiàng)目配備人員也有限，尤其是開發(fā)人員，要把握好產(chǎn)品迭代的節(jié)奏。

前文說道，在早期運(yùn)營(yíng)、商務(wù)、市場(chǎng)人員已經(jīng)介入到項(xiàng)目需求分析中來在，這時(shí)候他們可能會(huì)提一些對(duì)于產(chǎn)品未來的運(yùn)營(yíng)方針，要求在早期版本的加入更多可盈利的功能需求，這可能會(huì)因?yàn)橐恍├鎲栴}導(dǎo)致團(tuán)隊(duì)內(nèi)部矛盾，下面團(tuán)隊(duì)協(xié)作和需求管理會(huì)講到。還有一點(diǎn)要注意的是，關(guān)于項(xiàng)目延期，有些時(shí)候可能不是執(zhí)行團(tuán)隊(duì)內(nèi)部的問題，也可能是決策者規(guī)劃的失誤，所以不要亂扣鍋?zhàn)?，擾了士氣。

圖片來自網(wǎng)絡(luò)

4.2 團(tuán)隊(duì)協(xié)作

一個(gè)項(xiàng)目能否成功，和團(tuán)隊(duì)協(xié)作有著密切的關(guān)系。大家從五湖四海而來，為了一個(gè)目標(biāo)奮斗，總歸是斗志滿滿的。但身而為人，都是有缺陷的，不光是來自職業(yè)技能上的，還有性格這類相對(duì)隱性的屬性。作為產(chǎn)品經(jīng)理，應(yīng)該好好了解團(tuán)隊(duì)成員的履歷，擅長(zhǎng)做什么，不擅長(zhǎng)做什么，性格怎么樣，這點(diǎn)很重要。

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

世事洞明皆學(xué)問，人情練達(dá)即文章。這點(diǎn)，沒法分享具體的經(jīng)驗(yàn)。

不到萬不得已，別懟。

4.3 需求管理

需求管理直接影響到項(xiàng)目的排期計(jì)劃，多數(shù)執(zhí)行型產(chǎn)品經(jīng)理沒有話語權(quán)，經(jīng)常會(huì)被需求牽著走，導(dǎo)致自己工作很累，還經(jīng)常背黑鍋。這時(shí)候就要好好管理需求，這和前文團(tuán)隊(duì)協(xié)作也分不開，拿到需求的時(shí)候先分析，從以下幾點(diǎn)思考：

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

然后更具這幾點(diǎn)來排列需求優(yōu)先級(jí)，需求評(píng)估說到底就是價(jià)值評(píng)估。有很多突發(fā)的情況就是，老板一拍腦袋想出了一個(gè)好點(diǎn)子，這種時(shí)候，私下里找老板溝通，問清該需求的來源，如果老板執(zhí)意要做，那就按照老板的想法來吧。(逃

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

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

4.4 用例測(cè)試

把測(cè)試環(huán)節(jié)單獨(dú)拿出來講，是因?yàn)楫a(chǎn)品經(jīng)理在寫產(chǎn)品需求文檔的時(shí)候可能考慮不到很多細(xì)節(jié)，或者一些特殊場(chǎng)景，一般思考的是單元用例，而集成測(cè)試時(shí)會(huì)發(fā)生很多突發(fā)問題，比如一些刪除操作引發(fā)的關(guān)聯(lián)變動(dòng)。

測(cè)試人員作為專業(yè)挑毛病的人則會(huì)思考的更縝密，技術(shù)出身的測(cè)試人員邏輯思維也要強(qiáng)于一般產(chǎn)品經(jīng)理。早發(fā)現(xiàn)，早治療，趁著產(chǎn)品開沒進(jìn)入開發(fā)環(huán)節(jié)，趕緊補(bǔ)充細(xì)節(jié)需求。比如，一般運(yùn)營(yíng)后臺(tái)或者B端產(chǎn)品，會(huì)有系統(tǒng)使用者權(quán)限管理，日常使用中總會(huì)出現(xiàn)各種情況，總有一些是產(chǎn)品經(jīng)理遺漏的。這時(shí)候就要泡杯咖啡，虛心請(qǐng)教下測(cè)試同學(xué)。下列圖片例舉了部分特殊情況，沒有提供解決方案。

經(jīng)過了一輪輪的任務(wù)對(duì)接，改完了一堆bug，也美化產(chǎn)品UI，驗(yàn)收了產(chǎn)品，終于到發(fā)布產(chǎn)品這令人激動(dòng)的時(shí)刻了。但在正式發(fā)布前，還有準(zhǔn)備工作要做。

5. 發(fā)布上線

5.1 灰度發(fā)布

灰度發(fā)布常用于驗(yàn)證產(chǎn)品是否符合用戶心理預(yù)期，觀察市場(chǎng)對(duì)產(chǎn)品的接受程度，只向少部分目標(biāo)用戶發(fā)布產(chǎn)品，并根據(jù)反饋在短時(shí)間內(nèi)做出快速調(diào)整，游戲行業(yè)的公測(cè)就是典型的灰度發(fā)布，是一種常規(guī)化的流程。有些時(shí)候部分不能確定的功能會(huì)選擇在這個(gè)時(shí)候做AB測(cè)試，甚至是ABCDE的測(cè)試。一些空白市場(chǎng)的創(chuàng)業(yè)者常使用這種方式，用MVP低調(diào)地驗(yàn)證商業(yè)可行性。

還有一點(diǎn)就是，產(chǎn)品在開發(fā)環(huán)境和測(cè)試環(huán)境經(jīng)過了多輪測(cè)試，也不可能保證產(chǎn)品完全沒有BUG?；叶劝l(fā)布在某種意義上，是用線上環(huán)境做測(cè)試。

5.2 使用說明

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

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

圖片來自網(wǎng)絡(luò)

5.3 運(yùn)營(yíng)策略

互利網(wǎng)發(fā)展了數(shù)年，產(chǎn)品運(yùn)營(yíng)的方法論層出不窮，AARRR模型的運(yùn)營(yíng)方法論在業(yè)內(nèi)比較受認(rèn)同，這里著重介紹。

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

獲取用戶（Acquisition）

運(yùn)營(yíng)一款移動(dòng)應(yīng)用的第一步，毫無疑問是獲取用戶，也就是大家通常所說的推廣。如果沒有用戶，就談不上運(yùn)營(yíng)。

提高活躍度（Activation）

很多用戶可能是通過終端預(yù)置（刷機(jī)）、廣告等不同的渠道進(jìn)入應(yīng)用的，這些用戶是被動(dòng)地進(jìn)入應(yīng)用的。如何把他們轉(zhuǎn)化為活躍用戶，是運(yùn)營(yíng)者面臨的第一個(gè)問題。

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

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

此外，還有些應(yīng)用會(huì)通過體驗(yàn)良好的新手教程來吸引新用戶，這在游戲行業(yè)尤其突出。

提高留存率（Retention）

有些應(yīng)用在解決了活躍度的問題以后，又發(fā)現(xiàn)了另一個(gè)問題：“用戶來得快、走得也快”。有時(shí)候我們也說是這款應(yīng)用沒有用戶粘性。

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

解決這個(gè)問題首先需要通過日留存率、周留存率、月留存率等指標(biāo)監(jiān)控應(yīng)用的用戶流失情況，并采取相應(yīng)的手段在用戶流失之前，激勵(lì)這些用戶繼續(xù)使用應(yīng)用。

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

獲取收入（Revenue）

獲取收入其實(shí)是應(yīng)用運(yùn)營(yíng)最核心的一塊。極少有人開發(fā)一款應(yīng)用只是純粹出于興趣，絕大多數(shù)開發(fā)者最關(guān)心的就是收入。即使是免費(fèi)應(yīng)用，也應(yīng)該有其盈利的模式。

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

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

自傳播（Refer）

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

從自傳播到再次獲取新用戶，應(yīng)用運(yùn)營(yíng)形成了一個(gè)螺旋式上升的軌道。而那些優(yōu)秀的應(yīng)用就很好地利用了這個(gè)軌道，不斷擴(kuò)大自己的用戶群體。

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

不同產(chǎn)品每個(gè)環(huán)節(jié)需要做的工作差別很大，本文主要講述產(chǎn)品崗工作流，關(guān)于運(yùn)營(yíng)相關(guān)工作不詳細(xì)展開。

6. 反饋分析

6.1 用戶反饋

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

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

說在后面

到這里全文就結(jié)束了，復(fù)盤了從業(yè)這幾年的經(jīng)驗(yàn)，抽時(shí)間寫了這篇心得。

筆者才學(xué)疏淺，若觀眾老爺有什么高見，還請(qǐng)猛烈拍磚。

雙擊666，訂閱走一波~

我們下次再見。

相關(guān)閱讀

《長(zhǎng)文 | 如何從0到1搭建產(chǎn)品（上篇）》

作者：水果籃子，公眾號(hào)：老楊陪你來說事兒

本文由 @水果籃子 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自PEXELS，基于CC0協(xié)議