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. 研发阶段

在研发阶段，产品经理需要承担起项目管理的义务，协助研发和测试同事，以推进产品开发。

项目管理的四个维度：范围、时间、质量、成本。

可对应的项目目标：多、快、好、省。

项目计划：

项目风险管理：

项目风险：如果发生不确认的条件和时间，会对一个或多个项目目标造成影响。

项目沟通：

原则：不论采用何种手段，邮件、微信、电话、面谈，信息的发出方一定要保证接收方能够收到并且理解信息，做出反馈。

项目推进：

推进项目的重要基石是：标准化——标准化指完成某项工作的最佳工作方法。

产品经理可以将项目过程遇到的问题及处理方法、人员配合方式、项目流程等经验或文档分享给其他项目成员，推而广之，达成大家的共识。

比如：

项目会议纪要模板：帮助大家高效输出内容完备的会议纪要。
上线验收清单模板：让大家按照清单和步骤执行可以减少出错、提高效率。
项目工作流：明确各自角色的任务及配合时间点，团队配合更紧密。

标准化可以避免项目再次陷入相同的错误中。沿用成功的工作方法、经验，让项目不断被顺利推进。

而在研发日常跟进中，可以采用看板模式来记录和跟进。看板管理需要注意的就是：避免某个阶段的需求出现拥堵，或者是一旦发现拥堵，要及时疏解。

4. 发布阶段

上线前需确认的信息：

产品是否具备上线条件，比如：是否有测试报告，是否得到使用方的验收。
产品的操作培训是否完成，或者是否至少有使用说明文档。
产品上线时间是否合适。产品上线的时间点是否会影响其他业务操作，是否需要配合整体的运营计划。

产品发布：

产品推广产品，可运用营销推广模型的核心思路：描述一个重要的问题，并让大家认同，之后介绍产品给出的解决方案。

营销推广模型分7步：

背景介绍：介绍所发布产品的背景信息，比如：时间、地点、任务、事件等信息，便于大家了解背景知识，从而减少认知负担。
描述阻碍：描述用户目前会遇到的问题，并让大家认同该问题确实会给自己带来不便。
点燃希望：向大家说明这个问题有解决方案，引起打击的期待和注意。产品经理客户可以介绍这个问题的解决方案，及概念或者同行业对这个问题的解决思路。
震撼登场：抛出问题的解决方案——即发布的产品是什么。
展现价值：描述这样的解决方案和产品会给用户带来怎样的价值和收益，可以配数字，这样会更有说服力。
精雕细琢：介绍产品重要的细节、工作原理。
给出诱惑：给大家送一些福利，让大家快来体验产品。这里可以根据实际情况来选择使用。

发布一款产品或者介绍一个功能并不都需要发布会的形式，产品经理可以应用简单有效的演讲框架快速打动用户。

5. 监控阶段

数据指标：

数据监控应该监控什么才有意义，从黑箱、仪表盘和二律背反理论中我们可以得到一些启发。

黑箱：

我们只能输入和输出，而并不知道事物真正运行的原理是什么，比如：电商网站的输入是用户进站浏览，输出是订单。那用户在浏览网页所做的行为和决策就是黑箱。

通过研究黑箱，我们可以提升用户转化率。

仪表盘：

通过汽车的仪表盘速度、耗油量等数据指标，随时反馈出汽车的状态。没有仪表盘的汽车随时都有失控的危险。对系统运行状态的监控也是，数据指标要尽可能覆盖全面，比如：出现问题的次数、加载时间、业务相关数据等。

二律背反：

二律背反指规律中的矛盾，在互相联系的两种力量的运动规律之间存在的相互排斥现象——即两种事物此消彼长、此长彼消、相背相反。

因此，我们除了关注数据指标之间的相关性，更需要找到这些处在二律背反的指标，然后进行指标配对。通过指标配对，防止过度监控或者提升一个指标而带来副作用，用另一个指标来辅助分析和监控，从而权衡出好的办法以解决问题。

如果没有办法计量，就没有办法管理。数据指标就是管理量化的表现。

数据目标：

制定数据目标的方法：关键成功因素法

制定数据目标的原则：具体、可衡量、可实现、有相关性、有截止时间。

数据采集：

SQL学习原因：

SQL是查数据和做报表的工具，建议产品经理都要学，原因：

SQL可能是最容易入门的编程语言。因为他书写出来的代码，完全是按照英语语法，是初中语法中最简单的部分。只要学习非常少的SQL知识，或者说是几个英语单词，就可以快速在工作中使用。
使用频率非常高。
有助于产品经理理解数据分析的思路。

SQL 入门手段：

《SQL基础教程》，这本书内容实用且基础，适合零基础的人学习，且它描绘了很多使用场景。
学习编程的网站，如http://www.w3school.cn/ ，这里的教学内容简约便捷，可以当成SQL使用的工具字典
找一名程序员同事当老师，随时实践、随时请教问题。

三、最重要的产品力是什么

纵观《B端产品经理必修课——从业务逻辑到产品构建全攻略》，会发现书里满满都是干货，作者产品力MAX。

那么，作者本人最牛逼的产品力是什么呢？作者获得的路径又是什么呢？

1. 关于产品力

前面我们探讨过，作者认为：产品经理的技能可以分为硬技能和软技能。

硬技能包括：用户调研、产品规划、需求分析与管理、产品方案设计、数据分析等。

软技能包括：项目管理能力、时间管理能力、沟通能力等。

但在我看来，作者产品力真正的厉害之处在于：任何时候，你有问题，我有方案，而且是快速产出的、高品质的、切中要害的。

拿本书作为产品来举例：作者可以被视为产品经理，读者可以被视为用户。书中内容几乎覆盖了B端产品经理工作场景、工作内容、工作方法、工作规划等读者可能有疑惑的方方面面，在每个层面，作者都给出了非常恰当、贴合实际的指导理论，也就是给读者提供了解决问题的工具。

你有需求繁杂的问题，我有优先级及重要性管理方案。

你有产品设计慢的问题，我有模式思维设计方案。

你有项目管理的问题，我有风险管理和标准化方案。

不难理解，在产品工作中，或是在其他工作中，这种迁移能力才是真正发挥作用的能力。

2. 关于产品力的获得途径

我们看能否从作者的自述和经历中发现获得这种产品力的答案。

以下信息均来自《B端产品经理必修课》作者简介或自述。

首先是作者的经历：

教育经历：北京理工大学工业设计方向硕士
工作经历：To C——高德地图、百度地图；To B——小米物流系统。
其他经历：PMP项目管理认证、“人人都是产品经理”专栏作家。
个人微信公众号：李宽wideplum

其次，是做作者的个人情况或习惯：

喜欢看书、涉猎历史、哲学、科学、经管、互联网、技术等各个领域的书籍。
把写书列为一个长期的目标，规划了5年左右的时间。
因为B端产品经理的知识没有成型理论和体系，所以，作者立志填补这项空白。期望自己的总结和思考，为中国产品经理职业发展提供理论和实践的支持。
为了写书，查阅大量现有的互联网、经管类书籍，还有大量的软件工程类书籍，以及学术论文。
查阅资料注重追溯知识本源，了解知识的核心要义。
本书展示了作者对B端产品经理的理解，介绍了B端产品经理的工作流程、工作方法、工作场景，以及作者在工作中的经验总结。
喜欢跟研发同事散步聊产品和设计，在无拘无束的畅谈中总结自己对产品的看法和观点。

以上，可以了解到作者身上几个难能可贵的品质：

对世界充满好奇。在好奇心的驱动下，习得的知识非常宽广。
对产品工作发自肺腑的热爱。兴趣让学习、规划和实践更加纵深。
目标驱动、规划落地。目标明确，为达目标时刻准备。
喜欢追根溯源。了解知识时追求本源，学习知识时抓核心要义。
持续学习，知识内化，不断总结和输出。工作实践不断总结成经验和方法，形成自己的理论体系，揉碎成通俗易懂的生活例子阐释。
寻求好的实践经历。在好的项目、工作环境中迸发出更多的灵感和提升。

相信这些品质不单只对B端产品经理，对所有职场中的伙伴，都是有益的启发，都可以借鉴成为我们不断提升的路径。

最后，我想说：这篇文章可以成为B端产品经理工作的简版操作说明，遇到问题时可随时翻阅。当然，如需进一步拓展和了解，请看作者原著。

附上作者在书中引用过的书籍，可用于拓宽产品知识面。

最后也欢迎有问题的小伙伴加微信：chanpin628 沟通交流。

此外我们的官方网站也上线了，每日分享高质量的文章、原型素材和行业报告，小伙伴可自行前往索取，支持搜索，需要的小伙伴可点击底部的阅读原文直接查看，或者复制网址：www.dadaghp.com 打开。

更多干货可关注微信公众号：产品刘

想学习更多关于产品、职场、心理、认知等干货，可长按右边二维码，关注我们。

··················END··················

RECOMMEND