这其实是一种自然的产品线划分办法，功能越做越多，把所有的功能归成一个功能集，对这个集合进行分类，分类时会去考虑业务关联性和功能耦合性，这种分类就是产品线的划分方法。比如交易产品线，所有和钱相关的功能都会划到这块，商品管理产品线，涉及到商品基础管理、属性、类目相关的都属于这条线。
产品线划分的比较明确之后，必然会涉及到产品线之间横向的协作。这也是为什么只能划分的比较明确，否则产品线之后都没有什么关联的话，就变成做N个单独的产品了。所有产品线构成一个产品，从产品经理的角度来说，既要考虑产品线自身的规划和发展，也需要考虑产品整体的发展。
当你有能力负责一条产品线的时候，你会发现除了每天要和所属的技术人员撕逼以外，还需要和其他产品线的人撕逼，这中间包括对方的技术人员和产品经理。撕逼不能成为常态，和谐沟通才是王道。如何能在各条产品线之间协调的游刃有余，达到自身产品线发展的目的，是产品经理能力进阶的很关键一点。
协调的本质是要有共同的目标
通常当我们涉及到跨线合作的时候，往往是项目的范围超出了单条产品线的业务边界，需要其他业务线的配合。
从技术的角度来看，对于模块的划分，或者说是对服务的划分是很明确的，不同的服务实现不同的功能要求。当A模块需要使用B模块提供服务时，只需要调用B模块向外提供的公共服务即可。
这种架构设计的目的是降低模块之间的耦合度，并实现业务模块的封装，涉及到相应业务服务的地方，统一都由该业务模块来提供服务，减少代码的重复度。
而产品线之间的协作也可以借鉴类似的方法，产品线的业务边界虽然不是特别明确，但在一些明确的边界上是可以基于边界来定义各条产品线所需要执行的功能范围的，这一点很关键，你要去协调人家做事，首先要告诉对方需要做哪些事，如果这点都说明不清楚，协调没有什么意义。
在说服对方接受的过程中，可以从业务模块之间的耦合度、业务专一性角度出发，多替对方考虑一下业务设计的合理性，把同类功能整合在一起，统一对外提供服务。不要一副“本来就应该你做”的态度，工作协调中没有上下级的关系，不能使用类似下命令的方式。
最后很重要的一点是明确告知整体项目的背景、实现的价值，要将这点升级成为大家的共同目标。如果有一些关键的考核指标能来衡量项目的价值，最好能说明这些关键指标对整体产品所能带来的价值。
项目边界和业务边界的区别
项目边界我们更多考虑实现层面，很多项目都会分为一期、二期、三期来实现，最终实现出相对完善的整体项目结果。这里面每期的功能范围，或者说是功能列表，就是项目分阶段的实现边界，而整体项目的功能列表就是项目的边界。
这其实和简约设计思维很像，合理控制需求的实现范围，从成本/产出比的角度去衡量，不过分实现需求，也不阉割。同样的需求在实现层面上，技术可以给你好几种方案，每种方案的实现成本肯定是不一样的。比如要做一个优惠券的项目，可大可小，小的可以单独实现发单一面值的券去使用，大的从生券规则、发放逻辑、使用逻辑、结算逻辑出发，可以做很多模块。
业务边界则更多的定义业务之间的耦合度。我们经常讲“专业的人做专业的事”，业务设计层面也是一样。还是以上面的优惠券项目为例，从券的生成、发放、用户领取、用户使用，都是围绕券本身进行处理的，但到了结算的部分，更多围绕的就是订单和财务层面的需要来处理了，所以订单产品线和财务系统产品线要分担这部分工作。
始终牢记沟通的本质和目的
这一点在类似的工作协同文章中讲的比较多，跨产品线的横向沟通一般来说还是比较和谐的。稍微需要注意的技巧是，当产品线之间的排期或者迭代节奏不一致的时候，如果你需要保持项目进度一直，就需要提前较多的时间去沟通协调，优先考虑对方需要做什么，提前进行合理的安排。
这里需要注意两点：
1、要更多的从对方的角度去考虑功能实现的问题和排期的困难，提前想好对方可能会有哪些问题，并想好应对措施。大家都是同事，一般不太会出现故意刁难的情况，真有的话就只能上升一级来协调处理了。不过不到万不得已，少去借领导的势来达成自己的目的，不然下次协调会更麻烦。
2、多留点时间余量给对方去思考和提建议，特别是你自己都觉得项目的排期和方案设计存在问题的时候，多听取一下对方的项目，有的时候从主导的角色上变成配合的角色也未尝不可，只要项目完成了就可以。
很多产品新人都比较怕对外的协调和沟通，越怕越做不好。勇敢的走出第一步，第二步就轻松很多了。多从他人的角度去思考问题，换位思考说说很简单，做起来没那么容易，要刻意的逼自己去换位思考。
从单一产品线的管理协调升级到多产品线，是对产品经理自身能力的提升，也是为后面带产品团队做准备。当你有带几个产品新人的时候，你就会发现如何划分他们的工作边界，如何协调好他们之间的工作任务是很重要的。
原文链接：https://jiankeweb.com/articles/1279.html，转载请注明出处。 百度收录：
