在TestBird不到两年，时间过得很快也很充实。因为分管的是产品和研发，而研发上的东西都是跟具体问题相关的，没有什么太多条条框框好总结的，所以总结一下产品和管理这两方面学到的经验或者教训。
先从产品说起：
在最开始的三个星期，透彻了解产品的历史，明白它们发展到当前面貌，其中的偶然与必然。多提问，多记录，多分析，不要想当然，更不要开“上帝视角”。
搞清楚公司的产品是“ 马太驱动”还是“数据驱动”的。
“马太驱动”是本座造的一个词：形容谁光环大谁说了算。在缺乏数据支撑的决策过程里，既然大家都是拍脑袋，很多时候就是谁的屁股大，谁拍了算。
“数据驱动”包括了“做什么”和“做得如何”两方面：做什么产品，做哪些功能，需要数据支撑决策；产品做得怎么样，功能用户是否买账，需要数据验证效果。
“数据驱动”是很难实践的，所以发现公司是“马太驱动”的，首先，不要惊慌或者灰心，其次，更要发挥自己的作用，对团队负责，仔细分析和思考，做决策的时候好好拍自己的脑袋，不要为了短期利益去拍更大的屁股。
要有“空杯心态”：过去的套路、经验和成绩，和能不能对现在讨论的事做出正确判断，毫无关系。每天我们面对的都是新的商业环境，新的技术平台和新的用户，要有自己的想法，也要有胸怀去聆听别人经过认真思考（最好是有数据支撑）的结论。
在团队里面也要推崇这样的文化。聪明人在一起工作总是会有一些“张力”的，但是要让这种“张力”健康向上：在讨论中，明确讨论的核心是观点是否正确，而无关讨论者自身的价值。很多争论的发生，并不是捍卫“自身观点”的正确，而是防止“自身价值”被挑战。要鼓励前者，唾弃后者，所谓“Strong ideas, weakly held”。
同时，难归难，还是要培养团队特别是管理团队“数据驱动”的习惯：明确产品的品类和发展阶段，有针对性地收集相应的数据，作为决策的有效输入。不要在用户是否喜欢自己的产品这件事情上欺骗自己，要有意识地让团队具备快速有效的试错并不断开发新产品的能力。
有的合伙人或者投资人喜欢看短期，另一些则喜欢听愿景。要证明数据驱动对这两方面都是有好处的，需要准备更多的数据，并且在短期和长期之间有个清晰的规划。多沟通，多讨论，和养成团队任何别的习惯一样，让大家养成用数据说话的习惯，也需要发起者坚定的意志和良好的沟通。
聚焦。在当前产品遇到问题的时候，很容易陷入“下一个功能一定能成为转折点”的泥潭。用数据找到焦点，投入所需的各种资源，包括自己。因为这个点做不好，其他的做好了也白搭。
把其他的功能点交给产品经理和团队最“难搞”的开发去协商，这个开发还能再砍掉一些。
忽略关于UI的建议，反正无论怎么改，50个人会有50种不同的建议。
开放、理性地对待关于流程和功能的建议：及时给予反馈，让用户有参与感，但内部做好版本规划。
把握好“创意”和“产品”的边界：还在“创意”阶段的时候，各方面压力要小很多，一定要有足够的讨论、尝试、数据和推演，确定它真的是一个好的方向。一旦进入“产品”阶段，就需要所有参与者有“传教士”而不是“雇佣兵”的心态。这个时候再来验证是不是一个好的方向，往往只会增加内耗和消磨士气。
值得做的产品都是“困难”或者“未知”的，要能分清楚你的产品属于哪一类，才能判断你和你的团队各方面状态（时间、能力、心态、自身和外部经济条件）是否适合现在做这类产品。
“困难”的事情，通常模式什么样，团队如何搭，甚至产品是怎么做都是清楚的。要具备把困难的事情拆分成一系列简单任务的能力，要能够比较准确地计算出完成这些任务的各种成本，要能听到竞争对手的脚步：通常还有好几帮同样聪明同样努力的人也在解决这些困难。
“未知”的事情则是说，它开创了新的商业模式，然而这种东西是否被市场接纳是未知的。做“未知”的事情，风险更高（相应的成功后收益也更大），很多时候死了不是因为你产品不够好，可能只是时机未到（比如微信没有把支付打通之前做类似于皮皮麻将的App），或者运气不好。而且一旦“未知”的事情被证明是可以成功的，它往往就变成了“困难”的事情而已（你要开始学会聆听对手的脚步了）。
绝大多数的合作都是浪费时间。
要有信心，即便到了你开始怀疑自己的时候，还是要有信心。
