我在阿里这 10 年:从 BI 到产品经理,曾被程序员踢翻桌子骂

   2019-07-26 91运营0
核心提示:10年前,我加入阿里B2B国际事业部,从事用户和数据分析工作,做了3年用户研究、数据分析以后,决然毅然的转型,走上了产品经理这条黑道;而后1手打造了国际事业部的商家数据产品,产品、运营都实现高楼平地起,成为事业部用户满意度最高的产品。时隔多年,前

a1138 我在阿里这 10 年:从 BI 到产品经理,曾被程序员踢翻桌子骂

 

10年前,我加入阿里B2B国际事业部,从事用户和数据分析工作,做了3年用户研究、数据分析以后,决然毅然的转型,走上了产品经理这条黑道;而后1手打造了国际事业部的商家数据产品,产品、运营都实现高楼平地起,成为事业部用户满意度最高的产品。

 

时隔多年,前段时间某晚11点多,老同事打电话来咨询当时的产品设计逻辑,我仍然异常清晰。

 

这是1段尘封多年的历史,再次打开,仍然会思绪万千。

 

非常感谢我的老搭档们,你们是我这10年工作最大的收获;感谢曾的老板们,谢谢你们放手让1个对产品认知为0的人,去闯去拼;感谢曾的客户们,是你们1直伴随着我,给我内心的鼓励;也很感谢自己,作为产品经理,有这样1段经历,值了。

 

1、我为何要从 BI 转产品经理?

 

作了3年用户研究、数据分析以后,感觉自己对业务、对用户的理解登峰造极。

 

国际站的业务:国内的工厂、贸易商在国际站发布产品、公司信息,海外买家到网站上来找供货商下单,作出口贸易。

 

这些海外买家从站内或google、或SEO来到阿里巴巴以后,landing了甚么页面,来了以后多少PV,看了哪几个页面,在页面上停留了多久,输入了甚么关键词,页面有无下拉转动,根据这些信息我基本能推断出:这个买家是甚么类型的?是来找工厂的、还是找产品?还是只是4处看看商机?每类人核心关注的是甚么?

 

知道这些信息以后,要转化这些买家,让他们下单,需要不同的产品方案;比如:1直在看工厂信息、特别工厂地址、视频的买家,就给他推荐有高信誉度的工厂,不是贸易公司。那些SEO来的买家,恍忽了1个页面就开溜,可以斟酌推供货商信息的同时,告知他阿里巴巴是干吗的——由于可能他们对阿里巴巴没有认知。

 

作BI的时候,面对问题,会产出1份份报告,比如:买家画像、买家保存分析、买家转化分析;用报告的方式,给管理层、业务、产品输出建议,有时候建议会被采用,更多时候建议不被采用。

 

不被采用的缘由常常是那1句“产品很复杂,没那末简单的”。

 

我的小宇宙不甘心,看着买家的行动路径,恨不得把自己变成万能的魔法器,随时都可以变成各种产品到页面上,把买家留下来,给我们的供应商下单。

 

这类状态延续了1段时间。

 

有1天,我跟老板们说:“我要去作产品,我觉得这产品可以解决很多问题,然后开始不断销售我的业务蓝图。”说得内心斩钉截铁。

 

老板们问:“你想清楚了吗?”

 

我:“想清楚了。”

 

老板们:“那就去做吧。”

 

然后,我就从BI变成了满腔热忱的产品经理,开始打怪兽的产品之路。

 

现在回想起来,转型最深层次的缘由是:我不是1个愿意只是给他人提建议的人,我要的是这件事情落地并且真的解决问题,看到效果。

 

这类性情上的诉求,BI已阶段性的不合适我,产品经理才是我该干的事。

 

最近和很多BI的朋友聊天,有的想转产品,有的想转BD,有的想换个环境继续做BI。

 

从岗位角色来讲,BI有点像军师、顾问,产品经理则是要上1线打仗的,这是二者最大的差别,但优秀的产品经理1定具有数据分析的能力。

 

所以,不管BI、还是产品,最重要的是审视自己的性情和阶段性的诉求。未来某天,我也许会再回到BI,也何尝可知。

 

梳理下,BI和产品经理两个角色在互联网公司的职能与差异。

a294 我在阿里这 10 年:从 BI 到产品经理,曾被程序员踢翻桌子骂

 

2、转产品经理遇到的最大困难是甚么?

 

转产品经理后,遇到了很多问题。

 

转型早期,遇到最大的4个问题:

 

  1. 产品小白,不知道产品经理的协同链路,前门起火、后门遭殃的事,偶有产生。
  2. 开发GG在项目室踢翻了桌子,把我吓楞了几秒。
  3. 业务环境焦灼,差点就被废柴了。
  4. 没资源、没资源、没资源,第1期项目从提需求到开始开发,花了半年时间。

 

1. 不知道产品经理的的协同链路,致使前门起火、后门遭殃

 

没干过产品经理,空有作产品的心,对产品经理有哪些合作火伴,各合作火伴有甚么的特点、诉求,全然不知,以为1个个环节已捋顺了;忽然JAVA负责人来责问,前端资源弄定没?再不弄定,我的资源就要撤出来了。

 

本以为通关赛已打完,可以歇口气了,原来还有关口;要命的是我尽然不知道,过不了可就前功尽弃。

 

类似这样的问题,在刚开始的阶段,偶尔总会出现那末几次。

 

更要命的是产品经理的工作是全上下游的协同,每一个部份相互影响。就像多米诺骨牌,1开始多是前端有问题,但由于前端有问题,后端、数据、测试可能相继会有问题——由于每一个环节都重压在身,不是为了我的产品而独立存在的,任何1个环节1旦错过约定时间,就全链路连锁崩溃。

 

可能有人问:怎样1点弹性都没有?

 

是啊,那不是刚作产品经理吗,没有建立信任感,大家愿意投资源已很给面子了,每一个人手上的to do list都很长,哪来那末多弹性?

 

每一个团队、每一个岗位都有自己的目标,不会为谁停留。

 

当时,1个需求从idea到上线到底要经历多少环节,我不知道,也没给自己找个靠谱的师傅普及下。

 

大家入行时,记得给自己物色1个好师傅,非常重要!

 

好在自己的抗压力、抗挫力还不错,各个方面也都很给力,终究没成大问题。

 

说到这里,我们就来看看产品经理的常见协同链路:

a379 我在阿里这 10 年:从 BI 到产品经理,曾被程序员踢翻桌子骂

 

 

这是常见的相对完全的协同链路。

 

有的环境下,需要协同的环节会减少,比如:不触及收费的,就不需要财务参与;不触及法务合规的,也能够不参与。

 

有的工作环境中,没有那末多讲求,产品上了再说,不同形态下会有所取舍。如果触及到特定行业的产品,比如:金融产品,风控、资产团队就会变得很重要。

 

超大型的项目,常常会有项目PM(项目经理),由PM承当项目管理的主要职责。平常项目,产品经理常常身兼项目管理的职责。

 

2. 开发GG在项目室踢翻了桌子,表示对我的抗议

 

事情产生在我已站稳产品经理这个岗位以后。

 

当时有个线上历史遗留功能有问题,作为有洁癖的产品经理,我1直在推动技术GG修改,技术GG拖沓了下,演化成我盯着技术GG现场改。

 

当时项目室里大家还有说有笑,忽然间,那位在修改代码的GG站了起来,两步走到紧挨着但没有放电脑的桌子边上,1脚啪的踢翻了那张桌子,指着我大声吼:“你再让我改,再让我改!”。

 

大家都惊呆了,我也惊了,不知道产生了甚么,整层楼都听到项目室的消息。

 

我迅速在头脑里搜索,我的语气挺客气的,项目室里的氛围也挺愉悦,唯1的毛病就是这个修改已说了有56遍还没改,只能盯着改,但不至于这么大反应。

 

头脑里又搜索了1遍,还是不知道缘由。

 

大家的心情平复的都很快,稍过1会儿,我主动约开发GG聊。

 

那天晚上我们长谈不知道几个小时,从小时候的家庭到当时的工作。原来在我盯着他改代码之前,开发GG刚刚被他的老板严厉批评,他心中不甘又没法发作,而我没有留意他情绪,撞到了枪口上。

 

成年人的崩溃1定是积存了很久,只是看上去压死骆驼的是最后1根稻草。

 

经历这件事情以后,我反而变的更强大,也开始要求自己对项目室的每位同学要多1些关心,要让这些1起战役的同学们,拿到他们应当拿到的东西。

 

对全部链路上的同学来讲,他们支持谁的产品都是支持,怎样能让他们的付出有价值,我开始思考这个问题:利他,成绩他人。

 

3. 业务环境焦灼,我差点被废柴了

 

随着1期期项目发布,我们的产品口碑愈来愈好,大家的成绩感也愈来愈强。

 

有天,对接我们产品的客服同学跟我们说,我们今天接到1个客户来电,客户坚持问了好几遍:“XX产品是否是换产品经理了,做的愈来愈好了。我们历来没有接到过这类电话。”这类喜悦1直以来是产品前进的核心动力。

 

原来无人问津的产品到口碑愈来愈好,想来割韭菜的人自然也来了。初为产品经理的我,没成心识到潜伏的危机,继续豪情高昂的奋战,那时候项目组的人心、凝聚力空前。

 

有1天,我突然接到通知,要作产品复盘。

 

仗着自己的战功,也仗着上下游都有自己人了,没太当回事,直到复盘才知道掉坑里了——所谓的复盘就是产品经理给大佬们汇报,讲产品的定位、计划、目标。

 

被问了几个问题以后,我意想到有人要收割我们的产品,理由是我不称职。

 

整场复盘,本该是我的主场,结果几近没我说话的份,1路在被Diss。

 

想一想这1步步走来,所付出的心力,到当时的成果,在1个复盘会上,被否认到体无完肤,内心是委屈的——虽然我知道这是大佬们的战场,我只是个靶子,当时的内心仍然委屈。

 

当时的老板为了抚慰我,连续几天都来安慰我,现在想一想其实老板当时的压力,比我大多了。

 

这场复盘,终究我活了下来,产品也没有被收割。

 

经历了这1场,我的心力又变的更强大,再高段位的撕逼,都不怕了。

 

后来也确切遇到了更高段位撕逼场合,验证了自己变得更耐撕了。

 

人生的每段经历,都不是平白无故的,有1天,曾所有的经历,都会帮到自己。

 

4. 没有资源、没有资源、没有资源,半年才熬到第1个需求的资源

 

作为新上岗的产品狗,凭仗满腔热忱,对用户需求的深入理解,不断游说4方,渐渐的各方资源进来了;有的大佬还主动帮忙站台去说服其他资源,感激之情无以言表。

 

当时以为以自己的人品、耐力,1定可以弄定全部资源,天真的想法终究败倒在前端资源上。

 

当时全事业部的前端资源极度稀缺,以致于但凡触及前端资源投入的项目都要到事业部业务大佬层面排期,我这新出道的产品汪离的有点远,够不到,但仍然使出了吃奶的劲:

 

第1步,请我的老板、老板的老板和大佬沟通,并且明确要求给出回复时间点,老板们作了充分沟通,但仍然无果。

 

第2步,启动了兜底方案,坐到大佬办公室门口死等。

 

那时我心里已做了最坏的打算,还是不行的话,辞职。由于业务价值已充分论证,各方都已被撬动了,只差东风。

 

以阿里的文化——客户第1,我不信不行,要不就是公司的文化是骗人的。

 

后来还是没等到大佬,只能给大佬发短信,扼要说明业务价值、进展及需要的支持(那时还没有微信)。

 

大佬很快回复了短信,言语中尽是关心和理解,并表示下周1他会发起会议,让相干方到会,让我准备好给大家介绍。

 

——这就是阿里的文化,也正是这样的文化,1直伴随着我以后在阿里的多年时光。

 

第2周的会议如期举行,各方大佬齐坐,我表现的气贯长虹,对答如流;终究大佬们达成1致,先给我们1期项目的资源,但仅限最小的功能,来证明价值。

 

我们只能作项目切割,后来第1期项目发布,产品访问、回访延续拉升,1个小功能带来的访问量比历史所有功能的访问量总和都高,商家好评如潮。

 

我们的产品就这样打爆了,从此以后,资源不再是问题。

 

从决定作这个产品到第1个功能开始开发,用了半年时间,这期间的煎熬,如坐针毡;特别是后来愈来愈多的人开始信任自己,主动投入资源,但自己却不肯定是不是可以给大家1个交代时,内心不好受。

 

小结:产品经理需要强大的心力。

 

作好产品经理,除商业敏感度、逻辑、沟通调和等专业能力以外,需要强大的心力——由于内外部环境随时都在产生变化,怎样样有韧性的坚持,又柔软的改变,再驱动、协同各方的同时,还能保持内核的稳定,需要修炼。

 

也请上下游的每位同学,对产品经理多1些理解,少1些不关紧要的diss,由于产品经理是你最重要的合作火伴。在你diss你的产品经理之前,他可能刚刚被撕,哈哈!大家多1些商业价值的探讨、多1些行业、用户的探讨,多1些实现方案、解决方案的探讨,产品会愈来愈美好。

 

最后,在此再次向曾的战友们、老板们致以最深切的感激。

 

谢谢大家的信任,谢谢大家的担当,谢谢大家的当仁不让,谢谢大家对客户价值的坚持。

 

感谢我们曾的客户,是你们1直在赋予我们气力。

 

作者:水中鱼

微信公众号:菩提产品(ID:putichanpin)

 

 
标签: BI 产品经理
反对 0举报 0 评论 0
 

免责声明:本文仅代表作者个人观点,与乐学笔记(本网)无关。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
    本网站有部分内容均转载自其它媒体,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责,若因作品内容、知识产权、版权和其他问题,请及时提供相关证明等材料并与我们留言联系,本网站将在规定时间内给予删除等相关处理.

  • 为了帮全印度的产品经理简化工作,Innohabit推出云产品管理软件Woises
    为了帮全印度的产品经理简化工作,Innohabit推
    )】10 月11 日报道 (编译:小干果) 目前,正在快速发展创业公司大都是开发了满足大众需求的产品的科技公司。而且无论市场竞争如何激烈,这些公司都需要创造出属于他们自己的USP(独立销售主张)。而Paul Graham提出的“创企=增长”理论也恰恰验证了这一点
  • Teambition的用户增长策略和运营底层逻辑
    Teambition的用户增长策略和运营底层逻辑
    在互联网圈内,企业服务(又称2B类产品)这个市场,一向是个迷局。一方面,总有人在鼓吹企业服务和Saas是个大市场,有无数机会。另一方面,无数人扎到其中之后,真正有所成就的项目和产品却很少,甚至是,很多产品和运营在其中也都做得很纠结。两相比较起来,
  • 售后真的有这么难?Big Boss来救场!
    售后真的有这么难?Big Boss来救场!
    店铺售后问题可谓是最头疼的事情,售后问题如何在不损失利益前提下安抚解决好。没有一些“套路”,如何解决?透析售后问题根本,治标还得先治本,让友谊的小船不再说翻就翻!所谓售后服务,就是在商品出售以后所提供的各种服务。现如今电商,不像以前的传统思
    09-08 顾客快递
  • 谈谈Mobile Web App的设计方法
    谈谈Mobile Web App的设计方法
    [导读]Native App与Web App的争论从未停息过,尽管很多人在批判Web App的各种不是,但也阻止不了各种各样的Web App如雨后春笋般