你的团队需要一个会讲故事的人。
这其实是一本书的名字，作者叫安妮特·西蒙斯。很早之前看到这本书，美国人写的书都这样，只看目录和开头就大概知道讲的是什么，这本书也不例外，然而在好些日子以后的现在，我忽然发现，我的思维无意识的被它影响到了。
就拿 “ 女版乔布斯 ” Elizabeth Holmes用一滴血造就的商业帝国Theranos来举例，她给投资人和公民们讲了一个相当富有传奇性的故事，也将自己包装的和那些伟大的前辈们一样，当然我无意像她一样用子虚乌有的技术来欺世盗名，但是我发现，硅谷、整个科技界以及风投家们，都喜欢会讲故事的人，这个故事越传奇越好，越像那些已经成名了的天才、硅谷巨头的经历就越好。
为什么最开始没有人质疑背后的技术的真假？在很多书里面，包括《你的团队需要一个会讲故事的人》《高效演讲》《思考、快与慢》等等，里面都会告诉我们，我们以为自己下决定是因为理智，实际上，大部分是因为情感。Elizabeth Holmes就充分利用了这一点，一串包装的精彩绝伦的故事，一个又一个大饼，将背后的技术藏得严严实实，Theranos在短短几年内获得了高达 90 亿美元的估值，简直不可思议。虽然是一个负面的事例，却让我发觉讲一个好故事的重要性。
想要说服别人，不仅仅需要铁打的数据，还需要能打动人心的故事，与你相关，或者与你的目标相关。我为什么说团队需要一个会讲故事的人？一是因为故事能以情感动人，二是故事场景能让人迅速进入你预设的角色，跟着你设定的场景走——也就是代入感 。
我是一只产品狗，比较喜欢场景化设计这个概念，一个需求，不能描述出具体的使用场景，就不是一个真正的需求，同样，一件事情，一个案子，如果你描述出使用/发生的场景，让人们顺着你描描述的场景去思考，你会发现效果比干巴巴的1234要好得多。
今天晚上为了明后两天的黑客马拉松，我们小队在一起头脑风暴，我是产品经理，当我要把我的想法描述给开发GG和MM的时候，如果只是用纸笔和手说出元素和概念，他们可能压根没法将所有的需求连起来，甚至不能有一个完整的印象，还有有各种理解的偏差。
于是我把我们的产品概念串成一个场景故事，假设你们是目标用户，当你XXX的时候，你发现你需要XXX，于是你发现XXXX可以很好的解决这个问题，然后我们还有这个平台，跳转过来，这部分可以完美的XXXX，那部分还可以实现XXXXX，这些都服务于我们产品的主要目的XXX。我们的产品主要目的是XXX，产品的调性就是XXXXX，定位要明确，XXXX。
头脑风暴快结束的时候，再次把这个故事梳理、完善了一遍，伟大的程序猿们继续根据故事的流程，最终确定了使用的技术还有接口等等问题，于是赛前会议完美结束~
反思一下：
1、头脑风暴的时候思路有一些部分还不太清晰，还好开发们一直提出各种问题和质疑，帮助完善思路【难道这就是传说中的程序猿与产品之间的相爱相杀？】
2、具体的设计在脑暴的时候不用太纠结，重点是功能结构，逻辑结构
3、脑暴笔记没做好，思路不断被程序猿们挑战，不断的解释说明，梳理结构，到最后有点累了，之前讨论的东西有一些细节差点忘了。需要学习一下如何科学的速记。
4、应该让团队知道，产品的目的，产品的价值，产品这样设计的原因等等，因为程序猿们都是很厉害的人，当他们理解了为什么要做这个产品，不要仅仅认为他们只会完成给的需求，他们会做更多wonderful things。就像《重新定义公司：谷歌是如何运营的》里面提到的一样，团队文化、团队的价值观很重要，有什么问题的话，可以去问问程序猿，如果程序猿们都认可团队文化、价值观、团队目标，事情会完成的超乎你想像的好，他们是一群无所不能的天才。
