來源丨鳥哥筆記

作者丨華飛

（一）項目啟動前

從事產品的工作一年多，但自己一直苦于這樣或者那樣的困惑，很多人想要從事產品，或者老板自己創業要親自承擔產品一職，但他們對產品這個崗位的認識卻不明晰，有的以為是純粹的畫原型，有的是以為做項目管理跟蹤項目進度，有的是做競品分析給老板看。實際上，這些都不是產品經理的核心和重點。在較為成熟的企業，因為產品的壯大和人員的增多，為了便于協作和溝通，崗位會細化的很清楚，如產品經理、交互設計師、UI設計師、用戶體驗分析師、數據分析師、運營等等。但是創業型公司中產品經理往往都是身兼數職，創業公司追求的是效率最大化、成本最低化，根本沒精力將崗位分的那么細致。下面我以一個創業者的視角或者說負責一個產品項目的產品經理角度出發，來審視整個過程，看一個產品從無到有，產品經理需要哪些事情。

產品從概念到產出到流程

做任何東西之前，首先要考慮其背后的用戶需求、商業價值、技術難度。只有用戶有需求，你的產品才會有人用；只有其商業價值成立，才能為企業帶來利潤，畢竟企業最最基本的目標就是要盈利；只有技術上的總體評估是可行的，整個項目才可被執行。現在的互聯網創業，大家都在追求”快“，比如2個月融資，4月用戶過百萬，3年后納斯達克上市。但是這都是大家看到別人創業成功的表象，殊不知做任何事情的前提是，你得了解你在做什么，誠然，不排除哪些膽子大運氣好隨便干就成了的，但那只是個案，不值得深究。

一、用戶需求

1.1產品定位

在項目的執行過程中，我們經常陷入一種情景，就是一堆人在一塊，討論的氛圍可謂是情緒高漲，A說這個地方的按鈕不行，B說這個地方應該像人家APP那樣做，C又說你們都不對應該是這個模塊不要換成這個云云。經常參加這種討論，會無比的耗費時間和體力，動輒好幾個小時過去，但一散會，發現什么結果也沒得出來。多數情況下，一定是產品定位出了問題。執行的人一定要清楚的明白產品是用來干什么的，給什么人用，才能正常的去討論具體細節。如果熱血沸騰、蹬鼻子上臉的的討論了好久，發現沒結果，發現會議的討論跑偏了，不妨回歸本質，想想我們的產品定位是什么。

產品定義：

產品定位包含兩個大的內容一個是產品定義，另一個是需求定義。產品定義要分析的內容包含產品的使用人群、主要功能和產品特色。

舉例，你現在要創業搞一個移動端招聘APP取，作為產品經理首先應該干什么？中國每年的就業人口非常龐大，行業也各種各樣，那你就有要想，你的產品是要給什么樣的人提供服務，你如果想服務所有行業的人群那是不可能的，首先一個小公司去整合這么多行業招聘信息本身就非常困難，另外并不是每個行業的人對互聯網的接受程度那么高。

通過數據分析和調研，發現現在國家鼓勵創業，創業的高峰期必然產生大量的人力需求，尤其是現場幾乎說到創業沒有哪個是跟互聯網無關的，而且從事互聯網的人對于APP的接受程度也很高，至少都愿意嘗試。所以你把互聯網這個行業的從業人群作為你產品的使用人群。

當你分析完其他招聘類APP后，你發現這些APP有很多問題，比如我就是要找北京西二旗那邊的工作，但是很多APP目前都是沒位置篩選；雖然可以海投，但是得到的反饋的寥寥無幾；能夠了解的企業信息太少；在投遞建立前，作為求職者希望知道這個公司的老板是誰；現在都互聯網時代，電子簡歷完全可以了，為什么每次招聘還需要招聘者自己打印簡歷，要知道打印簡歷對于求職者來講并不是很方便，因為隨時會改動，這對求職者非常不方便。所以你打算做這個APP，他的特色功能就是1、崗位支持企業所在位置分類；2、招聘方應該時時給予求職者反饋；3、取消紙質簡歷。主要功能就是招聘。現在我們給APP取名叫做飛鴿招聘。

需求定義：

需求定義的分析包含目標用戶、使用場景、用戶目標三個方面。目標用戶是什么類型的人會用你的產品；主要功能是指你的產品是用來干什么的，是工具是社交還是其他；你的產品相對于其他市面上的產品有什么不同的地方，這就是產品特色。

剛才明確了APP的適用人群、主要功能和產品特色。市面上的招聘APP，有的是做獵頭的專門針對于希望跳槽的，你的APP的目標用戶是誰？基于特色功能分析和用戶痛點，分析出出產品的目標用戶是那些有想在具體位置找工作的人，比如已經定居北京后沙峪的人，希望工作在望京；當你剛剛搬家到回龍觀時，此時你面臨著換工作，你可能會傾向于找西二旗那邊的工作。

1.2需求分析

以上就是所有產品定位的內容。這些完成之后，緊接著的就是競品分析和用戶調研，一方面這是對我們的需求進行一定的驗證，另一方面也是我們直接接觸用戶的一個機會，看用戶存在什么需求。

1.3需求篩選

早期需求篩選是個非常苦逼的事情，如果產品經理自己就是老板，自己心里很清除還行，如果不是很容易陷入海量的需求中拔不出來，討論著討論著就跑偏了，討論完之后好像什么功能都需要，這個功能有用，必須加；那個功能太好玩了，用戶肯定有趣。這話總完全憑個人主觀臆斷的東西，往往都是當時聽起來貌似合理，但事后卻經不起推敲。所以我們需要始終把握住我們的產品定位和優先級，萬不可盲目的在這個地方做很多無畏的犧牲和奮斗（少做不經思考的、拍腦袋的、不經過大腦的決定）。

需求記錄表：

早起需求篩選期間，會出現很多這樣或者那樣的需求，有些我們不能立馬做出判斷說做還是不錯，這些點子有可能以后會成為我們產品迭代的啟發點，也會給產品的發展帶來更廣的思路。做好管理，尊重每一個人的想法，在出現模棱兩可時，記錄下載，對會議的推動和進展會有很大的幫助。

二、商業價值

市場需求文檔和商業需求文檔，一般在大公司會得到比較成熟的體現。小公司往往多數都是老板自己決定，老板可能不會搞這樣或者那樣的文檔，但他自己肯定會去做基本了解，或者本身自己就很了解某個行業。這兩個文檔并不是多余的，也不是累贅，如果在項目啟動前，能夠花一定的時間去深入了解行業和用戶是非常必要的。具體文檔細節在這里不做闡述，網上有很多可以去借鑒的。

三、技術評估

作為不是技術出身的人，就不再這里轉筆了。尊重開發人員，和開發相處融洽一點，會對產品的推動非常有幫助。

（二）項目執行中

在前文中已經給大家講了項目啟動前應該做的三大塊1、需求；2、商業；3、技術。在這些準備工作整理完之后，接下來就是執行，執行過程中不像之前需要考慮的那么宏觀，但需要你足夠的細心和耐心。

一、產品層面

需求產生了之后，緊接著產品人員就可以產出需求文檔，需求文檔對接下來交互設計（創業公司往往產品經理會擔任）、UI設計起著關鍵性的作用，當然在需求聞文檔產生的過程中，如果有專職的交互設計，在需求階段最好和產品人員一起來探討需求文檔的細節，這對于交互設計自己理解整體的需求有幫助，也對他進行原型設計和撰寫交互說明有很好的幫助。

需求文檔大致包含的內容會有如下幾個方面：

背景描述：為什么開展這個項目？解決用戶什么問題？會有多大的價值？大致就是把項目啟動前做的功課進行一下總結說明，務必精簡明了。

用戶畫像：對用戶特征進行虛擬說明，闡明用戶情況。

項目時間規劃：什么時候出來原型？什么時候出來真實設計稿；什么時候進入開發？什么時候開始測試？什么時候開始提交應用商店？  這些都需要明確出來，不然如果沒有時間概念，什么事情都會拖拖拉拉，沒有緊迫感。

信息結構圖：APP的內容組織結構。下面是舉例，簡單的給出微信的基本結構。

任務流程圖：對于APP中的大功能，把用戶從開始到結束的整個過程梳理出來，把各種可能性考慮進來，否則之后如果開發碰到問題了問你，你還得重新考慮，更可怕的是開發不問你直接就開發了，而結果還不是你想要的。下面以一個簡單的登錄為例：

需求說明：把每個操作的條件和結果說清楚，如果能夠用文字說清楚的就用文字，說不清楚的最好用圖片。可能有的人會說，這個時候還沒有線框圖，怎么解釋啊。這個并不矛盾，早起的需求文檔是用來給交互看的（再次強調，創業型公司的產品可能會兼著交互），交互設計師再根據你的功能結構和流程梳來設計線框圖和高保真的原型圖。

數據埋點：把后期需要查看的數據列成清單，比如說這個按鈕的點擊率，這個頁面的打開率等等，這個時候需要和運營多交流，對需要做埋點的地方理清楚。這對于產品上線后的數據分析很有幫助，數據也可以輔助產品功能的迭代。

二、交互設計

需求整理完成之后，接下來大致要進行的就是線框圖、頁面流程、高保真原型圖和交互說明的設計和產出。高保真原型是具體情況來定，有的公司有要求，有的沒有。

2.2線框圖：

力求簡單清晰的表達出每個頁面的視覺效果，這里最好不要加入交互，也不要搞的五顏六色，最好是黑灰色。每個情形就是一個頁面，把各個情況用頁面分別表達出來，一方面你會更加清晰APP整體的界面數量，另外設計也會更加清楚你想要什么，否則加入了交互，設計也不知道怎么點，你還得解釋半天。

2.2頁面流程圖：

比較類似之前的信息結構圖，頁面流程圖這是用各個頁面來做連接，視覺上更加清晰各個環節的銜接和跳轉。

2.3高保真原型圖：

對交互的要求會更高。需要比較完整的展現各個功能之間的交互動作，另外在視覺上盡量還原真實產品的樣子。（關于Axure，可以學習金烏的課程，很不錯，很多人覺得講的太羅嗦，但是你認真看下來還是很有收貨的）

2.4交互說明：

我個人覺得，交互說明和高保真原型有重合之處，如果做了高保真，那么多數的交互動作基本上都可以展現。但是有些地方的交互動效是軟件無法搞定了，這個時候就需要你用交互說明了。

如果文字和圖片都不要說明的就直接用紙片來模擬。不要小看這種方式。

這里做交互標記的工具推薦幾個給大家：mac電腦果斷是sketch了；windows下有snagit、圈點、FScapture，另外viso也可以標注。

三、UI設計

一般情況下，交互設計師講線框圖交給設計師，設計師就可以開工了。這個過程，交互也要多和設計去溝通，畢竟UI也會有自己的專業度，她會有自己的設計見解，這很正常。

四、項目執行

設計產出了，交互的工作也做完了，該去交給項目經理執行了，這個身份目前來看那只有很大的公司里才會有，一般情況下是由產品經理直接兼任了。這里需要提醒的是，在執行前，各種相關的規范要先建立起來。比如：

4.1apk、api文件的命名規范和不同類型安裝包的管理：

這里全是我個人的經驗，做好這些，會對以后安裝包的管理會有極大的幫助。我們當時把搭建了一個開發者環境，這個環境下的APK、API文件只能在局域網類使用，在這個環境下可以任意折騰和測試，不會影響到已經上線的應用。

開發者環境下打包的安裝包圖標和命名要和線上環境下的應用區別開。以后在續測試時就不會因為各個版本搞的手忙腳亂。

4.2APK、API文件管理

4.2.1開發版：純開發自己使用或者產品使用，其他無關人員一般情況下不會接觸到這個版本。網絡環境：僅特定網絡環境下使用（需要技術人員搭建環境）。

4.2.2公測版：經過產品和測試人員的詳細測試后，基本沒有什么BUG了，就可以拿出來給公司的人使用，也算是上線前的穩定性測試。網絡環境：僅在特定環境下可以使用（需要技術搭建環境）。

4.2.3商店版：準備提交到市場的APK、API文件。在經過開發版本、公測版的全面測試后，排除一切不穩定bug，此時打包的商店版仍然需要經測試人員的最后把關，最后一定要保證的是，準備上線的APK、API文件是經過測試人員的最后把關的，否則如果開發如果做了改動不通知測試和產品人員，上線后出了問題再改就晚了。

五、APP測試和版本號管理

版本好號的管理，前期就要搞清楚，否則后面產品上線后，出現bug要改進，或者添加新功能后對老版本是否有影響，這個時候版本號管理的好就會起到很大的作用，一方面你可以隨時找出之前上線過的apk、API文件，另一方面面對不斷修改打包的文件不至于把自己搞混。

下面是我個人的意見，如哪個大牛有好方法可以分享出來。版本號始終是唯一的，是依次迭代遞進的，不要為了上線時版本號好看就去刻意干擾版本號，嚴禁搞多套版本號。

測試須知：

UI、交互、產品在技術人員開發階段，要多和技術人員溝通，最好是將大功能細化成小功能模塊，每次做好一部分就通知相關的人進行檢查，以免累計到最后問題過多修改動作太大。UI負責盯著開發是否按照自己的設計實現的，交互負責關注交互效果是否符合你的標準，產品負責關注各個功能的實現是否正確。

測試用例：好的測試用例能夠有效的推進測試的進程，好的測試用例在于盡可能的把APP的各種需要測試的情況用人話描述清楚，這點就看你的文字能力了，測試用例寫出來會交給測試人員來測，這也是他們評判APP是否達標的標準。

Bug管理工具：bugtags,bugclose等等，市面上有很多，多是免費的，即使是收費也不要在意那么點錢，借助bug管理工具能夠有效的提高測試人員和技術人員的協作效率。

（三）項目上線后

之前給大家介紹了兩個部分，項目啟動前和項目執行中。項目上線后，作為產品需要關注的事情有幾個方面，一是APP數據，二是用戶反饋，三是需求提取。

一、APP數據

新增用戶：第一次啟動應用的用戶；

新增獨立用戶：全體應用的新增用戶的總和（去重）

活躍用戶：當天啟動一次的用戶即為活躍用戶，含新用戶和老用戶；

活躍獨立用戶：當天應用的活躍用戶總和（去重）

MAU：MAU（monthly active users）月活躍用戶人數。

DAU:DAU(Daily Active User)日活躍用戶數量。常用于反映網站、互聯網應用或網絡游戲的運營情況。

用戶留存率：在互聯網行業中，用戶在某段時間內開始使用應用，經過一段時間后，仍然繼續使用該應用的用戶，被認作是留存用戶。這部分用戶占當時新增用戶的比例即是留存率，會按照每隔1單位時間（例日、周、月）來進行統計。

用戶留存率中的40-20-10法則：如果你想讓游戲、應用的DAU超過100萬，那么日留存率應該大于40%，周留存率和月留存率分別大于20%和10%。

次日留存率：（當天新增的用戶中，在往后的第1天還活躍的用戶數）/第一天新增總用戶數；

第2日留存率：（第一天新增用戶中，在往后的第2天還有活躍的用戶數）/第一天新增總用戶數；

第7日留存率：（第一天新增的用戶中，在往后的第7天還有活躍的用戶數）/第一天新增總用戶數；

第30日留存率：（第一天新增的用戶中，在往后的第30天還有活躍的用戶數）/第一天新增總用戶數。

另外就是APP的埋點數據，這個功能的點擊率是多少？這個功能有多少人打開，又有多少人使用了？有多少人在頻繁使用這個功能？等等，這些埋點數據要時常關注。結合數據變化來反思功能設計的問題，從而優化產品。

二、用戶反饋和評論

產品上線后，用戶的反饋和評論對于產品人員來講是尤為珍貴的材料，一方面這是你的真實用戶的直觀感受，另一方面他們再表達直接的需求。那么，怎么樣處理用戶的意見就顯得格外重要。用戶反饋什么我們就做什么，這是肯定不行的。很多情況下用戶表達的只是一種表面現象，要學會去挖掘用戶背后的需求本質。多去研究世界上一些革命性的產品，多去了解人。

當看到四處飛來的意見時，我們要學會思考，而不是全盤接受、全盤照抄。

是不是我們的目標？想想我們的目標用戶是誰。

使用場景是否成立？還是這只是極個別人的場景需求。

用戶目標是否正確？我們的APP是不是用來滿足用戶這個需求的？

產品定位還正確嗎？如果做了這個功能，還符合我們產品的定位嗎？

如果要做這個功能，那么自身的項目資源是否能夠滿足？如果需要舉全部資源來做這件事情，那就要慎重再慎重。

三、需求提取

也許用戶的意見是個圓形，但經過分析之后，很有可能得到需求是個三角形。

“如果我最初問消費者他們想要什么，他們應該是會告訴我，‘要一匹更快的馬！’”

——這是亨利·福特的一句經典名言，如今我們在《喬布斯傳》里又見到了它。

100多年前，福特公司的創始人亨利·福特先生到處跑去問客戶：“您需要一個什么樣的更好的交通工具？”幾乎所有人的答案都是：“我要一匹更快的馬”。很多人聽到這個答案，于是立馬跑到馬場去選馬配種，以滿足客戶的需求。但是福特先生卻沒有立馬往馬場跑，而是接著往下問。

福特：“你為什么需要一匹更快的馬？”

客戶：“因為可以跑得更快！”

福特：“你為什么需要跑得更快？”

客戶：“因為這樣我就可以更早的到達目的地。”

福特：“所以，你要一匹更快的馬的真正用意是？”

客戶：“用更短的時間、更快地到達目的地！”

于是，福特并沒有往馬場跑去，而是選擇了制造汽車去滿足客戶的需求。

客戶需求有顯性需求和隱性需求兩大類。我們通過市場調查得知的往往都是一些諸如“我要一匹更快的馬”這類顯性需求。客戶的顯性需求并不是客戶真正的需求。企業需要根據所收集的顯性需求信息進行深度挖掘和捕獲，以了解客戶的隱性需求是什么，進而分析出客戶的真正需求是什么（例如：用更短的時間、更快地到達目的地）。這就是一個需求分析的過程。

喬布斯所言：“我們的任務是讀懂還沒落到紙面上的東西。”實際上就是用戶隱性需求的深度挖掘。

姑婆那些事兒(www.3377on.com)是互聯網推廣運營知識分享平臺,關注移動推廣(android,ios)運營,網站推廣運營、校園推廣及互聯網領域最新動態 。歡迎關注我們的微信(gupo520),新浪微博(姑婆那些事兒)。

版權聲明:本文來源于互聯網,僅作分享學習之用,姑婆那些事兒負責整理推薦。文章僅代表原作者獨立觀點,不代表本平臺運營者觀點與立場。如有版權問題,請聯系姑婆那些事兒—小秘書(微信號:gpxms001)協商解決,謝謝！