产品经理日常工作流程

互联网产品经理最核心的岗位职责是为产品负责，一个产品经理如果有过负责一个产品从 0 到 1 的过程，通常我们认为这个产品经理就拥有了一个完整的项目经历，对于行业的理解会更深，在工作中也会更加得心应手，这里我们以一个产品的诞生流程来讲述产品的日常工作流程以及过程中产品需要注意的要点。

组建团队

首先，想要培育一个互联网产品，仅仅有产品经理是不够的，一个靠谱的团队非常重要。通常来讲，直接参与整个流程的人员有产品人员、市场人员、交互设计师、视觉设计师、前端开发人员（包含移动端、 web 端、 H5 端等）、后端开发人员、测试、运营人员，各司其职才能成功的培育出一个 APP 。

需求分析

当拥有了一个完整的团队，就可以开始正式的设计了。 首先，为了确定产品存在的价值，同时让团队内部的人员彻底的了解产品的核心设计理念 , 团队成员需要一起对 APP 的规划进行分析，主要包括风险评估、成本评估、竞品分析等，并输出对应的成本分析报告、市场分析报告、竞品分析报告和可行性分析报告。 接下来，产品经理会进行对用户需求进行分析，具体流程如下：

1. 需求筛选：“用户需求”转化为“产品需求” 所谓 用户需求，关注的是用户遇到了什么问题，希望能解决成什么效果； 而 产品需求，则是针对用户需求所产生的一个解决问题的思路和产品策略。 当产品经理接收到需求，第一步就是要对需求进行价值初判，剔除那些明显不合理的需求。不合理的需求主要是指那些很小、无法实现或者是投入极高的需求以及和产品定位明显不符的需求，例如 APP 需要跟随手机壳变色就是明显的不合理需求。

当剔除明显不合理需求后，我们需要对剩下的需求进行进一步的分析，找到用户需求的本质。不同的人对于产品会有不同的需求，这些需求都是用户的声音，是有价值的，我们要倾听，但不可以完全按照用户要求去做，我们需要的，是通过用户需求分析找到用户的核心诉求，满足用户内心深处真正的渴望。

对一个需求进行评估，可以按照下面的路径进行思考： 第一：你是否准确的理解了用户需求？（用户真的是需要一个包子吗？） 第二：用户产生需求的场景是什么？（用户提出这个要求的时间和场景是？） 第三：需求产生的场景是否具有普遍、高频的特征？（是不是很多人都想要包子？） 第四：用户提出这个需求的核心诉求是什么？（是因为饥饿吗？） 第五：针对这个核心诉求，这个需求有其他的实现方案吗？（除了包子，馒头、鱼肉是不是也可以满足他？） 2. 需求拆解：“产品需求”转化为“功能性需求” 需求拆解是指结合产品的战略定位和已有的产品架构将“产品需求”通过思考模块归属、细节设计来转化为技术可实现的“功能性需求”。 在实际的产品工作中，需求拆解可以从两条路径进行思考：一个是“用户流程”，就是指一个用户在体验这个需求的路径中会遇到的功能点，通过列举用户所可能遇到的所有的场景来对前端页面进行设计；另一个是“数据流程”，指的是从技术的角度，对数据流通的整条流程涉及的实现要点进行分析，来确认后端需要设计的接口以及字段。 进行需求拆解时，最重要的两点，一点是横向上尽量的全，不要漏掉技术点，导致形成链路断节，另一点是竖纵向尽量的深入和清晰，避免描述不清影响实现的情况。结合以上两个方法进行分析，能够做到前后端设计上没有遗漏，完整详细。 在进行需求拆解分析后，我们可以用 Feature List 来进行需求的管理。 Feature List 又称之为功能列表，格式一般为 excel ，其中包含“一级模块”、“二级模块”、“特性”“需求描述”、“类别”、“优先级”、“产品人员”等列字段，能够清晰的显现需求拆解的结果。

3. 需求优先级排序：“功能性需求”转化为“版本需求” 虽然将产品需求拆解成了功能性需求，但实际工作中的开发资源总是有限的，常常会遇到需求积压、无法全部实现的情况，故而能够对需求的价值以及成本进行评估，进而确认需求的实现顺序非常重要。合理的需求优先级排序以及版本需求决策能够提高公司资源的利用效率，将需求价值最大化。 通常我们采用比较“性价比”的方式来评估需求，即通过对需求的产出价值以及投入成本进行评估得出需求的性价比分数，然后按照最终的性价比得分由大到小来对需求进行排序。 产出价值方面我们一般从两个维度进行考虑，一个是需求的用户价值，也就是这个需求为用户提供的显性、情绪价值，另一方面是对公司或者是合作伙伴的商业价值，也就是能为公司带来多少收益，这里的收益不仅仅指真实的金钱收益，也包括社会声誉、企业形象等隐性收益。 针对用户价值，我们通常采用卡诺模型（ KANO 模型）来进行评估。 KANO 模型是东京理工大学教授狩野纪昭 (Noriaki Kano) 发明的对用户需求分类和优先排序的工具，核心理念是从用户对于需求的满意程度出发，来分析需求价值和用户满意之间的非线性关系。

针对商业价值，一般会从两个角度分析，一个是可量化的商业收入，另一个是抽象的社会声誉与企业形象。 具体来讲，商业收入是指通过经验推算需求能够带来的预期收益，例如广告收入、商品售卖收入；社会声誉与企业形象主要是指需求带来的品牌形象的增值，品牌形象的增值能够增加用户对产品的忠诚度，进而转化为商业收入。 对于需求投入成本，我们通常谈的最多也最为明显的需求成本是“技术人力”，通常包括设计、开发、测试三大模块。 除了“技术人力”外，许多需求还包含了需求上线后运营人力的投入。具体来讲，“评论功能”和“点赞功能”的后期所需运营人力就是十分不同的，评论功能上线后必然要运营去维护，按照一定的标准对评论管理、筛选、删除，点赞功能则无需运营人力投入，故而在进行需求成本评估时，上线后的维护人力也需要考虑。除了上述两个“人力成本”外，公司还需要考虑实际付出的资源，例如是否需要配置硬件以及会增加多少带宽费用等。

当了解了每个需求收入分数与成本分数后，我们需要将两者相除，得到最终的性价比分数，然后按照性价比分数来将需求进行排序，并按照工时限制确定最终的进入版本的需求。

需求实现

在需求分析之后，就是需求实现阶段。这个阶段最为重要的就是把你在你脑中的各种产品逻辑准确清晰的表达出来，通常的渠道有四个： PRD 、 UE/UI 、需求评审会议以及日常聊天软件。辅助的还包括原型图、用例图、流程图等。 其中的起点就是 PRD ，一般 PRD 的组成部分是文档信息、修订记录、目录及正文内容，正文内容又包括引言、特性所包含的功能、功能性需求等。在撰写 PRD 的过程中，要注意以下要点： 第一， PRD 作为沟通的桥梁性文件，确实在产品研发中举足轻重； 第二，虽然 PRD 的内容很多，但其实最为核心的仍然是对于需求的描述和管理，能够把需求用文字的方式叙述清楚，是最重要的； 第三， 由于设计师会按照你所撰写的 PRD 去输出 UE 和 UI 稿，所以 PRD 里的逻辑必须十分清晰、完整，尽量考虑好所有的边界情况和逻辑漏洞，同时在 PRD 中用语需要规范，避免由于对于某一词语理解不同而导致效率降低的情况。 PRD 中的功能入口设置通常需要和 UE 共同商讨， UE 在输出 UE 稿后需要交给产品经理去统一同步到各位技术手上，为了避免反复修正和需求变更引起矛盾，产品需要仔细的确认 UE 稿，防止出现 UE 稿和 PRD 矛盾或不同步的情况。 在输出 UE 和 UI 后，会举行一次需求评审会议，主要是产品经理主讲， UE 辅助，这是讲清楚中最重要的部分，因为语言总是比文字有更强的说服力，在评审会上要明晰各方疑惑的问题并同步到 PRD 以及 UE 上。 需求评审会议后，开发的老大一般会进行排期，这时候开发和测试童鞋可能会来与你核对或者确认一些需求的细节，在沟通时，需要注意当聊天软件无法讲清楚时，一定要积极的去找开发当面交流，以避免矛盾的产生，另外要注意用流程的规范降低交流成本。 比如：你确实需要变更或许补充一个需求，一定要和开发以及测试先事先确认，再进行 prd 和 UE 、 UI 稿的修改，修改后一定要通过邮件或其他方式同步到各方。 跟进技术人员开发情况、测试人员测试情况，随时应对可能出现的沟通上的各种问题。 当然，对于某些特殊无需前端配合的需求，可能不需要提供交互稿或者视觉稿，例如数据产品和算法产品等，这些都需要根据实际情况进行判断。

数据验证

在数据实现上线后，数据分析和验证是非常重要的，主要的数据分析是对页面、区块的展现、点击情况进行分析，以判断功能的使用率以及使用路径。数据分析一般分为三个部分，分别为提前埋点、开发检验与数据验证。 首先在进行产品设计时就需要考虑到哪些数据是我们看中的，需要提前进行埋点，以便之后进行查询，一般埋点查询的方法有两种：建立内部分析系统，或者依赖第三方的分析系统。内部分析系统可以根据度量指标进行定制开发。缺点是我们需要耗费资源单独建立和维护。外部分析系统，譬如 Google Analytics, Mixpanel, KISSmetrics 等都是不错的选择。第三方的分析系统易于实现且不会浪费建立和维护所需要的资源。 开发检验主要是通过开发自查、测试检验与产品验收三个阶段来确认埋点的有效性，这与一般需求的检验过程是一致的。 数据验证则是指在功能上线有一定数据积累后对埋点数据进行采集与分析，通常我们通过制作比较图表和趋势图表来做进行数据分析对比，在数据验证时我们最在乎的是以下两个点： 1 、相同功能数据是否发生了变化，例如一个按钮的点击量上升了 10% 代表功能使用率提升； 2 、数据变化的趋势，例如一个指标在周末上升，工作日下降，可能代表其使用场景大多集中在周末。 无论是数据对比还是趋势，都需要在定位出问题进一步分析， 这能够帮我们验证我们在产品设计之初的判断与规划是否正确，以优化之后的产品方案。同时，数据分析的结果也可用于市场推广以及运营方案的制定，在产品日常工作中非常重要。 当然，在进行数据分析时也应结合用户反馈一起来看，能够提升数据分析结论的准确性，以避免纸上谈兵。