转行两个月，作为产品经理的一些感想思维导图

查看详情

一、学会验证需求和正确提需求产品经理的核心工作是发现问题和解决问题的过程，也就是挖掘需求和实现需求的过程，挖掘到新的产品需求，首先要做的是对需求从价值、可用性、可行性进行验证，只有需求通过验证，才…

树图思维导图提供转行两个月，作为产品经理的一些感想在线思维导图免费制作，点击“编辑”按钮，可对转行两个月，作为产品经理的一些感想进行在线思维导图编辑，本思维导图属于思维导图模板主题，文件编号是：5a0466570423c8af2112f52b824c7305

举报/反馈

思维导图大纲

转行两个月，作为产品经理的一些感想思维导图模板大纲

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

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

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

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

（1）可用性测试

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

（2）有价值性测试

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

（3）可行性测试

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

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

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

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

（1）需求文档要尽量周全、细致

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

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

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

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

（2）让技术感知到需求的紧急程度

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

（3）避免开发中途修改需求

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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