与外部公司合作，什么才是产品经理的正确沟通方式？

不知道在你的职业生涯中有没有过这样的经历，公司的产品是需要两家公司的一起合作来完

成的，其中涉及到产品、设计、技术、测试、运营等每个部门的协作，两家公司合作来做一

个产品。

虽然作为产品经理不缺少跟技术、运营等部门打 交道的经验，但那还都是局限在

一个公司的范围内，解决问题的最终决定权也在自己公司的高管手里，很多问题

都是可控的。但是与别的公司合作就不一样了，跟外包公司还不同，外包公司是

一方出钱一方出力，甲方的话语权更大一些，乙方在满足甲方需求的前提下，可

能也不会提出过多的主见，双方员工的心里都有一个默认的守则。

我要说的这种合作模式中，双方公司的地位是平等的，只是各自的分工、职责不

同，这样的话在过程中更容易出现问题，各种小的摩擦更是不可避免。而对我来

说，与外部公司的技术和设计沟通也还是头一次，合作的一年多来也有了一些收

获，深深感受到沟通的重要性。

两个公司合作往往是因为各有各的优势，彼此取长补短，在项目开发前首先要明

确好各自的职责。这事说起来这点挺简单的，做好各自的工作就好了，但是在实

际过程中还是有很多模糊的地方，为了避免矛盾产生主要还是要明确各自的边

界。

说个例子，我们跟对方公司合作的过程中，由于内容是放到对方家的平台上，为

了避免内容风险，对方会给我们一定的要求，至于在符合要求的前提下上什么内

容就是我们公司自己把控了。两家公司各自职责的明确这是合作的前提。

虽然同属互联网行业，对于行业内的一些常见的名词，例如产品，UI设计等，大

家都很熟悉，但是不要自以为是，为了防止做无功用，彼此还是要明确一些，哪

怕多问一嘴，也是有必要的。

我们就吃过这个亏，对方公司当时让我们提供一下产品详细设计文档，我们以为

是产品需求文档，所以就把产品文档发过去了（为了体现专业性，发出之前我们

还临时评审、修改了一遍）。结果后来却发现原来我们理解错了，人家说的“产

品设计文档”其实是指技术开发文档。这就造成我们在错误的方向上花费了时

间，而正确方向的事情，技术文档还一直没写，耽误了时间，最后没有得出想要

的结果。

更重要的碰到这种事情，往往是说不清的，没法追责，所以为了避免出现这种问

题最好还是提前沟通一下比较好。

除了明确术语概念外，还要提前沟通好合作中所需要书写的文档以及文档的内

容。有了文档能够减少沟通成本，避免扯皮。关于文档，最重要是应该明确其中

都要有哪些内容，只要文档中的内容，特别是关键点，有就可以了，形式不重

要。

沟通方式分两个方面：一个是确定一种沟通的工具，比如说邮件、QQ、微信等；

一个是建立定期开会的制度，开会除了讨论已有需求如何实现外，还有一个好处

是彼此可以就下一步的一些想法做一些沟通，有些事情做到双方的相关人士都知

情。

不同公司之间的沟通方式和工作流程是不一样的，虽然在一个互联网公司中大致

的流程都是相同的，包括产品设计、UI设计、技术开发、测试等环节，但是在具

体的执行、产出物的标准上还是有一些不同的，所以在合作前还是要互相了解一

下。

拿测试来说，即使都有测试环节，但具体的过程还是不一样的，一般的公司可能

在内测后就会直接上线了，但是在有的公司就会有内测、众测和A/B测试这三个

阶段，这样就会延长上线的时间。如果之前没有沟通好，认为测试只有内测一个

环节，双方之间预估的上线时间不一致也会造成一些误会，影响其它工作如运营

活动的准备时间。

对于产品经理来说，了解工作流程有一个很大的必要是不会耽误需求的开发时

间。举个例子，如果有些功能是自己公司开发的话，那还好，对于技术的开发时

间有准确的把握。但如果是需要对方公司开发的话，因为对方可能还有别的项目

做，所以就需要提前把需求提给对方，把握好时间点，要不然因为需求提晚了，

对方没时间做那麻烦就大了。

两个公司合作肯定会出现一些摩擦，虽然彼此的关系不像谈恋爱那么亲密，但也

要建立起信任的基础。

让我感触非常深的一点是不要故意揣测对方，比如说对方是否有意使我们为难，

对方是否有对我们的系统进行攻击等等。虽然这种情况可能确实存在，但是也要

在经过实际验证后才能确定问题。

恶意揣测对方会造成什么不良的后果呢？极大影响团队的士气，特别是在两个公

司的背景和团队实力相差悬殊的情况下，弱势的一方在某些方面确实会收到强势

一方的要求，例如在代码的书写规范上。我们就遇到这种情况，虽然我们不是外

包公司，但是由于产品性质和对方公司在行业内的地位，对系统的稳定性有特别

高的要求。

如果对方的要求比较高，自己又无法理解，时间长了，次数多了，内心会积攒很

大的情绪。这样一来就更容易揣测对方的意图，加上本身存在的公司地位的差

距，会让员工的工作比较消极。

双方的合作中如果自己的下属受委屈了，领导会极力袒护，这可以理解，一个好

的领导理应维护下属的利益。但还是要有公正的对待，对下属的工作态度和产出

的结果有准确的评估，在维护下属利益的同时要判断下属有没有把事情做好。

有的领导一味的维护自己下属的利益，却忽略了下属能力欠缺的问题。甚者，有

的下属也会利用领导的这种心理，工作上敷衍了事，遇到坎就让领导出面解决。

曾经有过一个页面的设计，我们的设计师出的设计稿，需要经过双方共同评审后

才能通过，但是对方的设计师对我们设计的作品不满意，语言上有一些不妥。碰

到这样的行为，可以强硬一些让对方道歉，但毕竟结果还是不理想，冷静下来还

是要处理问题。

与技术上的问题不同的是设计稿的评审更多的是受主观因素影响。碰到这种问

题，自己一方在尽其全力的前提下，如果效果还不太理想，双方彼此之间要给出

具体的意见。之所以说是具体意见，也是为了模糊的说辞引起双方的猜疑，而且

意见具体一些，解决问题的效率也更高一些。