產品汪大大小小的工作中，歸納起來有這樣一些日常事務：

1. 需求管理

2. 寫文檔

3. 項目跟進

4. 數據分析

5. 產品評測

6. 市場調研

需求管理

多半的需求來自自己使用中的感受，用戶反饋和數據大多只是輔助驗證想法、指導需求優先級或啟發靈感的因素。產品同學對需求的把握能力最產品工作中最難的部分，并且常常功夫在事外，平時的積累很重要。做好產品的需求管理，一般有這樣幾件事情：

1）產品定位和長線規劃

一般是半年左右的規劃，做好規劃的基礎是明確或者反思產品最重要解決的用戶需求是什么，產品定位是什么，區分核心功能和附加功能。展現形式最好是ppt，也便于向老大匯報，從產品定位到欲實現的后續功能，這其中的邏輯關系可以看出你對產品規劃的節奏感，也容易讓數據業務層的技術同學做好提前的基礎數據流規劃。

2）零散的想法

靈感這東西常常來無影去無蹤，隨時記下很重要，使用中感到引起困惑的操作流程，吐司文案是否人性化能打動你，引導時機是否恰到好處，哪些環節和交互沒有給用戶及時的反饋，頁面是否突出了該突出的核心功能等。

所謂想法，包括兩部分缺一不可，吐槽（哪里做的不好，產品同學首先應該是個挑剔的用戶）和解決方法（用好奇心探索和發現問題，并能對想到的問題盡量試圖找到一個目前能夠想到或理解的答案是做產品應當訓練自己的一點）。我通常會這樣去找尋解決方式，從競品或有類似場景需求或功能的其他應用吸取靈感，與團隊成員討論或調研他們的看法，從中獲得啟發。

3）用戶反饋

屬于例行工作，堅持有規劃的去做很重要，每周抽2個小時回顧，記下關鍵幾條（新問題、頻率高的問題），并打上標記，便于每月一次從數量和類別分布上的統計。產品同學如果人員充足，這事兒最好輪流做，然后每周簡單碰一次分享一下。

4）bug記錄

使用中任何問題當即記下，任何小問題的修復從提出到修復的效果驗證，整個過程都是PM要參與的，而常常因為問題較瑣碎，做了前者而忽略了后者，想起來的時候發現技術漏做了，甚至是你自己都記不清bug復現的流程或者badcase是什么。所以這種時候好腦筋不如爛筆頭，避免后續麻煩的方法就是管理好你產品中那些可愛的bug，之所以是可愛，因為那些bug都記錄了你產品不斷變化的過程。

產品評測和數據分析也是兩個相對專業的發現產品問題或需求的方法，但它們同時也承擔著評估產品迭代效果的功效，因此放到后面細說，不在此處贅言。

和下面要說的其他產品工作相比，需求管理工作是最需要產品同學之間交流的，定期的頭腦風暴、用戶反饋分享和交流、自己的使用感受交流，會對提高產品工作效率、發散想法有很大的幫助。

寫文檔

說寫文檔這件事兒，要說這么幾點，

確定版本需求

在寫之前，有個重要環節叫“確定當下版本要做什么”，這是需要產品做決策的一種最常見的場景（決策和判斷力是做產品最重要的能力，木有之一）所謂決策，意味著你面前有很多路，也常常意味著你的資源有限，n多需求先做哪個后做哪個、多個需求解決起來有何關系、是否存在天然的先后順序等，都需要產品同學判斷和權衡。但這種能力非一日之功，要慢慢培養，把產品規劃做好，需求、bug管理好，評測分析做好，該做什么其實自然明了。

搭架子

到了寫需求文檔的時候，先搭框架，列出需求點，避免遺漏也能全局把握這個版本的核心功能點。若是大功能，先流程（從主流程主場景開始），再確定頁面，其次確定頁面主功能、輔功能，而后確定頁面元素。若是不涉及頁面的邏輯層面的需求，則重點在于接下來的事情，叫場景想象，你能想象出的場景的豐富性一定程度決定了你寫的文檔的嚴密程度，而往往又決定了測試環節（或你自己驗證時）能發現bug的可能性，最終可能影響上線質量，而后可能影響下個版本的需求。這件事情換言之叫從各個維度說清楚產品可能發生什么，當然也有一些方法可言，分維度的的去說，先從視覺說，用戶什么場景下、做了什么動作的情況下，會呈現出什么樣子，再從數據層面說，什么操作帶來什么數據的變化，再從某個操作前后可能關聯的操作說，如果前面用戶操作過什么，在此處的交互中將發生什么。此處有個小細節是關于產品中的各種交互文案，其實在思考需求細節時順帶確定和寫出是上策，不然很可能回忘，到想到時，常常急于給技術一個方案，而草草了事，那些我們在產品里看到的過于生硬的、或者不夠協調統一的顯得非常沒有誠意的交互吐司，大概就是這么形成的。

反復摳細節

寫文檔還容易犯兩個毛病，一是寫完不看不反思，二是過程中不注意文檔的維護，我曾經多次犯過這樣的問題，評審中發現文檔的紕漏，或發現遺漏的場景和邏輯點。避免犯錯的方法是提前一些寫文檔，且多看幾遍（以假想產品已成形的使用狀態去看）。關于文檔的維護，重要性和做好的方法是態度和習慣問題，不必說。

項目跟進

工作中經歷過很多次延期、意外和疏漏后，我總結出這樣些許經驗：

1）項目時間表。從立項到上線為周期做表格，全局把握項目動態，記錄項目的各個時間節點，在關鍵時間節點上提前告知和提醒相關人員，需求變更也在表格中記錄，便于與QA同步需求。

2）單元性測試。大項目用幾大功能點進行拆分，盡量每周團隊內部出一個版本驗證效果，及時發現問題。

3）敏捷開發。敏捷開發模式，站立會形式，一日一碰。

4）打點統計的規劃。做需求時同時把打點統計需求加入開發中完成，而不是QA環節做。

5）大小版本交替進行。版本規劃中盡量大小版本交替進行，讓團隊的開發節奏一張一弛。

6）版本總結會。延期問題、項目中出現的錯誤、欠缺考慮之處，在上線后的總結會中提出并得到團隊同學重視，避免犯同一錯誤。

數據分析

主要包含這三類分析：

1）例行版本變化分析

例行版本上線分析主要用來持續觀察產品核心功能的相關指標，用于對比分析產品迭代效果。例如看片神器中的用戶量、留存、播放量、資源分布、播放類別分布、播放下砸成功率、搜索相關指標，屬于需要例行觀察的核心指標。

2）新功能效果分析

主要針對剛上線版本的新功能或改進功能進行分析。使用比例、次數、路徑上的各個操作的數量和頻率是否符合預期，和上個版本相比、和同等地位其他功能模塊對比等，方法不一而足。

3）用戶行為分析

每隔一段時間應對所有打點進行統一的分類分析對比，從全局把握產品被使用的情況，以及與產品定位預期是否一致、是否存在一些雞肋功能或做了但沒做好的功能、有何特別的數據顯示了某些用戶行為變化等，通常進行大的版本規劃前這種用戶行為分析是十分必要的。

產品評測

評測的意義在于將體驗從個例擴大為相對準確且可量化的共性上去。評測通常是圍繞一個核心功能，但不止于發現這一功能的產品問題。例如視頻的例行評測包括搜索評測、播放、下載評測。搜索評測可以發現從內容缺失（爬蟲和產品策略問題）、結果排序（搜索排序問題）、結果可用性（聚合、源排序、播放效果問題）等。播放下載評測可以發現解析、播放器、播放流程、切源流程、清晰度策略等多個環節的問題。

市場調研

市場調研除了在產品初期要做以外，實際上產品的生命周期中是一直要關注的，產品要在市場中存活下來，要時刻確定產品有價值的，滿足這個價值的競品做的如何，是否有其他途徑和產品方向可以取代我們的產品等等。細分一下，產品同學要做的市場調研方面的工作有：

1）資訊獲取。每周有固定的時間整理和回顧本周的行業動態，零散時間的積累會在長時間看出效果。

2）新產品體驗。關注移動端新產品，從創意、到視覺、到交互，汲取有價值的方面，或僅僅作為一種開闊眼界也是有價值的，和任何一個領域一門學問一樣，多看是增加見地的最重要的方法。

3）競品分析。大到產品定位，小道一個小的產品功能或交互邏輯，都值得仔細推敲已經實現了這個功能的競品的實現方式，避免出現前人做的不好的地方，才有望從它們中間脫穎而出。

4）產品間的交流。和需求管理類似，市場行情、新產品新創意的分享交流也是提高產品工作效率，培養產品團隊專業性的方法之一。