B端产品经理工作流程

1. 需求获取
   1）概述
   产品经理以深度访谈、问卷调查、轮岗实习等方式获取需求方的需求，其中深度访谈这个方式最为常用。
   需求获取是一个由粗略到细致的过程，从概括性的项目背景说明、价值分析，深入到目标用户确认、业务现状、业务问题和期望效果的梳理。视项目实际情况，可能需要和基层执行者、中层业务负责人和高层领导分别进行沟通。
   2）注意事项
   沟通时避免使用封闭式提问（即提问者提出的问题带有预设的答案，回答者的回答不需要展开），封闭式提问容易忽略问题本质，停留在问题表象。
   3）产出
   访谈记录、调查报告、实习总结。

2. 需求分析
   1）概述
   产品经理针对获取的原始需求进行伪需求的过滤，梳理得到真实需求并汇总进项目需求池，进行优先级判断和迭代规划等管理。
   其中优先级主要从重要/紧急程度两个维度进行判断；迭代规划则是权衡工期要求和开发资源，在当期版本中删减优先级低的需求，在后续版本中再开发。
   根据确认下来的当期需求，进行业务流程、功能架构、工作流状态定义的梳理工作——即进行框架层的需求设计，也是进行详细需求设计前的必要步骤。
   2）注意事项
   需求方嘴上说的和他真实想要的很可能是两回事。《有效需求分析》中总结了这一现象：需求方往往提出“方案级需求”，需求分析则是要还原出“问题级需求”——其实就是过滤“伪需求”，得到“真实需求”的过程。
   梳理出真实需求后，根据实际项目要求和资源限制，可能还需要从技术、业务、成本和收益、风险和策略等方面进行可行性分析。
   3）产出
   项目需求池、需求概要设计（包含业务流程图、功能架构图和工作流状态定义等）。
   包括：图-项目需求池、图-业务流程图、图-功能架构图

3. 需求review
   1）概述
   产品经理依据需求概要设计（业务流程图+功能架构图+工作流状态定义）向需求方再次确认需求内容并阐述对应的解决方案。
   这个过程主要是用于确保产品经理对需求理解的正确、完备，在进行详细需求设计前及时纠错，同时也尽可能的避免后续环节中的需求变更。
   2）注意事项
   很多PM会忽略需求review这一部分的工作，或许是抱着“我在需求获取阶段已经进行了充分沟通，并基于沟通结果开展需求分析，那么需求设计就是没有问题的”这种想法，然而最终上线的产品不能满足需求。
   主要原因就是信息在表述、理解过程中的失真，需求review则是尽可能避免信息失真。初中级PM受限于产品能力，或者需求复杂度高，需要输出系统级解决方案，那么“再确认”的步骤是必不可少的。
   3）产出
   修正后的业务流程图、功能架构图和工作流状态定义等需求概要设计内容。

4. 需求设计-详细
   1）概述
   依据确认无误的功能架构图、业务流程图等内容，产品经理进行需求文档的编写。需求文档中需要说明页面内容、交互、字段释义和数据逻辑等产品细节。相较于内容详实全面的PRD，我个人推荐“原型+文字/表格注释”的形式进行需求文档的输出。
   PRD详实全面，也意味着又臭又长，项目组同事基本不喜欢看；在“让人快速准确理解需求内容”这方面的确不如“原型+备注”的形式。我个人理解PRD目前最大的作用在于项目归档、追溯和交接，而非需求内容传达。
   2）注意事项
   需求文档作为产品经理的主要输出物，是一个衡量其基础能力是否牢靠的重要指标。
   需求文档的目的，是为了让项目组成员就需求的理解达成一致，并能明确指导UI、前端、后端、测试等同事各自开展下一步工作。达成了以上目的，那么这已经是一份良好的需求文档。
   此外，需求文档具备“规范的内容格式”也同样重要。内容格式的标准化不仅能让产品经理在一个清晰的框架下编写文档，文档更具条理性，内容更完整详实，而且有助于知识传承和统一管理。对个人和团队都十分重要。
   3）产出
   需求文档：
   “原型+备注”形式的需求文档

5. 需求评审
   1）概述
   产品经理组织项目组成员参与并依据需求文档进行需求宣讲，让产品、UI、前端、后端、测试等同事对需求的理解达成一致。
   这个环节也是产品经理经历各方“拷问”的重要环节，尤其是技术同事经常会在产品设计上深究，因为这往往决定后续的技术选型并左右开发难度。
   2）注意事项
   需求宣讲需要注意语言表达的逻辑和条理，应当从“项目背景&目的、业务场景”扩展到“业务流程、功能架构”，最后再详细展开“具体页面和功能”——即结构性思维的应用。
   人无完人，哪怕是高级产品经理也不是每个项目都能考虑到所有细节。但这并不是产品经理在进行需求设计时“大而概之”的借口，相反，产品经理需要在设计时进行深度思考，尽可能考虑到所有细节。最好能做到面对大家的疑问，都能有理有据的应答。
   3）产出
   依据评审结果修订的需求文档。

6. 项目排期&项目管理
   1）概述
   将整个项目从“需求对接”开始，到“项目上线”为止，各个阶段的负责人以及人日消耗以表格形式罗列。目的是让项目组同事明确各个关键项目节点，产品经理（或者专门的项目经理）以此为依据进行项目管理。
   2）注意事项
   项目管理需要定时关注各环节实际进度与预期进度的差异，及时反馈风险、协调资源。如果觉得线下管理、沟通效率低，可以采用TAPD和Teambition等协同办公软件。
   这类软件一般都有甘特图和看板等管理工具，使用起来还是比较方便。
   3）产出
   项目排期表。
   4）需求优先级判定
   对需求类型进行分类，我对所有的Ｂ端需求分为3大类:
   业务闭环型需求；便利性需求；个性化需求。
   这3类需求第一个最重要，排第一；第二个，第二重要，排第二；第三个，第三重要，排第三。

7. 产品审查
   1）概述
   产品上线之前，产品经理需要对UI和功能进行审查。
   一般来说具体的界面测试、数据准确性测试和兼容性测试等会由专业的测试同事负责。产品经理只需要验证产品主流程通畅即可。实际执行也很简单，依据之前梳理的业务流程，发散出各个业务角色的用例，进行流程验证即可。
   2）产出
   产品审查报告：

8. 系统运营
   1）概述
   一个业务系统初次上线或者版本更新，需要针对系统各角色开展相应培训。
   一般而言，企业自建自用的B端产品不会分配相应的运营人员，往往是产品经理一并负责系统的运营，需要输出针对各个业务角色的“系统操作手册”，并视情况召开宣导会进行业务流程和角色操作的演示。
   如果该产品有向外部推广的意愿，产品经理也会负责产品白皮书之类的编写。
   2）产出
   系统操作手册、产品白皮书。

9. 运营数据分析&迭代规划
   1）概述
   产品上线后，产品经理和运营同事通过分析用户行为数据得出产品的优化方向。常见的B端产品评价指标如下：功能完善性、系统可靠性、时效性、易用性、兼容性、数据准确性、界面排版合理、响应速度等。
   一般采用问卷和访谈的形式进行收集，根据收集的数据，可分析出用户在当前版本的痛点，结合在“需求分析”阶段拟定的“迭代规划”，共同构成最终的迭代计划。
   2）注意事项
   常见的埋点事件（点击、曝光、停留时长）对（除SaaS外的）B端产品并没有多大的参考意义。
   因为B端产品与C端产品有一个根本差异——不直接产生收益，往往是通过间接的“降本增效”来为企业助力。这些常规的埋点事件和与之对应的分析模型很难量化B端产品的效益。故采用上述评价指标进行B端产品的运营数据分析并得出迭代规划。
   3）产出
   运营数据分析报告、产品迭代规划。