外包产品经理,如何提升自己的综合水平?

在行业内,产品经理在X分类中,又可分为常规产品经理跟外包产品经理,这两者的区别是什么?在外包当产品经理与常规X有什么区别?身处外包X,如何能够提升自己的综合水平?相信很多X从业者或多或少都会有这些疑问,本文作者从自身工作实践出发,与大家谈谈外包X产品经理如X丽变身。

本文导图框架:

一、外包X产品经理的定位

在外包X,产品经理(PM)往往更偏向于项目经理,由于在一定程度上缺失了部分用户调研,需qiú分析的liú程(下文会提到),更多的是直接的XX需qiú(也不一定是X用户的需qiú,可能是甲方大大臆想出来的),从而在甲方大大的“要qiú”下,完成产品。

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

“能够X到N多的0-1,但1-N基本是很少能X的”

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

二、外包X的项目liú程

外包X的项目liú程X接单→产品经理对接客户需qiú→将需qiú整合成PRD→客户确认→设计稿阶段→开发阶段→测试阶段→项目验收上线

常规X的项目liú程项目立项→需qiú调研→需qiú评审(产品、设计、开发、测试)→将需qiú整合成PRD→客户确认→设计稿阶段→开发阶段→测试阶段→项目验收上线→产品迭代

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

三、外包X产品经理的优劣势分析

1. 优势

(1)多→X更多的项目

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

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

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

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

(2)广→探索更多的行业

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

在常规X当中,若X是电商行业,那么该产品经理X的,基本也是jú限于电商行业,对于其他行业,平时若没有机会的话,那么基础的机会就会少很多(排除自身接私单的情况)。

通常外包X本身会有几个市面上比较热火的行业案例,如当下热门的电商行业、X行业、新零shòu行业等,由于市场的驱动,造成了部分行业的兴起

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

(3)知→了解更多的X

X的项目及行业多了,自然,X模式也会更加的了解。

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

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

那么,在规划产品的时候,理解X的前提下,也能够更加地贴切

(4)强→更强大沟通能力跟执行能力

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

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

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

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

2. 劣势

(1)浅→项目的研发深度浅

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

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

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

  • 低成本快速试错,验证项目市场可行性。
  • 内部无研发团队,需外包团队配合协助。
  • 已探寻项目的市场可行性,内部研发缺乏经验,需要外包协助。

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

(2)少→对用户了解少

在甲方寻找到外包之前,就已经做好了“需qiú调研”及“产品定位”(也可能是甲方大大自身的想fǎ)

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

而在甲方见到你之前,就已经完成了这部分,那么,没办fǎX到X的用户,自然而言,对用户的了解也就少

而我们知道,对于C端产品,最重要的便是用户;对于B端产品,则X的使用者也是重要的一个角sè。

(3)差→对数据分析能力差

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

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

(4)弱→创新能力较弱

当一个人xí惯了不用去探索用户需qiú,就能够X到X的项目需qiú的时候,自然就会产生惰性。

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

用“wēn水煮青蛙”来形容,再贴切不过。

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

四、如X外包X获得常规X同等历练

1. 进行需qiú分析→多问为什么

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

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

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

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

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

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

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

在很多时候,甲方大大自己带来的功能清单,十有X掺杂着不合理的需qiú或者是不必要的需qiú;

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

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

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

  1. X型需qiú。X团队内,实践得来或X调研来的需qiú,只缺开发团队完成即可。
  2. 抄xí型需qiú。某竞品有这个功能,那么我也照着来一套(实际上可能并不符合自身项目)。
  3. 臆想型需qiú。凭空想象,无任何依据,也不管实现起来对自身是否有利,主观性强。
  4. 无用型需qiú。对于目前阶段并无任何作用,却坚持在这一版中实现。

既然没办fǎX到真正的用户,那么,也可将能面对的甲方当成一个“用户X”的X,

能够挖掘的需qiú就进行合理的分析并排期,不能够挖掘的需qiú,X其余途径(论坛发帖,X用户访谈等)来进行探索。

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

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

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

(1)为什么要做这个项目?

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

产品的核心,在于满足____用户的____需qiú,以此为基点,再X产品本身的定位,阐述做这款产品的目的。……

(2)产品盈利点是什么?

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

产品的功能,都是为以后的盈利点X,X____的途径,帮助X实现_____,可大可小。

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

(3)X架构及主要Xliú程是什么?是否有足够的能资源及能力来保持产品的后续支持?

往往在不了解X架构的时候,直接设计,那么相应的Xliú程看似走得通,但实际运营起来,处处碰壁,这边走不通,那边缺漏,返工在所难免

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

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

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

2. 增强数据分析能力→多回访,获取项目数据

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

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

一些X数据(例如X金额,订单máo利等)可能暂时没办fǎX得到,但是X对于用户体量、平台曰活及平台盈利点的结合分析,也大概能够知晓一二。

获取途径的方式也很多:H5可X第三方统计(百度统计)来获取页面的数据,小程序可X小程序数据助手来获取,APP可根据数据埋点来进行抓取想要的数据。

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

3. 不断复盘→总结项目的成功/失败原因

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

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

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

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

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

4. 提升个人行业认知→跳出舒适圈

乙方PMX的项目来自各行各业,各种类型的都有,且应该都是当前较为X的项目(不X,也没人会投资开发)。

例如前几年的电商行业,近两年的K12教育行业及短X行业等,都赢得众多甲方的青睐(什么火做什么,什么可能X做什么)。

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

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

这也要qiú乙方的PM,若想提升自身对于不同行业的认知,那么,跳出舒适圈(仅仅“把项目当成项目来做,而不是产品”的想fǎ)很重要,尽管并不那么的容易

写在文末

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

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

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

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

Tomorrow will be ok,you will be strong.

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 外包产品经理,如何提升自己的综合水平? https://www.xiongfawang.com/2591.html

常见问题

相关文章

外包产品经理,如何提升自己的综合水平?-海报

分享本文封面