一、项目经理与产品经理之间冲突与问题列表
对于新业务，公司常见做法是将该业务独立出去以免受到母公司组织架构、人力资源模式以及财务资源的限制和束缚，目前，很明显，业务受到过往经验和管理的掣肘。不谈宏观，即使从微观上看，考核方式也不应该单纯沿用互联网公司的逻辑，因为这场仗是硬件之仗。
首先，由于公司战略围绕产品展开，因此，PM做的产品工作是显性的，也是受重视的，容易受到表扬，但是项目由于周期长，很多工作是铺垫，所以PM的苦劳相对少且易见，而项目经理的苦劳多且不容易被看到，不量产即为没结果、没绩效，在业务初期，这种考核并不合理。我们可以抛弃“只有苦劳而没有功劳者”，不应该误会那些“有苦劳最后也有功劳者”。
另外，车联网目前的商业模式是采取了传统车企的项目制，项目经理这一角色的地位理当提高，而且，PM自身深受项目经理这一角色的困扰，因此，对于承担项目经理角色的PM，针对于他们的考核和激励措施应该有所调整，一方面是一线的权力要增强，尤其是资源调配，另一方面是激励要提高。然而，就目前来看，工作量即使可以厘清，但是却无法降低，因此，我认为需要优化的在工作之外，比如激励、明确分工以提高效率等。
二、解决方案（以机制解决，群策群力）
应该通过机制将冲突暴露于问题集中爆发之前
由于B端客户的多样化，产品经理和项目经理很难合二为一，但是产品经理和项目经理的责权应该规定清楚，从本质上讲，产品经理应该一直看到产品落地，我认为这是PM该有的姿态。当然，鉴于当前的业务形态，每个PM不可能做每个项目，解决办法可能有：
1、分工：分工可以减少推诿、提高效率，也是改进的基础，产品与项目绑定，规定清楚PM应该在项目推进中的责任权力，体现在纸面上，必要时进行考核，让他们重视产品落地，感受到市场压力，对最终产品体验负责
2、激励：每个PM深受项目困扰，针对项目经理的激励需要制定政策
3、权力：项目经理的权力要大，尤其在调用资源方面。
注:文中的项目经理均指角色，不指代某个人，因为PM身兼项目经理
三、其他观察
1、关于目标管理
互联网公司层级很少，却依然缺少充分沟通，而且，上级对下属目标完成难度和实现状况理解存在较大偏差，这说明目标不是从上往下传导，不符合目标管理。
2、关于激励与考核
第一，以互联网的思路理解车企落地项目可能有问题，在实际落地的项目中苦劳和风险可能更多，看不见的工作更多，所谓的结果（SOP）较远，非短期可以看见，项目经理不是在处理风险，就是在处理风险的会议室里，这不同于互联网的“小步、快跑、试错和迭代”。在组织内部，考核功劳是对的，以绩效为组织精神也没有问题，但是这些看不见、摸不着的苦劳恰恰是达成目标和绩效所必须经历的过程，因此，必须承认这些工作的价值，换句话说，项目不同于产品，不仅结果有价值，过程也有价值，而过程又不是浮在表面、显而易见的。
第二，事本大于人本，人本又要“以奋斗者为本”，项目应接不暇，变现程度多有差异，项目的优先级到底是该按照目前的公司关系分还是按照实施的深度分存在争论，但应该按照贡献来予以激励，就目前而言，市场处于快速扩展期，而产品又需要打磨，前线的“士兵”不断发起冲锋，边进攻边填弹（产品打磨），更需要后方有支援（物质激励）和认同（精神激励），华为的“不让雷锋吃亏”是这个意思，否则，人本剥削资本，激励的平均主义伤害员工积极性。
因此，工作量因为市场扩张短时间内很难压缩，就要考虑分工和激励，在许多方面做到规范化以提高效率，不能凡事都太随意。
3、组织内两大矛盾
1）项目繁多、优先级不均与产品打磨之间的矛盾
需要定义何为优先级；
项目繁多来自高层决策和市场扩张，而产品打磨却是市场的压力，两种力量形成冲突
2）PM与项目经理由于市场压力不均导致彼此协调效率低下的矛盾
4、关于项目经理与产品经理之间的分工
1）产品经理的压力来自市场，不应该来自项目经理
在车联网的具体业务中，产品经理与项目经理之间分工、权责不清晰，项目经理几乎包揽所有责任，PM则从不为市场交付而承担压力，PM最大的压力来自于他自己负责的项目，可能不会为所有项目中的全部产品模块负责，其中的一个根本原因是产品经理没有直接对接市场，面对客户。如果一个PM感受不到市场的压力，感受不到市场的温度，中间需要同时有一个车企和一个项目经理作为双层隔热层的话，这对于最终的产品是有害的。PM应该尽快响应项目经理推动中的市场压力，这是必须的，也是必要的，要想打磨产品只承担自己负责的项目产生的压力怎么可以，当然，两头兼顾工作量会很大。感知每个项目中产品模块的压力后，问题的关键就落到了如何缓解这种压力上来，也就是项目的繁多、优先级参差不齐与产品打磨之间的冲突，一个是市场发展的需要，一个是核心竞争力的形成，“同时兼顾”是一个组织战略问题，这个应该着重解决，但不应该以牺牲PM对市场压力的感知和响应为代价。
2）关注组织结构和职权分工
首先，PM与市场之间横亘着项目经理和车企，隔热层太多，同理，当项目经理需要PM提供产品的反馈时，产品往往有顿感，因此，项目与结果之间反而又嵌入了一个PM作为隔热层，推进效率十分低下，倒不如直接去找技术沟通，但PM对于市场就完全无感知了。这种模糊分工导致彼此成为对方的推动障碍。
分工固然难以分清楚，但是没有初步的规范，混乱会消磨更多效率。
3）串联传导压力有问题
其实，很多工作一直都在沟通，沟通几天都没结果，为什么没结果：技术不想做、PM响应慢。最后客户发火了，技术和PM都说那还是乖乖做吧，看来，压力只是传导到项目经理这里是绝对不够的，传导给每个人才有效果，要并联的组织结构，不要串联，因为压力会逐级削弱。
4）一线的项目经理是否该有最大的权力
项目经理的权力并不大，身处一线却不能调用很多资源，一线的士兵最了解市场，却无法呼唤炮火。
5）不要用互联网公司的逻辑考核项目经理
在传统车企中项目经理权力很大，调用资源能力较高，而互联网公司重视PM。但是与车企的对接方式决定了公司必须改变针对项目经理的考核方式，在资源和权力方面是否有所倾斜是一个非常重要的议题。用互联网思维而非硬件思维打智能驾驶这一仗，有可能会吃亏，也有可能会一败涂地。
5、关于沟通方式
沟通自下而上层层汇报符合科层制要求，也是最简单易行的方式，但是自上而下的沟通却是管理学者和管理实践者们都在倡导的，走近一线对于管理者而言将会越来越难。管理者需要明确下属的进度、困难点和支持点，但绝不深入业务。换句话说，如果不做业务，他的工作就成为了“首席解释和沟通官”。
6、我们不是创业公司，需要探索出符合新业务发展的管理模式
在很多方面，我们都不是创业公司，但是业务新，战场残酷，激励就必须跟上，“大公司管理+新业务”的搭配是非常危险的，这个问题在“颠覆式创新”里显而易见，旧有的管理方式和资源调配方式会阻碍新业务的成长，尤其是会错过新机会。
关于分工的几点思考
首先描述建议，然后再说依据，如果前提假设不合理，建议便不可行。
建议：
项目经理的岗位再定义（责任大权力也要大）：在某一个具体项目中（不考虑其他场景），项目经理角色最为关键，要以项目经理这个角色为主，从理论上讲，项目经理的权力应该远大于技术、BD和PM，只有如此，他才能迅速调集资源推动项目，因此，需要重新进行岗位定义和设计，在岗位中要强化该岗位的权力和资源（让人有能力干）以及激励（让人有意愿干），这样每个人都能够并且愿意胜任
2、串联不分级只能做甲乙方，并联分主次可以做军师，以项目为作战单位：目前在某个项目中，现状是项目经理内部求着PM，外部求着车企，平级之间推进效率缓慢。在具体项目中，项目经理的权力应该大于PM，同时，项目经理掌管KPI，项目经理为主，PM为辅，PM是项目经理的赋能者，项目经理是PM的市场压力传导者，二者绑定，并联同时面对市场
3、只做最重要的事：部分项目经理的繁杂工作可以分出去或者外包出去，比如协调车机可以让BD做，语音测试找外包做
4、制度化：
1）纸面上定义清楚彼此的权责，尤其是针对交叉模糊的任务需要定义清楚，另外需要根据项目需要不断更新；
2）设置负反馈机制，KPI绑定，如果违反规定，应该有相应处罚才能完成闭环管理。
依据和假设：
1、项目经理很关键：由于对接车企，目前车联网的项目经理这一角色更像车企的项目经理，与互联网的项目经理差异太大，岗位要求很高（组织能力、资源调用能力和沟通协调能力等），因此，这个角色很关键、任务也很重，需要更高的权力和更多的资源，只有配备好武器，一线冲锋者才能快速抢占市场。
2、PM需要了解市场，全盘把握产品：由于业务新，项目多，每个模块的PM只有对各个项目的市场情况有一定了解才能全盘把握产品，即PM的角色不能离开用户。无论是订制化的需求还是不可复制的需求都应该与整体产品战略相联系，都不应该被PM忽视。单纯的内外分会将PM隔绝于公司内而无法了解车企需求，更无法了解用户需求。
3、串联不可取：PM和市场之间隔着项目经理和车企，市场压力逐级递减，而项目经理与结果之间隔着PM，项目经理不求助PM而是直接解决问题会更快实现结果
4、现实：几乎每个环节都需要项目与PM的沟通
隐患：
后期，大多数人由于项目增加，项目经理这个角色产生的压力会越来越大，因此，一方面需要定义项目经理的角色，认识到项目经理的意义，另一方面基于项目经理的认知讨论分工问题。
