产品推介
由于公司风气、业务内容，所处的环境可能没有内部（指公司或团体内较为公开的环境）产品分享和推介的惯例或机会。如果可以，需要向公司内部的同事介绍自己的产品，可能不是正式的会议，可能就是闲聊、海报、线上分享会等等。
- 让同事知道我们在做什么
- 提供产品试用条件和意见反馈渠道
同事的反馈，有时能估计市场上旁观者和竞争者的反馈。
文档沉淀
- 产品Q&A：在产品探索阶段思索产品所解决的问题、核心特性时，一般就会有各种Q出现，也随之会有A，将这些问题和思索记录下来也就形成了Q&A，直到后期产品上线，几乎有关产品的问题和解决思路，都能在这个文档里找到。当需要提炼产品特性、做产品宣传、解释为什么选择了某个方案而非其他方案时，都可以从中取材。
- MRD：这是我至今还没有能落地的文档。一份完整的MRD应当能够展现出对行业的纵深洞察，挖掘出行业规律，总结出机会和风险，得到产品是否可行的价值判断。
- 需求清单：各方来源的需求的清单。力求完整地记录需求的背景、来源、原因、提出时间等等。需求清单不是功能清单，不会直接作为开发依据，但它是很重要的参考资料。
- 功能结构：功能结构可以用脑图、表格的形式展示，以功能模块（不一定是前端页面模块）作为分组逻辑，展示产品功能的内容和效果。可以在功能以外补充功能所属的迭代版本、开发优先级等等。
- 系统库表结构：对产品底层的核心数据库表结构，应当在需求梳理阶段就进行整理，评审之后进行相应调整，正式上线之后再做相应更新。保证底表结构清晰准确。
- 需求文档：需求应当按功能模块或重要的功能点进行组织，文档内容应当包括每个功能的背景描述、方案框架、方案内容、如果涉及前端页面，还应当包括页面解释（看板页、表单页、列表页的需注明内容会有些微差异）。需求文档应当记录与当前需求相关的所有内容，或链接到相关文档。保证查看的人能够直接定位到其他关联的文档。
- 需求评审记录：每次需求评审会都应当进行记录。可大致包括待评需求清单、讨论记录、会后待推进三块。其中，待评需求清单是前面所说的，会前就应当整理好的，剩下的则是记录讨论时的重要内容以及会议结束之后还需要就当前需求进一步做的工作。
- 产品说明文档：对产品本身，应当有一份文档能够完整、详尽地介绍它是什么、可以用来做什么的文档，不同角色的人可以从中获得对应的帮助：售前和商务可以知道产品有什么特性，什么样的客户可能会需要它；项目和其他产品可以知道产品的结构，有没有可以借鉴的思路。
- 操作手册：对于产品的每一个功能，都需要有用准确、简明、易于理解的语言撰写操作手册。当然，我一直相信好的产品应当在每一个细节都让人好上手，但是b端产品和c端产品的特点还是不大一样，操作手册还是很有必要的辅助工具。
- 外部依赖清单及相关文档：产品有时不可避免地会调用一些外部组件，或者对外部数据有些依赖。对于这些部分，都应当有很好的归档和导航。
- 落地项目相关文档：除了产品的主干内容，不同项目落地时，会有对应的特性文档，包括使用的数据、组件还有定制模块，对于这些内容，也应当合理地组织归档。