产品和研发经常会PK一些东西，有时候PK系统设计，有时候PK活动方案，有时候PK数值…
PK了半天我们有没有想过，为什么会PK？
为什么PK？
PK前先搞清楚状况，如果连这个都搞不清楚，那就是瞎PK！
主流的原因无非几种：
为了把产品做的更好
为了彰显自己的实力（也就是装B）
为了拖延时间或者其他不单纯的目的
如果是第一种，其实整体面上是好的，这种PK需要建立在“平等”和“讲道理”的基础上。这种PK是值得的，并且要不断坚持这种PK，因为通过PK产品和研发能够互相理解，互相提升。
如果是第二种，那就是个人英雄主义，完全凭借自己的实力和喜好来大刀阔斧的修改产品，小的改动是无法满足个人英雄主义的，他们对风险的评估很不充分。
大刀阔斧的改产品一定会有很大的风险，所以真正有实力的人很少会大刀阔斧的改产品，更多的是稳健前行。
如果是第三种，就尽快逃离这种境地吧。
综上所述，第一种PK理由是有价值的，要不断坚持这种PK，享受PK的过程和乐趣，在PK中不断提升团队成员的实力。
单点PK5要素
针对某个具体的问题进行PK是初级和中级产品人员需要锻炼的能力。
当我们跟研发进行PK的时候，一定要想清楚以下5个点，如果下面的5个点都想明白了，胜率非常高！
1.为什么会设计成现在这样？
事必有因！搞清楚原因才能对症下药，如果完全不了解背景和原因，就是瞎搞。
如果研发这么做是因为深深的情怀，跟他讲逻辑是没用的；
如果研发这么做是因为这么做更快，那么你跟他说一套复杂而完美的解决方案也是没戏的；
如果研发这么做事因为能力不够，你跟他说高大上的解决方式是浪费时间的。
……
所以一定要搞清楚背后的原因，搞不清楚就是做无用功。
2.现在的设计问题在哪？
其实这个问题非常难回答，因为产品是一个小世界，任何一个问题都不会孤立的存在，会跟很多东西关联在一起，任何一个改动都可能产生连锁反应。
大部分初级产品经常PK不过研发，是因为他们想问题都只是局部，而不是全局。全局的思考方式是很困难的，需要不断地磨练。
提升全局观就需要多PK，多虚心接受，多跟不同的角色(研发、前端、后端、市场)去沟通，多了解策划，程序方面的知识。但是如果从研发角度跟研发PK，一定PK不过，因为你是在用自己的短处跟别人的长处PK。
所以当我们跟研发PK的时候主要从用户角度来分析，同时从研发角度来考虑风险和漏洞。
3.修改后的利弊是什么？
大部分改动都是有利有弊的，如果不充分考虑弊是什么就是自己骗自己，认为自己是天才，自己的所有想法和点子都是正确的。
如果每次PK我们都说好的，然后研发丢回来一堆弊端，你不知所措。久而久之你在别人眼里就是不靠谱的代表，只会做不现实的白日梦。
4.我想改的东西优先级高吗？性价比高吗？
可优化的点永远都做不完，优先级低的需求=不会实现。所以，你想改的地方真的非常重要吗？这个问题一定要想清楚。
另外，实现这个改动需要谁来配合？需要花多少时间？有多大的风险？值得吗?
如果不知道这些答案没有关系，在PK之前就先找策划和程序了解相关的细节，收集到充足的信息。自己心里有底了才行。
5.除了“我觉得”，有更多的证据吗？有数据支撑吗？
不要总说“我觉得…”，你一个人代表不了所有用户，也不一定代表了核心用户。PK的时候一定要从客观事实出发，不要过于主观。
数据是产品最有力的武器，我们在提出想法的同时如果有大量数据作为依据，是非常有说服力的。
在运用数据的时候一定要逻辑非常严谨！如果逻辑本身不严谨，一切数据支撑都是白搭。逻辑是否严谨多找一些人把把关就行。
如果能吧上面5点想明白，说清楚，那么相信对方会被你说服的！
把自己当Boss
很多时候PK的死去活来不是因为大家的猪逻辑，也不是因为有人故意显摆，而是因为高度不同和方向不同！
产品在想我怎么通过新的功能来完成这个月的KPI
研发在想我做完这个功能后，数值就超出当时的预期了，需要考虑其他系统的平衡和数值
设计在想这个功能能否在这么短的时间里做完
而Boss，需要考虑到所有这些！
产品说我觉得改动A的优先级更高，因为balabala（有道理且无懈可击）
研发说我觉得改动B的优先级更高，因为balabala（同样有道理，且同样无懈可击）
而Boss需要站在产品的制高点，判断到底哪个更重要！
产品说这个地方要改成balabala，因为已经有无数用户反馈这个地方不好了。
研发说如何这么改，会有balabala的后果，对产品会有影响。
而Boss需要站在用户和设计理论的之间，判断到底如何做才是“正确”的！
千万不要抱着一决胜负的心态，如果念想要PK赢，那么从一开始就已经输了，因为这不是辩论赛，而是大家一起寻找更好的前进方向！
一定要抱着Boss的心态，站在产品的制高点上！
不要站在自己的立场去思考问题，多站在对方的立场考虑问题；
忘掉自己的KPI，如果有一个方案可以让产品往更好的方向走，就不要管他是否能够帮你完成这个月的KPI；
不要在乎自己的方案是否被采纳，而要在意哪个方案才是最合适的；
多考虑对方遇到的困难，多克服自己遇到的困难。
