B端产品本质是：解决组织痛点，实现商业价值。
B端产品经理，既要有对宏观的把控能力，又要有对细节的专注力。
没有细节的高度，会变成一个华而不实的空架子。B端产品的方案需要遵循以业务为中心，自顶向下的设计思路，从抽象到具体，逐渐勾勒出B端产品的轮廓。
一、缘起：业务调研
1. 概述
无论是一个项目还是一个真正的产品，都要明确的说出这个项目的目标或愿景是什么，这是产品的灵魂。
深入一线，深刻理解业务，是B端PM诊断业务问题，做出正确决策的前提；B端产品面向企业用户，产品目标是更好的支撑业务运转，调研目标是分析业务现状和业务问题为方案设计提供支撑，最终解决企业的业务问题，提升运转效率。
B端用户是一个组织或者是机构，所以调研对象有涵盖组织中的不同人员，从高级管理人员到一线执行人员，关键角色都要覆盖.
2. 执行步骤
1.2.1 步骤一：找到&引导目标客户
a预期高于现状时：客户有明确的改进预期，通常会比较积极的配合需求调研。
在问题场景中，我们要识别外因还是内因，外因可能包括包括参观考察、竞争对手动向、热点及新趋势；内因可能是自身业务的新需求或者遇到的问题；
B预期等于或低于现状：客户对变化表现不积极，对需求的调研表现出消极的态度，直接的调研方法无法获取需求。
在机会场景中，需要对客户的现状进行深入了解，提出客户可能为之心动的新预期，从而让他们进入预期高于现状的状态。比如我们可以从以下几方面引导：
新业务&新机会：与该领域领先企业的差距，从差距中寻找机会场景；跑在前面的同行的所作所为；他山之石可以攻玉，借鉴其他行业的商业逻辑；
新技术：了解新技术发展，从实际场景出发，技术可以解决什么问题&带来什么机会？
新人群：每一代人有不同的特点，你服务的对象有什么习惯、什么价值观？
1.2.2 步骤二：选择客户组织中的调研对象
对客户的组织架构要有所了解，着重关注三类人，包括项目发起人、出资人和项目实施部门负责人；
选择干系人代表，如果有多个干系人则从中选择一位或多位典型的代表人以便聚焦；每个具体干系人，他的专业背景、职业背景、价值观、组织地位、工作经验等方面都有一定的特殊性，选择一位或多位代表就能覆盖各种有差异性的人；然后，了解干系人的基本信息，比如说他的职业角色是什么样的？他的个人特点是什么样的？他的联络方式是什么？
除了要关注干系人的影响度以外，还要关注他与项目的相关度；
关注具有一票否决的关键干系人，我们必须分析它的关键需求，提出针对性的双赢的解决方案。
1.2.3 步骤三：确认调研方法
第一点，基于KPI分解，KPI指标体系通常直接体现了管理者的核心关注点，因此可以实现数据归类，然后逐一切入，以发现潜在的关注点和阻力点；
第二点，基于工作主题分析，管理者通常会涉及多个不同的工作主题，比如说负责物资供应的经理会涉及采购仓储等不同主题，先梳理被访谈对象的工作主题，以便访谈分而治之；
第三点，根据工作阶段分解，有些管理者的工作可能会比较单一，如销售主管，那么可以针对工作阶段进行分析，比如说售前、售中和售后；
第四点，干系人关注点整理，横向评估不同干系人之间的诉求，分析各个干系人的关注点之间是否存在冲突，制定相应的策略。
1.2.4 步骤四：给客户讲个好故事
1.2.4.1 给谁讲故事
我们要向客户证明系统的价值，而且向影响力越大的用户证明，项目成功的概率就越高。
在大大小小各行各业的项目里都很难实现，每个干系人都满意的完美结局，所以需要折中和平衡，项目其实就是一个博弈的游戏，重要的是要获得足够多的筹码，也就是需要找到关键的筹码持有者，赢得足够多的筹码就可以赢得项目，并且你不可能获得所有的筹码。
1.2.4.2 故事怎么讲
1.2.4.2.1 问题和机会
客观的从业务的角度来描述问题。
1.2.4.2.2 影响了谁
要清晰到具体的人。描述的问题，给谁带来了什么样的影响；注意推理合理，层次清晰，具有说服力；
1.2.4.2.3 产生的后果
要匹配读者的视角，与你讲述对象的视角匹配。比如关注目标愿景的一般是高层，高层会关注的问题企业经营、管理模式、业务模式；
1.2.4.2.4 解决方案
说明主要的策略以及推荐这个方案。一切知道为什么的人，都会知道应该怎么办，用一句话来提炼你方案的价值；
3. 注意事项
1）识别背后的问题
客户容易说出方案，而不是问题，我们应该识别背后的问题。
因为，就算我们完美的满足了客户提的方案，最终未必会得到完美的反馈，因为客户是问题专家，而非解决方案专家，他提出的方案未必能够完美的解决他遇到的问题；
2）产品经理得学会功能排序
能用的功能用户希望都有，人性本就是贪婪的，如果能多实现功能，那用户一定会让你实现，这时候产品经理让用户对想要的功能路线进行排序，确定他们最看重的东西，或者明确一下用户可能会失去的东西，比如说加载速度变慢，操作流程变长，再来让其判断最想要的功能是什么；
3）站在用户的立场
我们在建议解决方案时，应该站在用户的立场，说明这种方案的优点，我们要作为问题的解决者，而不是需求的传递者；
4）始于故事，终于数据和逻辑
B端的产品无外是问题，机会，成本，效益四个关键点；在引导客户时，我们应清晰描述整个软件系统解决什么问题？创造什么机会？带来什么价值？对于一些放之四海皆准的定性描述，其实没有什么卵用，因为它失去了指向性，我们最好采用上文提到的故事方式，始于故事，终于数据和逻辑。
4. 阶段性产物
输出业务调研报告，包括：
二、蓝图：系统整体方案设计
1. 概述
遵循自顶向下的设计思路，依次是设计核心业务流程，业务场景分析，应用架构，功能模块演进蓝图；随着设计的深入以及业务的开展变化，功能模块可能需要修正和调整，但只要业务的本质模式没有变化，功能模块就不应该出现结构性的变化。
2. 核心业务流程梳理
2.2.1 执行步骤
流程分析的过程中，我们可以遵循以下流程：明确系统角色分工 — 明确角色执行的活动 — 确定各活动的顺序执行/并行执行/异步执行的协作关系 — 识别流程的分支 — 识别流程的流转物，比如表单、单据等；
业务系统是对线下已有业务流程的固化、优化和重构，应与客户一起进行关键业务流程的梳理：
2.2.2 注意事项
业务流程的源头是外部/内部服务请求，所以业务流程图只允许有一个起点，但可以有多个终点；在定义流程的起点和终点时，首先理清端到端的概念，实际就是服务请求从提出到满足的全过程；判断一个流程是否完整，应该站在服务请求的立场，判断服务请求是否满足或者被拒绝。
划分为主、变、支三种流程，主业务流是我们对系统的主诉求，变体业务流也是主流程的一种，但是不容易整合到一个流程中，支撑业务流是一些边缘性的支持业务。
我们应该在做需求分析时应找出与系统边界直接接触的部分，进行边界识别；业务流程有两种边界，一个是职能边界，也就是跨越我们未涉及的业务域，二是系统边界，就不属于系统的那一部分。
将业务流程作为一个最小的交付单元，制定迭代计划，做完全部业务流程划分后，根据是否为主营业务，对优先级进行划分。
如果流程中涉及审批流程，不要用岗位名称加审批的样式，而应该识别审批意图，比如资金使用额度审批，因为不同组织可能审批的人不同。
2.2.3 阶段性产物
我们可以用业务流程表来呈现我们的分析结果，包括流程名称、简要描述以及优先级（高、中、低）。
用泳道图来描述完整的业务过程（包括线上和线下）。根据分析阶段和读者对象的不同，流程图可以分为四级
组织级流程，即部门间协作，以部门为泳道；
部门级流程，展现岗位间的协作，以具体岗位为泳道；
个人级流程，定位岗位的操作规程，没有这种泳道；
是子流程，如果个人级流程过于复杂，还可以再分层。
我们可以用跨职能流程图/活动图/时序图来展示我们的分析结果；如果强调每个角色执行的活动，就选择跨职能流程图/活动图，如果强调各角色间的协作和交互关系，就选择时序图。
绘制跨职能流程图/活动图时应该注意：业务流程绘制暂时不要考虑系统边界，要画出业务的全过程；活动的命名应该采用动宾结构，且主次活动根据读者的不同只留一个；活动图只有一个起点，但是可以有多个终点。
3. 场景分析&用户故事
2.3.1 执行步骤
这一阶段的关键点：就是说清楚产品针对谁提供什么样的支持。
上一部分，业务流程的绘制，没有考虑系统边界；这一部分，我们需要站在用户视角，梳理用户在哪些场景下需要系统提供支持，哪些不需要系统支持，哪些是需要系统进行半支持的。
用户故事的本质，就是希望用户或者是用户代表以作为某某某角色，希望通过系统解决方案或是功能要求，以便达成什么什么样的业务目的，它的本质上是用户视角。我们可以按照场景—挑战一方案的逻辑进行场景&用例梳理：
2.3.2 注意事项
岗位和系统角色有时不是匹配的，可能存在一个岗位对应系统的多个角色。
2.3.3 阶段性产物
我们可以用用例图来简略描述业务场景，绘制用例图时应该注意的几点：用例应该是一个独立的，可汇报可暂停的单元；角色和角色仅存在一种关系，也就是继承，用泛化表示；用例和用例之间存在三种关系，包含关系表示的一定会执行的公共子事件流，扩展关系表示不一定会执行的扩展事件流，泛化关系表示公共的事件。
我们可以用业务场景分析方案详细描述业务场景，包括：
场景概述，说明该场景任务的名称，该场景任务执行的目的，执行该场景的前置条件，任务出现的频率；
场景分析，以场景/任务、问题/挑战、方案/所需功能的形式整理分析结果，描述该场景最预期的步骤及每个步骤的问题；该流程的扩展事件流和相应的问题；最后描述这部分问题、挑战所需要的功能。
主流程外，对特殊场景的支持，它不是一种正常执行过程中的分支，而是一种例外情况（非必填）。
我们可以用例任务书来展示我们的分析结果，包括场景、任务名称、任务描述、解决方案几部分。
4. 应用架构设计
2.4.1 执行步骤
识别出用户场景之后，就应该细化业务场景的事件，实现以用户视角发现系统应提供的功能。但是对于对于复杂的业务系统，我们首先要进行子系统的划分，来降低需求分析复杂度。
PM视角的子系统划分和程序猿视角的子系统划分是两回事，程序猿站在技术实现的视角，而PM要站在用户/业务视角来划分子系统，这样客户容易理解，可以参与梳理过程，避免遗漏；
对于支撑管理业务的系统，最典型的就是先按照部门职能进行划分。
理想情况下，独立的业务部门应该有独立的系统来支持工作；可以先画出企业组织架构图，比如中型教育培训机构的四个典型部门：分别是教学部、教务部、市场部、财务部。
对应的子系统分别是：教学管理子系统、教务管理子系统、营销管理子系统、财务管理子系统。
在此基础上，再根据产品/服务进行分解，以教学管理子系统为例，可以继续划分为教研支持、课堂工具、助学工具等；
此外，确认子系统之间的关系，即“我”要“别人”提供什么？&“我”为“别人”提供什么？这一部分应该由产品负责人和架构师共同讨论决定。
2.4.2 注意事项
对于已有的业务系统，我们先开发来支撑新的业务；就需要去了解哪部分是需要重新开发的，哪部分是需要改造原有的，哪部分是需要复用原有的。
2.4.3 阶段性产物
我们可以用UML构件图来展示此部分的分析结果。
三、筑梦：系统细节方案设计
1. 概述
在应用架构的基础上要为每个系统设计功能模块，要问自己两个问题，这个系统应用于哪些业务场景？用户可能在系统中做的操作有哪些？
2. 组织机构模型设计
对于组织机构模型这一部分来讲，我们要考虑它当前的业务，以及未来可能存在的业务扩展——也就是各组织&角色是1对1、1对多还是多对多的关系，我们可以用E-R图进行分析结果的呈现。
3. 角色权限设计
需要明确不同角色能访问哪些页面，能看到哪些数据，以及能做什么操作。
3.3.1 功能权限
每个系统角色都对应一个明确的权限集合，包括对菜单页面元素等资源的访问和操作权限。
如果用户较多，我们可以对用户进行分组，将角色和用户组进行关联。当有新用户只需要设置其所在的用户组，就会将用户组关联的权限赋予新用户。
如果用户角色需要批量调整，只需要调整用户组和角色的关联关系；而不用重新变到每一个用户和角色没有关系。
本质上讲，一套软件系统就是对不同数据对象的增删改查的合集。
3.3.2 数据权限设计
角色在页面能查到的数据范围就该角色的数据权限，能查到的数据范围不是指能看到的数据字段，而是能查出来的数据集合。比如针对订单列表页，数据范围可能是某个城市的订单也可能是某个账户下的订单。
4. 页面流转图设计
页面流转图是向软件产品的页面设计更进一步的方式，是一种很好的衔接方式。
可以基于页面流转图进行讨论、修正，比原型画出来再讨论、修正，更高效。
页面流转图描述的是：用户完成某项工作需要访问的页面以及页面的跳转顺序。
我们绘制页面流转图时，都是针对某个单一角色在某个特定场景下的页面访问，和跳转逻辑，从用户的视角梳理一遍所有的相关页面。每到一个新页面时都要思考：需要先做一个页面，还是可以复用原有页面，最终整理出系统涉及的所有的页面的初稿。
有一点需要注意的是：不是所有的页面，都来自页面流转图，有些页面是独立于总体流程之外的。
5. 原型界面设计
当一套业务系统上线之后，后期迭代就基本不需要UIUE了。
前端工程师参考相关图，就可以直接进行前端页面的开发，业务系统的产品经理一般还是要自己做交互。
很多产品现在喜欢在界面设计啊，交互设计上有创新，其实没必要。因为B轮产品的用户需要的是——解决业务问题，提高效率。
交互体验并不是他们最在意的，而复杂的界面和交互会增加研发的工作量。PS：axure还是最经典的原型设计工具，然后用蓝湖进行一个实效性的沟通效果比较好。移动端的话可以用墨刀，比较高效，页面流转图用墨刀也比较好制作。
保证B端交互效果的尼尔森原则（虽然网上已经随处可见了，但是为了大家看着方便，还是搬过来了）：
3.5.1 反馈原则
系统应该在合理的时间，用正确的方式向用户提示或反馈，目前系统在做什么？发生了什么？
人机交互的基本原则就是让系统和用户之间保持良好的沟通和信息传递。比如安装程序时显示进度条，比如说上传文件时显示进度条，比如说提交表单时，如果失败，提示错误原因。
3.5.2 隐喻原则
系统要采用用户熟悉的语句短语符号来表达意思，遵循真实世界的认知习惯，让信息的呈现更自然与辨识和接受，
在人机交互设计中程序的沟通和表达功能的呈现都要用最自然的用户易于理解的方式，而避免采用计算机程序语言的表达方式。
3.5.3 回退原则
用户经常会不小心操作错误，需要有一个简单的功能让程序迅速恢复到错误发生之前的状态。
软件系统应该有撤销，重做这些功能。比如说word，美图秀秀的撤销，比如说点击删除关闭按钮后，让用户的二次确认，比如说电商平台允许在一定的规则下取消订单。
3.5.4 一致原则
同样的情景环境下，用户进行相同的操作，结果应该一致，系统或平台的风格体验也应该保持一致。
我们应该遵循惯例，不要盲目的标新立异。比如说office软件，各个产品就设计风格和界面布局就保持了高度的一致。
3.5.5 防错原则
系统要避免错误发生，要好过出错后再给提示。
进行设计师首先要考虑如何避免错误发生，其次再考虑如何检查校验异常。有时候为了防止用户重复提交，然后第1次点击之后就只会，比如说，调整二次确认对话框中的是否两个按钮。所以很多情况就把否放在前面。
3.5.6 记忆原则
让系统的相关信息在需要的时候显示出来，减轻用户的记忆负担。
比如说很通用的APP或PC的搜索引擎会记录用户的搜索历史。
3.5.7 灵活运用原则
现在用户中中级用户往往最多出高级相对较少，系统应该为大多数人设计，同时兼顾少数人的需求，做到灵活易用
系统就要做简单易用，让所有的中级用户用起来得心应手，也应该提供必要的帮助，让入门级的初级用户顺利上手，还需要支持灵活的个性化设置，让高级用户以进阶的方式使用系统。比如说word的，强大的配置功能。
3.5.8 简约设计原则
对话中不应包含无关的或没必要的信息增强或强化一些信息，就意味着弱化另外一些信息。
重点太多就相当于没有重点，所以要把握好突出标记的尺度。
3.5.9 容错原则
错误信息应该用通俗易懂的语言来表明，而不是向用户提示错误，代码提示错误，信息是要给出解决建议。
就比如说在填写表单的时候，不要等到提交的时候再提示用户错误，而是在填写的时候就，嗯，说明，填写要求，对不符合格式要求的，直接给提示。
3.5.10 帮助原则
对一个设计良好的系统用户往往不需要经过培训就能轻松的上手使用，但是提供帮助文档依然是很必要的帮助信息应该与检索，通过明确的步骤引导用户解决问题，并且不能太复杂。
B端产品的复杂性要比c端高很多，所以对于B的人品来讲，帮助文档依然是有必要存在的。
6. 业务报表设计
业务报表的核心价值是掌握事实，然后发现问题，分析原因，产生对策。
产品经理要和业务人员一起关注完整的体系化指标建设，设计有实用价值的报表。
观察分析问题的视角和思路是报表设计核心，绚丽的交互只是次要的外表。
产品经理要参与业务分析工作，建立业务分析监控体系，并负责实现线上化。
前三个环节是产品经理要直接负责的环节，包括构建分析体系，定义观察指标设计呈现形式；后三个环节是报表用户使用报表的过程，包括跟踪指标变化，分析变动原因，根据处理问题。
产品经理需要理解用户使用报表的方式，然后和用户持续的沟通；不断的优化报表的设计，只有从用户使用报表和分析问题的角度考虑才能设计出优秀的报表产品。
3.6.1 构建分析体系
之所以设计报表，就是因为要对某个业务诉求进行监控和分析。
在构建分析体系之前，要明确分析的目的是什么——即我们需要通过分析发现哪些方面的问题。
然后再思考我们应该采用什么方法来识别诊断这些问题，可能的困难是什么。
构建分析体系必须建立在对业务的深刻准确的理解之上，要和一线管理团队多沟通；可能很多问题的分析框架和思路已经被一项工作中发现并有效实践了，一定要善于发掘，并参考借鉴。
3.6.2 定义观察指标
理清了分析框架和思路，下一步要确定观察指标，设计具备明确业务含义的指标来考量业务。一般会从几个大方面拆分出几方面的观察指标，然后考虑是否将指标进一步的拆解为二级升级三级指标，从而在更精细的维度观察分析业务，更准确的反映业务特征。
3.6.3 设计呈现形式
确定了观察指标以后，我们就要思考以什么样的方式来呈现这些指标，以便用户能够准确快速的理解掌握指标及变化特征。比如说是采用数据表呢，还是柱状图呢，这个环节要核实用户都讨论寻找最佳的呈现方式。
可能，作为一名业务管理人员，各种核心数据都是了然于心的。看见当前数字都就知道有什么异常，管理人员需要的只是干净的界面和能够实时更新的，准确数字，其他炫酷的交互效果不需要。
3.6.4 跟踪指标变化
管理要用数据说话，报表数据就是诊断和决策的依据。管理人员要认真对待分析报表中各种数字的变化波动，如果只是走马观花的浏览报表，看不出任何问题，报表就失去了意义。
作为一名管理人员必须要对数字非常敏感，能够快速感知并解读数字背后的变化和问题，这是出色管理人员必须具备的素质。
3.6.5 分析变动原因
如果指标发生了明显的波动，需要跟进分析波动的原因，分析工作可以由数据分析师完成，团队最好每周分析上周的数据走势变化背后的原因，以便及时准确的掌握业务变化情况。
3.6.6 跟进处理问题
分析出问题后，下一步就是给相关部门或人员安排工作解决问题也就是报表设计的初衷，报表设计的第3个环节设计呈现方式。除非有很特殊的充电需求，其他都强烈地采用成熟的报表引擎，比如说之前我们用了e-chart；
需要注意：管控点、指标、报表是三个概念。
不同领导、不同企业可能用同一管控点、不同的指标和不同的报表，来实现同一管控目的。
所以，最重要的是把握用户想要什么信息，它的管理意图是什么？
管控点和报表之间是存在断层的，实际管控点和指标之间可能是多对多的关系，部分指标是可以复用的。