一、学会验证需求和正确提需求
产品经理的核心工作是发现问题和解决问题的过程，也就是挖掘需求和实现需求的过程，挖掘到新的产品需求，首先要做的是对需求从价值、可用性、可行性进行验证，只有需求通过验证，才开始部署产品，安排技术开发。
1、证明产品的价值、可行性、可用性
这一点也是我最近读了《启示录》这本书后感受比较深刻的，在正式开发产品之前要先进行产品验证，证明产品的可用性、可行性、有价值性，不要盲目自信地等到产品开发出来再进行测试，产品一旦开发出来进行较大的改动基本是不可能的，所以一定要在产品开发之前就做好产品验证的工作。
（1）可用性测试
需要交互设计师和产品经理密切合作，设计出符合用户习惯，或者改良用户习惯的产品，让用户知道怎么使用产品，当然有些公司可能没有交互设计师只有产品经理，所以这就要求产品经理要多去提升这方面的能力。
（2）有价值性测试
设计出来的新产品是否解决了用户的需求痛点？是否让用户渴望去使用？如果用户使用了之后仍然选择使用其他竞品，说明产品还不合格，在进行开发之前，可以先提前制作高保真的产品原型，邀请十个左右的目标用户群体进行测试，验证产品的创意、价值，只有用户真正喜欢并且渴望去使用的产品才值得进一步开发。
（3）可行性测试
在产品说明文档定稿之前一定不要跳过技术，我自己就吃了这方面的亏，当时在做产品需求文档定稿的时候，完全就是产品、运营讨论确定好就拿去给技术进行排期开发，等到技术看到需求文档的时候，才发现有一些技术根本实现不了，最终只能重新修改需求，重新定稿，导致进度被迫拖慢。
所以在产品需求文档的评审阶段，我们就应该邀请技术负责人或架构师一起进行讨论。因为他们最清楚最新的技术，了解哪些技术存在可行性风险，帮助我们在做产品决策的时候提供更好技术解决方案。
2、撰写产品需求文档安排开发
正好两位室友也是程序员，上次闲暇的时候跟他们一起探讨了关于产品需求的话题。作为产品经理要懂得怎么跪研发，如何写出一份好的产品文档。
（1）需求文档要尽量周全、细致
技术是执行、产品是策划，技术在开发的时候需要考虑到事件所有可能发生的情况，不然代码就很容易出bug，而产品经理的思维有时只关注到他们想要达到的结果，而忽略了其他可能的状况，比如：
产品可能只关注这项功能需要给用户展示什么样的内容，而技术会考虑到网络稳定、断网的情况分别给用户展示什么内容，什么提示。
又或者产品只考虑到用户的某项数据指标需要做什么样的处理，而技术会考虑到数据指标有值、空值的情况需要分别做怎样的处理。
所以在写需求文档的时候，多站在技术的角度上思考问题，尽可能详细地阐述所有可能出现的状况，并分别给出解决方案。
（2）让技术感知到需求的紧急程度
在技术的心中他们有自己的紧急排行榜，可能是按产品经理的性别、颜值进行排名的，也可能是按需求方的职级排名的，所以如果你的需求特别急的时候，要让技术感知到。
- 跟技术讲清楚需求急的原因，是急着上线，还是需要配合其他功能的实现，让技术明白为什么急。
- 跟技术约定好完成时间，一定是一个确切的时间，而不是“下星期”、“下个月”之类的，只有让对方做了口头承诺，才会迫使他们去兑现承诺。
- 多跟进需求的进度，每天上班主动跟技术了解进度，了解是否有遇到什么问题导致开发停滞，技术的日程计划等等，下班之后再次了解今天一天的进度，你只有多跟进才会让技术感知你的需求重要紧急程度，当然也要适当跟进，不要让技术觉得你很烦。
（3）避免开发中途修改需求
开发中途修改需求是技术的大忌，因为可能意味着做出来的东西需要全部推翻重来，所以能不改需求一定不要改，先思考有没有其他解决方案同样可以实现，迫不得已才改需求，很多情况下更改需求的根本原因在于定稿的时候没有确定清楚，特别注意要在定稿前跟所有相关的人员（尤其是老板）确定清楚需求才开始跟技术排期开发。
同时，需求中待确定的地方要标记出来，不然技术会按照他们的想法去实现，到时候再要求更改也是很不好的。
二、学会读懂产品上司的话
工作中，经常会遇到这种情况，上司跟你说某产品的新出的特色功能做的不错，然后让你看看如何在我们的产品中也加入这样的功能。于是你开始研究这个特色功能，觉得效果确实很不错，然后开始按照老大的建议加入了差不多的功能，等到功能上线后，才发现得不到预期的效果，最后只能无奈砍掉了辛辛苦苦做出来的东西。
这个时候你应该埋怨老大的建议不合理吗？当然不是，因为背锅的永远是做执行的……在开始执行之前应该先读懂上司话中背后的意思。
简单分析下背景情况：一般上司是要背负KPI的，可能是产品的DAU、用户付费率、营收、营收离散化等等，而且上司日理万机，主要承担统筹把控的角色，所以在产品的细节方面上可能没有我们了解的更深入。
因此上司提出了增加新功能的建议，并不是真的觉得这个功能好玩，可以借鉴一下，而是因为上司看到了该功能在产品某方面，如在DAU上有不错的表现，对完成我们的产品DAU的KPI可能有所帮助，但是由于上司对自身产品细节的了解并不是很深入，所以有时候提出的建议合理性是需要评估的，所以这个时候就需要我们去仔细分析上司的目的，以及我们如何达到这个目的，即使你最终分析出来的结果完全反驳了上司的建议，提出了完全不同的产品方案，但也好过做出一个没有价值的产品。
读懂产品上司的话能帮助你找到工作的正确方向，更有目的性地完成工作，避免耗费了大量的精力、资源却最终却以失败告终的情况，先三思而后行，真正优秀的人是花70%的时间在思考问题上，30%的时间在思考方案上，先思考事件的本质意义，然后才开始付诸行动，不要急于一时，特别是在高成本的事情上。
三、产品新人应该多去经历，丰富自己
扎实的专业知识通过努力还是可以达到的，但是经验这种东西，如果你没有真正参与到一件事情中，就像纸上谈兵，你永远不知道前方的路会有什么样的坑，尽管你做了万全的准备，还是会出现你意想不到的坑。
一个真实的案例：之前A直播平台邀请了重量级的明星B入驻直播平台进行开播，在活动之前，平台对此次活动做了大量的宣传，运营经理也对此次活动做了充分的准备，所有能想到的应急措施、补救方案基本都已准备好，正当所有事项都准备就绪开始明星B的直播时，这个时候明星B却由于家里网络问题无法进行直播，导致活动过程中技术花了三个钟在修复网络问题上，几十上百万的粉丝和观众干巴巴地见证了这尴尬的场面。
谁都没想到，在活动开始之前，明星B家里的网络受到直播平台竞争对手的恶意攻击。
过去一年从事游戏运营的经历，接触到的工作领域还算挺多的，包括产品调优、活动策划、用户运营、社区运营等，甚至有时候由于合作同事忙不过来，还需要帮忙分担一些分外的工作，虽然我觉得工作分工明确是有必要的，但特殊情况下，为了结果导向，为了一起把一件事情做好，可以在自己的能力承受范围内适当的帮助团队伙伴，不要急着划清界限，让自己多去接触更多的东西，这未尝不是一件好事。
亲身经历一些事情，跟作为一个旁观者了解到的东西是完全不一样的，这些经历也许会在未来成为你不可复刻的优势。对于产品新人来说更是如此，踩一个坑就少一个坑，多去经历，丰富自己，这样才能在未来中运筹帷幄，做出更有价值的产品决策。
文章就写到这里，以上是自己转行产品经理两个月来的一些心得和感受，作为产品新人，前方任重而道远，但同时也对新的行业、新的职业充满好奇和动力，希望在未来可以跟大家多多交流，一同进步~
作者：Buff先生
来源：人人都是产品经理
