当部门切割之后我才意识到做下游产品是多么苦逼的一件事情，无法控制另一端的设计和进度，无法推动项目的进展。能做的只是静静地背锅。
我讨厌把锅甩给别人，在我看来我辖区范围内没有达到老板的要求，挨骂或者被吐槽都是活该的。然而最近却担了太多不属于自己的锅，于是跟老板吐槽了几句，老板直接站了出来推动。
老板站出来当然好，我这个传声筒有了行政权力的支持，声音都大了好多，抵抗力量基本没有，一路绿灯。让人不忍感叹，特权果然不一样，难怪那么多人争权斗利。
然而从长远来看，这种绿灯只是暂时的，甚至在我看来这是一种饮鸩止渴的前兆。当老板发现自己的干涉竟然有如此威力，那么他将会不断的干涉，以加快研发的进度，满足自己的要求。同时责怪产品无用，为何自己推动不了，也会觉得研发就是核桃，不敲打一番不成气候。
一旦老板刚好很闲，迷恋上这种感觉后，实现者将痛不欲生，而我这个产品也没什么存在的必要。我无需用自己的逻辑说服他们，只需要加一句“老板规定的”即可。
那么如果没有行政力量，下游要实现产品功能？如何跟上游沟通呢？
下游产品与上游产品原本同属产品部，研发资源共用，同时还有产品总监的控制，此时产品不会太支离破碎是因为产品总监先进行整体的规划，将主逻辑理清楚，再将任务分配给他人。各司其职，在规定时间上线即可。
然而我司CTO一上来废掉产品部，将研发和产品按照业务和端口分成两条线，基础组有产品有技术，另外一组同样有产品有技术。然而CTO并不统筹产品。
于是就变成了一个功能点需要两组产品同时协作，但主要功能在下游，或者是核心在下游。上游理应统筹整个产品并支持下游变成了上游辅助下游做功能。
基础组的研发本应是共用的资源变成了上游产品的专属资源，当下游需要在上游产品上做功能时需先得到上游产品的同意。
这种制度很像元代行省制度，将一个整体切割成两个各自独立的个体。既然是个体就会争取独立的权利，而拒绝共同整体的责任。这是一种心理的归属，也是个人利益的最佳追逐方式。例如两广为整体时，当广东地区出现水灾，此时两广负责人有义务维持本地区的安定，所以集中力量解决问题，若二者各自为政，广西帮助广东只是尽友邻之爱，若是之前二者还有过节，这种帮助多少有些不情不愿。原本研发会拒绝产品的需求，现在基础组的研发又新增了一条拒绝需求的渠道，那就是隔壁组产品可以从根源上拒绝或者无限延后此需求。
而从行政制度上来说，下游产品是没有资格对接上游研发资源的，因为研发拒绝跟你沟通，除非你将上游产品拉进来，所以这是一个拒绝的死循环。这种情况下，似乎只有将强有力的皇帝拖进来了。
即便没有制度问题，下游产品在面对上游产品时就可以不低声下气了么？
当产品没有达成一个共识：公司的所有产品是大家的产品，我们是利益共同体，我们努力将它变得更好。那么协作就变成了帮助，下游你需要我帮你做什么？
如果下游此时变成需求方，能充当甲方简直不能更棒，然而现实是充其量是个没有太多否定权的甲方。
一方面语言沟通需求，三言两句没讲清楚逻辑（可能你自己觉得很清楚），对方只关心自己要做什么。于是你将复杂的流程浓缩成几个词，最后却发现页面展示很简单，但是形容词的内在逻辑对方并不知情。
另一方面每个人做产品都不喜欢其他人指指点点，从各自利益出发思考的点不一样，无关对错，谁也无法说服谁。
再者下游对于实现的失控导致心态的变化，既然扔出去了就不关我什么事情，毕竟他人的产品你很难指指点点。
最后的结果当然不太好，于是双方都很气馁。加重下一次的合作不顺利，毕竟没有一点成就感。
或者换一种方式下游不光提出了需求并且做好了解决方案，得到上游的认可后再来实现。这样相对于上游做需求而言更符合下游的预期，但是十分考验下游产品经理的心态，毕竟大家谁都不服谁。为什么我做需求必须经过你的同意？
除此之外，自己生完了孩子，结果别人去养，养到成年还得送回来，这就意味着生母要担心养母是否尽职尽责，以后是个熊孩子生母都不敢要，同时万一真熊自己还得承担本次的后果。
所以下游很难平复好心态。
换言之，上游同样觉得自己委屈，明明有自己的孩子要生要养，还得操心你这边，到时候不符合你的预期你还埋怨。明明是基因问题还要怪我养法不对？
所以行政出面最有利了，双方都有了很好的借口。
仔细想想，单从双方的角度讲，行政力量是最有效的方式呢。
我所想象的双方是共同确立一个目标，一同讨论和谐共处貌似从来没有实现过，最受刺激的莫过于明明是连接上游的功能但是因为端口在下游，收到了关我们什么事，是你们做的回复。
很多事情一旦变成了是你做，还是我做的选择题，它就没办法被完成的很好。这本来就是一道协作的题目，完全交给一方来做肯定会有问题的。
我在想如果我是上游的产品，我是否可以搞清楚产品中所有的逻辑，与下游的所有交集？当下游提出需求时可以做到很好的统筹？给下游一个满意的答复？当上游发生改变时是否可以提前通知下游做好准备，而不是等待研发提出疑惑或者下游产品出现bug？
即便是个疑问，也为之后做产品指出了一些方向：
1.只要是产品的逻辑，都应该在自己的认知内。
2.任何改动都应该想清楚其影响范围，不要等出问题再复盘所有逻辑。
3.相信别人，相信自己（虽然本条最难。