工作中经常会遇到这种情况：
当有些事情需要你来做决策的时候(不管大决策还是小决策)，经常有一种痛苦，不知道怎么开始思考这个问题，通过什么依据来思考。更多的是利用过去的经验来倒推，如果经验也不管用就会无从下手。心里默念“怎么办?怎么办?。。。”
下面就给大家介绍我的一套方法论，这套方法我感觉开发和运营都适用，但是更适用于运营(因为开发不确定的时候，可以找几个成功产品拿来看看，然后开抄)，运营需要更多的基于当前产品，当前用户来思考，很难找到靠谱的参考物。整不好就是邯郸学步。
这套方法操作起来其实超级简单，但是需要大量基础功底(对用户的理解程度，对产品的熟悉程度，对产品的历史足够了解，积累过很多试错的经验)。没有这些基础功底，这个方法对你没有任何价值，纯属瞎猜。
一个原则：不要争对错，只求让大部分人觉得有道理
出现分歧是家常便饭，要不要做，怎么做，做到什么程度，都会出现分歧。分歧不重要，最可怕的是很多人把讨论问题变成了一种辩论赛，非要争个我对你错才甘心，完全不考虑争论所付出的时间成本和其他隐患。
而我的原则就是，我的想法能让大部分人觉得有道理，没有太大问题，就算OK。
游戏面对的都是用户，相同文化背景的用户，思维逻辑和习惯都差不太多，如果团队内大部分人觉得OK，那么用户也不会觉得有太大问题，找7个左右的人来询问一下，基本能出结果。
如果几个人的想法都没太大问题，团队成员觉得都OK，那就得有一个人出来拍板，然后落实到执行。
有一点需要指出：讨论的时候，尽量回归到人类最本质的心理层面去谈，所以我在跟别人讨论问题的时候，会经常脱离游戏，用一些生活消费的例子来做类比。(比如LV降到100块1个会如何，我们的这个道具如果出现定位的突然改变会如何。。。)如果心理层面不太好拿捏，那就只能凭借经验了，但是不要觉得过去的“经验”一定是对的!(就好像有人说wii的成功是因为机型很少，但是机型少就是wii成功的最大原因吗?)
条条大路通罗马，不要觉得自己的点子就是最好的，时刻把自己放空，给团队更多的包容，如果大部分人觉得有道理的东西，就敢于尝试。
模型一：用户金字塔模型
