【作者丨Buff先生  】

【来源公众号丨Buff先生】

【编辑丨善小花】

毕业一年从游戏行业转行直播行业，从游戏运营转职产品经理，不管从行业还是职业跨度相对较大，不过到目前为止一切都还算顺利，从入职到现在两个月时间，刚好小组有新项目在开展，所以最近两个月相对比较忙，今天刚好有空记录下两个月来的一些想法。

一、不断去经历，去丰富自己

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

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

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

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

亲身经历一些事情，跟作为一个旁观者了解到的东西是完全不一样的，这些经历也许会在未来成为你不可复刻的优势，对于职场新人来说，更应该如此，让自己不断去经历，去变得更丰富。

二、学会读懂上司话中背后的意思

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

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

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

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

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

三、关于产品需求

最后想聊聊从事产品经理职位两个月来对产品需求的一点感受。

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

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

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

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

可行性测试：在产品说明文档定稿之前一定不要跳过技术，我自己就吃了这方面的亏，当时在做产品需求文档定稿的时候，完全就是产品、运营讨论确定好就拿去给技术进行排期开发，等到技术看到需求文档的时候，才发现有一些技术根本实现不了，最终只能重新修改需求，重新定稿，导致进度被迫拖慢。所以在产品需求文档的评审阶段就应该邀请技术负责人或架构师一起进行讨论，他们最清楚最新的技术，了解哪些技术存在可行性风险，帮助我们在做产品决策的时候提供更好技术解决方案。

2、如何正确提需求

正好两个室友也是程序员，上次闲暇时间也跟他们一起探讨了关于产品需求的话题。

①需求文档一定要周全、细致

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

产品可能只关注这项功能需要给用户展示什么样的内容，而技术会考虑到网络稳定、断网的情况分别给用户展示什么内容，什么提示。
又或者产品只考虑到用户的某项数据指标需要做什么样的处理，而技术会考虑到数据指标有值、空值的情况需要分别做怎样的处理。

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

②让技术感知到需求的紧急程度

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

A、跟技术讲清楚需求急的原因，是急着上线，还是需要配合其他功能的实现，让技术明白为什么急。

B、跟技术约定好完成时间，一定是一个确切的时间，而不是“下星期”、“下个月”之类的，只有让对方做了口头承诺，才会迫使他们去兑现承诺。

C、多跟进需求的进度，每天上班主动跟技术了解进度，了解是否有遇到什么问题导致开发停滞，技术的日程计划等等，下班之后再次了解今天一天的进度，你只有多跟进才会让技术感知你的需求重要紧急程度，当然也要适当跟进，不要让技术觉得你很烦。

③避免修改需求

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

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