或許好的產品經理不只是這八個良好的工作習慣，但，你做到了么？本文是關于作者的產品筆記，值得一讀。

1. 維護一份競品跟蹤文檔

競品分析是一個長期、繁重、瑣碎的工作，而不是在剛接觸產品時，寫一份文檔就丟在一邊。維持一份長期的競品分析文檔，保持對競品的關注，不僅可以從中分析競品的策略。競品跟蹤主要從以下三個方面來看：交互變化、功能迭代、戰略變化。

2. 維護一份產品全局文檔

年初我剛接手現在在做的產品時，踩了很多坑，當然現在也還在持續踩。當時幾乎沒有文檔，而僅存的文檔不僅數量稀少，而且過時（跟實際情況有較大的出入）。當時想要知道一個功能的實現邏輯，只能靠自己手工測試，或者讓程序員去查看代碼，效率十分低下。

除了被別人挖的坑埋了之外，我也做過自己挖坑埋自己這樣的蠢事···在做版本迭代的需求的時候，自己是非常清楚上下文和用戶場景，以及在細節處的實現邏輯（要知道在實現過程中，總是會臨時做出一些不在文檔范圍內的小調整），由于調整比較小，所以也沒有體現在文檔中。于是出現了在幾個月后，想不起來當時的實現邏輯的情況···

鑒于以上的慘痛經歷，我開始維護一份產品的全局說明文檔。在這個文檔中說明版本的大致迭代情況、各個模塊的現狀和調整。

在實際情況中，我建議你的產品全局文檔不用寫的特別長，妄想把所有文檔都集中到一個文檔中，我建議你只在這個文檔中說明『變化』和相關文件的地址。

另外，在云筆記中保存文檔也是一個不錯的主意，這非常利于及時修改和查看。但是切記要備份。

3. 橫向記錄版本：版本的需求文檔

請注意自己的需求文檔的閱讀體驗。

好好寫需求文檔。

好好寫需求文檔。

好好寫需求文檔。

重要的事情要說三遍。如果你覺得這個不夠重要，請你去翻一下產品的歷史產品需求文檔再來說話···

結構不清晰的產品需求文檔，不僅會虐死你的繼任產品經理，還有可能虐死自己。請在寫文檔的時候，務必注意格式，注意錯別字，注意結構。確保文檔語句通順，且能夠完美的表達你的想法。

4. 縱向記錄版本

從時間軸上，記錄每個版本的基本信息和概況與上下文

之前已經說了，對競品的迭代要保持關注。但同時也要對自己的產品的迭代進行記錄。這個記錄包括了每次版本迭代的內容和相關信息，以便于以后查詢。

5. 需求池

維護需求池，而非收集所有需求。

在平常工作里，你一定都會收到來自很多同事或用戶的改進建議，千萬不要棄置一旁，也不要立馬將需求加入需求池。多和提需求的同學溝通一下，了解一下需求的上下文、場景等，從多個維度對產品進行評估，如果需求足夠重要就將它加入需求池。

注意要用多個維度對需求進行衡量，建立上下游都認可的衡量體系。譬如隸屬的功能模塊（不同模塊有不同的重要性和優先級）、緊急性（影響程度）、重要性（覆蓋面）等等。

6. 記錄需求的場景與上下文

這個本來是要歸到『好好寫需求文檔』那里，但我覺得很重要就另外抽出來了。

我知道需求文檔是給技術部的程序員看的，而大多數情況下他們并不 care 你需求的上下文、場景和合理性，但是，不管他們是不是 care，你都要記錄下需求對應的場景，好記性不如爛筆頭，千萬不要過度信任自己的記憶力。

7. 良好的文件管理習慣

所有的文件，一定要好好管理，分文件夾擺放，定期備份，及時清理。

不經歷一次找不到重要文件的事情，你就不知道好的文件管理習慣有多重要。

8. 指導全局的文案風格文檔

一個產品的文案會出現在產品的各個角落，一個統一一致的口吻，有助于塑造一個優質的品牌形象。而前后不一致、不禮貌、不細心、冷冰冰的文案風格，將會極大的影響用戶體驗。

而最簡單的解決方案是，將文案風格用文檔的方式確定下來。哪怕團隊只有你一個人在負責產品，也一定要寫下來。寫下來，那就是準則。被遵守的機會也更大一些。

作者：張小四兒，微信公眾號【張小四兒的產品筆記】

本文由 @張小四兒 原創發布于人人都是產品經理。未經許可，禁止轉載。