对于产品经理而言，我们需要向不同角色的人讲述一个需求，可能是你的老板，可能是研发，可能是运营，也可能是你的投资人，并且这些人也会有新旧之分，老搭档，新同事，这个技巧并不适合将所有的需求都进行类似的描述，但在关键时刻使用，会有不错的效果。

　　我们的思考，总是比文字更加的有力量，这导致我们更容易自己想明白一件事。

　　你有这样的经历：在沟通中，为什么对方就是不明白“这么简单的一件事情” ，oh 他真是 “太笨了”

　　这是因为你尚且不能很好的运用文字和语言。

　　我感触非常深刻，当我尝试将一些技巧，书写出来时，总是费劲心思，我曾无数次想，还不如开个课程，咱们面对面，几分钟就能讲清楚，写出来还要写2个多小时，还不一定让你明白。

　　我很清楚，这不过是一种自嘲而已，写不清楚，你又怎么讲的清楚呢？你所写的，与你所讲的，都不过是文字的一种表达形式而已，事实上，书写更容易让我们更好的去理解，毕竟书写是一个相对安静的环境，这会有助于你思考，并且是深入的思考。

　　我试图让自己变得简单， 简单到不去展开多余的争论，只是完整的去叙述一个需求。

　　你如何去叙述“分享到朋友圈”这个功能呢？

　　分享至朋友圈

　　你会怎么描述这个需求呢？简单的说，需要一个分享功能，让用户分享到朋友圈吗？

　　我大概会这样讲吧：

　　当我们在看到这篇文章时，非常喜欢这篇文章，希望将对自己有帮助的信息，传递给自己的朋友。

　　我们都会将自己认为好的东西，推荐给自己的朋友，是因为人们在某些时候是无私的。

　　但是，如果这需要我很费力的复制粘贴，我可能就不愿意这么做了，这实在太麻烦了，而且我相信，我的朋友在看到一长篇密密麻麻的文字时，也会质问我，发的是什么东西。

　　所以，我需要一个分享功能，能够让我直接非常简单的将这篇文字传递给我的朋友，并且他们看到的，和我看到的是一样的。

　　所以，你会发现，分享至朋友圈，并不是一个需求，而是两个

　　分享出去能够在外部被访问（H5的详情页）

　　需求故事

　　很多时候，我们沟通不顺畅的原因，不是因为不明白做什么，而是不明白为什么要做，怎么做。

　　在产品里，基本不存在完全独立的功能，每一个功能之间必然会和其他的功能产生呼应，这一点会直接反映到我们的需求里。

　　对于分享而言，研发并不是不知道如何做分享，而是不知道，为什么做，在哪里做，怎么做？

　　互联网团队里，每一个人都是具备创造性思维的，不仅仅是产品而已，切勿将研发或者其他环节的角色定义为执行机器，只需要按照你发出的指令进行动作就可以了，你一定不要有这样的想法。

　　一个完整的需求故事，会遵循一些原则：

　　除了必要的描述，尽量避免多余的叙述，这会干扰大家的思绪，产生不必要的争论避免不确定的词汇，比如，可能，也许，这会让他人感觉这个需求是不确定的故事完整，这是避免需求衍生的核心点，如果无法对你的需求故事进行提问，这就是最好的故事了。

　　故事完整

　　一个完整的故事，是指听故事的人，能够从头看到尾，而不产生疑问，似乎一切就如故事里讲述的那样，顺理成章。

　　user： 故事的主人翁是谁scene： 故事的背景是什么Want： 他想要什么defect: 现在的有什么缺陷Action: 他需要做的行为

　　我们再来看看 关于分享的需求故事

　　User：我们Scene：当我们在看到这篇文章时，非常喜欢这篇文章，Want：希望将对自己有帮助的信息，传递给自己的朋友。因为我们都会将自己认为好的东西，推荐给自己的朋友，是因为人们在某些时候是无私的。Defect：这需要我很费力的复制粘贴，直播，我可能就不愿意这么做了，这实在太麻烦了，而且我相信，我的朋友在看到一长篇密密麻麻的文字时，也会质问我，发的是什么东西。Action：我需要一个分享功能，能够让我非常简单的将这篇文字传递给我的朋友，并且他们看到的，和我看到的是一样的。

　　我们在需求沟通过程中，往往关注的，或者是仅关注到了ACTION， 这是指用户需要付出的行为动作，大部分时候，action 会直接等同于需求点。

　　这是不够的，一个故事应该是个完整的“小世界”，我们平时所看的电影，电视剧，就是出自于“故事”