一、产品和运营的爱恨交织
简单的职能划分：产品负责产品设计，运营负责拉新，留存，盘活
那什么时候会有交集呢？运营在实现以上工作时需要产品协助配合运营策略，完成工作目标。藉此产生交集。同样两者总KPI一般相同，比如日活，装机量，GMV，订单量、利润。总的目标一致，但是偶尔也会有目标冲突的时候，下文再讲。
二、不同阶段职能的转化
一个产品一般分为：1.引入期，2.成长期，3.成熟期，4.衰退期
交易类产品经理一般引入期会快速完成产品的功能模块搭建，偏B端；成长期则侧重C端引流，UV，转化率的提高；成熟期主要是配合运营实现市场目标，提升用户体验
由此可见，产品和运营在产品的早期交集并不多，也可以说引入期运营角色的存在感并不强。产品会直接接触市场，分析筛选市场需求，进而完成功能转化，此时因为用户不多，市场不大产品还能hold住，但是当产品进入成长期，产品没有精力再并发处理需求的筛选分析，设计，运营就显得极为重要。
三、爱之恨之
运营是产品和市场的过滤器和挡箭牌，运营比产品更了解市场需求，因此和运营多交流一定没有坏处。而且运营凭借对竞争对手的关注，可以为产品提供新的思路。在和BD沟通过程中也会更加顺畅
系统化，自动化，理想化，万能化是运营对产品的期望和要求。每周的产品和运营需求碰面会上运营都会将需求一一列出来，产品对有疑问的需求先质疑一番，然后再放到需求池里。当然每次需求都会很多，产品需运营同学列出优先级。以及每项需求的必要性和收益。不然产品在找开发时一定会被开发喷死。
举个例子，有次碰到市场同事无意将200个商品做了下线处理，发现后立即给我打电话，说是不是可以让开发直接上线。其实这个需求的实质就是通过系统代替人工上线200的商品。我当时直接拒绝了此需求。原因有三：1、人工能否处理？2、如果人工能处理，一单耗时5S，200单耗时1000S，总共不超过20分钟，开发做批量处理要改动数据库，而数据库是联动的，不能只修改一个数据库，加上中间的沟通时间也需要20分钟，哪个更可行？3、开发通过修改代码，或者数据库完成此项任务，可能会存在不可预知的风险，如果有风险责任谁承担？这个不是推脱责任的意思，而是对不可预估风险的保守做法。（PS：鄙人在五一前的夜晚曾手动审核通过500个商品，上线后整个五一开发都没能好好休息，前车之鉴呀）
其实类似的事情很多，双方在考虑需求的时候出发点，着眼点不同。
当然也有运营会直接上来提一个需求，说目前设计不合理，需要改，实际是其不明白产品的设计思路，解释后则立刻无话可说
五、相处之道
1、运营在提出需求时一定要反复审问：
需求背景
竞对是怎么做的
没有其他解决办法了吗
ROI怎么样
优先级高吗
只有把这几个问题问透，才会对整个需求有一个好的把控
2、需求设计时一定要及时同构产品的设计思路，以及那些可以实现，那些需要花费高成本实现，哪些不能实现，哪些需要外部支持方支持实现。确定整个产品需求文档没有问题时再进行开发，不然到后期运营不满意或者不满足对方需求时就要做无谓的返工了。
3、后期产品验收时一定需要运营参与，一来确认需求是否被满足，二来运营对需求是否满意或者有其他意见（有意见不重要暂时保留，可以放在二起来做），包括后期培训等。
