当我们思考问题的时候，总习惯性的从问题出发，寻找上下游的环节，从细枝末节中去寻找解决方案，我对这种思考逻辑理解为“纵向思维”。

然而，很多时候我们应该横向看待问题，以网面为出发点，搭建思考的逻辑面，然后下沉到每一个纵深的线，再从每个纵线中寻找点，我理解这种为“横向思维”。

产品和用户之间是需要沟通的，有了用户的反馈，产品才能制定长期的发展战略，做得更好。

“从上往下”、“从高到底”的思考习惯形成的时候，遇到任何一件事情或者工作上的每一个目标的时候，都可以将目标以全栈视角思考，然后逐步进行拆解，不至于遗漏关键环节。

不久前，我还在面临一个挑战——我试图去优化当时手头上的产品，让它在用户的面前变得更加个性化。

我当时想到的第一件事就是做一个仪表盘（ dashboard ），然后把针对各类用户的所有自定义数据都放进去。因为我觉得这是一种通用逻辑，尤其是当我们想到产品和用户间的沟通时，我们就会立刻联想到通知中心、邮件通知、消息通知提示框（ toast messages ）和仪表盘（ dashboard ）。

另外，虽然我们可以立刻想到一些特定的视角去解决关于沟通概念的问题，但是我还是想（ 和大家一起 ）深入地研究一下“ 所谓构建更有意义的沟通 ”背后的概念。为此，我打算“ 先后退一步 ”，这篇研究性文章也正是上述努力的成果。这也就意味着，我会首先从“ 沟通 ”的定义说起。

一、定义沟通

名词：通过口头表达、书写或使用其他媒介进行信息的给予或交换活动。近义词，传输（transmission）：传递某物的动作或过程，抑或是正在被传递的状态。

当我们讨论过程时，用动词来传递沟通的意思会更加自然。从这个意义上说，沟通转化为信息是指从一个地方、个人或群体转移到另一个地方的行为。沟通过程是指为了成功沟通而采取的一系列行动或步骤。它涉及多个组件，如：

1. 沟通行为的发起者
2. 被发送的消息
3. 消息编码
4. 沟通行为的接收者
5. 消息的解码
6. 在某些情况下，接收者可能会对发起者进行反馈或响应

完成第六步才算是启动“交互”。这种互动包括两个或两个以上的参与者之间的相互行动、影响或交流。

定义这些词语可表明，在讨论诸如反馈、开展研究、期待审查、协作等事项时，我们讨论的流程具有诸如时间线、多方参与、流程和反馈以及结果等属性。事实上，它们都是相连的，并反映了“沟通”的流程。

二、“及时" 设计

一方面，产品由客观实体组成，比如项目、进度、档案等存在的层次结构和组织。另一方面，这些实体的主观属性反映了与单个用户相关的信息，例如“ 我需要为项目X 执行哪些相关的后续步骤 ？”。为什么主观语境很重要？因为它声明了系统与用户、用户 A 和用户 B 之间的沟通意义。

三、在信息收发的过程中，传播信息的主要属性应该考虑到以下问题的答案：是否及时？是否相关？有用吗？

用户希望产品能够响应那些与时间、相关性和有用性相关的适当信息集，因为：

1. 用户希望直接控制与他们有关的东西
2. 用户无法跟上所有信息
3. 用户会错过信息

这是记忆和注意力有限的结果，而且事实上，人们必须要有控制感。产品实体的这些客观和主观属性对用户来说是最重要的，这些属性与信息的关联性、有用性和及时性有关，我们可以依据这些内容为用户定义“ 适当的沟通 ”。

四、在研究人员、协导员及其经理之间建立适当的沟通

我正在开发的产品旨在供可用性研究人员使用，其主要目标是帮助他们与客户进行规划、协作，获得反馈、帮助，创建模板以及传输可用性测试。

在我开始考虑如何提供角色之间正确通信的最便捷方式之前，首先，我要确定产品的不同方面，其中包括预计需要进行大量沟通的功能：

• 定义和规划可用性测试及其所有类似的资产：用例场景、任务场景、逐步流程；
• 预期并提供反馈：在研究项目的不同阶段的特定部分引用其他或类似实体；
• 组织：反映单个用户最相关的活动；
• 进展：研究的不同阶段，多方之间的反复过程，包括对研究进展的感觉。

五、这些流程中包含的角色

研究人员——大多参与所有阶段的研究过程。他们的职责是审查对方要求的每一次更改，并决定他们是否需要反馈，如果需要，需要向谁请求。如果他们需要某事的反馈，他们需要能够看到问题的进展，并在收到有关问题的反馈时得到通知。

审阅者——审阅者希望在一个位置查看他们需要做的所有事情（ 即在全部阶段内，他们需要审阅和批准的所有未决问题 ），并希望按项目查看问题的规模。他们还希望能够跟踪所有进行中项目的进度。大多数研究人员也是评审人员。

管理人员——其中有些是研究人员，但有些只是管理人员，他们可能不负责推进工作，但负责监督研究人员的工作。通常，他们希望查看以下各项的快照：

谁负责每个阶段？

目前处于哪个阶段或研究现状？

每个阶段有多少个未决问题？

六、建立交流的基础：时间、相关性和效用

在定义功能时，我尝试回答下列问题：

在此阶段，用户最重要的事情是什么？

用户下一步需要做的所有事情中最重要的是什么？

这些功能需要有两个方面，第一个方面是使它们成为可能的工具，第二个方面是这些功能提供使多方相互交流的地方或环境。

无论使用产品的角色是什么，用户都应该能够了解下一步需要做什么，以便在工作中取得进展，这是终极目标。这意味着用户首先应该能够看到所有相关的东西。

七、问题陈述

问题陈述集中在被优先处理的信息上，而不是分散的、流离失所的、丢失的，这样用户就不会感到焦虑，好像他们丢失了信息。

上图中的英文单词样式与此意均有所关联（ 从右至左依次是：anxious 焦虑、missing丢失、lot 份额、prioritized 优先次序 ）。

我们发现，显示不同角色最相关的信息不仅很有价值，而且还可以根据他们可能具有的相对重要性确定它们的优先级。

八、沟通的领域

接下来看起来合乎逻辑的是 —— 定义那些不同方式来衡量真正协作产品所代表的沟通领域。

不同的沟通领域标识了支持沟通过程的不同模块，如研究中 6 个步骤所定义的，它们同时反映了不同角色的需求。

我们从通知部分开始吧。

1. 通知

第一层次的沟通是通知对方新来的信息。一个恰当的平台级通知中心有可能带来以下好处：用户能够始终根据环境保持知情状态；在产品内，用户能够控制弹出的不同类型的信息。

通知中心不一定需要在一个位置具备查看所有通知的所有功能，通知中心可以是每个项目中所有提示的部分片段，也可以是用户需要的反馈，或者需要反馈的事项列表等等。

2. 目标 —“ 查看我的信息 ”

其中一个主要角色是研究员协导员，他／她负责审核客户要求的每一次更改，并决定是否需要更改，以及需要哪些人进行更改。

如果产品适用，则可使所有角色之间的协作过程成为可能。但是，这个过程是双向的。因此，我们需要支持研究人员的这两种面貌：

（1）用户能够了解提到他们的对象、地点和时间。

（2）用户能够了解他们提到过的对象、位置和时间，作为查看他们向其他人请求的待定反馈的一种方式。

3. 互动 —“ 对我的信息采取行动 ”

交互片段进一步关注什么才是最重要的东西，即用户最应与之交互的。此过程集中于用户能够继续与另一方推动信息流，因此如果最初没有发生这种情况，则开始交互。

交互流程是之前的目标流程的后续流程，目标流程往往是指要求反馈的一方希望能够进一步反馈、批准或完成某个问题，或者就他们最初发送的待决请求发出提醒。用户能够响应指向他们的事项提及。用户能够上报或向另一方发出提醒，告知他们最初对反馈的针对性请求。

4. 访问 —“ 查找我的信息 ”

此特定模块针对想要直接控制与其自身相关事物的用户。访问是指对不同访问区域内的信息进行适当分类。例如，当用户处于列出每个项目的所有用例场景的视图中时，将提及的内容按照角色进行过滤非常有用。

另一个有关访问获取的要点是所有项目中的特定角色的提及，或者用户能够拥有每个项目上下文视图中的个性化提及。按项目视图能够展示简介的总结，无论是对来自所有接入点内的每个问题的直接操作/反馈，还是对单个实体中可能存在的所有问题（ 如使用案例场景 ）来说，都非常有用。

5. 分类 —“ 对我的信息进行分类 ”

分类包括将信息分组，以便进一步支持特定角色的信息适配，因为通知中心可能会成为“ 用户无法及时跟上所有信息 ”的场所。

此模块更符合特定视图的可视化——支持用户的需求：了解特定项目的任务规模并相应地跟踪这些任务，跟踪任务的迭代过程，随时间在多方之间跟踪；获得进度或状态的一般感知。

九、用户需求和痛点

经过初步研究后，这里展示了所有用户的需求和问题，这些问题非常突出，尤其是当涉及到用户期望从产品中获益的“ 沟通方式 ”时。

角色需要和痛点

需求和痛点按照用户角色排列

从这张表格中，我们可以看出大部分需求与所有角色都相关。因此，在实现这些需求时，我们可以先满足所有用户的需求。

十、组件情绪版

经过初步研究后，我想根据所有的“ 沟通领域 ”来处理现有组件及其可能的扩展。以下仅是覆盖上述痛点的单个组件的实验。这是输出物：

1. 不同组件中进度的整体把握

2. 项目进度的总体感觉

3.“ 我 ”信息相关概述：待评审、任务场景、责任人和笔记

在对可以支持通信流程的特定组件进行可视化实验后，下一步是构思出可以集成所有这些组件的特定视图，这是最终结果。

4. 项目视图

每个项目阶段所有未决问题的概览和最相关的资料

5. 所有项目查看

所有项目的所有未决问题概览和最相关的信息

十一、主要的收获

其目标是试验一种从下到上的扩展方法，而不是考虑诸如仪表板或通知中心之类的已知概念，以及它们如何适合我们的产品。

这导致了一个结构良好的方法，即定义哪些组件是首先和最重要的。

通知用户；

接入点：针对用户，定义这些组件在整个产品中的不同接入点；

用户目标相关：与“我”事物相关，与项目行动相关（与所有用户相关）；

交互的单个组件：定义如何构建一个不仅支持不同接入点，而且还支持来自平台不同区域的交互的单个组件；

类别：定义适当的视图，将此信息组织成有意义的类别，如特定视图。

最后，我采用的方法的理念是，合理地简化如何扩展通信并构建到最重要的内容之上的过程，而不是考虑诸如通知中心和仪表板之类的庞大功能。有趣的是，你可以将此方法应用于对某种类型的交流流程有要求的任何其他使用案例。

十二、产品营销的定义

产品营销是一门新兴学科，涉及产品、营销、销售和客户成功的各个领域。

这个概念在国外已经不算是新鲜事物，而国内除了某些一线互联网大厂、云计算公司、SaaS公司有这个职位规划外，其它很多To B企业尚属于未开发状态。

图1 产品营销（市场）

Eventbrite 的首席产品官 Casey Winters 曾这样定义产品营销的角色，产品营销，如果做得好，通常负责三件事：

• 第一，确定即将发布的产品的定位和信息；
• 第二，推出产品并确保用户/客户/销售人员了解它的价值；
• 第三，推动产品的需求和使用。

HubSpot 的 Lindsay Kolowich Cox 给出了类似的定义：“产品营销是将产品推向市场的过程。这包括确定产品的定位和信息传递、推出产品以及确保销售人员和客户理解它。产品营销旨在推动产品的需求和使用”。

在日常的工作中，产品营销角色一般会将工作重心放在如下几点：

• 确定产品的定位和信息。
• 协同产品经理将产品发布。
• 向销售人员和客户传达产品的价值。
• 推动产品的需求和使用。

为了实现上面列出的四个核心目标，产品营销人员必须与产品、营销、销售和支持（售前、售后）产品的团队密切协调，只有这样才能为客户带来价值。

十三、产品营销体系建设

产品营销本质上是营销的一个细分，并未脱离市场营销的4P理论。而我们将产品推向市场的过程其实就是产品GTM的过程。而整个GTM是一个体系化的框架，涵盖了产品（0-1新品）从最初的市场洞察到最终的客户应用及商业变现的过程。这里面其实夹杂了产品运营的思维，后面会为大家简略一些，供大家参考。

图2 体系建设

1. 战略规划层

1）商业模式

企业成立之初或者新产品布道时都需要优先考虑商业模式，决定了企业未来的走向，也决定了产品以后的演进方向。

商业模式描述了组织如何创造、交付和获取价值的基本原理。它可以通过 9 个构建块来描述：客户细分、价值主张、渠道、客户关系、收入流、关键资源、关键活动、关键合作伙伴关系和成本结构。

这里我们提到一个概念：商业模式画布（BMC）。

所谓“商业模式画布”，就是一张能将组织的商业模式展示出来的画布。商业模式画布是一种用于梳理商业模式的思维方式和工具，可以帮助我们描述商业模式、评估商业模式和改变商业模式，并以一种及其简练的、可视化的、一张纸的方式表现出来。商业画布能够帮助管理者催生创意、降低风险、精准定位目标用户、合理解决问题、正确审视现有业务和发现新业务机会等。

图3 商业模式画布

商业画布包含九大模块：客户细分CS、价值主张VP、渠道通路CH、客户关系CR、收入来源RS、关键资源KR、关键业务活动KA、关键合作伙伴KP和成本结构CS（具体如上图所示）。

这9大模块覆盖了商业的四个视角：客户、产品或服务、基础设施及财务能力。

2）市场分析

产品在推向市场之前，我们需要对特定行业内市场进行全面评估分析，进而研究市场动态，比如规模和价值、潜在客户群、购买力、竞争和其它重要因素等。

通常，市场分析时我们要确定如下几个问题：

• 谁是我的潜在客户？
• 我的客户的购买习惯是什么？
• 我的目标市场有多大？
• 客户愿意为我的产品支付多少？
• 谁是我的主要竞争对手？
• 我的竞争对手的优势和劣势是什么？

除此之外，也需要关注行业发展趋势、政策、法令法规等，对产品未来发展都具有重要参考价值。通过多维度分析，可以降低产品入市的风险，发现新兴趋势，利于产品成功。

3）产品定位

产品定位是指确定公司或产品在顾客或消费者心目中的形象和地位，这个形象和地位应该是与众不同的。以下是定义产品定位的关键要素：

图4 产品定位

一个简短的产品定位包括描述目标受众、产品与众不同之处以及客户应该关心它的原因。以下是产品定位模板的示例：

对于[ need/want]的[group of users]，[company/product]是一个[category/solution] ，它通过[benefit]唯一解决这个问题。

4）产品形态

随着云计算的不断发展，企业上云的趋势愈发明显。越来越多的企业开始布局或者使用SaaS产品，这类多租户、成本低、运维简单的模式被越来越多的企业接受。

除此之外，还有本地化部署的形态。在产品形态中，定位自身产品形态，需要跟目标客群来确定。

通常大型企业一般定制化需求比较多，这类用户通常会选择本地化部署，中小企业在成本、人员等诸多因素下是可以接受SaaS产品的。这一块后面可以再跟大家展开简述一下，本文不做过多描述。

2. 产品营销层

1）产品GTM

从本质上说，GTM战略是一个行动计划，它列出了每个职能团队（如市场营销、销售、售前、客户成功/售后、产品经理等）将产品（新产品）推向客户的过程。这其中就包含了产品从最初的规划设计、产品MVP到最后上市，并持续推广，持续输出产品价值。

（1）定义目标市场

洞察、调研目标市场规模、增速，所针对行业规模、行业类别、资本/政府对市场的关注度、客户的需求度等维度，判断市场成熟度情况，是否处于最佳窗口期。

（2）用户画像

TO B行业的用户画像包括行业画像和角色画像两个维度。

A：客户画像

客户画像简而言之就是指你目前的设计所服务的组织、公司的画像，它涵盖了该组织所在行业的特征、现状（包括行业类别、产业链细分等）和自身企业特征（规模、发展阶段、市场、业务情况等）。

这有助于我们快速地验证我们对产品的定位准确性，并且迅速地找准大致方向，以便于随时补充所在该垂直领域相关信息以更加了解客户。

当然从团队协作的角度来说，这些信息还可以帮助销售团队更为方便的找到目标客户进行签约。

客户画像以一种较为精炼的方式进行拆解可以分为基本信息、业务信息、组织架构和关键角色，其中具体来说：

• 基本信息：行业属性、地理位置、企业规模；
• 业务信息：业务概览、经营模式、付费能力、使用目标；
• 组织架构：组织自上而下有哪些机构，彼此之间有何联系；
• 关键角色：组织中所包含的各个岗位；

B：角色画像

而角色画像就是指你目前的设计所服务的组织、公司中的使用人员包括了公司的高、中、底层即决策层、中间管理层、执行层，它包括了你所研究的角色的个人特质或者说岗位特征（包括了岗位特征、职能、职场处境、决策链路位置、希望解决问题的目标等）。

角色画像以一种较为精炼的方式进行拆解可以分为角色名称、基本信息、工作目标、和使用场景，其中具体来说：

• 角色名称：具体职位的具体职位名称或是工种；
• 基本信息：文化水平、办公场地、平台偏好、使用频次；
• 工作目标：岗位职能、岗位责任和使用期望；
• 使用场景：以较为干练的故事叙事的方式对日常工作的各个场景进行描述；

（3）价值主张

价值主张是商业战略和品牌战略之间的关键点。定义价值主张可以区分跟竞争对手的不同，重点凸显产品价值。制定时可以参考如下（图5）画布模板。

图5 价值主张画布

（4）确定主要竞争对手

评估当前和潜在竞争对手的优势和劣势，有利于发现产品或服务与竞争对手的区别，寻找自身机会，减少潜在威胁。

（5）选择定价策略

基于业务、市场、竞对等维度制定定价策略，但定价模型应该围绕产品为客户提供的价值构建，同时最大限度地提高盈利能力。

（6）营销和销售策略

在产品上市推广前，内部组织需要赋能，让销售、售前、客户成功等部门对产品定位、价值主张、产品功能、解决方案等内容做详细了解，并准备相应的弹药工具包，辅助前场人员在客户端的后背支撑工作。

图6 营销工具包分类

（7）产品上市

当前面的准备工作做完之后，就可以将产品上市推广了。上线推广可以考虑从品牌公关、内容营销、活动营销、用户增长几个方向进行拓展。同时，也包括通过与渠道、代理商、集成商等合作进行线下产品推广，具体合作阶段根据产品生命周期及市场匹配度来定，后面详述。

做为To B营销重要一环，以下为内容营销的一些参考：

图7 不同阶段的内容生产

2）用户增长/运营

AARRR 框架是初创企业和 SaaS 公司衡量增长和成功的最流行模型之一。它由 Practical Venture Capital 的创始人 David McClure 提出，也被称为 Pirate Metrics 或 Pirate Framework。

它将您的客户生命周期分为 5 个阶段，从第一个接触点开始，简述了潜在客户成为付费客户。其利于我们了解客户生命周期的表现情况，改善转化漏洞有缺失的地方。

这里面有重要一环就是NPS（净推荐值），该概念更多会考虑产品、服务的内核实力，毕竟产品是核心竞争力。

图8 用户增长

过往，用户运营在互联网行业比较盛行，因为To C和To B的用户群体数量不同，To B针对的是企业用户，尤其是头部客户的数量有限，更多考虑线下的营销模式推进。

如果产品线为SaaS产品，中小企业的用户群体数量是众多的。

尤其是现在PLG的营销模式下，线上成交的产品可以采用数据埋点的方式对用户行为路径进行跟踪，对用户分层和打标签，针对不同用户采取不同的营销模式。

图9 用户运营

3. 商业变现

产品作为企业和客户进行价值交换的载体，最终目的是实现价值最大化，对于企业来讲有一个点就是商业变现。该模块可以更多从线索转化生命周期进行思考。对于市场营销专家来讲，对于线索从leads-MQL-SQL-商机-POC-签单来讲并不陌生。

图10 线索生命周期转化过程

当赢单之后，就需要售后（客户成功）做好项目验收、服务输出，也包括产品营销等其它团队做好客户需求采集、问题解决等环节，为下一年的续费、增购做好准备基础。

十四、总结

构建完成了如上的框架，基本的产品营销框架体系就建设完成，其实比较粗犷。这里面还有产品的MVP、产品迭代等内容模块，后面再为大家一一拆解吧。营销体系的搭建从横向思考，再去纵分每个环节的重要支撑点，把关键点完善，整个营销体系也就完成了。