0~2岁的产品经理该如何提高软实力?

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

近几年,产品经理岗位火热的一塌糊涂,受到了越来越多的应届生和互联网其他岗位朋友的追捧。好的产品经理在企业中的重要程度不言而喻,他是需求的发起者、项目的推进者、团队沟通的桥梁、企业发展的舵盘。

chanpjingli

然而,由于产品经理岗位没有行业认可的准入机制,产品经理技能也没有很好的量化考核标准,所以对于相当一部分产品经理,他们并不知道自己该如何发展,或者是该重点培养哪些特质。一般来讲,从业时间长了,产品经理们自然就会形成一套自己的方法论。

但是,在最初、最迷茫的前两年,初级产品经理应该主要把精力放在哪些软实力的提高上呢?或者说产品经理岗位要求千千万,应该优先做好哪些呢?

结合个人经历,我觉得有如下几点。

1. 学习

知识是无止境的,要学的东西也有很多,做到了学习这一步,至少能够给自己养成一个很好的习惯,并且在陌生环境下,可以迅速切入,而不至于前几天傻傻的不知道干嘛。

学习业务逻辑

不论是应届生,还是社招的产品经理,快速的学习、熟悉新公司的业务逻辑都是必须经历的过程。作为产品新人,一定要学会从产品文档出发,快速准确的理解产品上层和底层逻辑、产品架构、人员分配等一系列相关问题。在使用的过程中发现“改进点”,初步了解完业务之后,再搞清楚这些所谓的“改进点”背后的原因。并不是其他产品都是傻瓜,不能发现问题,可能是这样或那样的限制使然,搞清楚历史原因、弄明白上下文,才更容易有的放矢。

作为一个新人,能深入了解自己负责的部分、吃透里面的逻辑和规则是基础中的基础。足够了解业务后,自己的意见和建议才更有说服力。尽量不要出现下面这样的情况:

“我觉得XX功能应该这样这样优化”

“这个由于系统限制,现有方案是讨论当前出来的最优解”

(或者“这个是因为怎样怎样的数据存储,导致只能用这样的方式,否则改动起来成本太大,得不偿失”)

“哦……”

学习优秀的特质

不是每个新人都会有导师带的,也不要指望有人能够像老师一样一点点指导你。如果你在你看来,周围的人都不如你,那么趁早离职(我不奢望这种情况下,你还能去发现“美”)。如果在你看来,周围有更优秀的人,他身上的某些特质你希望拥有,那就去学。

别人的特质可能是做事态度,可能是思考的过程,可能是看问题的角度,可能是说话的方式,等等。这些东西能学多少就学多少,只要你觉得你学来了之后对你有好处就行。

2. 执行

大多数产品新人都是从产品助理或者专员做起,这时候的主要任务就是执行。所谓执行,不光指别人让你做什么就做什么,也包含了你做了类似改进需求之后不敢做主,需要老大确认才能做的事。

当老大交给你工作的时候,他要的是结果。但过程怎样决定了你能收获多少东西,你是呆萌的老老实实去完成,还是自己思考其中的原因,而且尝试在心里提个B方案,这都是由你决定的。

有时候,虽然结果都是加了个弹窗,但你既可以理解为就是加了个弹窗,也可以理解为需要考虑为什么加这个弹窗、弹窗的场景合不合适、会不会造成打扰、能不能满足需求、有没有其他弹窗会同时出现、出现之后是怎样的优先顺序、为什么弹窗就要比Toast好、为什么文案要这么写、为什么按钮要这么摆,想过一遍之后,还是加了一个弹窗,但对你个人的成长却是不一样的。(当然,大多数情况,老大也没想后面的东西,就是加了个弹窗而已,但对你有任何影响么?)

产品经理的工作内容本来就很杂,作为助理会更杂。你可能会接到很多莫名其妙、乱七八糟的事情需要执行。我建议尽量去执行,将执行做到极致。

比如一个公认的历史遗留的老大难问题,完全没有文档、之前的开发离职了,只能拜托另一个开发从代码层面重新梳理文档。这时候的你肯定是头疼不已、叫苦不迭,这种工作既费时、又费力,而且是梳理现有逻辑,完成之后老大也未必觉得你优秀,还可能遭开发大哥的白眼,但还是要要求自己执行好,只有完成一件事情,才有可能承担更多的事情。

比如让你去收集、整理、答复用户反馈,解决用户问题,这看上去好像是运营的工作,但还是要要求自己执行好,倾听用户声音、挖掘用户需求,才能更好的理解产品、改进产品。

比如让你找财务帮助部门报销,或者和法务沟通对外合同,你可能觉得这是运营助理做的事情,但既然落在你头上了,也只能要求自己执行好。(当时的我尝试和老大沟通,拒绝执行这件事,因为我觉得超出了产品工作范围,然而由于老大的强势和我之前没有给他留下做好初级产品经理的印象,导致我最后还是执行这件事了。至今我都觉得不该我做,不过类似问题大家仁者见仁智者见智吧)。

总结起来两句话,一是只有将执行做到了极致的人,才是最优秀的产品助理,二是不论多难啃的骨头,能把它嚼碎了、咽下去的人,才能有大发展。

3. 沟通

对一个新人来说,学会有效沟通非常重要。

描述需求

有好多新人,描述需求的时候吞吞吐吐,其实也不是因为紧张,但就是无法准确的表达想要说的东西,周围人听着听着就有一种你在说TMD什么的感觉。

这种时候,一定要想清楚了再说,哪怕别人问起来,你回答:我先理一理再说,也好过说一堆不知所云夹杂着明显的逻辑漏洞的东西好。这也侧面证明了刚才说的学习的重要性,先把自己负责的东西搞清楚,看看别人说需求的时候是什么逻辑、什么层次,慢慢模仿,多多练习。

交流

产品人员参与头脑风暴类的会议应该很多,在沟通一件事情时能够首先发言、抛砖引玉固然好,但是也尽量将问题说到点上。虽然网上好多人都说新人不要怕说错话,别人会理解你,可是也不要南辕北辙。有时候新人的出发点本身就错了,如果团队里糊涂的人居多,那就会把一件事“成功”的带歪,所以先想想事情的前因、背景、大环境、可行性,再表态。一方面多学学别人看问题的角度,另一方面也在大脑中提炼自己要表达的东西,然后争取说个八九不离十。

组内开会如此,与人小范围沟通也是一个道理。想明白自己的立场和要说的东西,再进行沟通,清晰、简洁的把问题描述清楚,可以给双方节省不少成本。

沟通,无它,多想,多说。

4. 积累

别人的亮点

积累在产品生涯初期能显出更大的效果。0~2岁的产品经理看看竞品、写写报告是常有的事,在看其他产品的时候,把能够打动自己的东西记录下来,它可以是个文案、登录窗样式、交互方式甚至是一段更新日志,将来它们有可能成为你需求的背书。

比如你提了个什么需求,开发说没有这样交互的,你就可以说谁和谁是这样做的。比如你提了个什么需求,开发说没法实现,你就可以说为啥别人能实现。说白了,积累别人的亮点,可以让你随时都有的抄,但是积累的多了,运用的熟练了,这就是你自己的东西了。

需求文档

需求做多了就发现脑子越来越不好使,明明自己做的东西就是死活想不起来逻辑了,这时候就需要翻阅之前的需求文档了。
我个人的建议是,每一版做了什么改动要记录下来不论对外更新还是对内说明,每一版对应的需求文档好好保存(包括原型、效果图等等)。

假如某个功能模块迭代了4、5版,要定期回顾需求改动,反思自己前几版为什么没这么做,或者为什么把之前的改动又回滚了,中间发生了什么、原因是什么。这种定期回顾和反思,有助于让你明确之前出现的漏洞,容易总结各种各样的坑。

总结

除了上面说的之外,我个人觉得“向上汇报、管理上级、积极主动、良好心态、项目管理、发散思维、行业理解、数据分析”这些也都很重要,但并不普适,所以也就不加在这篇文章里了,有机会可以单独再说。

这篇文章里的好多“比如”都是发生在我或者我周围的例子,虽然我写出来了,但并不代表我做的很好。同样道理,大家看完了也未必真的有用,但是可以当作迷茫时的一个参考。有太多人知道很多道理,但依旧过不好这一生。

做到并且做好了上述几项,一定能成为优秀的产品助理甚至产品经理,但是后面的路还有很长,希望大家可以一起进步。

PS 1:写的主要是宏观维度,具体如何做写的不多,大家参考即可。切记,别把手段当目的。

PS 2:文章图片来源于Pixabay,一个很好的免版权网站。

PS 3:谢谢阅读。

 

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

您的赞赏,是对我创作的最大鼓励。

评论( 3

登录后参与评论
  1. 产品新人,你说的这些问题,确实都遇到过。

    回复
  2. :?: :!: :?:

    回复
  3. :razz:

    回复
加载中