一二三做好B端客户需求分析

一二三”，做好B端客户需求分析编辑导语：对于产品经理来说，客户需求是必须详细地记录与分析的，只有掌握了客户需求，才能了解存在的问题，从而根据客户的需求场景去制作出客户满意的产品。那么，应该如何对B端客户的需求记录进行分析呢？本文作者三方面为我们做出了解答。随着中国互联网行业从消费互联向产业互联转型，企业服务市场进入快速增长期。根据艾瑞咨询的报告，虽然新冠疫情影响了宏观经济增速，但线下转线上、远程办公等需求反而助推了SaaS发展，预计2020年企业级SaaS市场仍将保持可观的增速，到2022年市场规模将突破千亿元。风口上，不只是资本纷纷涌入ToB领域，许多产品人也在谋划着从C端转型到B端。本文作者针对以SaaS产品为典型代表的B端客户需求分析，提出“一二三”的方法论，即一条公式、两个维度、三种分析，希望能给有意从C端跨界到B端的产品人提供参考。本文的主要内容用思维导图呈现如下：一、B端和C端的区别在进入本文的正题前，先通过回顾产品大牛的论述，对B端和C端产品做个简要的区分。产品人Frank在《三大方面，分析toB和toC产品的区别》中，从三个角度对这两个产品做了区分：面向对象：2B产品面向偏理性的客户，2C产品面向偏感性的用户；产品特点：B端卖工具，强调性价比；C端卖玩具，突出好玩；商业模式：B端“卖身”，实打实地一手交钱一手交货；C端“卖艺”，主要通过广告、排名等方式间接变现。在《何谓B端产品》一文中，产品糙叔把B端产品定义为：为组织提供商业价值的产品或服务。他提出，B端产品经理在日常工作中，要做到“一个明确，两个基于”，即先明确目标客户，再基于价值决策、基于场景设计。概括而言，C端用户更重体验，要求用得爽、玩得嗨，因此，在做产品设计时要轻流程、重体验。而B端客户更重效率，在做决策时更符合理性经济人假设。所以，在设计产品时，要带着帮忙客户降本增效的目标，对企业业务流程进行重构、优化。二、一条公式产品大神俞军曾把他百度工作时总结的12条产品方法论，简化为一个公式：用户价值=新体验-旧体验-替换成本。类似地，本文作者认为，在B端市场也适用这样一个公式：作者认为，这个公式是预判需求是否有商业价值和客户是否购买后续做出来的产品的根本标准。为什么这么说呢？来源：《艾瑞咨询：2020年中国企业级SaaS行业研究报告》在当前的国内环境中，一个SaaS产品只有在需求分析阶段就瞄准客户痛点、在产品设计阶段就帮客户把账算清楚，才能为走通商业模式、实现产品盈利奠定基础，国内的SaaS市场环境目前是落后于发达国家的。艾瑞咨询的数据显示，2019年中国GDP占全球的比例达到16.4%，但企业IT支出占全球比重仅为5.5%，总体而言，中国企业信息化水平相对经济发展程度仍比较落后。具体而言，国内目前愿意付费订阅SaaS的客户多为国企与政府，且偏向定制化开发。而小微企业由于竞争环境相对恶劣、对于用人力来经营有路径依赖等原因，所以对软件工具的付费能力普遍不强。这种情况下，B端产品经理只有在做顶层设计时，就帮目标客群把SaaS产品价值的ROI测算清楚，才能保证做出来的产品既切中客户真实需求，又在目标客群的付费能力之内，进而支撑销售和客服团队把SaaS产品卖出去。然后，这条公式要怎样使用呢？参考用法是：先从市面上选择合适的解决方案作为参照物，跟拟开发的新解决方案、客户正在使用的旧解决方案作比较，引入参照物是为了比较客观地做出分数评估。然后，按选定的统一标准从不同维度给这些方案打分。经标准化处理后，取综合得分并进一步计算、比较不同方案之间的优劣。关于新旧方案评估的维度，以及每个维度的权重，建议根据行业经验和产品特性来确定，可以包括但不限于技术先进性、价格、功效、安全性、方案完备性等等。计算不同解决方案的价值得分计算不同解决方案的成本得分举例：假设我要做一套客服系统，我选择了从技术、价格、服务和功效这4个维度来评估我们公司打算做的客服系统、市面上的参照方案和目标客户正在用的旧方案。假设经计算得到，新解决方案的价值得分为70分，成本为65分，而旧解决方案的价值得分为30分，成本得分为45分。那么，根据客户价值公式，产品价值=(新解决方案-旧解决方案)-替换成本=(70-30)-(65-45)=20分。产品价值为正数，表明这个新解决方案可以给客户带来价值，也就是说这个B端产品的价值模型有较高的可能性成立。其中，在根据行业和产品特点选择具体维度来比较不同方案的替换成本时，建议考虑“功能专注度”和“功能丰富度”，为什么呢？因为这两个维度分别对应了把功能做强和把集成做广的SaaS产品竞争策略。具体如下：1.功能专注度：把功能做强相比于通用型SaaS产品，有些SaaS厂商会专注于某一垂直领域做专用产品切入，打磨好符合该领域需求的细节功能，从而构建起自己的竞争壁垒。这样当竞争对手尝试以低价抢走客户时，客户可能会考虑到某些细节功能更符合自己在特定场景中的业务需求，而拒绝竞争对手的诱惑。2.功能丰富度：把集成做广相比于专注做强功能，有的SaaS产品会面向B端客户多样化的管理需求，把可以共生的多种软硬件服务集成在一起，为客户提供一体化的解决方案。这样既通过一站式帮助客户解决全部相关问题，在销售时赢得客户的青睐，又使得已经在用的客户在面对友商提供的替换方案时，考虑到要投入额外资源把几套系统割接在一起，很可能会慎重考虑要不要更换。把“功能专注度”和“功能丰富度”纳入到替换成本的测算中，可以帮助我们构建起产品的竞争壁垒。总而言之，B端产品经理要有一把秤来衡量做出来能否给目标客群带来正的商业价值，要提前帮目标客户把新解决方案的价值计算清楚。上面这条客户价值公式供参考。三、两个维度明确了产品价值的衡量方式后，接下来从商业和技术两个维度，来摸清B端客户对于SaaS产品的需求。其中，商业维度的分析是技术分析的基础。商业分析如果错了，那么后续搭建出来的产品技术模型很可能是没用的。商业维度的分析可以从以下角度展开：1.目标客群C端产品有用户研究，类似地，B端需求也可以建立目标客户模型，只是考虑的维度不一样。C端一般从年龄、职业、性别等维度来勾画目标用户的个性特征，而B端产品则会从行业、地域、企业规模等角度来明确目标客群。2.需求背景B端产品一定是立足于某个具体的环境和（或）发展阶段来为目标企业创造价值的，这个价值可大可小。企业对软件工具的需求，一定是客观环境或者发展问题映射到决策层的主观意志上，再回馈出来的痛点。产品经理一定要理解这个需求产生的背景，例如：同样是对自助建站的需求，一个企业在50人左右的阶段，可能只愿意购买模板和基础的数据库服务来展示自己的业务，而当它扩张到500人的阶段，就可能比较看重平台开发/制作能力了。自助建站SaaS产品经理就需要明确自己面向哪个发展阶段的企业客户。3.商业模式在理解需求背景后，B端产品经理要弄清楚目标企业的商业模式，商业模式决定了产品规划和设计的框架。只有梳理清楚了企业的商业模式，准确把握目标客户经营什么产品或者服务、怎样销售、怎样盈利，才能避免B端产品的系统设计出现严重的偏差。对商业模式的理解，可以结合下文介绍的场景分析来展开。4.付费能力B端产品只是通过用技术辅助企业降低成本或者增加收入，来改变B端客户的支付对象，但并不能增强客户的付费能力。产品经理需要确保自己在用产品来帮助客户时，所采用的技术和成本没有超出目标客户的购买能力范围。同理地，产品在完成商业角度的分析后，可以从开发目标、系统架构、功能模块和参数要求等维度来分析目标客群对于SaaS产品的技术要求。四、三种分析具体到怎样从商业和技术两个维度做好、做充分对B端客户的需求分析，我认为有三种手段可以辅助实现，分别是：相关方分析、场景分析和业务逻辑分析。首先，我们需要确定这个需求涉及到的相关方有哪些。与C端需求主体只有用户一个人不同，B端需求会涉及到更多主体。一般来说，B端需求中，决策者（老板）、购买者（采购部、财务部）和使用者（业务人员）是分离的。相关方是产品需求的来源。一定是在某个特定的场景中，几个相关方在他们的现状和想达到的目标之间有差距，这些差距集合在一起才形成了一个痛点，进而形成了B端客户对一个新的解决方案的需求。作者认为，全面的相关方分析是首要的。例如：假设收银员人均处理500单流水，而要达成人均1000单才能应对业务扩张，这种差距反馈到老板那里，他可能就会有控制成本、提高效率的想法，然后授意采购部去询价能辅助实现这个目标的收银解决方案。产品经理一定要把一个业务场景中涉及到的相关方都捕捉到了，然后分析他们在特定场景中的互动，才能确保在做需求分析时没有遗漏。这里特别提出，在做相关方分析时，建议把合作伙伴也考虑进来，然后整体分析他们在特定的行业生态中，是怎样围绕特定主题合作实现价值创造、流动的，为什么这么说呢？前文提到，目前国内企业的信息化程度还相对落后，中小企业的SaaS付费意愿没有美国的强。这种情况下，SaaS产品如果想盈利，就不能只是做一个软件，而是要以降本/增收为目标导向，为B端客户提供一体化的解决方案。再次拿收银系统来举例：如果某SaaS产品只是给到客户一个IT系统，那么，企业是不会买单的。因为企业在买了这个系统后，还需要去采购电脑、连接网络、部署软件等，在售后问题上需要额外投入很多资源。客户会觉得不划算；而现实中，国内大部分厂商现在都是提供一整套的移动支付解决方案，包括收银机、扫码枪和收银系统等在内。也就是说，B端产品在做相关方分析和场景分析时，需要充分捕捉到涉及到的角色，然后思考信息流、资金流和（或）物流是怎样在这几个主体之间流动的，他们是怎样形成一个小型生态的，然后才能针对性地为这个场景设计出一体化的解决方案。另外，在做场景分析时，还需要考虑物理场景。虽然都属于线上场景，企业对于网页端自助建站和小程序自助建站的需求是不一样的。网页端建站时，对于功能模块的要求会更齐全；而在小程序建站时，由于它倡导用完就走、不适合做留存，所以对于功能模块的需求就会聚焦在商品上架和订单交易。同样地，虽然都是做线下支付，商铺扫码支付和公交扫码支付对于产品的功能要求是不一样的。因为跟便利店里信号稳定不一样，公交是一个网络波动的场景，可能这个车站信号满格，下个站点却没有信号了。不同物理场景中，对于产品的功能参数要求是不一样的。在做完相关方分析和场景分析，对目标客户的商业需求有个完整的理解后，才开始着手业务逻辑分析。而不是一上来，就开始画流程图。在做业务逻辑分析时，可以调用一些比较成熟的工具模型。如下：范围模型：生态系统图、系统交互图、功能模型等；流程模型：过程流、用例、用例故事等；规则模型：商业规则目录、决策树、决策表等；数据模型：数据流图、数据字典、状态表、状态图和实体关系