本文以产品新人小白的故事，向我们介绍了新手产品经理如何开展工作，以及其中需要了解的工作流程与注意事项。

01

小白是某教育公司的一名初入职的产品经理，公司的核心产品是小学数学直播课，用户通过APP上课。某天下午，小白的领导小黑走到小白的跟前，给小白布置了这样一个任务：

小黑：小白啊，你应该知道最近咱们业绩的压力比较大，我这边给你布置一个任务，你这边分析分析，看看是不是可以出个方案。

小白：嗯嗯好的。

小黑：咱们公司产品目前的用户量大概有两十万人，但是实际购买课程的用户只有不到三万人，我在想是不是可以通过给用户提供几节体验课的方式提升用户的转化率。

小白：了解了，大致思路是通过体验课的方式提升用户的转化，那这个事咱们是确定要做吗？

小黑 ：嗯，这可能是个机会点，你这边研究研究，出个大概的方案咱们过一下，看看是不是可行。

小白：好的好的。

小白总结1

当领导给你布置了一项任务，如果你有不清楚的地方，一定要主动沟通多问几个为什么，多了解相关信息，这其中大概有以下三种情况：

1. 领导确定要做：这个方向是领导经过掉调研论证过的，或者是领导的领导布置的，领导的信息量比你大，你只需要细化方案，填充细节即可。
2. 领导没想太清楚：这个可能是一个机会，需要你这边研究研究，思考是不是有可行的有价值的方案。
3. 领导想错了：可能性极小，通过充分思考和沟通尽可能避免此情况。

02

小白明确了任务之后，开始进行需求的调研：

首先，小白从数据后台导出了当前所有没有购买课程的用户的剩余课时数（注：1课时能上1节课），通过整理发现，80%的用户课时数都大于等于2，这时，领导布置的体验课的任务，实际上就转化成了：如何触达、通知引导用户去上课？从而为后续的转化做铺垫，这里会涉及到一些运营的方案，在此不详细展开了。

当然这里还有一种情况，80%的用户课时数为0或者1，这种情况就涉及到产品方案，需要继续往下分析了。

小白开始思考，给用户体验课是不是这个需求的核心呢？

显然不是的，需求的核心目标是为了让用户买我们的课程，用户不会仅仅因为你赠送了几节体验课就会直接买课程，买课程这个动作是多个变量共同作用的结果。

• 比如说在app里的banner推广免费领体验课的H5
• 比如说给用户发送push/短信
• 比如说在服务号发送文章宣传免费领体验课的H5
• 比如说客服给用户群发消息，告知用户有几节免费的体验课可以进行领取，用户从H5充值课时后隔多长时间再次推送消息进行转化等。

产品经理在这过程中应该考虑的是完整的方案(需要产品和运营配合)，在每个时间节点应该做什么事情，针对不同的用户应该分别用哪些文案或者刺激点，推送的时机是什么，这些都需要定义清楚。

小白总结2

作为产品经理，接到需求的时候要思考需求的本质，挖掘需求的核心价值，明确需求的目标，这样才能确保做的需求能为业务、为用户带来价值。

无论是产品需求还是运营需求，方案都应该是一个完整方案，要思考每一个动作是不是为你的核心目标直接或者间接服务的，这样才能确保整个方案流程上是完整的，并且每个动作都有它的意义。

03

通过绘制流程图确认各个环节，设计与用户的接触点，穷举、收敛需求点，反复修改方案的过程，小白终于完成了方案，接下来就要与研发的伙伴进行评审了，小白的心里有些忐忑。

场景：XX公司XX会议室

• 研发A：你为什么要做这个需求？ 这个需求有什么价值？一上来就讲产品方案，都给我讲懵了
• 研发B：XXX这块逻辑你没考虑完整，如果XXX怎么办？
• 研发C：XX功能你这设计的逻辑太复杂了，我觉得这个功能没什么太大的价值，这期先不做了吧
• 研发老大：什么？你这个需求要下周一上线？为什么不提前沟通啊？研发资源有限，项目经理，你看这个需求该怎么排？

小白面对一群人各种各样的问题，不禁开始反思……

小白总结3

产品经理产出方案的时候可以产出多套方案，比如理想方案，精简方案，方案里有些实现复杂的地方可以提前和研发沟通，或者想一想是否有替代的方案。

跟研发评审的时候先讲需求的背景和目标，不要直接讲需求。当你讲清楚为什么要做这件事，目标是什么，有什么收益，通过讲故事的方式把研发带入到场景中去，研发就会认同你做的事情，评审就会比较顺畅，研发也乐意给你提供一些建议。

研发很关心做的事情有没有价值，比如一个需求上线后一周，是不是可以发一封邮件，同步一下上线之后的数据，肯定设计、研发、测试等伙伴的辛勤付出。如果指标没有达到预期，是不是可以总结一下有哪些环节可以优化。

如果产品经理能站在研发的角度思考，大致就能理解为什么有的需求研发不愿意做。比如说需求上线时间点太赶，需求的一些逻辑没想清楚，把一个简单的需求复杂化，需求背景没说清楚研发觉得做了没什么价值，等等等等。

04

终于，小白的方案在第X次评审时顺利通过，研发开始评估技术方案进行研发了，小黑这时找到了小白。

小黑：小白啊，这个方案你做的还不错，流程完整，一些细节考虑的比较清楚，但你有没有想过一个问题？

小白下意识地哆嗦了两下：什么问题啊？

小黑笑了笑：你产出的方案其实只是做到了局部最优。作为产品经理，你需要把视角拉高，站在稍微宏观一点的角度去思考，去定义当前阶段我们做什么事情收益是最大的。

小白有点懵：这…我该怎么操作呢？

小黑不紧不慢地说：我给你提供一个工具，叫需求池，通俗一点就是一张excel，里面列举了当前阶段我们可以做的需求，里面的需求可大可小。有了需求池，你就能按照统一的标准把需求排序，评估哪些需求优先级最高，收益最大了。

小白：那要怎么评估优先级呢？

小黑：可以用一些能够量化的标准，比如说需求影响的用户范围，用户需求的频率，研发实现成本，用户付费频率、客单价等等维度综合评估。

小白：哦哦，原来是这样啊，我明白了。

小黑：悄悄告诉你，需求池在某种程度上还能够管理老板的需求哦。

小白：啊？哈哈….原来是这样。

小白总结4

互联网公司，通常来讲产品团队可以共同维护一个需求池，产品经理也要有自己的需求池，需求池里的需求可大可小，讲究宽进严出。

需求池能够保证产品经理在不同阶段能够定义相对有价值的事情，而不是只是围绕一两个点去做事情。

需求池在某种程度上能管理老板的需求，比如老板提了一个需求A，产品经理发现这个需求在需求池里的优先级排序是第5位，这时，产品经理就可以和老板说：boss，你的这个需求确实不错，可以达到XX的效果，但是我这边有几个方案也不错，分别是XX/XXX/XXX，咱们是不是可以综合评估评估?

当然，假设老板提的需求是需求池里没有的，这种情况下就需要把需求池里优先级靠前的需求和老板的需求放到一起评估，假设老板的需求优先级高，或者优先级类似，这种情况下就要先做老板的需求。

最后，愿看到文章结尾的你和小白一同成长~

本文由 @神奇海螺 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Unsplash ，基于 CC0 协议