长文：一文看尽ToB产品全景像

概念：

ToB（To Business），即对商家（泛指企业）的产品

ToC（To Customer），即对消费者（泛指用户）的产品

ToB黄金时代的到来

移动端的流量红利是互联网上半场创业市场繁荣的根本原因，海量的新流量，从供给端拉低了平台产品的获客成本。然而到了2018年后，移动端增速见顶，预示着移动互联网进入“存量残杀”时代。而与之相对应的ToB市场呈现出截然不同的趋势特点。早在2016年，美团王兴提出了“互联网下半场”的概念，他提到：“美团点评作为国内最大的互联网餐饮平台，过去几年做的只是很薄的互联网化，即帮助企业引流。接下来要实现和行业的深度融合，全面帮助它们提升效率，降低成本。”历史之势从来不是无心为之，那这次为什么是ToB呢？就在2019年，中国人均GDP正式迈入1万美元梯队，这是中国发展四五十年产生的奇迹。但在对成绩感到骄傲的同时，外部富有针对性的遏制措施越来越多，霸权思维主导的国际秩序下，民粹、贸易保护主义抬头。强者间斗而不破，开始进入全方位的战略竞争期。在内部，劳动力受旧政策、新环境的复合影响，出现断崖式下降，成本不断攀升。导致低端制造业比较优势丧失，相关产业逐步转移至东南亚、印度、巴西等地区。中国制造的升级需求急迫。还需要清醒认识的是：“中国的科技实力、大学教育、基础科学，相比西方仍然有巨大的差距。”应该避免盲目自信稀释了专注度。宏观层面，仍高度依赖发达国家的高科技产品（进口）；中国智造想要迈向全球，也还长路漫漫。微观层面，传统行业信息化水平低、企业管理粗放、诚信体系缺失、供应链效率不足，制约着中国从量到质的转型。这是未来10年必须要变革的难点，也是ToB赛道的历史机遇。

1.ToB产品面面观

人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。

1).如何理解ToB中的“B”

B从字面解释，应该是Business，也就是商业。站在商业模式的角度来说，ToB中的“B”指代的就是从事商业活动的商业机构主体，可是站在产品的角度来说，并非如此这么简单。许多做ToB产品研发之后，发现产品根本无法卖出，其背后的原因是B端重要决策者不愿意使用。因此，这里强调的ToB，更准确的描述是“商业机构中的核心决策者或者意见领袖”。这也是为什么ToB的很多产品都需要非常强大的市场销售体系，需要针对B端机构中最重要的那个决策者进行定向营销，从而影响他的决策。这个关键的决策者可以是老板本人，也可以是某个具体业务的负责人。无论如何，这个角色都是ToB产品能够走出去落地的关键。

❖ 客户与用户

通常我们将ToB产品面向对象称为客户，ToC产品面向对象成为用户。

• 客户是理性的，用户则偏感性 ToC产品促销是一大法宝，为什么很少听说有ToB的产品在搞大促销。原因很简单，一是企业采购是有计划安排的，不太可能刚好就在促销的时候企业就需要采购；二是企业的采购是要考虑投入产出比的，不会因为打个小折就决定采购。
• 客户关心的是ROI，用户要的就是玩的爽 客户更为关心给企业带来价值，因此ROI（投入产出比）很关键；而用户则满足个性的需求就好，不会考虑那么多。

❖ 客户多角度：决策者与使用者

ToC往往购买者和使用者是同一人，做ToB一定要区分客户的决策者和使用者。因为大多数企业软件，决策人跟使用人往往不是同一拨人。决策人通常是这项业务的负责人或者公司老板，使用人通常是他的下属。当然决策人也不是完全不用，可他用软件的频率肯定会比较低。这两拨人都要搞定，既要让老板买单肯定你产品的价值，又要让下面的人真正使用起来，让产品在客户的企业里创造价值。这就凸显了前面提及的客户成功部门的重要性。还需要注意，决策人和使用人有时候利益是冲突的。所以对于To B端的产品经理，在产品设计时到底该偏向哪头，这是个比较有意思的权衡。

2).ToB产品本质：价值理论

好产品就是为用户创造价值。所谓的"价值"，就是解决用户的问题。解决的问题越大，产品的价值也越大。解决问题的深度、广度越大，产品经理的价值就越大。所以，对产品经理而言，一定要找到具有潜力和想象空间的领域，并深入到核心的场景，才可能跟随着风口，成为那只可以飞起的猪，反过来，就会变成那个最笨的熊。回到具体的产品，也就必须要搞清楚每个角色在整个产品生命周期内的核心问题，也就是产品的问题，最终都是"人"的问题——那些受产品影响的人。所以，想要做一个好产品，首先就是要搞清楚谁是用户，然后才有价值可言。

3).ToB产品定位

• To B产品是一种面向生产的工具，企业需要借用产品提升生产效率。并不像C端产品，后者更多是来实现一些人性的需求。可以说，提升生产效率永远都是to B产品作为一个工具存在的最高目标。
• 企业需要B端产品提供一组完整的生产能力，这里有点像串链条。链条中的每个的环节都很重要，缺一不可。因而B端产品的重构上线时间周期就很长，都要等所有链条环节都可用且有效连接并做好润滑，才能上线给客户用。与之对应的C端产品更像是在搭积木，搭好几块重点的积木，这个产品就算完成了，后面可以继续再搭其他块积木，但不影响主要建筑的积木。
• To B产品更多是产品化和线上化。线上化，B端产品的需求来源于线下实际的业务场景，也就是有业务需求，只是现在难以线下手工处理，需要借助线上化的产品来提升工作效率。产品化，则更多是指通用化，每个企业对于相同业务的处理都不太一样，可能因为一些现实情况有所适应。但是作为软件方，我们应该提供通用的产品，至少是行业通用，而不是为单个企业设计的产品。
• 服务也是ToB产品的一部分。To B获客不易,，企业决不能以做To C业务那样简单的售后服务形态，来处理To B业务，也是为什么设置很多服务类岗位（如售前/客服/实施/技术支持等），即使你不是最前线的服务人员，也要有服务思维。对To B来讲，卖出去产品仅仅是一系列工作的开始。要实现产品价值，还有漫长的过程。到了一定规模的To B公司，还会设置一个部门叫客户成功。这个部门就是要针对客户留存，展开维护工作。

4).ToB&ToC产品之不同

5).ToB&ToC产品特点

❖ C端产品特点

• 低边际成本 在经济学和金融学中，「边际成本」指的是每一单位新增生产的产品（或者购买的产品）带来的总成本的增量。在C端互联网平台中的核心业务是信息&服务，当平台已经搭建完毕后，每服务多一个用户的边际成本是很低的，每一个单独的用户个体对于成本的影响因素是非常小的。
• 马太效应 很多C端平台都在业务发展成熟期，无论是借助资本还是借助先发优势，都逐渐形成了高集中度的规模壁垒。而随着集中度越来越高，在相同业务模式下的C端用户越来越聚集在头部平台，而小平台的较难的获客也会逐渐抑制其平台业务边界的扩展，这就形成了互联网的马太效应，使得行业内的两极分化愈发严重。
• 高技术杠杆 技术代码不涉及库存和资金流占用，对于C端平台来说属于非常轻的核心生产力，沉没成本极低。通过技术可以快速迭代产品体验满足用户需求、标准化产品流程、降低信息匹配撮合成本、提高交易效率等等。优秀的产品和技术模型架构是各C端互联网平台竞争的核心。
• 网络效应筑产品壁垒 C端产品只有具备一定规模，成为全国甚至全球产品时，用户的需求才能更完整地被满足，它也才有更高的产品壁垒。一个硬币的反面，当一款产品无法通过网络效应提升壁垒时，它的竞争压力也会相对更大一些。试想下，如果淘宝只能买几个城市的商品，你还会去使用吗？

❖ B端产品特点

• 更重商业利益 “付费”对ToB产品的重要性不言而喻。与ToC产品免费不同，用户使用ToB产品更习惯于付费。做ToC产品时，听到的总是“用户”、“体验”、“竞品”、“转化”等词语；而做To B产品时，听到的更多的是“商业化”、“客户”、“收费”等词语。
• 更重业务模式创新 To B产品同质化的情况较少，更多需要在业务模式、商业模式方面上的创新。
• ToB产品理解成本高 由于ToB产品往往是面向专业客户的，所以需要对客户业务有较深的理解，这需要多年的积累和沉淀。因此ToB产品的门槛是非常高的，很多刚入行的人会有较长时间的适应期。
• ToB产品功能逻辑复杂 由于涉及到商业利益，因此To B产品的功能设计务必严谨，比如涉及到角色、权限的功能会比较复杂。如果是平台型产品就更加麻烦，可能还涉及到不同部门的协作、各个模块的衔接关系等，改动起来成本也很高，往往牵一发而动全身。
• 产品设计难度高 目前ToB产品发展较落后、产品功能逻辑复杂、理解成本高、用户量小、缺少竞品、缺少成熟的方法论指导，因此产品设计难度非常高。在业务、功能、技术方面牵扯的过多精力导致无法聚焦于体验方面，再加上设计难度过高，产品的用户体验自然也较差。

2.产品四步曲之“产品规划”

人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。

1).宏观市场分析，确定切入行业

产品规划之初，首先要进行必要的市场分析工作。这里面包括要开展ToB新产品工作的信息，如要进入哪个行业、哪个市场？做个什么产品？盈利模式如何等。提取关键信息：行业、市场（卖者与买者）、产品及商业逻辑。从它们各自定义中看出在一定条件下它们既紧密相连又彼此影响，也不能孤立看待而且要动态看待。

❖ 行业

行业比较重要的一个属性信息是行业规模，行业规模可以理解为市场规模或市场容量，摸清行业规模能够大概估计出企业或者产品的生存空间。企业都希望利润最大化，做一款产品也希望可以获取最大的价值，但是企业顾客竞争者等获取价值都是在宏观环境中运作的，宏观力量和趋势既创造机遇也带来威胁，那么就有必要先做一下宏观行业分析。

• 宏观行业分析，包括自然环境、人文环境、经济环境、社会文化环境、技术环境、政治法律环境。通过分析宏观环境找到趋势从而验证要做什么产品的想法符不符合趋势，大环境下是否可行。比如如果是触犯法律的，产品走不远。
• 预测市场规模，符合宏观趋势，那么就该测量并预测具体市场机会的大小以及增长和获利能力（市场容量）。怎么测量并预测？一般是通过收集相关信息去做估算，比如某个产品的当前需求就可以通过测量特定条件下的顾客群体购买的总数量来预估。一般来说，行业规模的相关数据可以从36氪、艾瑞等等网站获取。有些ToB行业在网上确实很难找到有用的相关数据，这种情况下凭借的就是大领导们在这个行业自身的各种资源积累吧，比如从曾经合作的顾客那儿留有相关的资料信息，记得寻求帮助。

2).微观市场分析，明确目标市场

从以上的分析得出一个行业大体的情况，公司是不能在一个大市场中与所有顾客建立关系，但是可以将这些市场划分成有着独特的需求和需要的消费者群，并且确认哪些细分市场。一般情况下会选择最能有效满足需求那个细分市场为目标市场。细分的主要变量可以是：地理、人口、心理、行为、经营、情景等等。

❖ 细分判断标准

细分市场后要注意判定这些细分是否有效，有以下5个关键标准可供参考：

• 可衡量（细分市场的规模、购买力和特性是能够衡量的）
• 足够大（细分市场的规模和获利能力大到值得为之服务）
• 可接近（细分市场可被有效接近和服务，使用成本不大）
• 能区分（细分市场能被区分）
• 可操作（能制定有效计划来吸引和服务细分市场）

❖ 细分市场环境

细分市场后就得考虑对应细分市场的总体吸引力。细分市场总体的吸引力可以从规模、成长性、获利性、规模经济和低风险等去考虑。分析某个细分市场的吸引力，可结合以下方面分析，这是从竞争威胁层面来分析的。

• 该细分市场竞争者的威胁（有多少，竞争力量如何）
• 潜在进入者的威胁（有没有）
• 替代产品的威胁（有没有）
• 购买者的谈判价格能力增强所带来的威胁（购买者有多少，他们选择的机会多不多等）

在完成分析过程中，就应当识别了竞争，竞争者有谁、各自的战略、目标以及优劣势（主要是各自的市场份额）。尤其要注意竞争者别找错了或漏了强大的竞争对手。关于竞争者可以从不同角度来定义，从购买者在获得和使用产品时的步骤来描绘公司的直接和间接竞争者，可以显示更广泛的实际和潜在的竞争者，凸显公司所面临的机会和挑战。

❖ 公司内因分析

除了上述外部因素外，还要考虑公司目标与资源，耳熟能详的SWOT分析法运用起来，就把公司目标内部资源与外部环境有机结合起来了，就可以确定企业自身的竞争优势、竞争劣势、机会和威胁。这个时候进入某个细分市场做某个产品是否有意义就会有些眉目。在评估不同的细分市场后，考虑选择目标市场。在一定资源下，一般选择的是单一市场，如果能顺利进入了一个单一市场后，往往都会进行其他考虑：市场专门化或产品专门化或逐个进入其他细分市场，不断更新市场计划等。如果公司实力雄厚，可能就很容易一开始选择市场专门化，针对该细分市场的特定顾客群体开展一条产品线，满足多种需求。比如针对媒体主、广告主，提供一个软件产品满足它们交易的需求，提供一个软件产品满足发布广告的需求，还可以继续深挖哦。选哪种模式之前也是要做一定评估的。

3).目标客户分析，分清用户客户

确定目标市场后，目标市场所对应的目标用户自然就知道是哪些顾客了，毕竟有卖有买才有市场。To B市场，此时一般需要将购买者与使用者分开分析，弄清楚购买者与使用者各自的目标是什么。调研方法有定性分析与定量分析。调研目标购买者一般适用定性分析往往是访谈，也有可能是公司领导去做的访谈。调研目标使用者一般访谈或问卷调查，后期开展功能需求时要基于使用者的使用情景，别yy过度。通过调研，也可建立各自的人物模型，能明确记录购买者与适用者各自的需求是什么。（这一过程可以再次验证修正目标市场是否有足够的意义）

4).竞争优劣分析，明确产品定位

接下来要考虑的就是以什么方式进入目标市场并发展会获取竞争优势。就得清楚新产品自身定位，在这个位置上如何应对竞争。

• 新产品自身位置及产品目标 选定竞争系并分析竞品，结合自身以及竞争对手确定新产品将会扮演市场领导者、市场挑战者、市场追随者或市场补缺者，还是新产品将进入的是一个蓝海市场。清楚了自身位置，就好确定该采取怎么样的产品策略竞争策略，来帮助产品更好地获取竞争优势，能占到多少的市场份额。
• 创建该新产品差异点 创建相似点、差异点，竞品有的我该怎么做、我能否有竞品所没有的。这一点毫无疑问是基于顾客需求来做的。弱者要生存必须实行差异化，这是弱者的基本战略。差异化有助于品牌形象的建立，使之与竞争对手的产品和服务区别开来。“一种名称、名词、标记、符号或设计，或者这些要素的组合”这是品牌的一种定义。
• 确定产品竞争策略，建立竞争优势 在明确产品定位及差异点后，再次思考修正。一方面，可以根据自身以及对手的角色，可以进一步认识自身；一方面也可以从产品对顾客是否有吸引力来判定是否建立竞争优势。有三个基本判定标准：产品特征及质量（产品满足顾客的核心需求的程度）、服务组合及质量、基于价值的价格（模式是怎么样的一般由商业逻辑决定）。这三个要素是适用于衡量to B产品的。毕竟如果这本身就是一个能满足顾客核心需求的产品，服务也还可以，价值设置为0，也就是免费了，这是降维攻击了，对顾客会有相当大的吸引力。

总结：用简短的话语来定义新产品

• 该产品的市场规模如何
• 该产品解决了什么问题，满足了谁的需求，有什么创新
• 该产品能获取怎么样的竞争优势
• 该产品将能占领多少市场份额

5).主导产品思路，确定产品路径

定位产品后，寻找合适的主导产品的思路，有可能需要思维导图或出简单的原型图来辅助设计产品。然后规划产品的蓝图，毕竟谁都希望做的是一个可以走得更远的产品，思考优先级排好各个版本功能。各个版本的核心功能安排既基于顾客主要业务需求、竞争者也会受限于公司资源，做好平衡取舍。这一阶段尤其要注意与开发人员交流沟通。还要思考产品完成后何时推向市场，怎么推向市场。如果根据版本规划开发设计测试销售产品等等，这一系列任务需要团队成员等来共同完成，这就产生了成本。到这步，也会大概清楚了产品什么时候可以完成1.0版本，什么时候推向市场。

❖ 推向市场时机

推向市场时机有多种选择：首先进入、平行进入、延后进入。前提条件是掌握竞争对手的情况得知对手的产品正接近开发工作的末期而你公司的产品的开发工作完全可控，还清楚各种时机进入可能面临的优势劣势。这样就有得选择，推向市场的时间点也不一定是产品测试完了的时间点。

6).衡量投资与汇报，确实是否做

分析了整个过程后，就可以用总收益减去总成本等于利润这公式来衡量。

• 总收益 总收益基于盈利模式进行测算，在ToB产品方面往往就是这个产品卖给一个客户可以收多少钱，这个是单价；然后看产品自身能占领多少市场份额，数量有多少，得到的数量乘以单价就等于总收益。而有的ToB产品是打算免费的，但是这类产品肯定有它自己的商业逻辑，有它自己的价值，比如用来逐渐建立起竞争优势。
• 总成本 总成本方面，人力、时间、技术、设备、后期维护以及推销、用户使用等等的成本。而所在公司结合自身情况投资多少能在多长时间内占到多少市场份额获取多少回报。

总收益减去总成本得出利润，这样大概就知道了该产品能否在合适时间内获利，回报值不值，所在公司要不要去做这个产品。当然了如果在上述的某个步骤中就发现了有问题行不通无法解决，可能已经可以判定这产品行不通了。

7).研发产品落地，实现从零到一

分析验证了产品是值得做的，接下来这个阶段就是将产品版本规划中0-1版本进行更具体细化甚至修正，重新审视理清业务流程，将业务闭环，将业务需求转化为功能需求，定义功能规则、逻辑规则，也要将功能闭环。从产品经理视觉来看，就是书写并完善产品需求文档。然后评审原型、开发设计、测试、上线。产品走得远，后面就是1到无穷大。此外，如今靠一款产品很难有竞争力，仅仅用产品思维去构建产品，已感觉远远不够，单在产品身上寻找差异点难以构建竞争优势。面对这个现实，需要有产业链思维，需要以产业思维视角去关注整个产业链的逻辑关系，这样会更能构建竞争壁垒。

❖ 产品阶段划分

• 可用 一款可用的产品，是要在客户场景中发挥实际价值的。如果开发了若干个功能，但这些功能是伪需求，那是没有价值的。可以通过打造MVP（Minimum Viable Product，最小可用产品），做价值假设和商业假设的验证。MVP 妙就妙在让你集中精力把最核心的价值流程走通，其它的周边都忽略。资源毕竟是有限的，尤其是在初期，我们需要用最小的成本最小的时间周期去做出尝试，行或者不行，及时得到反馈。MVP 不是 Demo，更不是一个不可独立使用的组件，它更像是你造出汽车前的滑板。虽然简陋，但却实现了你要从 A 到 B 地的目的。通过后续的迭代，从滑板到自行车、到摩托车、再到汽车。
• 可卖 一款产品能做出来到卖出去，这中间还有个跨度。对于一个产品到底如何定价，这是门学问，我相信核心取决于能给客户带来的价值，而不是成本。有些生意不成立，就是在于成本太高，但是客户愿意为此付出的价钱是远低于成本的。还有一个因素是竞争，如果竞争激烈，对于客户来说可做的选择变多，对你的依赖性降低，自然就有了更好的议价能力。许多人把可用和可卖混在一起，可用还没做好，就想卖出去。这样即使卖出去了，客户不能很好的使用出价值来，只会收获负面口碑。
• 规模化 To B 产品能卖出去，不代表可以规模化的卖出去。最早买你产品的可能是关系户，也可能是创新者，他们愿意尝试新东西。可从早期的几个客户扩展到更大规模的客户，就需要考虑组织能力、客户群需求差异等问题。 * 组织能力 首先要考虑的就是组建销售团队，此外市场团队也是需要的。前者需要通过后者获取线索。 * 客群需求 从客户群来说，不同的群体需求不一样。在服务互联网公司时，一般只要产品功能过硬就行，其他服务需求不大。但是面对传统客户，服务、咨询类的全面解决方案就需要了。这就需要不断迭代整个产品和服务体系，不管是产品功能、服务流程、角色分工、管理工具等，全面的提升，这样才能规模化的支持客户。

其他：优秀产品特征

• 产品的切入点要小而准，最好能解决企业中的某个不易被察觉的刚性需求。这样的产品不仅精准地定位了客户，竞争对手也较少，甚至根本没有竞争对手。好处是能够开拓一个新的领域。如果做得出色，领跑者就能够直接占据客户心中的第一席位。
• 产品为用户提供的价值，最好具有颠覆性，就是说使用你的产品和不使用是完全不同的。如果能帮助企业把效率提高或成本降低数倍甚至数十倍，企业很难不使用你的产品。
• 产品最好具有开放性。一款产品带来的服务可能是有限的，但如果产品具有一个开放平台，或者嵌入多款其他产品，就能够跟其他产品一起来提供服务，方便客户使用。而且可以从其他产品导流，有利于产品本身的传播。此外，还营造了一种非常开放友好的氛围，让别人更容易认同产品。
• 产品能够进行自传播为佳。一些有协作、共享特点的产品，既有用户在使用中就会要求合作伙伴加入以共同使用，这种模式使得产品能够自传播。还有一些To B产品十分灵活，本身就能够在小范围的几个人间使用，再借由他们去影响企业使用与付费决策，算是另一种讨巧的传播方式。

3.产品四步曲之“产品设计”

人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。

1).需求调研（三阶段）

❖ 阶段一：需求获取

• 获取方法 * 主动获取（1、市场环境整体调研；2、竞品分析3、问卷调研） * 被动接受，对于被动接受的需求，往往是用户直接提出的需求，通过意见反馈渠道或主动联系产品沟通。 原则：明确目的采取不同的获取需求方式。选择哪种获取方式，跟我们本身想要达到什么目的有关，时刻牢记一切从目的出发，当然获取需求的方式不是3选1，也不是2选1，可以结合。一般来说本身产品的迭代规划往往采用竞品调研分析、问卷调研的方式。产品的原始规划往往采用市场环境调研、同类产品调研的方式在在每一项的具体方式中，根据自身的目的，调研的具体方式也不尽相同：拿问卷访谈来说，明确此次调研主要是为了产品优化的体验项，那么你设计的调研问卷更偏向于体验的问题，对象也更多是实际操作者，如果此次调研的目的是为了整个产品的二次功能迭代，那么调研问卷更倾向于产品功能的延展或改善上的问题（一个原则“问卷调研更多的是调研”，所以在设计问卷的问题更多的是开放和引发思考的问题）
• 明确调研对象 原则：针对主动调研的方式，可穷尽你的调研对象。B端产品的访谈对象不同于C端，B端涉及到的用户角色代表不一样，同一套产品一般不止一个角色使用，他们有可能往往包含着矛盾的需求，为了使需求更全面更合理，那么根据调研的目的要尽可能的选择包含相关所有的对象。
• 明确需求 原则：多问为什么？无论是被动获取还是主动获取，在面对所有的需求时，都需要问自己或者问你的对象“为什么“，据说有一个产品经理思考问题的法则，就是无论任何事情，都连问6个为什么，要多问为什么？直到说清楚原因、讲清楚逻辑，搞清楚环境、搞清楚原因的过程。

❖ 阶段二：需求分析

从产品经理视角看用户：用户不是自然人，而是用户背后的需求合集，这有两层意思：一是产品经理的最终对象是需求，二是需求的承载是人，它们具有异质性（特点千差万别）、情境性（用户的行为和反应会受情境影响）、可塑性（用户的偏好和认知会随着外界不同信息刺激发生变化和演化）、自利性（用户追求个人总效用最大化）、有限理性（用户虽追求理性，但能力是有限的）。这就意味着，我们还要从已经获得的原始需求里抽象分析、梳理整合出真正需要满足的需求，然后找到产品可以做的地方，这才构成了我们作为产品经理和产品设计者的核心价值。那么如何去做需求分析？需求的分析也是层层递进的关系。

• 需求过滤 面对原始需求，哪些才是我们需要去解决的，哪些不需要？而最终留下来的需求才是我们要去解决的需求。可分为两种情况： 【需要解决的问题】： 需求要最终解决的是什么样的问题？需求是正确的吗？需求是真实的吗？需求可以解决吗？需求值得解决吗？这几个问题层层递进，弄清楚这几个问题，基本上我们的需求就能决定其去留了。 【需求最终解决什么样的问题】 未经过训练的人都不是抽象问题的专家，所以在提出他们的需求的时候，往往直接说出感受，或者给出解决方案。大多数人的需求和“要解决的问题”都是需要抽象和梳理的，所以我们要将用户提出的需求，进行抽象。另一个经典的例子就是：用户说我需要一匹马，经过分析抽象才知道用户需求的不是一匹马，而是一个能快速到达目的地的工具。
• 需求舍弃 在明确定义需求需要解决的问题了，接下来我们要思考的是需求是真实的吗？需求是正确的吗？也就是说有没有“价值风险”需不需要去解决。我们可以试着从以下几个方向去思考： 【需求是否存在矛盾？】 要解决的问题和其相关的角色需求或现状是否有冲突：这很重要，尤其是对于B端的需求来说，我们前面提到产品经理面对的需求往往是个人赋予在当前角色和环境下提出来的，人提出的需求都是利己的。往往B端的产品需求会存在，角色于相关觉得之间的矛盾，与上级需求的矛盾，与整体公司管理需求的矛盾，与商业诉求的矛盾针对矛盾的需求，要理清矛盾关系，分清价值，大胆舍弃。 【需求是否只是解决了当时问题？】 就是“产品做出来了，某些顾客也会用了，但后来都不继续用，因为没有满足需求”的状况，此类需求是否需要我们花力气花成本去满足？还是是否可以需要用户麻烦一点。分清需求的长期价值，大胆舍弃。 【是否带来了真实的价值？】 有些需求可能是我们创造出来的需求，来源于我们自身认识的不足，比如我们认为用户一条条删除会很麻烦，想做一个批量删除的功能改善一下，但实际上用户批量删除更容易导致错误删除，而删除的情况并不多，所以此类需求就是我们人为创造的需求。充分认识需求是否真实带来了价值，大胆舍弃创造出来的不能带来真实价值的需求。 【需求的成本和价值检视需求】 此时需要考虑两个问题：当前是真实的需求也能带来价值且长期带来价值，但手边并没有解决问题的技术，或技术尚未成熟，就是「我们知道要做什么产品，但是做不出来」的状况，此类需求也只能暂时舍弃。投入的成本是否大大超过带来的价值：需求不是无边界的，满足超过一定边界，边际收益会骤降。绝大多数情况下，超过这个满意的边界，用户的满意度不会一点儿都不变，但变化程度会非常小。因此我们要关注这个边界并且定义这个边界。

❖ 阶段三：需求整理

• 需求聚合 对于ToB的需求往往都是以业务为导向的，着手去解决分散的需求，往往容易陷入点状里面，此时需要以业务为导向指引将零散的需求串联起来，形成一个完整，内容清晰的框架，以免落入拼命应付解决问题的境地。
• 需求分类 问题不分大小，不分场景，只要是需要解决的问题，都是需求，而需求扽分类有助于我们分清需求的优先级，一般我会将需求分为：功能性需求、体验性需求、二级分类是新增还是优化；他们的重要关系一般是：功能新增 > 功能优化 > 体验优化
• 需求优先级 在需求分类分级的基础上，采用“紧急程度”和“重要程度”互相结合的方法来评价优先级。其中，优先考虑紧急程度，因为To B业务的客户随时在使用你的产品，出了问题都是需要尽快解决的，毕竟“稳定压倒一切”；而“重要”的需求，要看它的侧重点在哪里，是提效，还是降本，还是竞品打击？或者说仅仅是因为KA客户提的，显得很重要？判断维度过多，就表示不是特别“重要”，所以我认为“紧急”比“重要”优先。

❖ 挖掘需求角度

• 从行业（市场需求）看需求 在做To B的时候，首先要瞄准自己的目标客户，自己想做哪些行业，先深入了解这个行业当前的发展情况以及市场发展趋势等，只有了解了客户相关行业的情况，产品才能更贴近与点子上并且持续发展。在设计产品的时候，首先想清楚自己需要主打哪些行业，如果产品是多行业可用的，要先定位好自己想切入的行业，从单点到多点的扩张。很多企业从小做到大都会说，我是做xx起家的，我在xx方面是最专业的，所以其他方面也不会差，类似的道理放在产品需求挖掘和规划中也是。
• 从企业调研中（用户研究）中找需求 ToB不像ToC，用户的量一走目标就是几千万上亿，揣摩用户心理要靠数据分析以及大众心理学等多因素。企业客户的数量一般都是有限的，而能够接受调研的机构也很少。在做ToB的产品之前，不妨花点时间制作用户画像，找到一批现在的客户，认真的做些调研吧！像企业调研这样比较高成本的事情，可能很多产品经理没有经验，公司的经费也有限，可以先自己多演练，调研目标遵循SMART原则，做到调研最大化。如果实在不能去做企业调研，那么可以多和市场销售聊天，ToB很多是市场销售驱动型。销售也是最接近客户的群体，和他们多聊聊天，掌握更多信息。
• 从业务流程（使用场景）中找需求 做ToB的产品，首先一定要摸清楚该产品的业务流程。可以列两个业务流程，首先列出没有自己的产品的时候，整个业务流程是怎样的，什么样的人会有什么样的痛点，哪些痛点如何解决成本和优先级如何。再画一个流程图，列出加入自己的产品后可以到达的效果。当明白业务流程之后，再利用自己的互联网思维改变不合理的现状，提高低效的运转，从而达到需求方的初衷。例如一个财务系统，在流程中不同的人可能会遇见审批慢、报销难等等难题，这个时候要想着如何解决难题，提高效率。看业务流程和场景去识别用户背后的需求，找出自己的使用场景，好的场景一定是可以帮助企业提高效率降低成本的。分析场景的时候也不光是分析当前的场景，还需要看具有增长点的方向，找到一个本身就有一个完美用户增长逻辑的场景，以一种客户能接受的方式为其提供更多的价值。
• 从友商找需求 竞品分析一直都是产品需求挖掘的一部分，也许不重要也不算紧急，但也是必不可少的一部分。在关注友商的竞品的时候，不仅仅要关注友商的功能和发展现状，更重要的是关注友商的生态建立得如何了。ToB相对ToC来说在竞争分析这一块也是多了这一环，大部分的ToB产品，不单单是做自己的功能，如果要持续发展的话，肯定是要做成一个生态的平台型的产品。关注友商的生态，揣摩他们的战略布局，思考自己产品的机会点。产品经理自己也要有生态意识和合作思维，假设一下，如果某一天自己的产品需要和另一个公司的某个产品进行合作，自己要去如何说服别人和自己进行合作呢？合作思维里最重要的意识就是“共赢”了，合作，就是为了共赢，一起增长获得利益。在和合作伙伴交流的时候，要更多的强调他们会得到什么好处。
• 从技术难点找需求 为什么说ToB的产品经理相对于ToC来说，多半都是要有技术能力的。这里说的技术能力不是指产品经理要会写代码、懂细节，而是产品经理对技术理解以及技术转化的能力，需要具备本业务领域相关的技术知识，知道有哪些新的技术点，有哪些业务需要用更优的技术方案。很多时候，一个新的技术的出现，可以大大的提高企业效率，成为B端行业的“爆款”。B端产品一般都是技术驱动业务，业务驱动产品，运用技术和产品达到核心目标——业务。多多研究技术，和技术研发经理讨论技术难点，对产品的推动也是有大大好处的。
• 从全球化市场找需求 当前很多产品都在做国际化，随着互联网的发展国际化是个大趋势了。在做当前的产品需求的时候，可以多想想自己的产品什么时候可以做到全球市场，国际市场是个什么样子。也有些产品，可能在国内不好发展，从国外回源反而是一条路子。

❖ 判断需求维度

• 有没有 判断某个产品需求，先看它是不是解决“有没有”的问题，而且还要再加上竞争对手的因素。客户提出这个需求，肯定是因为现有的产品功能和服务，真解决不了这个问题，必须开发出来才行；还有就是市面上就你一家服务商的话，客户没得选，人家也正用着呢，那就等等吧，没办法。但实际上能挣钱的生意，肯定不止一家来做（除非是特殊行业），客户有的选，竞品有这个功能，你没有，在这个市场就站不住脚。所以，解决“有没有”的优先级应该是最高。
• 使用效益 这一点是看这个产品需求的实现，对客户使用上的最终效益影响如何。一般有这么几个影响：增加收益、降低成本、提升效率、品牌增值……优先级排序也是按这个来： * 能多赚钱、少花钱的放前面，所以营销类的功能、服务额外重要； * 减少工作量的是产品使用者最在意的点，但可以稍微排后些，通过“拖着”来安抚客户，除非这个操作体验真的很恶心； * 品牌增值的话，前提是看服务方的影响力，国内很多企业倾向于使用oracle、SAP，就是看中无形的品牌增值效应；
• 便捷与美观 便捷问题，一般有两个原因：一是产品设计不合理；二是售后培训不到位。客户是没错的，可能他理解能力有偏差，可能习惯了别的操作方式，但是只要反馈产品不好用，后面是肯定没什么信心继续用的。所以“便捷”的第一要求是“上手快”，排较高优先级。 美观问题，因为To B产品先得让客户用起来，持续使用产生效果，人家才考虑要不要续费。“好看”是客群使用状况稳定、竞争压力不大的背景下才考虑的问题。此类问题优先级排后，当然丑肯定是不行的。
• 提交时间/次数 积压产品需求，需要额外重视。因为很多To B业务按年收费，攒了很久的问题都没处理掉，到后面不好跟人家再收钱。这就不是服务方技术能力的问题，而是服务态度和运行机制的问题。因此要提高这些需求的优先级。不过放在产品bug的处理上，应该反着来。几个月前提交的bug，一直没方案去处理的话，那就优先解决新提交的bug。给客户的印象应该是“一直在解决问题”，而不是“一直解决不了问题”。这一点，主要是方便前线的同事来做售后服务。当然，某个产品需求/bug已经存在很久，而且是大面积问题，就可以调到高优先级，要求产品研发团队成立专项组来解决。
• 覆盖的客户范围 覆盖范围，可以按几个维度来区分：数量、行业（类目）、地区。同一个产品需求，10家提过到100家提过，说明这是需求越来越刚需；只有这10家提过，那优先级就得靠后。To B产品的客群，一般会有扎堆的情况，或者同行的企业老板、负责人，都有一个圈子，甚至可能是一家子。产品功能的好坏，不用自己来宣传，人家私底下一讨论就能达成共识。还有一个情况就是，某个地区、某个领域，都存在着标杆客户，这家用什么产品，这一片客户也会跟着用这个。所以在确认产品需求的时候，一定要搞清楚：这需求谁提的？影响力怎么样？
• 竞品动作 涉及到竞品因素，在分析产品需求时，可以参考两个大的原则： * 对方有的，我必须有。能让客户付费的功能，一定要搞出来，哪怕实际用处不是很大。To B的运营要看业绩，市场被人抢了还怎么搞，一定要守住阵地。 * 差异化避免不了，就一定要保持领先。大家都服务同一类客户，或许会打差异化策略，但遇到抢单的时候，核心功能肯定会被用来作比较，这时候就看哪家的功能更落地、效益更明显了。所以，自家产品的核心功能和卖点，在涉及竞品影响的时候，一定是排高优先级。

❖ 需求中的个性与共性

ToB产品设计的最核心方法就是共性个性分析法。就是：提供通用解决方案的同时，满足不同客户的个性化(定制化)诉求。针对通用性部分，因为是通用的，共同的，所以我们可以参照产品设计的方法，按照设计一个产品的思路进行。注意：产品在做通用化设计的同时，应多采用可扩展性强的结构，为定制化功能预留位置。针对定制化部分则较为复杂，要再将定制化功能进行二次划分。我们采用的是重要性、难易程度原则。分为三类：简单定制、中等定制、高级定制。

• 简单定制。改动很小，在表现层的修改。比如颜色、间距、大小、文案，那我们可以快速响应。
• 中等定制。这类则是增加了某个功能点，比如在产品上增加一个新的功能。因此前面说了，通用化设计的部分要采用可扩展性强的结构，这样可以方便定制化功能。
• 高级定制。可能需要改动部分结构，需要一定开发量来支持。这部分需要具体问题具体分析。这类就是针对“高级客户群”，每个团队对这部分的定义不同，需要根据实际情况而定。

2).设计输出

设计输出包括了需求加工的后三个部分：消化—改良—评审。在已获得的需求中，首先提取出需求关键词并明确需求对象，一步一步推导出设计目标并得出接下来的设计策略。在明确设计目标及策略后，开始通过“解构—重构—评估”对产品进行合理再设计。

3).设计验证

数据驱动，不仅适用于C端产品，对于B端产品来讲同样适用，在产品的研发过程中，合理制定过程指标和结果指标，通过数据来调整研发方向。而对于数据的挖掘和关注，不仅仅聚焦于产品的某个功能点，而应结合行业客户画像和产品功能数据做决策。需要明确一个原则，To B产品的功能迭代驱动更多的应该是商业价值，而不仅仅是用户体验。在To B领域一般业界认为，LTV > 3*CAC，即生命周期价值大于等于3倍的获客成本，即是一个相对合理的状态，流失率应该保持小于20%。

4).专题：项目与产品

项目是面向单一客户，具有较强的个性化，而产品是面向群体客户的，具备相当的普适性。

项目做的多了，把各种客户的个性化需求进行通用性的抽象，再进行扩展性的架构设计使其灵活，就逐步达到技术层面的产品化，可快速复制，开发成本低。从项目走到技术层面的产品这个阶段发挥重要作用的是架构人员，如果项目的积累中，不能有意识的进行标准化的设计和扩展性的设计，项目很难变成产品。如果要达到商业化的产品，组织职能上就要建立完善的体系，市场团队，销售团队，实施团队，售后团队等要围绕产品进行建设。同时市场推广策略、定价策略、渠道建设等一系列的经营活动围绕产品展开。

5).专题：从自用产品到通用产品

从自用产品系统演化成通用产品，要比从项目到产品难得多，原因不在于产品本身，而在于公司的背景。除了一些通用型的产品，大部分ToB的产品都是具有行业特性的，自用系统产品化面对的客户群基本上都是和母公司同属一个行业，甚至大部分都是竞争对手。

• 纠结问题 作为产品方，你愿不愿意开放给你的竞争对手；作为客户，你愿不愿意选择你的同行或对手提供的产品方案。
• 解决思路 客户群的选择上可以优选和母公司行业相近的领域，业务相似又没有竞争关系。软件业务从母公司分离出来，股权和管理关系上尽量要更松散甚至更独立一些，商业关系上和原有公司合作的地位与和其他公司合作地位最好放平。协同原公司业务做其上下游的客户，变成原公司主营业务的补充。

6).专题：从ToC产品转到ToB产品

• 建立独立的团队和符合ToB特点的组织模式。用同一套人马做两种风格的事情，毕然会造成思路的混淆，以及组织体系和绩效体系不明确的现象。大公司通过并购的方式而不是内部创业，基本也是基于团队基因的考虑。
• 建立符合ToB产品研发的团队和体系。重视有行业背景或者行业理解力的产品人员，架构人员具备领域设计能力，以灵活的系统扩展性设计为核心。
• 推广模式，市场活动从线上转到线下。从重运营转到重营销的上面来，可以尝试代理商模式，多参加展会，多做公关活动，从影响每个人到影响关键人。

4.产品四步曲之“销售及定价”

人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。

1).商业模式

ToB端商业模式有四类：

• 一是跪着挣钱：做强定制的项目（project）
• 二是站着挣钱：有可复制的产品（product）
• 三是坐着挣钱：年费订阅模式（subscription）
• 四是躺着挣钱：分润模式（commission）

2).定价策略

• 买断式收费 买断式收费是传统软件的模式，因其需要一次性投入大量成本，实施起来越来越困难。
• 按年/月收费 是定价的一种创新，也是商业模式的改进，不需要一次性投入大量成本，促使SaaS公司能够保持良好的服务水平。
• 消耗模式 类似百度的SEM、今日头条的广告平台。这种先存钱再消耗的方式使得SaaS公司与企业使用者之间的绑定关系更为密切。
• 分销售额模式 软硬结合。SaaS软件与硬件系统的绑定，硬件系统的销售或者租借，设备商家将销售额或者租金与软件服务商进行分成。

3).产品定价

关注定价，是产品经理关注产品价值实现的形式之一。产品的定价主要有两种底层逻辑，即成本导向和竞争导向，而一个产品的最终定价策略一般是底层逻辑结合自身情况进行的综合。而定价更能体验出To B产品的不同特点，商业化的本质离出不开竞争，所以当看市场上的To B产品定价时会发现，往往是“竞争导向”为主，“成本导向”为辅，议价空间取决于产品的竞争优势和地位。

4).财务预估

财务模型包含了收益模式、成本结构和利润模式等。简单来说，在准备阶段时可以根据主营收来源，对平均销售能力作出评估，分析团队的营收曲线，测算在销售经验可复制的情况下，团队到多大规模的时候，能够实现收支平衡，进而根据边际收益扩大营收，合理规划编制。然后按照这个模型，匹配资源，组建团队。当然也还要留一定的风险储备，以备问题发生或预案失败。

5.产品四步曲之“产品运营”

人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。

1).运营意义

我们把运营定义为向用户传递产品价值，促使用户的使用、活跃、留存和付费。相较于C端，B端用户更加重视产品的实用价值，在传递产品价值上，手段就会有所不同，而由于B端用户与C端用户主体的差异性，在促进活跃和留存上的手段就会不同。此外，B端运营更加依赖于产品质量。To C产品有句话说“产品不够，运营来救”，然而对于一款To B产品而言，“运营好”是无法脱离“产品好”的。因为产品本身就决定了能为企业带来何种价值以及带来的最大价值，而运营则是实施层面。

2).运营体系

通常可将业务运营分为两个部分，对外与对内。

• 对外来说，业务运营是营销策略、客户服务、培训支持等。要实现业务的增长目标，并为客户提供更好的的业务体验。
• 对内来说，业务运营是流程管理、数据分析、行业/用户/政策研究及运营支持。

对于不同的B端产品，不一定有特别严格的内&外体系的划分，体系模块也是因公司组织和业务而定的。常见模块包括：行业研究、数据分析、运营支持、客户服务体系等。

3).运营角色

B端产品通常不是一个能一次性交付的产品，往往交付后，还需要进行客情维系，质询答复，增值空间挖掘，乃至续费等等。因此，可以根据阶段分为售前、售中、售后三个角色。在大型团队中，售后可能会有客户成功团队负责，而对于规模有限的创业团队而言，我们的客户经理需要同时负责售中和售后，并未设置客户成功经理的角色。这是基于服务周期、资源条件、行业特性（关系营销）等方面的考虑而定的。每家都有自己的服务特征和资源特征，根据产品和服务特征而定就好。

4).渠道运营

对于B端推广渠道的使用，与C端存在着比较明显的差异。首先，在渠道的选择上，B端更倾向于精准触发的渠道，很难也很少会出现大规模无差别的炒作与宣传。我们在进行上线前的渠道选择与推广的时候，一直都是坚持“精准触发”的原则，与此同时，辅之以其他常规的渠道进行品牌宣传。

5).用户运营

B端用户偏理性的属性，在产品推广前期，让获客比想象中的难。获客之后，我们需要跟用户进行大量的沟通工作，且不同阶段沟通的要点也不一样的。

❖ 不同阶段沟通要点

• 前期：这个时候的用户通过网站了解到我们的产品，表示出了兴趣，并进行注册。但因为信息不对称的存在，用户依然会表现出疑虑和不稳定性，所以该阶段的沟通侧重挖掘用户真实的诉求，突出自身产品的差异性和优势，抓住用户的心。
• 中期，用户已经认可我们的产品，就要安排双方进行技术上的调试。所以该阶段如何协调技术资源，如何快速响应技术问题，如何抹平用户对产品功能不完善的情绪就很重要了。
• 后期，用户产品上线后，存在的各类交易问题、系统问题、功能缺陷问题，也需要我们耗时耗力的沟通解决。

❖ 平等态度很重要

所有的沟通，都是建立在双方平等，尤其是对用户的尊敬上，比如口气平和，多用敬语（您、很抱歉……）。通过创造轻松愉悦的交流气氛，能够让用户得到认可和获得归属感，我们产品的价值才得以实现。

❖ 突出自身专业性

B端产品有一个很大的特点就是其专业性和复杂度较高，一般人都不太熟悉甚至完全没有概念。用户在使用我们产品的时候，我们更多的是扮演专家的角色。根据不同的用户分类，有着不同的策略。面向企业用户，有两类人需要从我们这里获得专业的信息：一类企业决策者（老板或则管理者），负责拍脑袋，；一类技术人员，负责实现产品技术对接。

• 对于决策者而言，他们关心的是：你们的费率为什么这样定价、如何进行资金清结算、每种支付产品有什么区别、业务的支付场景是否合规等业务层面问题。这需要运营通过不断的专业学习，形成支付行业的知识积累。
• 对于技术人员而言，他们关心的是：数据传输的安全性是怎么保障的，签名方式是怎么实现的，前端和后端如何实现接入等技术细节问题。这个有专门技术团队解答，运营也需要简单的了解自家产品的内部技术实现方式。

一旦用户有问题，千万不要急着回答，想清楚这个问题到底是谁提的，问的是什么，疑惑在哪里，他需要怎样的回答来说服自己相信这就是自己要的那款产品。答案和解决方案一定要正确要专业，这也是突出公司和产品形象的机会。如果不小心给错解决方案，也不需要太焦虑，谦虚地承认了错误并重新提供更加专业的方案，也会赢得用户的认可。

❖ 快速响应、积极反馈

反馈告诉我们现在处于什么状态，应该怎么做，没有反馈会让人感觉到焦虑和失去把控。企业用户一方面是理性的，他有耐心等待一个解决问题的答复；另一方面等待是需要时间成本的，用户也希望有一个时间期限。不要一味地说，等一下，我们在处理这类模糊没有意义的话，除非你可以在短时间内给出答复，否则用户漫长的等待得不到真实的解决，就会变的焦虑和失控。这里的原则就是，我们应该主动去反馈，而不是让用户苦苦等待和烦恼。

❖ 做好预期，控制需求

倾听用户诉求，进行需求分析，这活一般都是产品经理干的，但事实上与用户接触最多的还是运营，他们才能获取一手的信息。从某种层面来看，运营完全可以充当用户需求分析的角色，就看运营人有没有这样的自我定位。运营怎么平衡产品和商户之间的需求，就是一门很重要的艺术了。平衡的前提，就是一定要了解我们产品目前在公司的战略地位，高层重视程度，资源投入的比重，以及目前产品适用的人群占比。如果产品本身战略地位低，意味着资源少，那么商户的需求就要考虑到重点。如果目前产品已经满足80%的商户需求，那么其他合理的需求就应该纳入到后期的产品规划中去，不合理的自然剔除掉。针对不同的目标用户，如果产品本身确实存在不完善的功能，也要及时反馈给产品，并告诉用户等待我们的新功能。学会适当的画饼，要让用户看到希望和预期，但也要考虑到用户的承受期限。

❖ 关心核心价值用户

长尾理论，说需求曲线的狭长尾部分布着大量的产品和用户，这里是一座机会的宝库。运营的工作非常杂乱，而且时间有限，要实现高ROI，就要服务好20%的核心价值用户。这里存在一个客户价值评估问题。随着业务量的增长，就需要建立用户筛选和分级策略。运营应该快速的判断这个用户：是不是我的目标用户？是否认可我们的产品和服务？对价格是否敏感？是否容易抱怨？预期会带来多大的回报？合作过程是否顺利……。同时根据一些简单具体的规则，比如企业注册资本、背景实力、盈利模式、交易规模、用户数等，来识别核心用户，把更多的资源倾斜在他们身上。要警惕非核心用户，尤其是一些干扰用户，他们可能有无穷的要求和刁难，会不断消耗公司的资源，这类用户必要时要敢于放弃。当然，产品的每个阶段，对于用户的分类标准都是不一样的，重要的是在实践中不断的迭代和优化。

6).数据运营

数据运营，对明确运营方向、制定运营策略、改进运营治理等起着非常重要的作用。大家对数据运营本身也越来越重视，在实际操作层面可将定量分析与定性分析相结合，定量分析为主，定性分析为辅。

• 定量分析，也就是数据分析，可以通过CRM、工单系统等，记录并监控各环节的数据，针对每个环节点，提出优化策略，再进行前后对比，如此反复，即可实现一个向上的螺旋。
• 定性分析，则主要是针对难以形成量化或结构化指标的服务行为而展开，如各个动作的用户反馈、用户体验分析等。

7).其他：解决方案

“解决方案”一词现被广泛应用于ToB领域，可以看任何一家ToB的官网都有解决方案这个条目。解决方案在国内流行开来源于国际上ToB企业常用的“Solutions”的翻译。就字面意思理解，解决方案本应包含实施的对象和痛点。在ToB的解决方案中，通常涵盖：行业痛点/客户痛点，产品优势、方案措施（效果预估）、服务标准（SLA）。这就要求，产品经理和运营销售，瞄准痛点，来讲好故事。不要忽略服务标准，在以往的工作中发现，国外客户对服务标准尤其关注。如何写一份好的方案：

❖ 第一步：明确需求

多数方案的需求来自于领导、客户或销售，对方在描述方案背景、方案目的时候思维和表述是发散的，所传达的信息不充分，如果这时就直接去写方案，写好之后对方会意识到还有信息点没体现出来，往往会因此而返工。因此在方案开始前，需要了解清楚几件内容：读者、需求、现状、目的、信息点。

• 读者 读者就是方案的阅读对象，希望发给谁。有时候方案的读者不是一个人或一类人，是几类人，需要在方案中考虑到这几类潜在读者的需求，权衡各方的利益，满足各方的诉求。对于读者，最好可以对各类读者进行读者画像。用户画像对于产品经理来说再熟悉不过了，一般可从几个方面展开，认知程度，了解什么，不了解什么。认知程度就是对方的文化背景，知识水平等。
• 需求 需求即读者想知道什么，为什么要知道，需要感受到什么。挖掘需求是产品经理的基础工作，并不只是产品设计需要挖掘需求，写文档、写方案也同样需要挖掘需求。挖掘需求的方法可以采用丰田公司的5why分析法，就是对一个问题连续问5个“为什么”，以找到需求背后的根本诉求。读者想知道什么属于what，读者为什么要知道属于why，读者需要感受到什么属于再深一层次的why，利用这种方法，找到读者真正需要了解的内容，找到读者真正的需求，好进行下一步的方案撰写。
• 现状 现状即做了什么，计划做什么，什么不做。计划做什么就是对方的计划，近期计划是你的重点，远期计划可以畅想。什么不做就是对方的边界，对于政府、系统开发商都有自己负责的范围，如果跨出了范围，对方不会对这部分内容感兴趣，就没必要费笔墨费脑筋去写了。
• 目的 关于目的，要理清楚自己方案的主要目标和次要目标，多数情况目标就是为了满足读者的需求，也存在一些情况下方案就是为了抛砖，或者就是为了给对方搞晕，目标不同写方案的粒度和角度都会不同。其次要搞清楚方案的形式目标，是用于演讲还是用于发送阅读，演讲在什么场地上进行，阅读是电子还是打印。
• 信息点 信息点就是要看交代方案的人有啥想法没有，多数情况下给你交代方案的领导或者销售，都会有一些自己的思路，他们是方案的第一读者，需要先听一听他们的思路，思路不对需要给他们掰过来，否则方案都到不了目标读者就会被否掉重新。在信息点里面需要了解两方面内容，一是期望表达的内容，二是切入点。

❖ 第二步：简明扼要的标题

如果是非演讲的文档，标题和副标题至少有一个需要点明主旨。标题不是展示你是文艺青年的时候，读者也不是去意会你的诗意，起一个含义极深的标题，和不用标题没什么区别，白白浪费了标题的价值。

❖ 第三步：编写方案主体

内容要根据上面所述的需求，目的和信息点来决定，内容没有通用规则，需要根据实际情况来。下面几个常见的内容方向供参考，根据实际情况自行选择。

• 背景（可以参考金字塔原理的SQCA，情景、冲突、疑问、回答来描述方案的背景）
• 政法规（即政策、法规、法规，TO G方案常见，公务人员做事参考的标准）
• 产品功能(有时候一个方案会涉及多方用户，一定要在描述产品功能时候告诉读者这个功能的用户是谁，例如智慧城市解决方案里面，涉及到的后台系统，用户是政府部门的管理者，涉及到的APP，用户是城市居民还是执法人员，都需要重点突出，否则读者容易混乱产品给谁来用。产品的用户可以尝试使用UML的用例图来描述)
• 已有案例（有相关案例的话，一定要列上，大部分企业都不想做尝鲜者，有成熟案例落地概率高很多）
• 方案效果（对于领导来说，都是“乐见其效”的，突出效果，突出意义方得读者欢心）
• 方案优势
• 核心流程
• 功能模块
• 资源投入
• 实现周期

方案素材来源

从0到1的编文字很痛苦，如果有现成的文字拿来使用自然轻松不少，反正方案又不查重。查找内容大家最先想到的就是利用搜索引擎，搜索引擎确实是个好途径，但内容比较碎片化，以下两个渠道可以参考。

• 渠道1：解决方案对应领域书籍、白皮书、研究院报告；
• 渠道2：产品领域书籍、白皮书、研究院报告。

❖ 第四步：修改方案

方案写好后需要通篇修改方案，修改方案需要先思考方案框架是不是正确，而后逐字逐句的删词改句；最后切记朗读一遍，把内容改顺耳，很多时候默读、快读确实没问题，一旦朗读就会发现文章的不顺，切记朗读一遍。

6.ToB产品人能力图谱

人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。

1).ToB与ToC产品人差异

ToB和ToC的设计方法其实是相通的，只不过ToB的方法也可以用在ToC上，它对ToC的设计方法论是一种很好的补充，也很容易提升ToC的设计质量；但ToC的设计方法虽然看似专业，放到ToB上却总觉得不够用或用不上。这是因为针对两者，所需的知识结构有所差异。从前面所述的区别可以知晓，ToB产品的专业门槛较高、客户少但角色多、没有成熟的方法论指导、缺少竞品、难以提供数据支撑、产品设计难度大等，这些均对产品设计人员提出了更高、更深度的专业要求。但ToC产品的专业广度要求较高（周期短，需要用到不同方法；用户量大，需要掌握各种专业的数据验证方法；对界面体验的要求更高等等）。所以在业内，To B和To C的产品设计人员还是要多交流、互相补足的。目前这点做的还不太够。当然ToB、ToC只是一个笼统的分法、并不绝对有的ToB产品并不是很复杂，和ToC比较类似；有的To C产品涉及到具体行业知识或功能十分复杂，也有很高的门槛。ToB和ToB之间，更是可能有天壤之别，比如面向客服的产品、面向专业分析师的产品、面向开发人员的产品、面向未来的概念性产品（有待市场验证的）等等等等。

2).ToB产品人的要求

❖ 产品布局

这可以说是所有产品都应该思考的，但是很少产品经理有这大局观，更多的是执行，毕竟没有把产品当成自己孩子，也就不会为自己的孩子考虑未来发展。产品布局是个长远的计划，我们需要知道产品处于哪个阶段，处于哪个区间，上下级区间是什么，因为最后一定是要做平台化和一体化的。另外，to B产品都有个业务--数据--决策的过程，整个产品的迭代开发也要按照这个思路，也就是有了业务基础才会产品数据，有了数据，才会产生更高的价值。

❖ 产品价值观

所有的产品由产品经理一手设计的，都会有产品经理本身的基调，也应该有，这是体现产品和人融合。

❖ 服务意识

产品+服务才是ToB成功的关键。缺少服务意识的产品人，无法做好产品。

❖ 对称交叉的产品技能

需要需求/商业/体验/技术交叉集成的技能。按理来说是所有产品所有掌握的技能，只是在to B产品里尤为突出，综合能力，因为客户+开发+市场+追求，很多因素促使你需要关注方方面面。

3).初入B端职场建议

❖ 相信专家

B端行业中产业属性非常重，主要体现在场景、细节和业务逻辑。想要充分理解业务、提高决策有效性，是需要足够长的项目积累。因此，多向业务专家学习，吸取领域知识，有助于快速积累成长。

❖ 心怀敬畏

与C端不同，B端对应的业务模式都是依托于产业的业务场景，想通过互联网产品较为擅长的重构系统设计来颠覆业务模式是行不通的。对前辈和行业要心怀敬畏，在推翻前考究清每个产品设计细节的业务背景，能够帮助你做出更准确的决策。

❖ 独立思考

对专家、前辈的信任敬畏，并不代表着人云亦云的纯执行。扎扎实实做产品、关注业务中实际存在的问题，遇到问题首先尝试独立思考产出解决方案，在解决问题的过程中逐步提升业务认知，每一次决策后分析与专家和前辈对比思考造成偏差的原因、或者决策正确的关关键因素、多与业内团队交流分享信息，将信息从点到线，由线到面，逐渐完善对产业全貌的认识。

❖ 用户视角

ToB产品服务于企业级用户，这就要求ToB产品经理，不仅要熟知自己产品的亮点和功能，还要熟悉客户的行业流程和业务场景。不然无法以真实用户的视角评估客户需求，审视产品的功能设计。要做到这一点，还是很有挑战的。

• 首先，要强调的是，拜访客户，当面沟通，拿到第一手需求非常重要。
• 其次，关注用户使用。这里不是指某个按钮功能，而是依然关注提升效率本质。
• 最后，产品交付后，要亲自去客户生产环境实际操作，一线体会。

❖ 逆向思维

用户视角，强调从正面加强效率；逆向思维，强调反思，多问几个为什么，为什么要有这样的流程？有没有哪一个环节是多余的？人们很容易将现有习惯或流程认为是理所当然的，不会去质疑它。

❖ 全盘考虑

企业客户选择购买你的产品，往往是理性决策的过程。会有很多干系人参与，包括使用方，评估方，购买方等等。购买前，需要加速拍板人的决策效率，产品功能即竞争优势。购买后，需要关注用户留存与客户续约。

❖ 关注重点

ToC产品无法依靠有限的几个用户活下来，但是ToB产品却能够依赖几家核心客户活下来。产品设计中需要搜集并识别用户的行为特征与行业特征，将其产品化并落实到迭代计划。

❖ 保持耐心

做To C产品，有爆发性增长的机会。在To B里面是不可能。To B都是线性增长的。原因也很简单：首先，从企业真实需求获取，To B就要长一些，那自然研发速度也就跟着慢下来；到了采购阶段，To B用户决策流程也会偏长，导致获客周期就会比较长；通常客单价越高的产品，客户决策周期越长；到了交付产品的时候，To B还有一个实施周期的问题。所以To B的创业节奏相对于To C一定会慢很多。因此做To C的人转行去做To B，心态千万不能崩，不能急于求成。