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