与C端相比，B端业务更面向用户，会与企业的战略、业务、组织、供应链等密切相关。今天和大家聊聊B端产品的理解和要点，让刚接触B端的同学有个大概的了解。希望对正在做或者准备做B端产品的你有所帮助。
下面将对B端产品经理的工作流程拆解进行说明，从工作内容总结、注意事项、各环节主要产出三个方面进行介绍。
最终产品经理工作流程分解
1.需求获取
1)概述
产品经理采用深度访谈、问卷调查、轮岗实习等方式。获取需求方的需求，其中深度访谈是最常用的方法。
需求的获取是一个由粗到细的过程，从一般的项目背景说明和价值分析，到目标用户、业务状态、业务问题的确认和预期结果的梳理。视项目实际情况，可能需要分别与基层高管、中层业务领导、高层领导进行沟通。
2)注意事项
交流时避免使用封闭式问题。封闭式问题往往会忽略问题的本质，停留在问题的表面。
3)输出
面试，调查报告，实习总结。
2.需求分析
1)概述
产品经理根据获取的原始需求过滤伪需求，整理出真实需求，汇总到项目需求池，进行优先级判断、迭代规划等管理。
其中，优先级主要从两个维度进行判断:重要性/紧迫性；迭代规划就是权衡时限需求和开发资源，砍掉当前版本中的低优先级需求，在后续版本中重新开发。
根据已确认的当前需求，梳理出业务流程、功能架构、工作流状态的定义——即框架层面的需求设计，这也是详细需求设计前的必要步骤。
2)注意事项
需求者说的和他真正想要的，大概是两码事。这种现象在《有效需求分析》中总结为:需求方往往提出“计划级需求”，而需求分析则是还原“问题级需求”——实际上就是过滤“伪需求”，得到“真实需求”的过程。
梳理真实需求后，根据实际项目需求和资源限制，可能需要从技术、业务、成本与收益、风险与策略等方面进行可行性分析。
3)输出
项目需求池和需求概要设计。
3.需求审查
1)概述
产品经理根据需求大纲设计与需求方重新确认需求内容，并阐述相应的解决方案。
该流程主要用于保证产品经理对需求的正确完整理解，在详细需求设计前及时修正错误，尽可能避免后续环节的需求变更。
2)注意事项
很多PM会忽略需求评审这一部分，或许是抱着“我在需求获取阶段已经充分沟通，并根据沟通结果进行了需求分析，那么需求设计就没有问题”的想法。然而最终推出的产品并不能满足要求。
主要原因是表达理解过程中的信息失真，需求审核是为了尽可能避免信息失真。初级PM受限于产品能力，或者需求复杂，需要输出系统级的解决方案，所以“重新确认”这一步必不可少。
3)输出
修改后的业务流程图、功能架构图、工作流状态定义等需求概述了设计内容。
4.需求设计-详细
1)概述
产品经理根据确定的功能架构图、业务流程图等内容，编写需求文档。页面内容、交互、字段解释、数据逻辑等产品细节需要在文档中说明。相对于内容详细全面的PRD，我个人更推荐需求文档输出“原型+文本/表格注释”的形式。
PRD详细全面，也意味着又臭又长，项目组同事基本不爱看；在“让人快速准确地理解需求”方面，不如“原型+备注”的形式。我个人理解，目前PRD最大的作用是对项目进行归档、跟踪和移交，而不是传达需求。
2)注意事项
需求作为产品经理的主要产出，是衡量其基本能力是否可靠的重要指标。
文档的目的是让项目组成员对需求的理解达成一致，明确指导UI、前端、后端、测试等同事开展下一步工作。达到了以上目的，这已经是一个很好的需求文档了。
此外，同样重要的是需求文档有一个“标准的内容格式”。内容格式的标准化不仅使产品经理能够在清晰的框架下撰写文档，使文档更加有条理、完整和详细，而且有助于知识传承和统一管理。对个人和团队都很重要。
3)输出
文件要求
5.需求审查
1)概述
产品经理根据需求文档组织项目组成员参与并宣讲需求，让产品、UI、前端、后端、测试等同事对需求的理解达成一致。
这个环节也是产品经理经历来自各方面“折磨”的重要环节。尤其是技术同行，往往会钻研产品设计，因为它往往决定了后续的技术选择，影响开发难度。
2)注意事项
需求呈现要注意语言表达的逻辑和顺序，从“项目背景目的、业务场景”扩展到“业务流程、功能架构”，最后是“具体页面和功能”——也就是结构化思维的应用。
人无完人，即使是资深产品经理也不可能考虑到每个项目的所有细节。但这并不是产品经理在设计需求时“大而全”的借口。相反，产品经理在设计时需要深入思考，尽可能考虑所有细节。最好能面对大家的问题，给出合理的答案。
3)输出
根据评审结果修订的需求文件。
6.项目时间安排和项目管理
1)概述
整个项目从“需求对接”到“项目上线”开始，每个阶段的负责人和工日消耗量都以表格形式列出。目的是让项目组同事明确每个关键的项目节点，产品经理可以在此基础上管理项目。
2)注意事项
项目管理需要定期关注各个环节的实际进度与预期进度的差异，及时反馈风险，协调资源。如果觉得线下管理和沟通效率低，可以使用TAPD、Teambition等协同办公软件。这类软件一般都有甘特图、看板等管理工具，使用起来很方便。
3)产出项目一览表。
7.产品评论
1)概述
产品上线前，产品经理需要审核UI和功能。
一般来说，具体的接口测试、数据准确性测试、兼容性测试都会由专业的测试同事来承担。产品经理只需要验证产品的主要流程是否顺畅。实际实现也很简单。根据之前整理出来的业务流程，可以分布每个业务角色的用例，可以验证流程。
2)输出
8.系统运行公开
1)概述
当一个业务系统首次上线或版本更新时，需要对系统的每个角色进行相应的培训。
一般来说，企业搭建和使用的B端产品都没有指派相应的运营人员，往往是产品经理负责系统的运营。需要为每个业务角色输出“系统操作手册”，视情况召开宣贯会演示业务流程和角色操作。
如果产品愿意对外推广，产品经理也会负责产品白皮书之类的准备工作。
2)输出
系统操作手册、产品白皮书。
9.运营数据分析和迭代规划
1)概述
产品上线后，产品经理和运营同事可以通过分析用户行为数据，得到产品的优化方向。B端产品常见的评价指标有:功能完善性、系统可靠性、及时性、可用性、兼容性、数据准确性、界面布局合理性、响应速度等。
一般采用问卷和访谈的方式进行收集。根据收集到的数据，可以分析出当前版本用户的痛点。结合“需求分析”阶段拟定的“迭代计划”，共同形成最终的迭代计划。
2)注意事项:常见的被埋事件对B端产品没有太大的参考意义。
因为B端产品和C端产品有一个本质的区别——不直接产生收入，往往是通过间接的“降本增效”来帮助企业。这些常规的掩埋事件及其对应的分析模型很难量化B端产品的收益。所以用以上评价指标来分析B端产品的运营数据，得到迭代规划。
3)输出
运营数据分析报告，产品迭代规划。
摘要
可见，B端产品经理除了具备沟通能力、文档整理输出能力、项目管理能力等一般能力外，还需要具备优秀的业务理解能力和方案设计能力。所以在工作过程中，要着重培养自己快速准确抽象业务流程，提炼通用解决方案的能力。
b端产品经理在职业生涯中会慢慢发现，业务痛点到最后往往是流程问题，甚至是公司制度问题；仅仅是把线下流程做在线上，对于解决业务痛点可能作用不大。
