欢迎光临
我们一直在努力

转行两个月,作为产品经理的一些感想

11 转行两个月,作为产品经理的一些感想

一、学会验证需求和正确提需求

产品经理的核心工作是发现问题和解决问题的过程,也就是挖掘需求和实现需求的过程,挖掘到新的产品需求,首先要做的是对需求从价值、可用性、可行性进行验证,只有需求通过验证,才开始部署产品,安排技术开发。

1、证明产品的价值、可行性、可用性

这一点也是我最近读了《启示录》这本书后感受比较深刻的,在正式开发产品之前要先进行产品验证,证明产品的可用性、可行性、有价值性,不要盲目自信地等到产品开发出来再进行测试,产品一旦开发出来进行较大的改动基本是不可能的,所以一定要在产品开发之前就做好产品验证的工作。

(1)可用性测试

需要交互设计师和产品经理密切合作,设计出符合用户习惯,或者改良用户习惯的产品,让用户知道怎么使用产品,当然有些公司可能没有交互设计师只有产品经理,所以这就要求产品经理要多去提升这方面的能力。

(2)有价值性测试

设计出来的新产品是否解决了用户的需求痛点?是否让用户渴望去使用?如果用户使用了之后仍然选择使用其他竞品,说明产品还不合格,在进行开发之前,可以先提前制作高保真的产品原型,邀请十个左右的目标用户群体进行测试,验证产品的创意、价值,只有用户真正喜欢并且渴望去使用的产品才值得进一步开发。

(3)可行性测试

在产品说明文档定稿之前一定不要跳过技术,我自己就吃了这方面的亏,当时在做产品需求文档定稿的时候,完全就是产品、运营讨论确定好就拿去给技术进行排期开发,等到技术看到需求文档的时候,才发现有一些技术根本实现不了,最终只能重新修改需求,重新定稿,导致进度被迫拖慢。

所以在产品需求文档的评审阶段,我们就应该邀请技术负责人或架构师一起进行讨论。因为他们最清楚最新的技术,了解哪些技术存在可行性风险,帮助我们在做产品决策的时候提供更好技术解决方案。

2、撰写产品需求文档安排开发

正好两位室友也是程序员,上次闲暇的时候跟他们一起探讨了关于产品需求的话题。作为产品经理要懂得怎么跪研发,如何写出一份好的产品文档。

(1)需求文档要尽量周全、细致

技术是执行、产品是策划,技术在开发的时候需要考虑到事件所有可能发生的情况,不然代码就很容易出bug,而产品经理的思维有时只关注到他们想要达到的结果,而忽略了其他可能的状况,比如:

产品可能只关注这项功能需要给用户展示什么样的内容,而技术会考虑到网络稳定、断网的情况分别给用户展示什么内容,什么提示。

又或者产品只考虑到用户的某项数据指标需要做什么样的处理,而技术会考虑到数据指标有值、空值的情况需要分别做怎样的处理。

所以在写需求文档的时候,多站在技术的角度上思考问题,尽可能详细地阐述所有可能出现的状况,并分别给出解决方案。

(2)让技术感知到需求的紧急程度

在技术的心中他们有自己的紧急排行榜,可能是按产品经理的性别、颜值进行排名的,也可能是按需求方的职级排名的,所以如果你的需求特别急的时候,要让技术感知到。

  1. 跟技术讲清楚需求急的原因,是急着上线,还是需要配合其他功能的实现,让技术明白为什么急。
  2. 跟技术约定好完成时间,一定是一个确切的时间,而不是“下星期”、“下个月”之类的,只有让对方做了口头承诺,才会迫使他们去兑现承诺。
  3. 多跟进需求的进度,每天上班主动跟技术了解进度,了解是否有遇到什么问题导致开发停滞,技术的日程计划等等,下班之后再次了解今天一天的进度,你只有多跟进才会让技术感知你的需求重要紧急程度,当然也要适当跟进,不要让技术觉得你很烦。

(3)避免开发中途修改需求

开发中途修改需求是技术的大忌,因为可能意味着做出来的东西需要全部推翻重来,所以能不改需求一定不要改,先思考有没有其他解决方案同样可以实现,迫不得已才改需求,很多情况下更改需求的根本原因在于定稿的时候没有确定清楚,特别注意要在定稿前跟所有相关的人员(尤其是老板)确定清楚需求才开始跟技术排期开发。

同时,需求中待确定的地方要标记出来,不然技术会按照他们的想法去实现,到时候再要求更改也是很不好的。

二、学会读懂产品上司的话

工作中,经常会遇到这种情况,上司跟你说某产品的新出的特色功能做的不错,然后让你看看如何在我们的产品中也加入这样的功能。于是你开始研究这个特色功能,觉得效果确实很不错,然后开始按照老大的建议加入了差不多的功能,等到功能上线后,才发现得不到预期的效果,最后只能无奈砍掉了辛辛苦苦做出来的东西。

这个时候你应该埋怨老大的建议不合理吗?当然不是,因为背锅的永远是做执行的……在开始执行之前应该先读懂上司话中背后的意思。

简单分析下背景情况:一般上司是要背负KPI的,可能是产品的DAU、用户付费率、营收、营收离散化等等,而且上司日理万机,主要承担统筹把控的角色,所以在产品的细节方面上可能没有我们了解的更深入。

因此上司提出了增加新功能的建议,并不是真的觉得这个功能好玩,可以借鉴一下,而是因为上司看到了该功能在产品某方面,如在DAU上有不错的表现,对完成我们的产品DAU的KPI可能有所帮助,但是由于上司对自身产品细节的了解并不是很深入,所以有时候提出的建议合理性是需要评估的,所以这个时候就需要我们去仔细分析上司的目的,以及我们如何达到这个目的,即使你最终分析出来的结果完全反驳了上司的建议,提出了完全不同的产品方案,但也好过做出一个没有价值的产品。

读懂产品上司的话能帮助你找到工作的正确方向,更有目的性地完成工作,避免耗费了大量的精力、资源却最终却以失败告终的情况,先三思而后行,真正优秀的人是花70%的时间在思考问题上,30%的时间在思考方案上,先思考事件的本质意义,然后才开始付诸行动,不要急于一时,特别是在高成本的事情上。

三、产品新人应该多去经历,丰富自己

扎实的专业知识通过努力还是可以达到的,但是经验这种东西,如果你没有真正参与到一件事情中,就像纸上谈兵,你永远不知道前方的路会有什么样的坑,尽管你做了万全的准备,还是会出现你意想不到的坑。

一个真实的案例:之前A直播平台邀请了重量级的明星B入驻直播平台进行开播,在活动之前,平台对此次活动做了大量的宣传,运营经理也对此次活动做了充分的准备,所有能想到的应急措施、补救方案基本都已准备好,正当所有事项都准备就绪开始明星B的直播时,这个时候明星B却由于家里网络问题无法进行直播,导致活动过程中技术花了三个钟在修复网络问题上,几十上百万的粉丝和观众干巴巴地见证了这尴尬的场面。

谁都没想到,在活动开始之前,明星B家里的网络受到直播平台竞争对手的恶意攻击。

过去一年从事游戏运营的经历,接触到的工作领域还算挺多的,包括产品调优、活动策划、用户运营、社区运营等,甚至有时候由于合作同事忙不过来,还需要帮忙分担一些分外的工作,虽然我觉得工作分工明确是有必要的,但特殊情况下,为了结果导向,为了一起把一件事情做好,可以在自己的能力承受范围内适当的帮助团队伙伴,不要急着划清界限,让自己多去接触更多的东西,这未尝不是一件好事。

亲身经历一些事情,跟作为一个旁观者了解到的东西是完全不一样的,这些经历也许会在未来成为你不可复刻的优势。对于产品新人来说更是如此,踩一个坑就少一个坑,多去经历,丰富自己,这样才能在未来中运筹帷幄,做出更有价值的产品决策。

文章就写到这里,以上是自己转行产品经理两个月来的一些心得和感受,作为产品新人,前方任重而道远,但同时也对新的行业、新的职业充满好奇和动力,希望在未来可以跟大家多多交流,一同进步~

 

作者:Buff先生

来源:人人都是产品经理

赞(0)
未经允许不得转载:电商之家 » 转行两个月,作为产品经理的一些感想

登录

找回密码

注册