0°

转行入职满一个月的产品经理思考与总结

文 | 刀刀


算下来截止我开始动笔写这篇文字之时,刚好在产品经理这个坑里干了一个月时间。但是不是一位职场新人,所以就结合之前岗位的工作经验和现在的工作体会,做一点点分享。


入职的是一家小型互联网公司,公司虽小,但是五脏俱全。产品岗、设计岗、前端、后端、测试和客服应有具有。在这一个月的时间里,已经完成了两个迭代的规划。 虽然都是小功能迭代,但也可以一寇探产品经理这个岗位所做的事情、站的角度和流程。


在第一个迭代的过程中,由于初涉产品规划,所以在定了大概的需求方向后,召集设计、前端、后端开了一个需求讨论会,目的是集思广益。在大方向拟定的情况下,大家讨论一些设计的可行性,由于该迭代的需求,在技术没有什么难度,主要考虑的是迭代升级后对用户使用习惯的影响和接受度。 但是发现在需求讨论的过程中,大家各种想法和意见,很难达成一致。最终还是Boss和产品经敲定了具体细节。


会后,我的感悟就是产品经理一定要带节奏,不能被设计和研发把节奏带偏。如果讨论话题走偏后,产品经理要及时的把话题拉回到本次讨论的需求上面来,不然大家你一句他一言,发散性的就扯的很远。如果有Boss参与,那么尽可能让boss在听清楚各种分析后作出拍板,如果Boss不做拍板,那么产品经理就要及时拍板或者引导Boss拍板。不然,靠大家一致讨论而得出一个结果来,会很难。


还有一个现象,应该在很多公司都存在,就是其他职位的人的做法比产品经理还产品经理,提议或建议、从各个角度来告诉你,你这里应该怎样规划和设计,应该怎样提供一个功能。 刚开始我差点跳进了他们的坑里。仔细分析他们提出的想法和建议,在我们产品本次迭代中都是属于中等或者低级别,可做可不做的需求,所以在这种情况下,产品经理一定要控制,不要一口答应可以做或者马上改PRD。这样会直接导致你需求规划延期或者要重新评审需求。


在这里,我们应该把握一个度,比如他们建议的需求是否是核心需求,没有该功能,是否本次迭代上线就没有意义。如果是这样,那就必须加了,即使调整产品计划也要增加该需求。另一方面,如果在本次规划中,某一个需求点实现难度较高,需要钻研一段时间技术才可能实现。这样的需求需要评估是否会影响项目进度和强需求。如果不是,可以转入技术预研,在后面的迭代中实现。除此之外,建议或者反馈上来的需求统一收纳归类,并声明你们的建议和想法都用个小本本记下来了,在后续迭代中统一考虑。


理论上,产品经理是需求的规划者和决策者,所以在产品的整个开发过程中,一定要培养产品团队成员认可你决策和归你决策的影响力。不然,会一直被牵着鼻子走,自己的甚至会处于救火之中,那么怎么还会有精力思考规划更好的产品呢。


同时,我自身体会到一个细节,就是在开产品讨论会还是产品需求评审会的过程中,一般是边阅览PRD或者脑图,边讲解和答疑。产品团队里的成员一般都是坐着在听和讨论。但是产品经理是这个会议的组着这和引领者,所以我建议产品经理在讲解和答疑的过程中,最好是站着进行,这样吐纳顺畅、声音洪亮、思辨能力较快。会对评审过程有不错的引导和控制效果。


一点点小小的感受,毕竟在这个职位上工作的时间还比较短,有兴趣的小伙伴们可以后台留言,一起探讨产品经理的工作方法和流程。


「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论