B端产品经理思维导图
产品经理B端产品需求的3个层次,你都了解吗
编辑导语：产品经理在日常工作中经常会进行需求管理，B端服务于组织，所以B段业务的需求更多是部门内外、各层级的需求；本文作者分析了关于B端产品需求的三个层次，我们一起来看一下。
作为一个B端产品经理，日常工作中，“需求”一词，可能是我们听到过和说过频次相对比较高的词语了。
比如：以上提到的3点都属于需求吗？是的，都属于需求。
不过，它们分别属于需求的3种不同层次。
3种不同层次的需求分别是：这种需求的划分方式很大程度上代表了需求工作的3个不同阶段，通过对需求3种不同层次思维模型的理解、运用，会对需求工作带来很大的帮助（我亲自运用过，用起来非常有用）。
接下来，我将一个一个的详细说明。
战略需求是指软件系统的北极星指标，也就是设计、开发软件的目标是为了什么。
战略需求是软件设计、开发的原点，是指导软件往下设计和开发的最高层次需求。
如何发现战略需求？可以从客户现状与理想状态之间的落差角度来发现战略需求，战略需求来源于落差。
比如客户现在一年赚1个亿，明年希望2个亿，那么现在和明年之间就有了1个亿的落差。
如何增加营收一个亿，这就是客户的战略需求。
在具体落地找软件战略需求的过程中，不同的软件类型有不同的思考方法。
这里，我把B端软件主要分为两种：项目型软件找战略需求的过程，一般是来源于公司老板或者是高管在参观、考察行业相关企业、竞争对手分析、学习行业内标杆企业、参考其它行业等的时候结合公司自己的业务提出来的需求。
比如：假设，你是在一家提供体检业务服务的连锁门店做产品经理，门店现在的工作流程是全手工状态，靠每个门店的负责人来管理，没有办法保证每个岗位都按标准化流程来执行任务。
未来几年内，老板的期望会把企业做大，开更多的门店服务用户；有一次老板参观了一家标杆连锁医院后，发现医院通过信息化系统解决了病人就医流程固化的事情。
于是，老板回公司后告诉你，现在想要开发一套信息化系统，把体检业务流程进行固化，为以后开更多的门店，奠定基础。
产品经理-B端营销C端化,四种可能的B2B”单品”化路线假设
B端营销C端化，四种可能的B2B”单品”化路线假设B2B“单品”价值在于使B端企业级购买决策流程及对应产品/服务的营销策略C端化，通过普通用户倒逼决策者，带动企业终极产品/服务的销售。
说明：做toB市场的人则可能都会遇到一个问题，每当需要介绍自家产品的品牌时候，发现总是一句两句说不清楚。
往复杂了说，总有一种要从“很久很久以前……”说起的感觉，说的人不先对深呼吸一下，都怕中间一口气喘不上来……而听的人瞬间接收到的信息爆炸，大概率还是要懵逼的。
尽管你觉得自己已经极把前因后果方方面面各种场景假设说得很有条理很有逻辑很清晰了，但对方的知识慢下来背景和理解力真不一定跟得上。
往简单了说呢？往往又极度概括和抽象。
听起来每个字都听得懂，但还是不知道你是干嘛的。
比如：阿里巴巴马云经常说的“让天下没有难做的生意”，大家都听得懂，也能理解。
假设你没接触过阿里巴巴，你能从这句话解读出他们到底在做什么吗？最后，一言不合可能就需要有上demo了。
Demo也是要成本的，成本还不菲，用户也不是胡说八道就能同意你去demo。
有这种情况，肯定不能说“这一届用户不行”。
那啥也别说了，直接关门大吉叭。
正确姿势必然是先对在自己身上找原因：假设以上三点全都不存在问题，这就是一个非常复杂的比较复杂产品/服务。
那么，从营销策略出发，有没有可能将基于自身产品/服务，提供一个像C端一样简单的“单品”，让B端用户从接收信息到购买决策过程中向C端用户无限靠近。
我所说的永恒靠近C端的B端“单品”标准是：有四种可能的形式：第一种是现有产品/服务的横截面，现有业务和功能的阄割版子集。
大体上，市面上推出免费试用型产品/服务的B2B公司，都有类似的操作。
基于现有业务和功能的子集，有的不适用，有的有点别扭。
比如：Ahref这种低价限时付费试用，看似是全功能的，个人版其实就是部分核心功能的受限制组合，面向的是自由职业者和个人事业主，标准版面向的是企业。
本质上达致是能达到我说的标准的。
产品经理-B端—卡片式列表设计
B端—卡片式列表设计在交互设计中，信息集合的方式往往外观设计采用卡片式设计和列表设计。
列表专门针对的集合主要是信息栏的“排列展示”，而卡片式主要解决的是单条信息的“内容较多”，以及此信息的“可操作性”；本文分享了关于卡片式列表设计的一些思考和案例，我们一起来了解一会。
卡片式列表是一种很好的集合信息方式，它既有效用也有弊端，因此需要弄清根据场景和内容确定展现形式。
本文结合了案例与大家分享一下卡片式列表设计的一些思考。
1. 什么是卡片物理世界中，条码个人信息是用以承载信息的独立矩形薄片；例如电话卡、明信片、身份证、扑克等均属此类，具有“便携性、信息简洁和相对瓦理棕“等特点。
当它作为一种剪影，延伸至虚拟世界此后，其信息结构和交互方式更容易被感知和理解。
2. 卡片式列表在列表界面记录集结构中，我们可以采用表格、列表、图表等方式对数据进行集合展示；其中，卡片是与此相反一种特殊的列表为形式，其特点是每一个卡片高度固定（面积相对固定）。
这里注意，从数据结构上所来说，表格是二维数组，列表则是一维数组。
这两者是有区别的，没有包含关系。
首先，来了解一下数据展示较常用的表格有哪些特点。
优点：缺点：那么相对于表格，卡片式列表的特点列出如下几点：1. 强化主次，信息分级条码作为一个独立的容器，可以在内容上进行良好的布局组织，将信息分块，突出重点，从视觉感知上就对内容进行了相联，分明的层级能够引导用户的浏览视线，有秩序地阅读与键入。
2. 内容独立，多端适配对于响应式的设计来说，卡片作为一个承载素材的容器，能很易于的放大或缩小，做到既统一又相对独立。
在多设备间能创造出一个一致独立的美学效果，创建出一致的体验。
3. 整体的数据展示效率低尽管单个卡片得到了重点关照，数据分析但相对于用表格来展示数据来说，其承载的条目的数据还是偏少，整体的信息量较差。
1. 从表格到卡片在B端产品的设计中，表格是使用频次最强的设计元素。
对于数据量较大的申请表，一般情况下，我们会通过冻结列于的形式呈现它。
浅析：有关产品经理需要具备的B端设计思维
浅析：有关产品经理需要具备的B端设计思维一、为什么B端的需求这么难做？（1）产品架构复杂，功能庞大往往B端系统数据结构比较复杂，而事故严重度又比较高，对产品经理考虑的严谨性要求比较高（2）用户思维和客户思维的转化更难往往产品经理刚入门的时候，会去在意用户的体验性，考虑交互、样式和用户心理；但是到了B端，价值》流程》体验，如果过分考虑体验，那么就本末倒置了。
B端的业务，产品经理很难站在用户的立场思考问题，因为你很可能不是这个场景下的使用者。
（3）难以深入理解业务和市场如果B端的产品经理不能深入理解业务和市场，在你聊需求的时候，你可能跟客户都是牛头不对马嘴。
B端产品经理对自己的要求，永远是要比客户更加懂业务！（4）客户角色多，需求描述不清客户角色多元，需求提出方可能并不是系统的使用者。
管理者提出的需求可能会干扰需求的优先级决策；很多B端产品经理无法区分关键角色，从而对需求的本质判断不正确。
二、产品经理初期关键词（1）行业分析：要想做好行业分析，需要知道WWH（who、what、how）方法论：Who需要你知道分析的渠道来源是哪些，What需要你知道分析的内容是哪些，How需要你知道分析如何评估。
渠道来源（who）：百度指数、微信指数、艾瑞指数、易观数据、行业论坛。
分析内容（what）：行业背景、行业发展、行业领军、行业需求、行业产品、解决方案。
分析评估（how）：专业易读、数据可靠、理解透彻。
（2）市场分析：要想做好市场分析，需要知道市场分析的目的是为了什么？本质来说就是为了赚钱，无论是分析行业背景、市场现状还是商业模式等方面都是为了赚钱。
作为产品经理主要是做什么呢？不需要进行细致的分析，细致的分析有市场人员去做，我们只需要有一个大致的把控：市场现有阶段、市场现有规模、市场未来前景、当前竞争态势。
市场分析四步走方法论：行业背景、前后市场、用户分析、商业模式。
行业背景：PEST分析、行业技术、行业预测。
了解B端产品经理产品经理产品运营思路
了解B端产品经理成功的产品必须合并内部和外部成分的所有不同的层面，协调地支持所有可见和隐藏的服务和操作。
产品存在于一个复杂的交互网络中。
——唐纳德·A·诺曼《设计心理学2——如何管理复杂》1.1 什么是B端产品在B端或者to B中，B代表Business，即商业。
所以，B端产品要符合商业组织的战略要求，能够满足商业用户需求，将已有商业运行逻辑进行系统化、信息化、高效化处理。
说得简单点，就是B端产品让企业更舒服、更快捷地运转，从而向消费者收费并提供服务。
B端产品可以为公司管理服务，也可以为公司运营服务。
为公司管理服务的B 端产品包括HR系统、OA系统等。
为公司运营服务的B端产品包括供应链系统、ERP 系统等。
可以说，B端产品出生于商业逻辑和运营的娘胎，从生下来的那一刻就注定与商业有血缘关系。
B端产品和C端产品最大的相同点，都是要为用户提供价值。
只不过C端商品是直面用户，而B端产品要曲折一些，比如给用户更快地送货，就需要优化订单系统、仓库生产系统、运输系统等多个系统。
B端产品和C端产品的不同，还体现在以下3点。
●产品的使用者C端产品是面向大众用户的，谁都可以用，比如微信。
C端用户数量，需要通过运营推广来不断扩大。
B端产品是面向企业或者商业领域内特定范围的用户的，使用者非常少。
比如，公司内部的薪酬管理系统，可能只有几个人使用，以管理工资。
与扩大C端用户数量相比，B端产品更看重特定使用者的深耕细作，不断挖掘B端用户的需求。
●产品的提供者C端产品的提供者来源于市场，用户都是通过应用市场或直接登录网页，来获取产品和服务。
B端产品可以由企业内部团队来开发，比如ERP（Enterprise Resource Planning，企业资源计划）、SRM（Supplier Relationship Management，供应商关系管理）。
也可以向市场采购，比如SaaS模式（Software-as-a-service，软件即服务模式）、菜鸟的开放物流平台。
产品经理-B端功能初级方法论
B端功能初级方法论当自身经验不足，但又遇到“特殊”的功能需求时，可能会看上去力不从心，不知从哪里着手解决问题，这对我们的也造成了一定的阻碍。
想必每一个刚开启b端或从c端转b端的产品察觉到经理们都会遇到一个困境：做一个功能想要找到最优解，但没有可参考的对象。
胸中欲装山海，却拔剑四顾心无所适从。
b端的封闭性导致了我们看不到好的应用/好的管理系统来当老师，更多的时候是自己脱离现实，根据以往的经验去解决。
如果经验不足又遇到“特殊”的功能需求，就会无从下手。
我曾经就陷入这样的泥沼里，一个月苦思冥想，一次次的否定自己，没有输出。
偶然我在策略产品经理的视频中其，看到一个很有意思的模型。
这个模型在我无法输出成果的日子里，仿佛上帝打开了一扇窗，让光照了进来。
在讲方法论之前，我有心先谈谈业务逻辑。
这是b端的核心，也是方法论的前提。
无法理解业务逻辑不会停留于表层，更深层的细节其实就是产品经理挖掘需求的产品设计过程。
有一个笨办法是场景模拟太帅并取舍过程的每一个细节。
模拟发起者的动作，模拟承接者的动作，模拟中间发生意外情况，模拟最后的收官动作。
及时处理记录下你下要想到的每一个细节点。
就像做一个演员，自己写好剧本代入其中。
不要业务部门说什么你就听什么，那和传话筒没有区别。
业务部门只是帮助你恒温性致新了解业务走向，补充一些生僻的使用细节和共同敲定讹误你方法可行性的。
我们以投诉管理业务为例，表层是后台有一个展示投诉单的地方，投诉专员可以上传投诉结果并完成。
更深层的细节是：投诉单是否要根据不同的投诉场景进行分类？投诉单的重要安全级别如何定义？投诉按照什么规则分配到相应的投诉专员？投诉带来的赔偿损失是否要界定到内部人员责任并进行记录？等等。
需要声明的是，初级方法论只能做到简单知识论粗暴的解决当下的问题，它并不是最优解，绝无仅有也不是市面上最出色的解决方案。
但你可以入选为努力让它有望成为最适合你们公司的解决方案。
我把它分解为四步：目标-输入-输出-结果。
产品经理-B端体验细节(二)通用性图标统一的秘诀
B端体验细节（二）通用性图标统一的秘诀通用性桌面的统一对于B端体验来说是很重要的，本本为我们分享了“上传、下载、导入、导出”这四种图标按钮如何统一，希望对你有帮助。
在企业级设计规范建设中，我们会遇到相同功能的能操作，不同各异设计师用了不同的图标按钮去设计，如下所示。
这会导致用户在操作时产生疑问，同时会降低用户对产品的信任程度。
如果我们只是告诉产品负责人，我们要统一这些界面按钮，这个操作图标按钮长这样，那个操作方式图标按钮长那样，产品负责人是很难接受的。
一方面，每个人对于同一个图标的任一想像是不同的；另一方面，如果冒然替换图标，可能会导致用户学习成本上升，引起用户反感。
那我们是如何让这项工作顺利下去的呢？我们进行了图标图标的认知测试。
本次我们选出了界面上最常用且分歧最大的四种图标按钮进行统一，分别是“上传、下载、导入、导出”。
实施的步骤为：在我们的企业级图标库中，有6种认知较为相近的图标按钮已经提供给设计师使用很长一段时间了，也即在家电产品上已经广泛使用得起来。
由于当时没有哪种图标在什么场景下使用，导致现在这6种图标野蛮生长，因此现在要去规范它们，不可以改动太大，避免大幅动到客户习惯。
我们先收集了产品使用的情况，如下图。
从图中可知，产品认为1号图标是导出含义的最多，认为2号界面是导入的最多；产品认为3号图标是下载的最多，认为4号调色板是上传的最多。
5号图标和6五号图标产品选用的桌面概率非常低。
但产品使用只带代表产品设计师在图标的选取上，倾向以上图中的方案结果，并不代表用户对图标的原始认知。
笔者提出通过调研来整体看下用户在这些图标上会怎么选择，他们倾向于哪种结果。
我们设计了“现场答题”和“线上问卷”的方式，来收集用户的认知反馈。
“现场答题”我们采取了用户在图纸上舌战直接连线的方式，虽然方式很古老，但这种方式可以很直观的感受到用户的操作过程。
“线上问卷”工具采用的是腾讯问卷的方式进行。
由于目标很明确，因此调研题目设计上非常直白，客户直接进入就答题，干扰没有过多其他基本信息填写的干扰。
B端产品经理的金字塔能力模型
B端产品经理的金字塔能力模型B端产品的能力模型是如何构成的？本篇文章中，笔者梳理了B端产品经理的职业发展历程，并对各个阶段的能力进行了分析总结，与大家分享。
工作这几年，时长思考，作为B端产品经理自己应该具备什么样的能力？虽然工作依旧在有条不紊的进行，但是时常会陷入到对知识或者能力的焦虑当中。
特别时是工作三五年，产品经理进阶门槛时。
虽然产品经理的能力是经验的产物，但是产品经理依然需要学习各种技能，以备业务需要。
虽然界定产品经理段位并不仅仅是其所掌握的技能，但是如果不具备某些能力，产品经理是很难进阶的。
作为B端产品经理，我们的日常工作是非常繁杂的。
从需求到业务，从调研到迭代，我们时承担多种职责的角色。
这通常会使我们对自己应该掌握和加强的能力所产生困惑：好像这种我们应该会一些，那种我们应该也需要会一些。
在伴随着工作年限增加时，难免产生疑问到底什么才是我们的核心竞争力？B 端产品的能力模型，究竟是如何构成的？在与好一些前辈和同行朋友交流后，我总结了一些，我认为在B端产品经理各个生命周期应该具备的能力或者掌握的技能。
根据互联网行业的传统，我将这些能力分为产品经理初级阶段、中级阶段和高级阶段的。
整个产品经理的能力模型是成金字塔形状的。
初级在最下层，中级居于中层，高级位于上层。
金字塔模型对产品经理这个职业还是蛮形象，从底层的初级到顶层的高级，就像食物链，越高级，人员所占的比例越小。
同时，该金字塔模型也表示，越初级需要掌握的技能越多，相对也更简单；而越高级，掌握的技能越少，但是更为复杂。
产品经理从初级到高级，从底层到顶层，也代表经验积累的过程。
在我构建的B端产品经理能力模型中，初级阶段的产品主要包含基础产品技能和业务分析的能力；中级产品经理主要偏向产品架构和项目推动的能力；高级产品经理需要掌握产品解决方案的设计和对行业的深度认知。
总结说来，初级产品经理是产品设计方案的执行者，中级产品经理是产品的设计者和团队润滑剂，高级产品经理是产品方向的掌舵人。
产品经理产品设计-B端需求决策模型及实践指导
B端需求决策模型及实践指导提升消费需求决策的质量或业务决策的质量是产品最重要的必修课，保持高质量持续高质量的执行者水平，需要保证团队的效率，提升公司目前内部管理效率。
需求决策质量智囊团对个人和团队效率都起到杠杠作用，好的模型可以降低对个人能力的依赖性，减少变动变量，减小减少需求决策过程中的不稳定性，持续提升需求决策质量。
需求决策是家电产品经理的经理基本重要的工作，这部分工作影响了后续成倍的工作量，对团队工作的质和量项目组都起到杠杠作用，融资需求决策的正确率影响了资金来源团队/公司的效率及机会。
市场需求决策在没有框架需求指引下，高度依赖产品经理的个人性素养经验及素质，并且即便是单个系列产品产品经理，面对不同的场景这时，其需求决策的质量受限于其经验和知识背景，也具有一定的不稳定性。
需求决策模型可以将需求决策过程核酸中的影响因子提炼出来，将部分的因子通过产品团队整理固定共同迭代变成和变量而非依赖个人则判断的可变变量；通过需求重大决策过程的把控，降低个人重大决策的不稳定性，大幅提升需求决策的质量；通过决策过程中的中间输出结果整理，也可以让相关人员或其他产品经理协助识别需求识别系统决策过程中所可以的判断错误，进而提升需求评审环节时的有效性。
B端产品普遍是付费产品，B端商品需求的决策很可能会直接影响续约或新签，而部分对用户有很大价值，但对续约或新签没有资产价值的功能优先级也可能会低。
B端需求决策模型上所，公司商业价值影响不利因素品牌效应更大，如对续约的影响，对新签的影响等。
而C端产品完全免费在刚开始整体而言是免费产品，更多的考虑用户价值，较少的重新考虑商业价值，而后期即便考虑商业价值，商业价值和消费需求功能竞争优势之间的关联性较B端也是相对弱。
因此，一些C端常用的KANO模型、四象限模型可以作为判断用户价值的辅助，而不能随意应用于B端需求决策模型。
KANO模型四象限模型1.基本框架：用故事地图梳理短期固定变量B端需求决策前，最重要的是梳理清楚业务逻辑，这里的业务逻辑包括主要包括业务剧情、业务场景、业务场景中涉及的功能特性，销售业务在商业中的价值，以及战略定位。
一文看懂B端产品和C端产品
⼀⽂看懂B端产品和C端产品⼤纲什么是B端产品什么是C端产品为什么会产⽣B端产品和C端产品怎么判断⼀个产品是B端还是C端B端产品和C端产品存在哪些差异C端产品经理如何向B端产品经理转型写在最后什么是B， Business，商业、组织什么是B端，通常为企业内部或商家使⽤的系统和平台，如ERP系统、财务管理平台等B端产品的主体⽤户是组织，由⼀群不同⾓⾊的C构成，不同⾓⾊的C有不同的⼯作职能，有不同的⼯作场景，也有不同的需求，⼀般不同的⾓⾊C之间有职能或者业务上的关联性。
B端产品需要解决的是不同职能的⼈群在不同场景下的需求，⽽且场景之间具备不同程度的关联性，要求更全⾯。
什么是C， Consumer（也可理解为Customer），消费者、⽤户什么是C端，通常为消费者、个⼈终端⽤户使⽤的客户端，如淘宝、微信、⽹易云⾳乐等C端产品⾯向的客户往往是⼀类具有相似特征的⼈群，他们往往具有⾼度相似的共性属性、场景、痛点和需求。
C端产品主要解决的是某⼀类⾼度相似的⼈群在⼏个主要场景下的痛点需求，会更聚焦。
为什么会产⽣B端产品和C端产品？（1）⾏业的发展需要进⾏产品的细分任何⾏业或者产业发展到⼀定程度，都需要进⾏⾏业或者产业内部的细分，在⾏业越发成熟的今天，⾯向不同产品也需要进⾏细分。
（2）熟知产品特性，才能够更好的去设计产品B端产品和C端产品存在着差异化，只有熟练了解差异的本质，才能够将产品设计的贴合实际，贴合实⽤。
怎么判断⼀个产品是B端还是C端？判断⼀个产品是B端还是C端，最简单的判断⽅式就是看产品向谁来进⾏收费，企业付费的就是B端，消费者付费的就是C端。
⽐如HIS系统—医院付费、财务管理平台—公司付费、Tower系统—企业付费，都是B端产品。
⽐如⽹易云⾳乐、爱奇艺视频、印象笔记、得到、⽹易公开课，这些都是个⼈付费产品，都是C端产品。
B端产品和C端产品的产品特性有哪些差异?（1）应⽤场景C端产品主要是为“碎⽚化时间”服务的，⼀个⽤户不会花很长时间在⼀个产品上，⽽是将时间碎⽚化到很多个产品上。
产品经理产品设计-B端产品经理必修课组织架构设计与销售管理
B端产品经理必修课组织架构设计与销售管理笔者从B配件端产品经理理解业务的视角出发，梳理分析了组织架构与销售管理相关的概念、结构、要素等实用知识，与大家分享。
作为一个B端产品经理，理解业务显得尤为重要。
原因在于它解决的是用户关键问题在业务经营管理中遇到的问题，如果你对负责的业务不够了解，甚至对产业术语也一窍不通，那么在调研目标用户需求与业务场景把握上会显得无从下手。
以CRM产品经理为例：CRM产品实际上解决的核心问题是以客户为中心，通过信息化手段针对销售业务流程的各个环节进行管控，而这如若其中信息化管理的手段是工具而非最终目的，我们是想要希望它能够赋能销售管理，相当从而更高效的完成业务增长。
因此了解了销售管理体制知识，将对CRM产品的规划与设计有所帮助。
从这篇文章开始，我会分享几个CRM产品经理必备的销售管理知识来和大家一起学习。
这一期我们来深入探讨一下销售组织机构。
销售组织是组织形式的一种，在探讨销售组织工作前，我们需要先对组织的概念具备一定认知。
那么组织机构产生的意义是什么？下面我就从一个日常的例子讲起：西餐厅我们在路上经常能看到一些大大小小的餐厅，设想他们是如何一步步发展起来的呢。
创业初期，他们可能是第二家小的唯一一家煎饼摊，每天早上自己一个人备好食材、炉灶等器具。
城中村移置一辆小推车到小区门口等待顾客。
争取时间在这个阶段他由一个人圆满完成从食材准备、接待顾客、到制作早点、收钱等一系列动作。
后来这家煎饼摊渐渐在小区附近有了一些名气，顾客开始也常光顾这里，而且时不时还会带一些自己的亲戚朋友来这里品尝。
此时在前小推车前开始入夜了长队，生意红火起来，但与此同时也带了一些新的烦恼。
因为是专营煎饼摊，大多数的人都是赶在上班路上购买。
长时间可以的排队会造成用户的数以百计流失，很多人一看到队伍很长就选择了去其他家，实际上每个月最终的收入还是没有不会实质性提高。
煎饼摊老板也意识到了这一点，提议他决定找个人来给自己帮忙。
产品经理产品设计-B端产品如何进行业务流程的梳理与绘制
Ｂ端产品如何进行业务流程的梳理与绘制编辑导读：B端是近几年的风口行业，各大企业和巨头纷纷入场，希望能挖掘出市场的最大价值。
而B端的用户需求与C端有很大不同，如何成功进行需求分析，梳理业务流程呢？本文我对此发表了撰写自己的论断，与你分享。
在上一篇文章《Ｂ端产品需求的3个层次，你都了解吗？》中，我讲到：在用户需求与品牌需求之间（也就是把用户下部需求转化为功能需求的中间）有一个重要的过程叫做：需求分析。
这个过程，容易被工作等待时间党务工作不长的产品经理忽略；又或者，这个过程需要解决的问题，容易被工作时间不长的产品经理产生误解。
误以为需求分析的目的是：预测分析软件系统如何实现用户的需求。
然而并不是这样。
实际上，需求分析的目的是：业务分析。
也就是：型式可以选择一种以业务为导向的方式将零散的、不同颗粒度的需求串起来，形成一个完整的、内容清晰的框架，指导后续相关人员的产品设计、产品开发工作。
业务流程是需求分析伎俩的大多手段，它可以产品人员系统性的厘清思路，和相关人员沟通达成共识。
这篇文章先讲“业务流程”分析需求的方法（其它3个思考模型，再另写3篇文章单独详细要说）。
关于业务流程，我将从以下3点详细讲解：接下来，我一个一个的讲。
这里我们先对业务流程做一个定义。
百度百科内控对风控的定义是：业务流程是指，为达到特定的价值目标而由不同的人分别共同完成的活动。
活动之间不仅有严格的先后顺序限定，而且活动的内容、方式、责任等也必须有明确的指明安排和界定，以使不同活动在不同岗位间转手交接成为可能。
从业务流程的定义里，可以找出业务流程包含人力资本的要素如下：1.角色女角业务流程里的第一个基本元素就是角色，有了角色才会有分工、有协作，才能完成特定的资产价值目标。
2.活动也特指具体做的事，每个角色都会有具体需要做的事。
3.协作一家公司或者说一个组织里面，不同人做不同事，最终通过协助才能完成一系列的事。
而且的协作方式，有并行、也有串行（也就是可以在同一时间完成，或者是不同的时间段里如期完成）。
b端产品经理职责
b端产品经理职责
1.了解市场需求和用户需求，制定产品策略和规划
2. 参与产品设计，制定产品需求文档和原型设计
3. 管理产品开发流程，跟进项目进度，协调开发、测试、设计等相关团队
4. 负责产品上线前的测试和验收，确保产品质量
5. 监测产品使用情况，收集用户反馈，不断优化产品功能和用户体验
6. 分析竞争对手产品，制定竞争策略，提高产品市场竞争力
7. 与销售团队合作，制定产品营销策略和销售计划
8. 培训渠道和客户，提供产品相关知识和技术支持
9. 监测产品销售情况，分析市场反应，不断优化产品销售策略
10. 跟进客户投诉和问题，解决客户疑虑，提高客户满意度。
以上就是B端产品经理的主要职责，需要综合考虑市场需求、用户需求、技术实现、竞争对手等多个方面，协调各个团队，提高产品的竞争力和用户满意度。
- 1 -。
产品经理产品设计-B端产品,四招搞定老板不靠谱需求
B端产品，四招搞定老板不靠谱需求本文从客户、服务部门、竞品、历史数据四个店主部分阐述如何应对老板的不合理需求。
小张是一名B端产品经理，负责了这款快消品行业的SaaS产品。
有一天，老板找到小张：做一个微信收款的功能吧，销售人员在APP提交订单以后，生成一个收款二维码，让客户微信扫码付款。
这样一是收款效率高，二是财务也容易管理收款。
听起来是一个挺符合逻辑的需求。
然而小张心里虽打起了鼓：酒保上个月非要求增加建议一个短信功能，结果推出来以后根本没人用，劳民伤财不说，还打击了小组的士气。
但是，也不能直接拒绝老板的要求啊。
究竟怎样才能说服老板呢？小张皱起了眉头。
B端产品和C端产品的最大差别在于，企业的需求往往是客观存在的，很难去开创或者催化；同时，企业行为的特点是理性，企业的需求往往是收入和控制成本，因此具体的需求往往和所在行业、客户群体、竞争环境等密切相关，相对独特和复杂，远非在办公室演译就可以搞得清楚的。
如果酒保的需求经过了详尽的调研，或者着重于大量客户的反馈，那么，你可以相信这个需求是靠谱的；否则，更大可能性是不靠谱的。
老板往往可能需要快速决策，因此缓冲他的决断很多时候都缺乏数据支撑。
我们如果能够站在老板的角度去思考，给老板提供可供决策供的事例和数据，那么即便一开始老板还一意孤行，但是折腾几次此后，他就能听进你的意见。
因此，说服老板，要站在“帮助老板决策”的角度思考问题：1.让客户说话B端产品经理很高产品销售要有自己的“个人核心用户”。
所谓个人核心用户，就是当你在产品设计构思和设计一款产品时，能够帮助和他们紧密保持密切沟通的客户。
个人核心用户是有一定门槛的，最好是客户的管理层或者决策层，并且深度使用你所负责的产品。
个人核心用户的意义很大。
在构思产品套件的时候，他们可以帮助你判断是否有做的投资回报价值；在绘制产品原型的时候，他们可以已成产品体验官，帮助你处理好功能的细节。
当然，作为回报，你也需要亲自服务好你的个人核心用户，让他们感受到自己被重视。
产品经理B端原型绘制入门
编辑导读：原型设计是每一个产品经理的必修课，作为B端产品经理，如何做好一个逻辑清晰的B端原型呢？本文作者从三个方面进行分析，与你分享。
上一篇文章《如何快速接手一个甲方项目》讲到新项目如何快速接手，且快速梳理，这篇想说下在项目原型，脑图，逻辑都齐全后怎么绘制B端原型，毕竟设计到落地还是需要很大的一个工程，借这篇文章也对自己最近的原型设计踩的坑进行一个总结。
比如“评价管理”这个词，大家直接能想到这个页面需要对所有的评价进行统一管理，评价有很多状态，每一个状态都需要在后台进行后续的操作，也就是需要在评价管理页面进行各种状态判定，且不说程序上逻辑上处理的复杂情况，从用户角度出发这样友好吗？用户需要遍历自己需要的评价状态，且不能统一管理某种状态评价。
对于“评价管理”我们应该优先想到的是好评，差评，这是我们随便就可以想到的，但对于系统来说必须想到所有的状态，因为但凡有一个状态想不到后面的流程就走不通或者会重构。
除了好评，差评还有追评，追评的前提是差评才可以追评，好评肯定没有追评，那么这时问题就来了，何为好评？只有五星才是好评吗？四星呢？三星呢？二星呢？所以涉及到了一个中评的概念，这四个才是“评价管理”的完整状态。
评价情况列出后再去考虑系统业务，系统要实现什么？在原型设计上如何体现？再拿评价系统举例，我们先设想一个问题，为什么大家见很多的评价系统都有“追评”这个功能？存在及合理，追评最简单的场景是，用户差评了，我们需要让用户再次追加评价，将评价变为好评，这在网购平台经常可以看到，评价会影响商品和店铺的权重，还有一种场景就是“误评”，用户买完商品了或者是用户办完业务了，文字说的是好评，但手滑打了差评，这是追评的两种场景。
然后我们在结合着两种场景去考虑追评业务，比如第一种情况的话，我们怎么能让用户追评为好评，这个操作和记录应该怎么在后台体现，如果是第二种场景，又应该怎么在后台体现，会涉及到那些功能模块和哪些字段。