在外包公司做产品经理是什么样的体验？

相信很多互联网从业者或多或少都会有这些疑问，这边阿境近期与几个外包小伙伴深入沟通了下，于是乎，便想来谈谈外包公司产品经理如何华丽变身。

如有不足，望各位大佬批评斧正。

另：附上本文导图框架，节约时间。若您感兴趣，可继续深入阅读；若不感兴趣，感谢光临。

在外包公司，产品经理（PM）往往更偏向于项目经理，由于在一定程度上缺失了部分用户调研，需求分析的流程（下文会提到），更多的是直接的接触真实需求（也不一定是真实用户的需求，可能是甲方大大臆想出来的），从而在甲方大大的“要求”下，完成产品。

而在项目开发的流程当中，由于外包需要的是更多的项目，所以往往会有多个项目交替并行，这也就是说为什么外包产品经理更偏向于项目经理的原因。

“能够接触到N多的0-1，但1-N基本是很少能摸到的”

麦肯锡的咨询师在从来没有接触过一个行业的前提下能够快速了解这个行业然后提出解决方案一样，外包产品经理包括但不限于用户端产品经理也应该具备这样的能力，哪怕没有相应的行业经验。

销售接单→产品经理对接客户需求→将需求整合成PRD→客户确认→设计稿阶段→开发阶段→测试阶段→项目验收上线

项目立项→需求调研→需求评审（产品、设计、开发、测试）→将需求整合成PRD→客户确认→设计稿阶段→开发阶段→测试阶段→项目验收上线→产品迭代

阿境整理了一张图，可以直观地看出，这两者之间的差异点。

在外包公司里面，一个项目的生命周期大致为十几二十天到数个月不等，平均在两三个月内完成。

当然，不同的载体及项目难度也影响着项目工期，比如做APP耗时必然大于做小程序，做过H5、小程序、APP的朋友应该都能明白，这边就不再举例。

而外包公司的经济来源大多在于项目收入，大大小小的项目穿插着，特点鲜明：产品周期短（省略了前期需求调研的部分），迭代周期短（往往甲方会找外包团队做出1.0的版本，短期投入市场，若可行，大部分会组建自己的开发团队进行后续迭代），部分甲方会选择继续跟外包团队合作继续2.0的迭代。

所以，在如此快节奏的项目开发下，在外包公司中，作为产品经理/项目经理，能够接触到更多的项目，了解更多的产品，大多是从0到1的产品，小部分迭代的产品。

在项目多的情况下，基数大的前提，造成了行业广的结果。

在常规公司当中，若公司是电商行业，那么该产品经理接触的，基本也是局限于电商行业，对于其他行业，平时若没有机会的话，那么基础的机会就会少很多（排除自身接私单的情况）。

通常外包公司本身会有几个市面上比较热火的行业案例，如当下热门的电商行业、医疗行业、新零售行业等，由于市场的驱动，造成了部分行业的兴起。

那么，在每一年，不出意外的话，都会有不同行业的项目。

接触的项目及行业多了，自然，业务模式也会更加的了解。

虽说万物皆类象，但不同的行业造成其不同的业务模式，即使是相同的业务，不同的盈利模式也使得业务的方向有细小的差异。

而产品的规划设计，其根本都是基于业务流程，分析不同的业务流程，也能够加深对于不同行业不同业务的理解与认知。

那么，在规划产品的时候，理解业务的前提下，也能够更加地贴切。

在乙方公司，往往要跟甲方、甲方员工、销售、设计、开发、测试等多个角色进行沟通。本身产品经理在一个产品的生命周期当中，就需要不断地与团队的人去沟通。

那作为乙方的产品经理，更是如此，不仅需要面对自身团队内的人，还需要与甲方沟通（有时候甲方并不是一个人，而是甲方+甲方团队），且中间需要与销售同事做对接。

如此艰辛的环境，也使得乙方产品经理不得不磨砺好自身的沟通能力，外能抵御甲方的神仙需求和夺命连环call，内能应对设计MM开发GG的双重夹击，可谓是夹缝中生存，没有强大的沟通能力，是没有办法在这种环境下“存活”下来的。

而执行能力亦同，外包公司的节奏快，项目很多且穿插着来，那么，执行力也是必要的，每天的任务都满满当当，一个小细节没做好，那么后续可能导致的项目延期返工等，都是有可能的。长此以往，执行力自然不在话下。

在研发当中，乙方完成的角色通常是0-1的项目，那么，自然会有部分产品是采用MVP方式的产品。

甲方会尝试用简单的软件，快速投入市场进行试错，若是可行，那么可能就会将项目接回去自己做；若是不可行，那么可能不了了之。

甲方会找外包的原因在于：

• 低成本快速试错，验证项目市场可行性。

• 内部无研发团队，需外包团队配合协助。

• 已探寻项目的市场可行性，内部研发缺乏经验，需要外包协助。

那么，不管从哪个角度上来看，项目的研发深度相对来说都是浅显的，那么，作为乙方产品经理，接触到的，都是冰山一角，往往在冰山底部的更多的奥秘，都是没办法去体验及钻研的。这就需要身处外包的产品同学私下自身不断去做功课，挖掘冰山下的产品知识点。

在甲方寻找到外包之前，就已经做好了“需求调研”及“产品定位”（也可能是甲方大大自身的想法）

作为一个产品人都明白，一款好的产品，往往在其方案诞生之前，前面的需求调研，分析，筛选，确定MVP方案，需求优先级，迭代计划等等都缺失参与，而这些前期准备也可能是决定产品是否能获得成功的决定性因素。

而在甲方见到你之前，就已经完成了这部分，那么，没办法接触到真实的用户，自然而言，对用户的了解也就少。

而我们知道，对于C端产品，最重要的便是用户；对于B端产品，则真实的使用者也是重要的一个角色。

作为乙方产品经理，产品是从0-1居多，从1-N的极少（MVP产品若是成功，那么基本大部分客户会拿回去自己组建团队开发）。

那么，能够接触到的用户数据，产品数据并不多，对于数据分析的能力，自然也是相对来说差了一些。

当一个人习惯了不用去探索用户需求，就能够接触到真实的项目需求的时候，自然就会产生惰性。

长此以往，对于产品的Sense自然会变得弱一些。

用“温水煮青蛙”来形容，再贴切不过。

习惯了循规蹈矩，对于甲方需求的提出全盘接收，那么，互联网时代的变化瞬息万变，在创新方面，也没办法时刻的跟进最新产品的动态，若没有自身调整，因环境而影响，创新能力也会变得较弱。

甲方大大拿着功能清单过来，指着某软件，“照着这个给我做一个。”

那么，有的PM很“乖”地照做，项目最终也能如期交差，还很开心，又完成了一个项目。

殊不知，已然丧失了原本PM这个岗位的核心。

同时，甲方大大拿过来的功能清单，往往功能冗杂，且掺杂一些在1.0时期不必要的功能。由于部分客观原因（公司项目指标要求、甲方个人意愿等），劝说甲方更改功能的可能性微乎其微。

那么，在这个阶段，作为PM，我们能够做什么呢？

深入地走入甲方的需求中心，了解清楚为什么做这个项目，满足的用户群体是谁，核心的需求及后续资源如何调配，1.0版本出来了想要如何运营，是否有版本迭代的概念及相应的规划……

因为即使照着功能清单里的功能来做，不透彻了解需求的情况下，作为PM也只会是照搬照抄，“没有理解，抄不到精髓”。

在很多时候，甲方大大自己带来的功能清单，十有八九掺杂着不合理的需求或者是不必要的需求；

根据KANO模型（如下图）来分析，往往很多甲方提出的都是无差异需求，期望型需求相对来说较少，同时，在不了解产品规划的情况下，偶尔也会提出一些反向需求（如上述的例子）。

那么，这个时候，作为一名合格的PM，并不是一昧地迎合甲方，而是应该通过自身的履历及经验，来做合适的引导及分析，深刻挖掘客户的每一个需求的来源。

按照需求的作用大小来分类，阿境将甲方需求归纳为四种

• 真实型需求

通过团队内，实践得来或真实调研来的需求，只缺开发团队完成即可。

• 抄袭型需求

某竞品有这个功能，那么我也照着来一套（实际上可能并不符合自身项目）。

• 臆想型需求

凭空想象，无任何依据，也不管实现起来对自身是否有利，主观性强。

• 无用型需求

对于目前阶段并无任何作用，却坚持在这一版中实现。

既然没办法接触到真正的用户，那么，也可将能面对的甲方当成一个“用户群”的集合，

能够挖掘的需求就进行合理的分析并排期，不能够挖掘的需求，通过其余途径（论坛发帖，真实用户访谈等）来进行探索。

虽然在快节奏的项目规划当中，会费点时间，但是有思考有深究的一个项目，远比得上四五个无脑式的方案，至此，也不至于沦为“作图小弟”。

很多甲方也希望自身的项目能够被规划被建议（毕竟大部分人还是相信专业的人士），而一般PM提出的问题，也是基于项目能够合理的规划设计来提出的。

基本上都能够得到合适的回答，关键在于，PM愿不愿意花这么点时间来迈出这一步。

每个项目的最终需求是获利，那么，在这当中还有很长的一段路要走。

产品的核心，在于满足____用户的____需求，以此为基点，再通过产品本身的定位，阐述做这款产品的目的。……

“不谈盈利的产品都是耍流氓”

产品的功能，都是为以后的盈利点服务，通过____的途径，帮助公司实现_____，可大可小。

了解清楚产品的盈利点，也能够更加的明确，该如何规划设计才能够抓住用户的痛点，而不是一昧地堆砌功能。

往往在不了解公司架构的时候，直接设计，那么相应的业务流程看似走得通，但实际运营起来，处处碰壁，这边走不通，那边缺漏，返工在所难免。

而了解对方的公司架构，则能够保证软件在后续的实际运营当中，能够实现资源利用最大化，为产品的后续运营考虑，也是作为一个PM的重要职责。

举个例子，规划商品分类这么一个小功能，甲方想要做三级分类，一问为什么，回答是市面上都是三级。然而了解公司产品情况，并非有那么多的资源及渠道，这个时候如果还是设计成三级，无疑是增加用户的点击成本。

诸如此类的例子在实际的规划当中多如牛毛，用户体验差的结果最终只会导致用户流失，甚至可能铸就了这个产品的失败。

通常在乙方公司，产品上线了之后，基本运营都在于甲方手中，那么，除了多次迭代的情况，不然PM是接触不到产品的运营数据的。

这个时候，可通过向甲方提出要一些数据来对自己产品的分析，包括用户人数、付费量、订单量、页面转化率、日PV、UV等，因为产品当初是自己规划的，那么在哪些部分做了数据埋点，自身自然也清楚。

一些敏感数据（例如销售金额，订单毛利等）可能暂时没办法接触得到，但是通过对于用户体量、平台日活及平台盈利点的结合分析，也大概能够知晓一二。

获取途径的方式也很多：H5可通过第三方统计（百度统计）来获取页面的数据，小程序可通过小程序数据助手来获取，APP可根据数据埋点来进行抓取想要的数据。

这些都是PM触手可及的，同时，根据数据的分析，为甲方提供后续迭代的建议，甲方大大们也是乐意的，毕竟，谁会拒绝来自产品规划者对于后续产品如何发展的分析及建议呢？

在乙方的PM接触那么多项目，成功的项目例子存在，失败的项目也不少，那么，最重要的，便是进行复盘分析。

一个项目成功与否的因素很多，在于市场需求是否足够了解，在于产品规划是否得当，在于前期获客是否精准，在于运营方案是否合理……

成功的原因千奇百怪，失败的原因却往往大同小异。

因素很多，虽然产品规划只是项目的其中一个点，但是，我们仍然可以保持我们的“发问精神”，活动推广不好，是否是相关功能的页面层级过深？转化率过低，是规划过重还是运营不当？等等。

能够经历更多的项目，见证更多项目的成功与失败，也是乙方PM的优势之一，再通过自身对于各行业的思考探索，也能获得更多的经验。

乙方PM接触的项目来自各行各业，各种类型的都有，且应该都是当前较为火热的项目（不火热，也没人会投资开发）。

例如前几年的电商行业，近两年的K12教育行业及短视频行业等，都赢得众多甲方的青睐（什么火做什么，什么可能赚钱做什么）。

那么，这与处于单一行业的PM经历不同，处于单一行业的PM，可能两三年内都在研究自身行业的产品，会更加了解及精通。

那么，对于乙方PM来说，只能在有限的项目时间内，多花几倍的时间，去钻研这个行业的性质及了解业务流程，产品才能够被合理的规划出来。

这也要求乙方的PM，若想提升自身对于不同行业的认知，那么，跳出舒适圈（仅仅“把项目当成项目来做，而不是产品”的想法）很重要，尽管并不那么的容易。

在现在的互联网行业当中，大家对于外包产品经理褒贬不一。但身处产品岗，也应以客观的态度去看待问题，其优劣各半，阿境亦接触过不少外包的产品小伙伴，抱怨项目多，机会少，缺失部分产品环节等问题。

然而，不管是在外包公司还是在常规公司，做的顺不顺畅，从来都不是公司性质的问题，将目标聚焦于自身的问题才是根本。

在外包公司抓住了机会，找准了方向，同样是能够使得自己得到锻炼，通过上述分析，换个角度思考并努力（缺少了行动的思考毫无意义），同样能够获得更好的产品体验也能够使得岗位上的缺点在一定程度上也能转变为优点。

“打不倒你的，往往能够使你变得更强”，外包公司的产品经理，经历了越多，应该是越挫越勇，在荆棘当中，突出重围。（朋友们，随阿境喝下这碗鸡汤哈哈哈哈）

Tomorrow will be ok，you will be strong.

我是阿境，见字如面。

野蛮生长，产品汪一枚，做过电商、医疗、教育行业项目。有千万级流水产品经验。

坚信”产品源于生活”，欢迎交流。

公众号：梦想家阿境