一个项目在立项之前，是没有项目经理的，这个过程全部都由产品经理负责，主要是要完成需求确认的过程，待到项目立项之后，一般项目经理都是开发负责人或者测试负责人，这时问题就来了。产品经理与项目经理的分工和协作，真正要严格的区分开来是比较难的，在工作过程当中都是结合的比较紧密的，这个问题是肯定会遇到的，大一点的项目都会再指定一个项目经理来协助产品经理，以确保项目能最终上线，这种情况在大公司很常见，小公司就不说了，否则怎么叫苦逼的产品经理呢。
在接触了几个这样的项目之后，感觉这种配合模式比较难达到非常和谐的地步，项目经理从项目立项开始跟进，到项目上线，其要保证项目不被delay;产品经理介入的会更早，前期用户调研，需求确认等等就已经参与了，到项目执行的过程和最终上线运营，都需要参与进去，中间如果不是敏捷开发，没有严格的迭代控制，那么需求变更不可避免，自然就会影响到项目的进度，这里就不以敏捷开发为例了，就以常见的瀑布式为例。
1、对工作量的评估
产品经理一般对某个项目的上线运营是要背KPI指标的，在多长时间内上线，因此如果前期需求调研时间长了，后期就会很紧张，就会希望开发和测试加快速度，难听点就是加班;项目经理会更多的从实际工作量的角度去评估，往往一开始评估出来的工作量都让产品经理大跌眼镜，产品经理认为只要20个工作日的，项目经理说需要40个工作日，都还是保守估计，这个时候为了保证项目的按时上线，是要协商的，个人觉得这里有一个共识的问题，就是前期没有让开发人员参与需求的讨论，或者产品经理没有将需求实现的价值、意义和项目经理讲清楚，这样就会存在认识上的偏差，当为了做任务而做任务的时候，可想而知是没有什么紧迫感的，但要是从产品的角度出发，完全会是两码事。因为个人建议在进行需求讲解的时候，不要一味的只讲功能点和实现逻辑，一定要说实现的产品价值，给大家一个主人翁的共识，这样在协调工作量问题的时候会好很多，而且后续的过程当中也会顺畅很多。
2、对需求的理解角度
产品经理更多的是从业务的角度去理解去设计，而项目经理大多是从技术实现的角度来考虑，看问题的角度不一样，决定了会有很多冲突。比如产品经理在设计某个需求功能时候，认为这个功能是必备的功能，且是满足业务要求的;项目经理看了之后觉得实现的代码量巨大，就想对这个功能点进行拦腰斩，只做其中一部分，甚至建议不做，或者说会影响性能却又给不出更好的方案时提议能否暂时不做这个功能。这种情况下就会产生很大的矛盾，这种时候就需要建立一种负责制，遇到分歧的时候到底听谁的，是产品经理说了算还是项目经理说了算，理论上来说没有任何功能是技术无法实现的，应该由产品经理来评估决定最好到底要不要做这个功能。
3、对需求变更的容忍度
对于产品人员来说，需求变更是家常便饭，哪个产品在做的过程当中没有进行过需求变更，这个产品的不靠谱指数估计就会很高，因此对产品经理们来说，需求变更时很正常的，虽然也要控制变更的频率，太过频繁的变更就证明产品的框架结构有问题了，或者已经偏离了原来的主要方向。但开发人员不是这么认为的，当一个功能辛辛苦苦开发出来，马上接到通知说这个功能不要了，要换成另外一种，这种情况发生的次数多了，换成任何一个人都会觉得是被耍了，毕竟都是自己的成果，说不要就不要了，说改就得改了，而且变更的次数多了也会影响项目进度，如果开发负责人是项目经理的话，问题就来了。这种情况一是一定要让项目经理理解需求变更的目的及其价值所在，做好沟通，确保每次变