还记得以前实习的时候，leader 和我说，写好 PRD 是为了减少与研发的沟通的时间。
今天看到一篇文章，题目是《好的 PRD 关键》，文章总结了一些比较不错的 PRD 模板之间共通的元素：
Why：为什么要做这个产品、功能？为什么重要？有什么商业或使用价值？
Problems：这个产品、功能要解决什么问题？
Solutions：如何解决这个问题？
Success：如何衡量这个产品、功能的成功？
Scope：方案的范围是什么，什么在范围内，什么在范围外。
当然还有一些其他便于团队协作的，有专门的各类文件合集、各种讨论的合集、各种 Checklist
我也开始反思这段时间与研发团队、与需求方之间沟通的问题，总结来说，并没有高标准要求自己做好一个产品经理的角色，产出的结果并不专业甚至很草台。
原先实习的公司是 2B 定制化，大多数功能是业务驱动的，对应的项目经理在需求沟通会上，跟产品经理和研发负责人去阐释功能的优先级和价值，此时产品经理是答题人，PRD 会着重在 Solutions 上。
而现在，我们在做一款产品驱动的事情，很多结果（譬如用户增长）依赖产品提供给用户的价值，这时候就很依赖产品经理的 Product Senese， 这就需要写好一个 PRD 文档，把这些脑子里的想法落到实处。
好的 PRD，最终目标是要打造出能很好解决使用者问题的好产品。
那产品经理，就要把使用者与问题定义清楚，并通过 PRD，把「使用者与问题」清楚的和团队说明，把时间和资源，花在值得解决的问题上，防止走歪。
文中提了一些什么叫没定义好的例子，感兴趣的推荐阅读 ⬇️⬇️⬇️
原文地址：https://petersuppi.medium.com/prd-4f4ae5e8a473
今天看到一篇文章，题目是《好的 PRD 关键》，文章总结了一些比较不错的 PRD 模板之间共通的元素：
Why：为什么要做这个产品、功能？为什么重要？有什么商业或使用价值？
Problems：这个产品、功能要解决什么问题？
Solutions：如何解决这个问题？
Success：如何衡量这个产品、功能的成功？
Scope：方案的范围是什么，什么在范围内，什么在范围外。
当然还有一些其他便于团队协作的，有专门的各类文件合集、各种讨论的合集、各种 Checklist
我也开始反思这段时间与研发团队、与需求方之间沟通的问题，总结来说，并没有高标准要求自己做好一个产品经理的角色，产出的结果并不专业甚至很草台。
原先实习的公司是 2B 定制化，大多数功能是业务驱动的，对应的项目经理在需求沟通会上，跟产品经理和研发负责人去阐释功能的优先级和价值，此时产品经理是答题人，PRD 会着重在 Solutions 上。
而现在，我们在做一款产品驱动的事情，很多结果（譬如用户增长）依赖产品提供给用户的价值，这时候就很依赖产品经理的 Product Senese， 这就需要写好一个 PRD 文档，把这些脑子里的想法落到实处。
好的 PRD，最终目标是要打造出能很好解决使用者问题的好产品。
那产品经理，就要把使用者与问题定义清楚，并通过 PRD，把「使用者与问题」清楚的和团队说明，把时间和资源，花在值得解决的问题上，防止走歪。
文中提了一些什么叫没定义好的例子，感兴趣的推荐阅读 ⬇️⬇️⬇️
原文地址：https://petersuppi.medium.com/prd-4f4ae5e8a473
