如何基于用户洞察，设计2B产品的业务架构？

原标题：如何基于用户洞察，设计2B产品的业务架构？

产品的真正挑战在于对用户的彻底理解，并基于这种理解进行商业模式的设计。

通过上文对 “产品的信息架构、产品架构与业务架构”解析， 我们大概厘清了产品在进入正式研发阶段的三个关键设计成果：业务架构、产品架构和信息架构。

但如《商业模式新生代》一书所讲，“企业在市场研究上投入了大量的精力，然而在设计产品、服务和商业模式上却往往忽略了客户的观点。”

我们要从客户的角度来看待产品和我们的商业模式，但也并不是要完全按照用户的思维来设计商业模式。

在产品设计过程中，我们真正需要考虑的是，如何才能真正深入的理解用户对价格、环境、日常事务的关心和愿望，以及用户的目的和想法如何影响产品的具体设计过程。

有的产品提供了更为便利的获得方式，有的产品提供了更为独特的服务，还有的产品满足了用户未曾满足的需求，这些产品都获得了各自领域的成功。对创新性的产品而言，忽略对现有用户的关注，紧盯新的和未满足的细分群体，可能是更有利于产品的创新，从而带来更快速的增长。

但显而易见的是，我们始终无法同时去满足所有的用户和需求，取舍是必经之路。我们的挑战在于，到底应该听取那些用户和忽略那些用户的意见。

• 产品层：考虑如何解决用户的具体问题，以及回答用户选择产品的根本原因。

每一个细分的用户群体，都有该群体的独有特征，他们对环境的理解，以及由此带来的行为和愿望都会存在巨大的差异。实际上我们的产品设计就是针对该群体共同的需求，行为和态度提供的解决方案，这一点同时也就决定了产品在应对用户需求的优先程度。

• 运营层：考虑如何通过独特的渠道触达用户，以及找到建立和维护该类用户的独特方式。

用户在这个社群内的时间、频度和行为，直接形成了该产品的忠诚要素，同类型的用户聚集在一起，所形成的社群也具备同一纬度的忠诚度，如何通过巧妙的方式吸引和保留受众在社群内的能够不断的获得和增加价值，是社群运营必须关注的重点。

比如积分系统，就是一种提示用户忠诚度的有效方式，它能够充分的调动个体和社群的互动，有效的提高个体受众和整个社群的忠诚。

01 2B产品的需求洞察

互联网发展到今天，各个领域早已被各式各样的产品全面覆盖，对用户来说，选择和放弃某个产品都需要有足够的理由，或者足够的性价比，或者有足够的吸引力等等不一而足。

过去的产品设计更多是围绕组织的商业目标出发，考虑的是“有什么可以卖给用户”，“需要和用户建立什么样的关系”以及“到底怎样才能从从用户身上赚的钱”。

而在今天，则变成了如何围绕独特的用户来设计产品，考虑的是“如何帮助用户达成他们期望的目标”，”如何适应用户的日常工作”，以及“我们的用户希望我们建立怎样的”。

想象一下，我们之所以看到太阳是围绕着地球在转动，而不是地球围绕着太阳的原因。

这是一种独特的思维视角，要求我们必须“移情”以用户的视角看待用户，去感受用户的想法和感受，去理解用户所说的和所做的。

产品经理必须要能够与用户交朋友，深入了解用户生活和工作基本情况，才可能还原用户的真实场景，才能真正理解用户的痛点和目标，然后思考如何让产品和用户能够产生情感的共鸣，让用户有一种“哇，这个真好（真是我想要的）”的体验感受，而不是专注于产品功能和优点。

2B的“客户们”在做出一个产品决策时，所考虑的因素（压力/阻力）会更为复杂，产品经理们至少应该在4个维度上构建对用户决策的影响力。

1. 基于对产品价值的判断

对于“产品价值”的感受和判断，不同的用户群体和用户层次，有完全不同的理解和诉求，这也就决定了任何一个产品都不能满足所有人的期望。

产品经理对用户的理解，首先就是对用户“愿望”的理解和认同，在做用户研究时有4个典型问题：

1. TA经常遭遇的问题时什么？
2. 对TA来说，什么是最重要的？
3. TA想要事物或需要达到的目标之间有什么障碍？
4. TA会害怕承担哪些风险？

2. 基于对渠道通路的选择

所有的“渠道通路”，指的是用户对企业的产品的接触、了解、认知的沟通窗口，不管是从广告，还是线下门店，或者是销售员，用户所接触到的这些“认知窗口”都会对用户的行为选择带来重大影响（特别是老板们的说法和行为，会带来极大的产品决策压力）。

反过来，如何设计匹配的渠道通路也决定了产品的发展空间。

渠道通路的建设同样包括4个层面问题：

• TA经常接触什么类型的产品或服务？
• TA最想通过什么途径和方式购买产品，目前有那些渠道可以获取？
• TA周围的人是怎么做，怎么衡量最好的获得途径？
• TA最担心的风险是什么？

3. 基于对社会关系的影响

严格来说，用户的行为受社会关系的“支配”，而不仅仅是“影响”，我们接受一款产品，替换一款产品，是因为“关系”带来我们的吸引和约束，比如：微信之所以难以被取代，一个因素之一就是社会关系的捆绑。

社会关系是一把无形的剑，它更多的是在用户无意识中发挥左右，核心表现在于用户嘴上说的，和他真实感受直接的矛盾。也就是，我们在做用户分析的时候，为什么不能单纯的依赖表层数据的原因。

• TA所处在的环境看起来像什么？接触的媒体是什么方式？
• TA的周围有什么样的人，更容易被什么人影响？
• TA的朋友、配偶等社会关系如何对TA带来影响？

对“关系”的获取和维护，不仅仅是了解用户的社会网络，想要建立“全面的用户体验”就必须构建产品和用户，产品和社会的良好关系，它最终带来的产品的用户规模和利润规模，当然产品处于不同的阶段，也必须考虑其他阶段的特殊性，运用完全不同的产品运营策略。

4. 基于对价格的接受程度

产品定价，决定产品的价格，进而决定产品的利润空间。对企业来说，用户都其商业模式的核心，是心脏，产品的价格就动脉，因为它是企业的收入来源。

任何一个产品都必须要清楚的回答，“什么样的价格能够让用户真正的付费”，而且这种付费意愿必须是持续性的，我们常常能看到很多产品看起来时长容量非常的大，但增幅很慢，就是因为用户的持续性付费的动力不足。

谈论定价问题，首要要解决的问题是，这一类型的用户（不管是2B还是2C）：

• 到底是更注重产品的功能还是价格？现在付费买的是什么？
• 衡量最合适的价格标准是什么？
• 用户更愿意如何支付费用？
• 用户对价格的最大顾虑是什么？

一款产品获取收入的方式，包括实体销售比如电子产品，服务收费如酒店，订阅收费如在线游戏，租赁收费如汽车租赁，还包括专利的授权，广告等方式，不同的收费方式也有不同的定价策略，都会对产生的收入带来影响。

02 2B业务架构设计复盘

在前文解析 “产品的信息架构、产品架构与业务架构” 时，我们基于“业务驱动产品”的思路，勾画出整个O2O平台的业务框架模型，图下所图示。

超简版O2O平台业务架构

这种设计的基本理念是什么，为什么我们要如此强调 “ 我们能为用户提供什么 ”这个看起来很直接的问题，又如何在系统上实现这一目标？

（以接口层为例）坐席、门店和工程师作为“服务的实体”，他们是一种基于“用户请求”的供给端，为什么他们会被统一设计为“接口层”？

（这种设计意味着任意一个服务实体都可以直接完成接受用户请求到服务履约的完整过程。事实上最简单的做法是，只有一端作为接口则整个系统的复杂度要下降很多。）

其底层逻辑就是基于用户洞察的“产品价值”逻辑。

我们在设计这种方式的时候，是充分考虑到用户端的效率问题，以及现实中的社会关系问题，对用户和工程师（门店）而言，他们三者散落在任意一个街区，他们直接能够基于自身的关系网络，提供相关的服务。

比如一个具备空调、冰箱的维修技能的工程师，他可以基于他的地理活动半径提供服务。

这种特性，决定他能够在时空半径上超越传统的“坐席调度”模式的服务时效，极大的提升了整个平台的服务效率，在通过巧妙的激励性上设计，更进一步提升了工程师的服务动力。

（这一点是基于工程师的“产品价值”逻辑设计）

可以看出，任意一个“服务实体”，冗余了另外角色“业务”，他们在过去的垂直从属关系发生了重大变化。

在这种平行的服务关系中，三者之间就产生了一种不同与以往平台的管理规则和账户逻辑，从这个图我们可以看到，三种之间已经摒弃了过去那种“纵向架构”的管理模式，转为“柔性”的合作协调机制。

这种管理模式的改变，除了在能更覆盖更为广泛的业务需求之外，在日常的管理工作带了很大的改变，提升了效率和用户的总体体验，在产品设计上也带来了很大的差异。

其中之一就是账户体系的不同，三者不再是基于组织架构来推荐业务，而是根域各自的“业务技能”，以及地理半径来实现的协同。这里引申的另外一个概念是“基于网络的管理模型”，和“多租户框架设计”。

第二个则是，整个业务系统不再是依赖“单一订单”来推荐业务，我们在设计过充引入了“CASE单”的概念，来取代和弥补订单（工单）的不足，来更多范围的提升供给侧的业务弹性。

以上差异点，在后续文章中会深入探讨。敬请关注。

基于“用户洞察”设计的整个O2O平台，它涉及的用户既可以是终端用户，也可以是企业用户如电器卖场，作为连接用户和服务用户的“实体”则有坐席、门店和工程师，整个平台基于用户的服务请求形成的业务订单实现整个平台的业务流程。

这种“ 深度解耦 ”模型下的产品，其扩展性和灵活性非常大。

整个平台既能够满足“单一”业务领域的服务，也能够支撑跨领域的服务请求，对系统而言，相当于它只是新增了一个“通道”，而整体业务完全不受影响。

在后续的产品架构设计中，我们进一步抽象了“业务动作”这一概念，使得整个平台进一步解耦，实现了多种业务类型，多种业务订单的并行运行。

#专栏作家#

杜松，公众号：产品微言，人人都是产品经理专栏作家。专注于人工智能方向，擅长产品规划和架构设计。

题图来自Unsplash ，基于 CC0 协议。