抖音号交易出售资讯先列出所有跟这个服务相关的用户角

从上图例子中大家可以看到，其思路是：

1. 先列出所有跟这个服务相关的用户角色（Persona），如果是从0到1的产品强烈建议列出自己公司的不同团队、合作伙伴、客户的不同角色等，要全面，因为漏掉一个角色可能会导致你的业务跑不通或者不顺畅。
2. 再列出你这个需求的目标，让你思考过程有个原则，不至于YY到跑偏。
3. General Activity，我解读为High level的端到端任务流程。
4. Epic：就是模块化需求。
5. User Story：就是每一个子case。

另外，值得一提的是这个方法可以跟“服务设计”以及腾讯内部据说不提“产品”只提“服务”是完美匹配的，这也就再次验证了此方法的科学性。

这样做的好处是：

• 你看到并看清了整个系统；
• 利用Persona连接了各个孤立的分支；
• 优先级通过任务流程更容易看清晰，更容易找出MVP；
• 不同意遗漏重要的User Case。

四、给大家一些启发来串联本文的知识

首先我想让大家思考2个问题：

1. 需求的详细分析分解一定要PM来承担吗？

之前看到了一篇关于硅谷和中国的PM与工程师之间的差异的文章，本人刚好在两类公司都工作过，我对那篇文章说的有深刻体会：

硅谷有工程师文化，工程师懂技术也懂产品，PM懂产品也懂技术，目前我们公司当提出一个需求的时候，PM会思考需求并且会考虑技术实现，然后你要自己去Drive不同开发团队的人来组队来实现你的需求，如果你不懂技术基本就无法完成工作（PM和开发配合很顺畅）。

而国内的PM是承包了所有产品需求的部分，不怎么考虑开发的实现，开发只考虑实现不去深入理解或思考需求，这就导致了PM越来越不懂技术，开发越来越不关系需求的价值，也就导致了双方经常相爱相杀（配合不太顺畅）。