1.我直接说结论：设计可以改，功能不能改，具体情况具体判断。
2.团队的配合不是谁对谁错的问题，我们每个人都对产品和公司方向都有自己的理解，基于这点产生的矛盾都是正常的，没必要带着情绪去看待双方。这种情况，如果出现在产品初期，特别是对于我们创业公司，在做取舍决策的时候，只要坚持一个原则：产品能够如期上线，且功能使用没有大问题。这意味着会牺牲部分用户体验，部分代码质量。在这个阶段这样的决策都是极其合理的。
3.程序vs策划，产品vs研发这是很经典的矛盾。化解这样的矛盾，得从两方面入手：
1>.了解对方的知识体系。这很重要，了解内核和观察表面是差异很大的体验。最近这点体会很大，我是运营出身的产品，虽然之前也小打小闹做过网站，但其实这很浅。最近重新开始学习前端知识，发现自己对设计的理解更深了，更重要的是，你理解了对方的工作，也理解了对方的心态，这对团队管理和计划安排非常有帮助。准备后期再学一些后台开发和iOS开发的知识。
2>.多为对方考虑，减轻对方的负担，让对方参与决策，提供给对方更多有用的信息。这个不用我多说，但是这点却很容易走偏。当出现问题后，如果这个责任是多人平摊，则负罪心理就少很多。当然，现实生活中，这个时候肯定会产生一个“责任人”。
4.PM碰到的大多数程序都可以分为两种，产品型程序和技术型程序。产品型程序有一定的开发经验，除了对代码，也对其它方面比如设计，功能都有自己的理解。技术型程序则只关心自己的代码，自己的技术能力能否成长。
5.产品型提的意见一定要虚心接受，从经验和技术提的意见里面包含着他们的抱负。梦想不能轻易践踏对吧？这个时候矛盾解决方法就三个字“讲道理”。这是一句很难做到的废话。很多时候我们听到的话是这样的：“我觉得就应该这样。”“你不懂，这样做没问题的。”或者，讲了道理没讲清楚。很不幸，我属于后者。我的体会是，光有道理也是不全的，你得让对方明白理解。强行要求，就是下命令了，可实际我们是平等的。好消息是，产品型程序一般都很愿意听道理的。
当然，自己的问题得虚心改，对吗？
技术型程序比较难处了。这对产品评估功能开发周期的经验要求很高，技术型程序的代码洁癖或者惰性很难搞定的。只能说功夫在平时，好好相处，搞好关系吧，人情这个东西很怪。
6.每个人都有自己的方法论，我们在模仿别人。就像创业一样，真正给社会带来价值的没多少。我们在学习，在模仿别人的规则，学到最后发现精髓都是“潜规则”。
7.产品人的责任是什么了？对产品的责任心是基本的，这会让你关心运营，关心代码等等问题。得适度，别越俎代庖。我有个坏习惯，一旦出现问题了，我会从历史发生的过程去寻找解释。最近发现这样做，其实意义不大。比起真相，更好的做法其实是先承担责任，为自己错误的买单，挺幸运的，趁还年轻。
前者是解决问题，后者是成长，并承担更大的责任。做到后面，你才真正成长了。
8.如果公司是一辆赛车，你越靠近发动机，你能犯的错就越少，就这么简单。
9.再说一次结论：功能不能改也是瞎扯淡。
10.标题里面的角色之间互换，同理可解。
爱因斯坦的鞋很调皮，设计也应该偶尔调皮。
