什么是B端产品？B端产品经理是什么样的一个职位？应该具备什么样的技能呢？本文将从：“如何定义B端产品”、“产品各阶段的方法总结”，以及“产品经理所具备的产品力”三个方面来向大家详细介绍B端产品经理与B端产品。
（投稿说明：文章第一部分和第二部分，总结整理自李宽：《B端产品经理必修课——从业务逻辑到产品构建全攻略》，第三部分是自己所写。文章投稿至人人都是产品经理，获得了作者李宽本人的授权认可。）
作为一名产品汪，说来惭愧，接触过的产品书籍不多，而且大部分只是简单翻过。称得上整体翻看下来的，更是屈指可数，比如：
- 苏杰：《人人都是产品经理》
- 后显慧：《产品的视角——从热闹到门道》
- 刘志远：《电商产品产品经理宝典——电商后台系统产品逻辑全解析》
- 唐韧：《产品经理必懂的技术那点事儿》
这些书籍都在我的不同阶段，给过我不同程度的启发和指导。但因为我一直做的to B的产品，在我的当前阶段，感觉共鸣最多、解决了我许多疑惑、期待继续深入挖掘的，要属这本：
李宽：《B端产品经理必修课——从业务逻辑到产品构建全攻略》
怀揣着“将作者的产品干货学为己用”的初心，这份笔记心得，努力呈现书中20%的精益思想。相信你可以在这里，找到你想知道的B端产品经理那些事儿。
文章内容较长，以下是目录，方便大家定位到自己感兴趣的内容。
一、如何定义B端产品
1. B端产品
B端产品可以为公司的管理服务，如：HR系统、OA系统；也可以为公司的运营服务，如：供应链系统、ERP系统的。
不论哪种，其终局都是为企业流程效率服务，让分散的、低效的个体，更好地连接合作，发挥集成化的、系统化的更大作用。
相较于C端产品，B端产品最大的特点是：面向特定领域用户，且数量少得多，但更注重对用户专业领域操作流程的深度挖掘——也就是专业性更强，与业务的结合更紧密。
2. B端产品经理
B端产品经理重点关注：如何解决业务痛点？在业务逻辑的基础上，如何调度各类角色，提升各角色的工作效率、以及互相配合的流畅度？
正因为如此，做好B端产品经理的基础是：需要极其熟悉所属业务，否则工作容易浮于表面，甚至无从下手。
B端产品经理工作：
B端产品经理技能树：
要掌握的技能虽多，但不是每一种都需精通，可借鉴“二八原则”：真正重要的知识，或者在实践中被反复使用的知识，只占全部知识的20%。也就是说，20%的知识是需要反复修炼形成骨架的，剩下的80%在此基础上不断更新迭代。
总的来讲，在我看来，产品的核心能力是：能抓住问题本质，可提出合理解决方案，并将之执行落地的能力。
B端产品经理职业生涯：
一般产品经理的职业发展路径这张表可以作为产品对自己当前阶段的参照比对，也可以作为迈向下一阶段的方向指引。
B端产品经理的终局：
产品经理的职业成功之路，是成为某个领域的产品专家，而做B端产品经理是一条成功率极高的路。
因为进入某一领域做B端产品经理，需要具备某一领域的行业知识——即有入门槛。因此，B端产经理的职业发展容易形成护城河，更易成为某一行业的B端产品专家。
作者的这个论点，相信可以视为很多B端产品同行的福音。
二、各阶段的产品方法总结
1. 规划阶段
竞品调研：
调研方法：
B端产品经理的一个痛点是很难找到竞品。切入方法有：
- 明确查询方向后再起步。
- 从跟业务同事的沟通中发掘竞品。
- 通过专有名词进而搜索更多资料。
- 通过试用渠道体验竞品。拓宽搜索渠道：百度、谷歌是首选，知乎、简书找文章思路，知网、万方找专业信息。
调研结论：
- 竞品分析报告，应包括：行业发展状况，“有哪些竞品？”，竞品使用者和特性的描述，自己的产品与竞品之间的比较，通过分析得到的结论和信息等。
- 商业需求文档，应包括：产品创意产生的背景、产品或解决方案介绍、产品规划、产品成本、产品收益、产品风险等。
用户调研：
调研方法：
用户访谈的一般流程：请教——刨根问底——核实，具体为三段式问法。
- 发现问题：你正在做什么申请？做的过程中有什么不舒服的地方吗？遇到了什么问题？
- 分析流程：你现在用什么方法来解决这个问题？
- 探索机会：为了更好地解决这个问题，你认为有什么办法能帮到你？或者哪些地方可以优化一下？
调研结论：
用户调研报告，应该包括：对使用者的描述、通过分析得到的结论等。
产品规划：
战略规划整体分三步走
- 分析和预测需求：了解用户的期望，以及限制条件。
- 现状分析：用户已经从现有功能中得到什么，是否满意。
- 缩小差距：采取什么手段可以缩小未来（期待）与现状的差距。
具体产品路线可落地为:
需求分析：
需求应有的特征：
- 痛点：好的需求犹如根治用户痛处的良药。B端产品通过调研用户基本可提炼出痛点。
- 收益：需求应有可量化的结果导向。
- 明确、可行、简单的第一步：挖掘需求就是降低需求中的含混性，使之明确。如果在需求落地成型阶段才发现含混性，这个时候的改正成本实在是太高了。
需求可行性=（需求的当前价值+未来价值）/（需求的实现成本+维护成本）
解析需求：
- 探索需求的重要方式是以数据驱动的思路去探索业务。因为行为产生数据，数据联系（指导）行为。比如：用户下单产生订单（数据），订单传递给库房的生成人员指导他们发货。
- 用图形（流程图、实体关系图、数据流程图、用例图）来明晰业务和需求。
需求输出物：
需求管理：
识别干系人和角色：产品要与需求干系人和角色紧密合作，找到正确的人，非常关键。解决的办法就是了解所在公司及团队的组织架构。
需求管理的模式：通过“化散乱为规律，化应急为预测”，破解那些被打上“越快越好”标签的需求。
需求收集时间的把控：需求收集的开始时间和结束时间有一定原则性。产品经理要使用各种方法影响需求人，让他们不要赶在临近结束时间时提交需求。比如在结束时间前5天发提醒邮件。
需求的优先级：
需求的重要性：为了区分同一优先级的多个需求，可以用重要性来辅助优先级管理需求。
重要性就是对需求进行打分，分数范围是1—100分（根据5个优先级可以分成5等分），每个需求的分数是唯一的。优先做分数大的需求。
优先级和重要性一旦确定，所有的资源将向这些需求倾斜。处理跨部门的需求时，使用优先级尤为重要，但重要性的分数不能跨部门比较。
2. 设计阶段
设计信息架构：
设计信息机构的思路和方法：
- 组织信息：最简单处理信息的思路就是根据时间、字母、数字等内容，对信息进行组织分类。B端产品经理要注意把实际业务中，已经存在的信息组织结构，如：现有组织架构、单据分类等，在系统中映射出来，满足用户的预计和操作习惯。
- 给信息加标签：给信息加标签（取名），便于快速查询。注意取名需让用户易于理解。
- 设置找到信息的路径：即设计导航，B端产品大多是工具型产品，三级菜单一般足够。
- 搜索信息：B端产品的搜索场景中，精确搜索场景较多，因此，B端产品经理更多关注的是数据的结构。
- 描述信息的特征：B端产品经理在设计产品方案时，要关注数据对象的属性，即元数据。比如：学生的元数据包括姓名、生日、成绩、学号等。因不同的角色由于工作需要对元数据的定义不同。对元数据的理解不同会影响报表和展示信息的设计。
输出站点地图：站点地图可以采用树状结构展示页面之前的层级关系。
四种基本页面类型：
以下四种页面是B端产品最常见的页面。
这四种页面类型，是基于用户行为而设计的的通用化的解决方案。依据这些页面类型提供的解决方案，基本能够结构化地组织信息，为用户提供可预期的操作。研究透彻并熟练掌握这四种页面，也可以更方便地产出原型。
- 表单页：用户向系统进行增加、删除、提交信息的操作页面。
- 详情页：向用户展示详细的信息。
- 列表页：向用户展示结构化的数据信息
- Dashboard页：监控着整个系统的状态和运营数据。
设计产品原型：
学会用模式思维设计原型：
模式，是指：可以重复使用的方式和方法。这个概念源自《建筑模式语言》，它就像乐高积木一样，总结出了253种建筑模式。像乐高积木基础模块,，组合成为满足人们某一功能的建筑空间，比如厨房空间设计模式：
厨房空间由四个部分组成：炉灶、水槽、事物存储区、操作台，以上四个部分的间距在3m以内。其中，操作台的范围大致在1.2-3.6m。
厨房要满足人们做饭、储藏、清洗的活动。产品经理设计的每一个页面，也像设计厨房空间一样，要再一个页面上满足用户多种活动的需求，比如：信息的查看、搜索、下载等。
每种活动都对应着一个解决方案，这个解决方案就是模式，而多种模式搭建在一起就是页面。
用模式思维设计产品原型流程：
- 根据站点地图，找到要设计的页面类型。
- 根据页面类型对应用户操作行为，思考出各自对应的模式。
- 用组件搭建成对应的模式。各种模式的布局和组合，最终形成产品原型。
总结自己的设计模式：
设计思路:
- 模式名称：给模式命名，便于搜索和管理。
- 概念和价值：给模式定义，明确给用户的价值。
- 使用范围：说明模式边界条件。
- 模式描述：描述模式如何运行，即交互。
三种精度的产品原型：
以展示组件信息的丰富程度作为标准：
- 低精度：页面流程图，展示页面中的关键组件及页面之间的跳转流程。
- 中精度：展示页面布局，展示包含所有组件的页面，像照片一样。
- 高精度：详细展示原型中各个组件在不同操作下所展示的信息。（结构化输出文档）
原型的原则：只要能够说明清楚需求，任何样式都可以采用。
常用的原型工具：Axure、Sketch、Visio、Omnigraffle、墨刀。
产品需求文档：
需求方把业务语言翻译成需求（需求文档），产品将需求转化为可以产品解决方案，转化为让设计师和研发工程师可执行的方案（产品需求文档）。
当然，如果需求是业务逻辑的修改，不涉及界面操作，这时的需求文档其实等价于产品需求文档。
产品需求文档包含的内容：需求、背景、目标、目标和收益、需求范围、功能需求、业务概念、流程展示、需求描述、产品需求说明、网站地图、产品原型。
当然，并非所有需求都需包含以上元素。产品需求文档和原型的表述原则是一样的，不管产品需求文档以什么形式表现，只要能够清晰表达设计思路、便于沟通就是好文档。
设计交互：
源自《尼尔森十大可用性原则》的经典交互设计理论：
- 系统状态可见：用户能够随时获得产品反馈的信息，会让用户产生对产品的信任和安全感。
- 系统与真实世界匹配：要参考真实环境使用的单据和报表，将其映射在产品中。
- 用户掌控和自由操作：用户可以自由退防护或者结束当前任务。
- 一致性和标准化：让界面元素和操作形成一套让用户可识别、可学习的标准，并且在产品的任何地方都可以应用。
- 避免错误：需要检查一下界面的按钮是否可能产生误触。
- 直接识别比记忆好：产品要减少用户的记忆负担。
- 灵活高效地使用：要不断地提高界面使用效率
- 美观和简约的设计：设计要简明突出。
- 帮助用户识别、诊断和解决错误：着重关注给用户反馈的操作信息，且尽可能以友善的态度表达。
- 帮助和文档：需要在界面上提供必要的使用帮助，并整理出专门的产品使用文档帮助用户学习。
设计UI：
跟设计师的合作注意以下几点：
- 主动学习设计知识，如：常逛逛Dribble、优设、站酷之类的设计网站，提高自己对设计的认知。同时，了解公司或团队的设计规范。
- 明确指出设计重点，表达顺序。明确页面中重点功能是什么，使用者在什么场景下使用，以及希望用户重点使用的界面组件和信息有哪些。
- 给出设计案例。可以找一些比较好的设计案例给设计师参考，指出案例中哪些元素可以参考。
3. 研发阶段
在研发阶段，产品经理需要承担起项目管理的义务，协助研发和测试同事，以推进产品开发。
项目管理的四个维度：范围、时间、质量、成本。
可对应的项目目标：多、快、好、省。
项目计划：