产品人的野蛮生长感悟(1):新手产品,我想对你说

4 评论 7621 浏览 50 收藏 21 分钟

做产品,“我”不断摸索、不断尝试、不断摔倒、不断振作,一路磕磕绊绊,又勇往直前无所畏惧。这是“我”在产品新人时期的亲身经历,也相信是所有产品人都曾经历的遭遇。

仔细算一算,身上挂着产品经理这个头衔已经快4年有余,今年对于我来说是一个很特殊的年份,一直想为自己的职场做一个节点性的总结分享,从有这个想法到敲下第一个字,已经过去一年,但总归是坐下来,写写心路历程,职场发展一路过来之后的一些观点分享,和业内人士一起交流。

因为人人都是产品经理这个平台上很多人都已经分享过类似产品技能、市场分析、用户分析等等的干货,我在这里就不班门弄斧了,就从自己入行到现在做个分享交流。

我接下来要分享的会根据自己的成长轨迹结合以下几个关键词展开:

  • 整合
  • 推演
  • 量变

我先介绍下自己的发展背景,两年的金融行业产品经理,后进入跨境电商上市企业的研发部门,再从上市企业离开,看似简单的过程其实过程还蛮有戏剧性,也是想通过这个发展轨迹来给跟大家分享一名野生产品经理的野蛮生长过程。

通过这个过程也可以顺便回答有些朋友经常问我的一个问题:产品经理的门槛高不高?

01 产品经理的门槛高不高?

在遇到我的金融IT老东家之前,我经历了一个蛮悲催的半年,但那个不重要的,就从我的老东家开始说起:

老东家的创始团队是从国内金融IT三家上市企业之一出来的管理层,金融IT的业务背景和开发背景都有充足的实力,在我进入这家公司的时候的时候它刚起步不久,我在深圳最窘迫的时候遇到了这家公司。

我的领导,当时的产品总监,面试我只花了十分钟,问了几个相对比较简单问题,当时我也就只知道很粗浅的产品开发流程且很不专业,只是说我会画原型,然后跟UI和开发沟通。

他似乎也不在乎我回答的内容。

后知后觉,是因为他当时很需要人力来补充部门,帮助他分担产品设计的压力,要求不高。

后来将我引荐给CEO面试,反而是这个面试过程非常长,聊了很久,最后是他的一句话让我选择加入这家公司,他说:“任何时代都离不开金融,加入我们一起成长吧”

因为CEO在业内的关系,这家公司一起步就可以跟国内顶尖的券商合作,做券商的系统建设。

(这里划下重点!后面会说到这个细节为我整个职场方向埋下了伏笔。)

但当时他们可能是因为需求不明确或者是首次合作配合的原因吧,已经有一个项目是宣告失败的。

我当时很长一段时间都是在打杂,帮我的领导画画图,然后我领导会给我讲解行业的现状还有公司业务的相关方向。

当时很大部分我是听不懂的,没什么概念,只能靠自己的生活经验去串联一些知识点,到之后很长一段时间我回味起来才发现背后整个业务体系的复杂程度。

当时这个核心项目并没有真正做起来,我虽然没有完整参与过这个项目,但通过后来有支援一些需求和参与方案讨论,我自己总结项目失败的原因可能就是应用场景分析不够投透彻和过于理想化。

这也是我后面会说到的,构建一个产品,除了理想化更多还是需要阶段性的迭代策略和充分的市场分析,一口吃出一个胖子几乎是不可能的。

回归到我刚入职的时候,我领导给了我他画的原型和写的文档,让我自己去看,去理解,其实那时候真的看不懂,但就是强迫自己去适应。

在经历了一段时间的摸索后,我们接到了这家券商的第二个项目,而且这个项目还是一个比较大的需求业务,TO B和TO C都涵盖在里面,现在这个项目挂在了券商的官网下面,也是这个项目,真正起步了我的金融产品生涯,而且碰的是金融行业的核心部分。

当时我的领导也没设计过同类的产品,我们就边摸索边做,但也是这个0-1的过程,暴露了我的短板——非技术出身,没有系统的产品设计技能,每天面对各种各样的批评和嫌弃,原型不断改,文档永远不够细。

大概有半年的时间,非常的高压,经常性失眠……

这个项目从0-1的过程虽然蛮煎熬,但就是这个煎熬的过程让我慢慢理解前后端的设计原理,去尝试分析应用场景,同时通过设计产品挖掘了背后的业务知识。

我的领导会用他的经验引导下我,我不是拿来即用,但他的经验非常关键,给了我举一反三的“一”。

而且我们都非常喜欢写写画画,先在纸上记录,在纸上确定至少百分之八十以上了才会在电脑上启动工作,但很多东西,现在我回头去看都不知道我当时在想什么,在这里放出我以前的一些随手笔记,见笑了。

相信大家并不知道写什么,我自己都想不清楚我当时是在想什么,不过这种方式确实可以快速整理思路。

通过这种方式初步形成了自己的设计思维,把零散的思路通过这种方式进行整合组装,形成整体方案,最终将项目落地。

这种习惯从那时候开始一直沿用到现在。

当然这个只是我的个人习惯,每个人的习惯方式不同,产品经理应该都需要有一种能把自己零散思路整合起来的方式,形成自己的一套方法论非常重要。随着时间推移逐步完善,那将成为你职场安身立命的法宝。

02 做产品或需求方案的基本思路

我总结我下手做产品或者一个单独的需求方案时的基本思路:

抓主线>>分点扩散>>过滤>>推演>>整合

用我最早做的券商系统来简单举个例子,实际上这个产品是一个长期项目,在我离开时,甚至还在迭代需求,但是都是围绕着我们一开始定下的主业务线在进行:

1. 业务主线

所谓抓主线就是明确眼前要做的这个事情,他的主业务是要做什么?

比如说,当时我们做的这个产品,是应行业政策的需求构建一个信披系统,那业务主线就是披露相关的业务信息,问题来了:

  1. 披露什么信息?
  2. 怎么披露?
  3. 向谁披露?

看似三个问题,其实每个问题背后一延伸,一堆的需求就来了,比如:

然后就是开始介入业务层面去调研需求(除了业务需求,我前后端产品设计思维就是在这个过程逐渐形成)开始扩散,并且构思这个产品要怎么设计,TO C的场景和TO B的场景融合在一起,对逻辑性要求还是挺高的,要顺着这个业务体系去了解)。

2. 业务扩散过程

这个扩散的过程其实就是不断在问问题、然后会发现更多的问题,不断在找答案。你不去深挖思考,你不会知道:

  • 券商、银行、基金公司、投资者之间的关系;
  • 私募基金投资合同的约定规则
  • 一级市场、二级市场是什么概念
  • 基金的估值、投资者的持仓份额是怎么一回事?
  • 认申赎的流程、冷静期的概念等等…

好玩就好玩在,可能一个需求,背后是一整套业务体系,这是个不断在做加法的过程,业务知识、对需求的理解程度、传统软件的设计原理、甚至写文档的细致程度都在逐步提高,你会发现这种感觉像打游戏升级一样,所谓的产品经理的业务水平在这种过程中逐渐产生的!

3. 业务点过滤

接着开始过滤我们需要去落地这个项目所需具备的业务点,也就回归到之前我们提出的那个三个问题,去找答案:

  • 明确用户的身份验证规则;
  • 明确数据来源;
  • 明确披露设置规则;
  • 明确需对接的外部系统有哪些,分别需要获取什么数据;

同时过滤掉多余的业务点,多余的设计想法。

4. 产品推演

通常经过需求扩散和过滤之后,基本上所有的业务流程都出来了,就这个项目来说:

  • 用户的身份验证流程(高净值用户的身份验证较普通的用户);
  • 信息披露的设置流程;
  • 外部系统交互流程;
  • 用户所视数据要素及使用功能;

基本上就都出来了,然后我会开始做推演,这里所说的推演是,我会代入角色,按照设计思路把各个业务流程或者说是场景在自己脑海里反复模拟。

其实这个流程细化下去,有很多的东西可以分享,但是这次想借职场经历来传达一些感悟,工作方法的细节后面有机会我会再细写出来分享交流。

03 重视量变过程

现在看回去,其实那时候已经开始有一个体系化的过程。

我个人认为,一个从0到1的项目,不管大小,对产品经理的角色来说,是一个既考验能力又积累经验的机会。

现在很多产品经理入行可能0-1的机会会比较少,我当时接手这个项目,能力跟这个项目是不匹配的,但幸得当时领导给了空间和时间,同时他非常清楚我面对的情况,在心里预留一定的试错成本,我们就这么配合设计了整个项目。

除了产品设计本身,在开发各个环节的沟通和把控上逐渐积累经验,开始介入项目化运作的整体流程。

一次因为一个需求的设计问题,开发部门的老前辈直接就甩脸,几轮下来我也失去了耐心,彼此闹着不愉快,有天中午碰巧一起去吃饭,排着队,就聊了起来,他告诉我:“你尝试着从后往前推,不要只关注前面”。

这句话可能有点抽象,用现在流行的话来说就是,需要细细地品,慢慢地品!

我也是后知后觉,他的意思是希望我从底层功能规划上去推理产品设计,不是只从用户角度或者单纯的页面功能来设计。

这个点很重要!

我不懂代码,但随着日积月累的技术评审,我懂了技术概念,后来我设计功能的时候,会站在开发的角度去思考,如何便捷开发,同时又贴合需求,目前设计的东西需要底层怎么支撑。

后来经历过几个开发小组,我几乎不存在跟开发吵得不可开交的时候,评审沟通过程都相对比较高效,给到开发人员他们也基本明确我想要怎么做,或者他们提出矛盾点的时候,我可以很快速想到另外的方案对应。

得益于在当时,技术部门的前辈们愿意花时间跟我解释实现方式的原理,解释某些功能没那么容易实现的原因,同时给我一些设计思路。

当时是没有意识到这些零散的内容会对我后面的发展起到很重要的作用,庆幸的是,我用心听了!

你的经验,你的知识,可能来自于一次会议,可能是前辈的某句话,可能是他的方法论分享,或者是自己踩过的坑总结出来的。

我称之为——量变。

这个量变是储备能量的过程,这个过程,你就要学习业务知识、积累实操经验,去踩坑、去犯错——不要怕犯错,关键是不要重复犯同样的错误。

然后懂得总结,学会阶段性总结会加速你形成自己的经验储备——我之前没有做到,如果我从那时候开始就养成做阶段性总结的习惯,我相信可以再加速我的成长节奏。

回应回我前文所说的,这个创始团队的背景对我的影响:

平均年龄大我10岁以上,因为他们积累很多年的经验,同时在业内具备了一定的资源,对整个行业有自己的思考和摸索方向。

我进入这个团队,我就得适应他们的节奏和氛围,学会跟他们一样去思考,这就是野蛮生长的魅力。

无形中一个团队不断在拉高你的认知水平和业务水准,他们给你的经验所得不一定都对,但是一定有它产生的理由所在,没有人专门带过我,但其实又每个人都在无形中带过我。

我就这么吃着“百家饭”,前后帮这家券商落地了5个项目。

就目前我对自己的认知,如果进入其他行业我可能也不会比现在差,但是说在IT行业或者说是在产品这条路上我目前还算稍稍做出了点小成绩被认可的话,那一定是得益于遇到这帮前辈和这家券商的项目。

所谓站在巨人的肩膀看世界,看到的世界是不一样的,我这个比喻不知道对不对,但是跟着业务水平和做事态度都在线的团队,对我们自己的沉淀和对事物的思考上,都会产生不一样的效果。

跟着公司从10多人到60号人,再后来因为种种原因去了上市公司做研发,再从上市公司离开…

不知不觉已过4个年头。这一路过来有得有失,黯然自卑过、骄傲自负过、冷静反省过、深度规划过。

现在开始回过头整理之前的东西,可能还需要些许时间,然后加上自己很久没写过文章了,也不知道自己写得好不好,大家多多指点批评。

那通过这第一篇文章,我想回答很多人问过我的问题,在前文提到的——产品经理的门槛高不高?

我的回答是,说高也高、说不高也不高!

我介绍了我入行的项目经历和初步的发展轨迹,其实想表达的就是:

让产品经理安身立命的一定不是你的原型画得多好,你的文档写得多漂亮,而是业务水平思维方式。

这里的业务水平指的是对行业业务的了解程度和专业知识储备量,思维方式就是你已经形成对产品的商业价值和应用场景有一套自己的分析模型。

这两者都是需要时间和自我历练去获取的。

我入行的时候,我的领导就跟我说:

“金融IT行业培养一个产品经理,智商再高都至少需要两年。”

我现在是明白这句话的意义所在了——

成就一个产品经理的,可能是平台、可能是团队、可能是他以往的教育给他自己形成的方式方法、很多种因素!

总结到最后其实就是两点——机遇跟自己!

所以,成为一名优秀的产品经理,实际上门槛是不低的,这里面涉及到主观客观种种原因。

那为什么说不高?

因为产品经理没有任何一个学科专业定义——

对产品技能有认知后,任何人都有机会可以成为产品经理,原型不会可以学、计算机知识不会可以学、文档写多了自然也就很熟练了、人跟人之间的沟通也不是什么太大的问题。

每个人都有这种潜力成为产品经理,当你的技能广度足够的时候,成为一名产品经理是一件很轻松的事情。

为我自己第一篇文章做个总结——写给新入行或者初级产品经理的一些感悟:

要有挖掘业务纵深的耐心,积累技能广度的意识,你不知道哪个机会会让你爆发性成长,你也不知道哪个机会会为你的发展起到关键性的因素。

因此,把每个机会都当做做一次成长,抓住每个可能是机会的机会,最后量变起来之后,你会发现你的强大!

遇到问题——分析问题——解决问题,我今年经常跟我的伙伴说起这12个字。

这12个字,其实蕴含着我们需要充足的耐心以及面对问题的正面态度,这些才是成长的关键!

 

本文由 @WilliamWu 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 学到了!谢谢您

    回复
  2. 遇到问题,分析问题,解决问题,我往往忽略分析,老想着直接去结局,却忘了重要的理智的分析总结,很厉害👍

    回复
  3. 感谢作者大大的分享,读到这篇文章的您,

    如果想具备系统产品知识技能,
    有一套体系化的个人项目作品,
    去工作和求职,都更加的顺畅!

    那体系化的学习训练就很有必要,
    点这里,先看看公开课: http://996.pm/7GVQ4

    回复
  4. 写的很好,很赞,学习了。

    回复