产品经理是解决问题的人。如何更好地、更高效地解决问题？文档、原型质量，求其上得其中，求其中得其下。提供给开发的是上层次的原型、文档，他们也会提出问题，但这些问题属于让产品上另一个高度的问题。如果提供的是中层次的原型与文档，他们不明确任务，就会一直向你问问题，确认。
写prd的机会不多，是从0到1的项目，涉及到交互逻辑，需要仔细完整地记录。需求调研（各种渠道，现有客户，现有竞品），定个截止日期，这个日期后不再主动进行调研，开始根据调研结果，分析全面业务场景，画UML用例图，不局限于流程图、时序图、状态机、E-R实体图。理清大致的业务场景、流程逻辑后，开始画原型，在原型绘制中可能会发现之前的思路有问题，可以及时返回去修改，因为上述整个过程是逐步确认的过程。
另外我在原型绘制结束后，根据原型撰写prd这一过程速度极慢，我目前按照列表页、新增页、查看页；具体页面按照布局从上至下，一点点撰写，比如标题，查询条件，明细表，表中操作列按钮，表尾固定按钮。目前速度不快，最低的要求是能跟得上交付给开发的速度。
不仅要对工作中遇见的小细节进行知识沉淀，还要记录目前没时间，但逻辑值得优化的点。我之前只想着做自己的知识资产，并没有对自己的工作进行好坏的评价，所谓复盘，不只是列出做了什么，还要反思哪点做得好，哪些可以怎么做得更好。也不知道公司年终会开一个产品部的知识分享不，分享一年中最有成就感的设计，最让人烦恼的一项工作任务，最想改进的一件事。
未完待续。。。