1、维护一份竞品跟踪文档
竞品分析是一个长期、繁重、琐碎的工作，而不是在刚接触产品时，写一份文档就丢在一边。维持一份长期的竞品分析文档，保持对竞品的关注，不仅可以从中分析竞品的策略。竞品跟踪主要从以下三个方面来看：交互变化、功能迭代、战略变化。
2、维护一份产品全局文档
之一：年初我刚接手现在在做的产品时，踩了很多坑，当然现在也还在持续踩。当时几乎没有文档，而仅存的文档不仅数量稀少，而且过时（跟实际情况有较大的出入）。当时想要知道一个功能的实现逻辑，只能靠自己手工测试，或者让程序员去查看代码，效率十分低下。
之二：除了被别人挖的坑埋了之外，我也做过自己挖坑埋自己这样的蠢事···在做版本迭代的需求的时候，自己是非常清楚上下文和用户场景，以及在细节处的实现逻辑（要知道在实现过程中，总是会临时做出一些不在文档范围内的小调整），由于调整比较小，所以也没有体现在文档中。于是出现了在几个月后，想不起来当时的实现逻辑的情况···
鉴于以上的惨痛经历，我开始维护一份产品的全局说明文档。在这个文档中说明版本的大致迭代情况、各个模块的现状和调整。
在实际情况中，我建议你的产品全局文档不用写的特别长，妄想把所有文档都集中到一个文档中，我建议你只在这个文档中说明『变化』和相关文件的地址。
另外，在云笔记中保存文档也是一个不错的主意，这非常利于及时修改和查看。但是切记要备份。
3、横向记录版本：版本的需求文档
请注意自己的需求文档的阅读体验。
好好写需求文档。
好好写需求文档。
好好写需求文档。
重要的事情要说三遍。如果你觉得这个不够重要，请你去翻一下产品的历史产品需求文档再来说话···
结构不清晰的产品需求文档，不仅会虐死你的继任产品经理，还有可能虐死自己。请在写文档的时候，务必注意格式，注意错别字，注意结构。确保文档语句通顺，且能够完美的表达你的想法。
4、纵向记录版本
从时间轴上，记录每个版本的基本信息和概况与上下文
之前已经说了，对竞品的迭代要保持关注。但同时也要对自己的产品的迭代进行记录。这个记录包括了每次版本迭代的内容和相关信息，以便于以后查询。
5、需求池
维护需求池，而非收集所有需求。
在平常工作里，你一定都会收到来自很多同事或用户的改进建议，千万不要弃置一旁，也不要立马将需求加入需求池。多和提需求的同学沟通一下，了解一下需求的上下文、场景等，从多个维度对产品进行评估，如果需求足够重要就将它加入需求池。
注意要用多个维度对需求进行衡量，建立上下游都认可的衡量体系。譬如隶属的功能模块（不同模块有不同的重要性和优先级）、紧急性（影响程度）、重要性（覆盖面）等等。
6、记录需求的场景与上下文
这个本来是要归到『好好写需求文档』那里，但我觉得很重要就另外抽出来了。
我知道需求文档是给技术部的程序员看的，而大多数情况下他们并不 care 你需求的上下文、场景和合理性，但是，不管他们是不是 care，你都要记录下需求对应的场景，好记性不如烂笔头，千万不要过度信任自己的记忆力。
7、良好的文件管理习惯
所有的文件，一定要好好管理，分文件夹摆放，定期备份，及时清理。
不经历一次找不到重要文件的事情，你就不知道好的文件管理习惯有多重要。
8、指导全局的文案风格文档
一个产品的文案会出现在产品的各个角落，一个统一一致的口吻，有助于塑造一个优质的品牌形象。而前后不一致、不礼貌、不细心、冷冰冰的文案风格，将会极大的影响用户体验。
而最简单的是，将文案风格用文档的方式确定下来。哪怕团队只有你一个人在负责产品，也一定要写下来。写下来，那就是准则。被遵守的机会也更大一些。
