2018-01-10“完美主义倾向很多时候来源于对目标的不清晰和对真正产品价值思考的逃避”，非常赞同这句话，我之前就一直在追求事事完美，还自以为是产品经理必备的素质，其实在很多情况下，浪费了大量时间。现在越来越觉得，对目标的定义，对价值的思考，对投入产出比的把握，才是产品经理的核心价值。
对于各种文档也是，能做到有效沟通即可，当然除了内容，让别人看着顺畅和舒服也是需要考虑的。作为产品经理，要时刻提醒自己，不要为了形式而忘了目标。 9
2018-01-09感谢分享，今天的文章是产品经理的重要工作之一，很多时候我们会忘了将自己最重要的产品打磨好，交付给相关人员，这也是做事的态度。
我有两点想法：
一是用户用例，个人理解是将与用户交互的整个流程和逻辑全部理清楚，也就是偏向于在场景中解决问题，这一部分也是为了让我们更快速地测试与上线准备。
二是产品原型与交互稿上次经提醒，我现在正在用印象笔记拍照记录，特别方便，能够看到自己的努力转换为图片记录很有成就感，当然这里也需要我们明确地标出规则与说明，方便日后交流。展开作者回复: 学以致用，👍
5
2018-01-09一直写不出让开发同学满意的需求文档，可能就是自己太注重形式了。
二爷，文末的链接挂了呀…作者回复: http://heidixie.lofter.com/post/b8226_168d4b5
btw. Heidi 博客上的其他文章也值得一读 4
2018-05-20Heidi就是雨宏啊～ 她的各种文档，流程简直牛逼到爆炸 3
2018-01-10我们一般手画草稿加口述需求 3
2018-01-10我们公司产品经理分为金融产品经理和系统产品经理，一般金融产品经理负责业务方案的设计，也就是撰写MRD和BRD，而系统产品经理写PRD，并负责推进项目的上线，系统产品主要是面向后台系统，所以基本没有涉及到页面设计，文档核心在于后台系统的交互流程，系统交互都是通过接口交互，所以我觉得文档模板不能一味的套用，要看实际的项目，如果是toC前端业务，直接demo加说明文字甚至类似二爷说的线框图就可以搞定，而像我们公司的这个后台的，就不需要demo，直接流程加文字说明。作者回复: 后端业务通常都重流程中逻辑，页面和交互流程其实就不应该是文档中的核心部件
2
2018-04-23目前我从事的项目主要都是B端的工具类产品，感受非常深刻的的是，每次写需求文档我都是单个功能来些写，特别是一些体量大的需求，不可能整体写完prd，再来出原型，本身周期长很多东西会漏掉，所以我都是单个功能出uc后，出响应界面的原型，然后再反过来看uc有没有没考虑到的情况，
prd大概包括
1，交代使用该功能的背景，包括介绍用户是谁以及正常场景下的用户心理和期望目标
2，操作步骤闭环流程，其中包括前置条件和后置结果
3，异常情况的考虑展开 1
2018-01-14不管是原型上面没写完善，产品写漏了；还是原型上面写了，开发做漏了。到了这种情况下去讨论谁的锅，真心觉得这感觉很不爽……作者回复: 嗯，就是最好不讨论，产品争取把锅背了就好
1
2018-01-13文章里分享的产品原型标注非常棒，一目了然。
这几类文档在很多文章中都介绍过，虽然网上搜索有大量模板，但感觉质量参差不齐。真正想找一份能够提供给团队参考学习的不容易。
信任二爷分享的文档质量，希望二爷能够分享一下本文中提到的MRD、BRD、PRD、UC、FSD文档的范例，理论看来终觉浅，欲取真经需范例。
先谢过了，盼复。作者回复: 系统性地去讲解和培训这些文档类型是挺难的事情，可能要有一个我们都在同一语境下的项目会好一些。不过更好的方式可能还是在实践中去迭代自己
1
2018-01-12邱老师感觉很累啊，注意休息啊…… 1
2020-01-03才发现产品的专业文档原来有这么多道道，长知识了。
2019-05-05二爷，文中提到「如果项目是重交互，以用户场景驱动的话，我会推荐用 UC 来组织 PRD」，这意味着还有别的驱动方式？我一直以为都是以用户场景驱动的作者回复: 重逻辑和重系统规则的可能不会用 UC，有可能会写特性描述。
2018-06-30你表达清楚，说明其逻辑为直接目的，同时我今天也学习了一些文档种类，感谢分享
2018-03-28比如重操作的 To C 产品可能需要交互流程描述和线框图，而 To B 的产品可能注重的是概念模型和业务流程。
2018-02-28二爷，请教一下用例里面的主流程事件和分支流程事件是不是合在一起后就是一个完整的业务流程图？那如果是的话，主流程和分支流程是画图表达好一些还是直接文字按步骤描述？作者回复: 我一般是文字为主，图为辅助