在进入某个行业或者某个岗位之前，我们需要对其进行一定的调研，形成足够的认知，从而让自己和行业、和岗位达成更好的适配。这篇文章里，作者就从几个方面阐述了产品经理的工作内容，一起来看看，或许会对想要成为产品经理的人有所帮助。
大学稀里糊涂的熬到毕业，没去实习或者就发了发传单，校招时又是稀里糊涂的面试，开始还想着挑挑拣拣，后面越面越慌，没人要你啊，能找到需要招人的公司就不错了，至于是干人力资源还是干销售，总先要填饱肚子。
这里面最大的问题是啥？
没有拿出足够多的时间，认识自己和认识行业、岗位，所以就更别提去做自己和行业、岗位的匹配。
然后工作个1年，发现现在这个工作真心不喜欢，哪哪都不好，却又不知道该做些什么，再拖一拖等个3-5年，虽然不喜欢干现在的活吧，但毕竟也积累了这么多年的经验，想一想转岗从零开始更亏了，再到后面有了家庭，左边孩子吃奶学费，右边房贷车贷，认了，就这样吧。
互联网产品经理，是一个相对来说热门的岗位，毕竟一方面薪资足够吸引人，另一方面我们年轻时都在憧憬着能够改变世界，看看乔布斯、张小龙这些大佬做出的东西确实多多少少影响了太多人的生活。
这篇文章就想从几个方面讲述一下最真实的产品经理的工作内容，我认为没有完美的行业和岗位，只有最匹配你的行业和岗位，每个岗位总会伴随着优点和缺点，当你真的能够接受这个行业、岗位的缺点的时候，可能才真正的适合。
下面我会从一个功能的从0-1讲述，产品经理究竟如何把一个没有的东西变成有的。
一、需求池这潭池水比你想象的来源要多得多，也并不是你想做啥就做啥，当你逐渐成熟为模块或者系统的负责人时，才会有更多决策权，我把这池水的来源，归纳为两类：
被动流入：产品经理每天都会接受到来自于四面八方的“问题”，来自于功能使用者、业务方、领导等，仔细去分的话可能大致分为三种：
1）看似是问题，但其实是对功能不熟悉：可能是新功能上线时的培训或帮会文档没写到位，也可能是功能设计的不好，没有让人一看就会。
2）新功能：一般会有专门的需求对接会议，在这个会议上关键业务方会提出遇到了什么问题和想要什么功能来解决问题，有一些公司还专门设置商业产品经理岗位来评审BRD（商业需求文档 Business Requiment Document），除了专门的会议，也会单独提出，有可能是业务方看到你的功能才想到，原来他真正需要的是什么，毕竟对于有些提需求的人来说，不上线他是想不清楚自己要啥的（这样恰好说明前期沟通、功能原型讲解的重要性）。
3）上线的功能无法使用：这种问题是最棘手的，需要立即查清楚原因并给出一套合理的解决方案，如果是半夜发生还要做好熬夜的准备。线上问题的优先级最高，处理不好可能还会引发新的问题，有这种问题不管是谁的原因都会被喷的，遇见脾气不好的业务方或者领导，可能会被问候家人。
主动引流：能主动去挖掘潜在需求，才能够比别人成长的更快，有以下三个方面。
- 研究竞品：竞品是指的跟我们在同一垂直赛道的友商，又出了什么功能，这背后的业务场景是什么，我们的业务是不是也需要？注意，一定不是抄。
- 验收、体验自己的产品：多用用自己的产品能发现很多问题，有些时候是功能可用性问题，但可能更多的是交互还原的问题，比如按钮的位置等。
- 看数据：要学会找关键数据，数据异常时要多研究是为什么，比如电商场景下，某一天单量突然减少了，没准就是下单环节出了问题，主动发现问题并解决能有效避免被喷，降低损失。
大多数的产品经理，都不是像想象的那样每天都在做着特别高级的规划，更多人不是在处理问题就是在处理问题的路上，如果遇到软件质量极差的团队，需要习惯成为“救火队员”。
此阶段的产品经理能力关键词：抗压能力、主动性、同理心。
二、需求分析经过第一步的洗礼，会发现有很多问题等着解决，但是要怎么把问题变成解决方案呢？
需求的本质就是啥？是预期与现实的差异。
挖掘需求的过程中往往有很多迷惑性，这里面充斥着情绪和方案。
情绪：因为某些问题很棘手，会导致相关利益受损，此时提出问题的人可能非常的冲动，根本无法说清楚具体的预期和现实。你觉得你自己有不被情绪影响的能力吗？还是一点火就着，直接就跟人干起来了。
方案：产品做久了会发现，太多的提需求的人都是带着方案来的。比如一个老生常谈的例子，一个人说他需要一匹更快的马，那需要马是需求吗？不是，马是解决方案，他想要的可能是想更快的从A点到B点，那汽车是不是更好解决方案？你觉得你有能力或者通过学习去发觉背后实际的需求吗，还是会非常容易受别人的引导？
我看到过太多的产品经理一直停留在别人说啥他做啥的阶段，这不能让你成为更高阶的产品经理，只能让你成为更好的写需求文档的工具人。
你觉得你是一个善于创造东西的人吗，把一个东西从没有变成有，并享受其中的过程。还是更喜欢在比较固定的框架或者规则下，每天完成差不多的事情。
此阶段的产品经理能力关键词：情绪控制能力、分析&抽象能力、刨根问底的能力。
三、设计方案记住，永远没有完美的方案，只有最适合当下的方案，固执的寻找完美方案会导致错过更多。
设计方案的时候要考虑的问题就更多了，这里只简单的把维度列出，具体的案例会在后续的文章/视频中讲解。
需要同时满足：商业、研发、用户三方面的诉求。
- 从商业上是有价值的，要么增加营收，要么降低成本，最终的目标就是利润。
- 从研发上是可以实现的，不要搞什么乌龙，要求研发做一个手机屏保是根据手机壳颜色，就算能做成本要太高了。
- 从用户上是使用便捷的，除特殊情况以外，用户用着爽才是一个软件产品能够长久发展的必不可少的因素。
方案完整性：再初阶的产品提出的方案都必须要自恰和他恰。
自恰是指的你这个方案里面的逻辑不能自相矛盾，一会说A是麻雀一会又说A是猴子是不行的，他恰是指的你的方案不能肆意妄为，大概率你的方案是要成长在别人搭的框架之下，不能你来一个方案把整个框架都改了，如果不是以重构为目的的方案最好不要动。
进阶一些的产品需要考虑到方案的续恰性，也就是方案的可拓展性，对于高阶产品来说不能要完成这个方案就完了，还要依据逻辑和行业经验把架子搭好，方便后续业务的拓展和其他产品经理添加东西。
时间：时间是一个非常隐藏的成本因素，需要评估这个需求有没有时间要求，如果有时间要求一般会将大的方案拆分为多个阶段。第一个阶段先抢救或者先抢占市场，后续慢慢完善。
以上还仅仅一个比较独立的系统所需考量的，规模越大的公司会越容易涉及到跨部门的需求，此时还需要关注几个方面：
共同目标：寻找共同目标利益是合作的前提，不同部门之间的墙远比你想象的高，必要时还需要借助更上级的资源进行推进。
明确位置：在一个需求中，不同部门之间会有依赖关系，梳理不清依赖关系会导致项目推进中出现非常高的风险，比如你的需求是依赖其他部门给你计算的一个结果，如果方案设计阶段没有评估到，在研发的过程中再爆出来就还导致需求延期。
持续沟通：跨部门沟通的另一个难点就是大家都只了解自己的系统，紧密沟通非常重要。
具备以上的能力以后才是真正的将方案落地为原型和文档，原型是产品经理用来描述需求的界面，往往软件功能都是有操作界面的，文档更多的是更严谨的文字形式的逻辑说明，这两者是产品经理的基本功。
原型示例：产品一般会用最简单的线框图说明白这个功能的本质和逻辑。
图片来源于网络，侵删
文档示例：文档是配合原型将逻辑描述的更加清晰，尤其是涉及到业务流程和复杂逻辑的系统。
你是否愿意为了这个岗位学习如何画产品原型，写需求文档？
你觉得你是否是一个可以在多个因素的要求与制约下找到最合适方案的人？
你是否善于在多个职能/部门之间沟通，找到共同利益并有效推进需求。
此阶段的产品经理能力关键词：多因素决策能力、大局观、沟通能力、基础原型&文档能力
四、需求评审前面3个环节是需求的吸收、内化、总结，而需求评审是一个交付的过程，需要让交互设计师、研发、测试清晰明白的了解你的需求要做什么。
这个过程最重要的是能在评审会议上，将你的方案讲述的明明白白，不留任何疑问，但如果你以为这是一个相对轻松的过程，那你就大错特错。
参会人会和你提出非常多的问题，甚至会挑战你，因此你要做的不光是解释清楚要做什么，还要解释清楚为什么要做。比如：
- 你为什么要设计这样一个功能，为什么不用另外一种，我觉得XXX做的很好。（应该提前想清楚不同方案的优缺点以及为什么选这个方案）
- 你有没有考虑过如果不这样，那会出现什么问题。（流程不仅有正向设计，还有很多逆向和分支流程，这些最见产品经理的功力）
- 要实现这个功能，我们需要XXX，这个谁提供。（这在涉及阶段需要考虑到依赖关系，如果依赖别的系统需要在会议时说清楚）
如果会议上人比较多，可能会由某个点引申讨论非常多的问题，比如本来需求评审会是为了讲清楚需求是什么，而研发可能会讨论实现的方案，以及排期，此时需要及时识别并控制住，继续进行评审。
你是否能适应公开演讲的场合？能够条理清楚的表述自己观点？
你是否具备良好的控场能力，在各个职能的人讨论得不可开交的时候找出问题的关键给出结论。
你是否能在非常短的时间内判断别人的建议是好还是坏，是应该吸收还是应该用逻辑的方式拒绝？
此阶段的产品经理能力关键词：表达能力、控场能力。
五、功能开发需求评审只是初步的交付给研发，功能开发的过程（代码编写的过程）研发、测试还会源源不断的给你提出新的疑问。
你要针对这些疑问进行答疑，并且需要将这个过程中新的结论更新到需求文档中，否则这将成为日后你与研发、测试撕逼的开始。
如果你的项目没有专门的项目经理，你需要及时关注项目进度，在关键时刻提醒风险，保证需求能够按时上线。
你以为完成上面这些就可以高枕无忧？又错了？
别忘了还有需求变更！
需求变更是指最根本影响的是你的方案要变了，原因有很多：
- 当时跟你提问题和需求的人改变了主意，之前要A现在要B。
- 当时跟你合作的部门出尔反尔（也可能是你找的人根本没有了解很清楚），之前说能提供某个能力，现在由于资源不够不能给你提供了。
- 你自己的设计有问题，突然发现某个地方应该做调整（这种必须要杜绝掉，不允许发生）。
遇到需求变更，要根据需求变更的程度，重新拉通相关的人员，做出解释、安抚情绪，需求变更越早发生越不容易影响最终的上线时间，如果明天就要上线了，你今天说要变更，这意味着：
- 这段时间以来所有跟你合作的人部分努力都白费了。
- 需求不能按时上线，影响了业务发展，更直接的会影响你的绩效，无论是出于什么原因，你负责的项目事实就是没上线。
你是否具备给别人不厌其烦的解答的能力？
你是否能耐心的将文档维护成最新的？
遇到需求变更，你是否有能力协调一切资源，将变更降到最低并按时上线？
此阶段的产品经理能力关键词：主人翁思维、风险控制能力。
六、功能上线需求开发完，研发和测试的工作即将结束，此时需要你来对功能进行验收。
你需要提前写好验收的场景和这个场景对应的预期效果，比如点击某个按钮应该出现某个提示。
- 验收是枯燥且重要的过程，能够把问题暴露在上线前是对用户最起码得尊重。
- 验收是严格的，不能因为顾忌研发、测试的面子而将问题忽略掉。
上线前需要编写此次功能的指引文档和组织培训，目的是为了让使用这个功能或者负责推广此功能的人知道该如何使用，并告知具体的上线时间。
一般来讲功能发布上线不是你想象的简单的点击一下上线就上线了，研发和测试需要做大量的工作将代码部署到线上环境，这个过程很多公司可能要持续几个小时，期间还真的有可能发生新的问题，产品经理尽量能随时待命保证按时上线。
不同的公司要求不同，有些公司可能会要求产品经理必须在发布的现场的，而这可能会导致加班甚至通宵。
需求上线后还需要对功能做相对简单二次验收（一般来讲上线后测试同事会进行回归测试）
你是否能耐心的书写并验收即将上线的功能？
你是否能严格且礼貌的提出问题？
此阶段的产品经理能力关键词：表达能力、耐心、责任心
这些过程，每个需求都要走一遍，因此在同一时刻，你会有不同的需求在不同的阶段，要合理的规划好时间，同时也要做好被打断的准备。
想想自己刚毕业的第一份工作，工作内容非常的杂，仅有一小部分跟产品经理有一点关系，大部分都是做重复的运营工作，在工作了将近一年后发现自己非常不适合在别人的规则下每天做着同样的事情，更倾向于创造和制定规则，更希望能够用上帝视角看问题。
当时买了几本书，大概了解了一下互联网产品经理的工作，同时报了一个班学习了Axure（实时证明没什么用），毅然决然的投入到了产品经理大军，在屡次碰壁后终于拿到了一个产品经理的Offer，还好我当时及时放弃了旧工作，不然到现在自己应该挺痛苦的。
了解完产品经理日常，你还认为你适合做产品经理吗？评论区告诉我。
感谢@小智 @Joey @Mandy @Hotel的勘误和建议。
本文由 @秀明 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
