產品經理的八個良好工作習慣
或許好的產品經理不只是這八個良好的工作習慣,但,你做到了么?本文是關于作者的產品筆記,值得一讀。
1. 維護一份競品跟蹤文檔
競品分析是一個長期、繁重、瑣碎的工作,而不是在剛接觸產品時,寫一份文檔就丟在一邊。維持一份長期的競品分析文檔,保持對競品的關注,不僅可以從中分析競品的策略。競品跟蹤主要從以下三個方面來看:交互變化、功能迭代、戰略變化。
2. 維護一份產品全局文檔
年初我剛接手現在在做的產品時,踩了很多坑,當然現在也還在持續踩。當時幾乎沒有文檔,而僅存的文檔不僅數量稀少,而且過時(跟實際情況有較大的出入)。當時想要知道一個功能的實現邏輯,只能靠自己手工測試,或者讓程序員去查看代碼,效率十分低下。
除了被別人挖的坑埋了之外,我也做過自己挖坑埋自己這樣的蠢事···在做版本迭代的需求的時候,自己是非常清楚上下文和用戶場景,以及在細節處的實現邏輯(要知道在實現過程中,總是會臨時做出一些不在文檔范圍內的小調整),由于調整比較小,所以也沒有體現在文檔中。于是出現了在幾個月后,想不起來當時的實現邏輯的情況···
鑒于以上的慘痛經歷,我開始維護一份產品的全局說明文檔。在這個文檔中說明版本的大致迭代情況、各個模塊的現狀和調整。
在實際情況中,我建議你的產品全局文檔不用寫的特別長,妄想把所有文檔都集中到一個文檔中,我建議你只在這個文檔中說明『變化』和相關文件的地址。
另外,在云筆記中保存文檔也是一個不錯的主意,這非常利于及時修改和查看。但是切記要備份。
3. 橫向記錄版本:版本的需求文檔
請注意自己的需求文檔的閱讀體驗。
好好寫需求文檔。
好好寫需求文檔。
好好寫需求文檔。
重要的事情要說三遍。如果你覺得這個不夠重要,請你去翻一下產品的歷史產品需求文檔再來說話···
結構不清晰的產品需求文檔,不僅會虐死你的繼任產品經理,還有可能虐死自己。請在寫文檔的時候,務必注意格式,注意錯別字,注意結構。確保文檔語句通順,且能夠完美的表達你的想法。
4. 縱向記錄版本
從時間軸上,記錄每個版本的基本信息和概況與上下文
之前已經說了,對競品的迭代要保持關注。但同時也要對自己的產品的迭代進行記錄。這個記錄包括了每次版本迭代的內容和相關信息,以便于以后查詢。
5. 需求池
維護需求池,而非收集所有需求。
在平常工作里,你一定都會收到來自很多同事或用戶的改進建議,千萬不要棄置一旁,也不要立馬將需求加入需求池。多和提需求的同學溝通一下,了解一下需求的上下文、場景等,從多個維度對產品進行評估,如果需求足夠重要就將它加入需求池。
注意要用多個維度對需求進行衡量,建立上下游都認可的衡量體系。譬如隸屬的功能模塊(不同模塊有不同的重要性和優先級)、緊急性(影響程度)、重要性(覆蓋面)等等。
6. 記錄需求的場景與上下文
這個本來是要歸到『好好寫需求文檔』那里,但我覺得很重要就另外抽出來了。
我知道需求文檔是給技術部的程序員看的,而大多數情況下他們并不 care 你需求的上下文、場景和合理性,但是,不管他們是不是 care,你都要記錄下需求對應的場景,好記性不如爛筆頭,千萬不要過度信任自己的記憶力。
7. 良好的文件管理習慣
所有的文件,一定要好好管理,分文件夾擺放,定期備份,及時清理。
不經歷一次找不到重要文件的事情,你就不知道好的文件管理習慣有多重要。
8. 指導全局的文案風格文檔
一個產品的文案會出現在產品的各個角落,一個統一一致的口吻,有助于塑造一個優質的品牌形象。而前后不一致、不禮貌、不細心、冷冰冰的文案風格,將會極大的影響用戶體驗。
而最簡單的解決方案是,將文案風格用文檔的方式確定下來。哪怕團隊只有你一個人在負責產品,也一定要寫下來。寫下來,那就是準則。被遵守的機會也更大一些。
作者:張小四兒,微信公眾號【張小四兒的產品筆記】
本文由 @張小四兒 原創發布于人人都是產品經理。未經許可,禁止轉載。
真的,文檔,一定要分類,而且備份,總會有很粗心的人
我們程序員不喜歡看需求文檔
。。。
雖然是這樣說,但產品不寫需求文檔,程序員有理由圍攻他了
測試也會非常崩潰
講道理,你看不看我們都要寫呀
直接出交互設計給程序員,他們更喜歡
重要的需求都是關于后端邏輯,而不是交互設計哦
你們后臺和前端都是由一個產品經理來負責么?如果是后臺這塊的話,確實是注重邏輯性,對需求也比較看重,尤其是面向企業或者渠道開發的軟件。
好吧,后臺前端一個人負責,文檔沒有
那你挺厲害的
妹子,顏值高。愛反思和梳理
謝謝夸獎~~~