今天五味开会基本讨论了最为复杂的一个事情，虽然是晚上很晚才散会，但是大家都很兴奋，基本所有人都进入了这个场景之中，并共同制定出了能形成共识的方案。
这个会议是产品经理召集技术人员开的。最初的时候，产品经理室已经绘制了这个场景的所有方案，说了几句，我直接打断了，原因是我发现所有人都是木呐的。
产品经理和技术人员已经不在一个频道上，所谓的征询意见完全是牵引式问答，你永远得到的是沉默式认同。
于是，这个时候整个方案的水平完全取决于讲解者一个人的水平，而对于一个非常复杂的方案，一个人是基本搞不定的，哪怕是非常牛逼的产品经理。因为只有讨论才能产生灵感，才能发现自己未曾发现的需求。
开产品或者技术方案会议的时候，大家最容易犯的错误就是，自己先绘制了原型图、甚至产品架构图，直接来讲解自己的方案。
这是一个完全错误的会议方式，基本是浪费了所有人的时间。其实离开这个会议室，懂的人懂，不懂的人还是不懂。
当不懂的人去执行的时候，就会需要摸着石头过河，再基于局部找你勾兑，从而失去了大局观和整体性，也失去了自己思维模式之外的解决方案。
于是，二流的产品就这样出现了。
判断一个会议是否成功，就是你是否能引导大家一起生成方案，而不是自己讲解方案。要想做到这点，就是关注场景，而非产品设计；关注场景之后的需求，而非技术解决方案。场景也是可以妥协的，但是场景之后的需求要再三推敲。经常是一个场景是一个虚假场景和虚假需求，非常可能背后的需求可以换一个场景来解决。
就如取餐签单吧。本来这个场景是打印取餐条的，但是打印取餐条是告诉后厨顾客来了。如果能通过一种模式告诉他什么时候来了，其实就可以不打印了。打印取餐条是为了证明他是谁，如果能有另外的方式证明他是谁，就不一定打印。
如果不去关注场景背后的需求，就会陷入场景的阴影之中。当然90%的产品经理，都无法进入场景，讨论的永远是功能设计。
这就是很多产品做得很垃圾，完全用不起来的原因。目前中国的社区也好，行业软件也好，基本不能模仿国外的，基本都是做得不及格的。核心原因是，不懂推敲技巧，没有会议讨论技巧，不能生成和推敲场景背后的需求，再通过需求绘制完美的场景。
总结一下：
1、开任何会议，一定不要上来讲解方案，应该先讲解场景。每个场景先讨论背后的需求并定义清楚。
2、大家一起先讨论这个场景背后的需求是不是这个需求的是最佳场景。能不能删除这个场景，或者有其他场景代替这个场景还能解决背后的需求。
3、如果是需求的最佳场景，再开始讨论这个场景下的产品解决方案。
4、这个时候你再打开你最先设计好的产品原型图也好、产品流程图、状态图、UseCase图，那么你会发现有很多需要修改。如果你能即时修改，这就是大家一起生成的方案。
如果大家发现都不需要修改，能满足一起讨论和推敲的需求，那么他们会认为你很牛逼，你的威信就建立起来了。
只要违法了以上法则，那么你的会议就是无效会议，产品经理就是失职的产品经理。
这就是参与感，没有参与感，就不会有感情，技术人员做出来的产品就不可能是完美的，也不可能遇到需求偏差的时候，他能主动去修改。因为他会觉得你的方案有纰漏，需求变动了。
不互动不一起推敲出的方案，等于强奸技术人员。如果你是乔布斯，你可以那么做，如果你不是，请和技术一起生成方案，而不是讲解方案！
互联网或者软件项目开发，50%的时间应该用在沟通上，但是往往技术人员和产品人员不认为这个50%是应该的，于是你们就做了自己看上去效率很高的东西出来，最后用户拿脚投票！
于是乎，最悲哀的不是整天加班，是整天加班做出的产品，需求不对，没有人用。更可悲的是90%的人不知道是因为这个原因没有人用。不是你的智商不够，是你的思维习惯不对！
而思维习惯才是一个产品经理最大的修养，你是否能永远记住，一个思维模式下不能解决的方案，一定可以换一个思维模式解决！
这就是思维习惯！
五味创始人 王东烽
联系客服
