还记得学姐刚入职的时候，公司规模还比较小，每天就是埋头工作，也没有很多需要汇报的地方，周报就随意写点流水账，月会、季度会也挺少的。后来，随着公司“晋级”成大厂，开会和汇报的“文化”也就越来越多了，原本最朴素的周报也变得越来越“卷”，动辄就写个大几千字整得和作文似的，咱还得在周末空出大半天去写它。

后来学姐跳槽去了外企，各种会也是挺多的，但竟然不需要写周报了，我反而有点不习惯，总觉得不写周报这一周就没有什么回顾和总结。

Part.1 周报的目的

所以，童鞋们也不要太小看写周报、开周会这些小事儿，其实还是有很多好处的。

数据监控

每次月会、季会的前几天大家是不是都为了分析KPI是否达成而焦头烂额？周报其实就相当于把这些工作都提前拆分做了。咱们每周都观察下数据有没有什么波动，这样到了月末分析起来就很快了。

工作汇报

如果你在公司是核心、是管理层，那当然是很容易见到大老板，去给他们汇报，但如果你在公司还是一个打工人，或者你做的项目不在聚光灯下，咱就必须把你每周做的事儿告诉相关的同事和老板，坚决不做一个默默无闻的小虾米（相信姐，没有存在感真的很吃亏）！

Call out

这个词是学姐在外企学到的，字面意思就是“大声说出来”，也可以引申为一切需要及时和老板、同事们沟通的内容。特别是风险点，哪怕是你当面和老板提过了，在周报这样书面的场合也一定要重申一下，甚至用醒目的颜色标出。

总结回顾

如果说前面这三部分是为了沟通，那么这部分是留给自己的一片小天地了，工作一周大家也累了，如果能总结出一些经验和教训，或者记录一些自己的心得体会，那是极好的。这部分材料以后晋升答辩的时候也可以翻出来看看～

说了这么多写周报的目的，下面来讲讲具体怎么写，学姐一般会分为三部分：数据、项目、总结。

Part.2 如何写好周报

第一部分：数据

这部分主要是监控指标，关于互联网常用的各类指标，学姐在这篇文章里有详细描述。

举个例子，如果是做用户端的，那么每周必须要监控的指标肯定有本周的DAU（日活跃用户），那么不同渠道（比如从站外哪个广告渠道来的）、不同端（比如安卓、iPhone、PC）的周均DAU肯定也需要监控。如果是做交易产品的，那么日均订单量、交易额肯定也需要监控。我们还可以进一步拆分这些指标，比如不同路径下单的订单量、交易额、访购率（购买人数/访问人数）等，比如某些活动和新功能带来的订单量、交易额等～

除了这些比较关键的指标及进一步拆分之外，对于一些比较关键的功能，我们也可以把每一步的转化率监控起来，举个例子如果你们的订单量80%都来自于搜索列表页，那么首页->搜索列表页、搜索列表页->商品详情页、商品详情页->下单页，下单页->下单成功，每一步的转化率我们都可以监控起来，这样订单量的涨跌就非常好分析了。

因此，除了指标的绝对值之外，我们还需要把指标的“涨跌”表达出来，那么做周报比较常见的就是周环比了，也就是：

（本周的值-上周的值）/（上周的值）*100%

像上面这个表格这样，我们就可以监控本周和上周相比的情况了。那么每到月末我们还需要整理一整个月的数值，这时候可以新增一个维度，也就是该指标的MTD（month to date）。举个例子，今天是本月11号，我们统计出了本月1号到10号的收入（也就是MTD）是一千万，除以本月的KPI两千万，算出收入已经完成了50%，此时时间进度为33.3%（本月是30天），那么就可以看出我们本月的收入完成情况不错，已经大幅领先于时间进度。此外，我们还可以监控本月的MTD比上个月MTD的月环比，比如：（本月1-10号的交易额-上月1-10号的交易额）/（上月1-10号的交易额）*100，这个值在月初会不太准，不过随着时间推移，越到月末，会越接近真实的月环比值，这样我们到做月报的时候就不会慌乱啦～

除了表格之外，我们还可以进一步把某些关键指标的日曲线贴出来，这样更直观，比如某一天因为搞活动，数据激增，或者某一天系统挂了，数据狂跌，图一贴，大家就一目了然，避免了不必要的“抢功”和“推锅”。

第二部分：项目

看完数据我们该写本周主要工作了——那就是项目进展。很多童鞋会直接把项目平铺开写，这样其实可阅读性不高，缺乏重点（毕竟一个大老板可能要看N份周报的说）。所以我们一般会在进入正式的项目之前，先把一些重点拎出来写在最前面。包括：

这些建议大家可以考虑在重点部分标黄、加粗等，如果同事和老板再假装没看到，那可就不是你的问题啦～

接下来我们可以写项目进展了，不过学姐还是不建议直接平铺开写，一般我们在大厂会直接用OKR的表格（关于OKR和产品目标可以看学姐的这篇文章），也就是你们这个季度的产品目标、实现路径、再到具体项目进展，这样项目就可以和整个部门的目标挂在一起，项目的意义和优先级也就一目了然了。像是和大目标无关的一些小优化，我们也可以另起一组来写。

关于项目进展，大家只要突出一些关键节点就行了（关于怎么做项目的流程，可以去看学姐的这篇文章），比如启动、设计初稿、设计定稿、需求评审、进入开发、联调、提测、灰度、全量上线等，如果有链接的可以贴链接，不需要把太具体的过程写出来，周报毕竟是总结↓

第三部分：总结回顾

数据和项目两部分是周报中必写的，最后我们可以写一些本周总结、心得体会之类的，当然这部分不强求，也不建议大家在这部分写出一篇小作文来（除非公司要求），我觉得这部分更多情感抒发，也算是写给自己本周工作的一个交代：

• 如果你是做管理的，可以写一些管理心得，比如下属离职的原因分析，招人过程中的感悟等，总结一些经验和教训，帮助自己后续更好地搭建团队。
  
• 可以写一些对产品的感悟，比如新上线的功能流程自己主观体验下来怎么样，有舍呢需要迭代的，竞品最近是否有新的动态。
  
• 也可以写一些经验教训，比如在某个流程上吃的亏之类的，后续该怎样再接再厉
  

好了，周报怎么写就到这里了，学姐又贴心的准备了一份模版，关注“海贝学姐”公众号并回复“周报”可以获取～童鞋们有任何产品相关的问题也可以给学姐留言哦。

最近一年，本人经历了文旅和零售的2个大项目，金额在千万以上的大项目，在这个过程中感触颇深，想趁着这个空闲的机会，沉淀下项目相关的经历，也顺便复盘下最近的项目经历。

项目建设中，围绕着数字化转型这个主题进行数字化基建，涉及到内容包含用户数据中心(CDP)、会员忠诚度、自动化营销(MA)、智能外呼、私域助手。整个过程围绕这“用户”这个实体进行多方面的处理，比如基于用户生命周期的建设，用户旅程的规划等。以及当今获客成本不断增加，如果围绕着存量用户进行运营。

后面文档的顺序会先从会员体系、CDP和MA的顺序进行撰写。希望朋友们在看的过程中给予相关指导和意见。

1.会员产品的定义

会员产品是提升用户忠诚度，帮助企业从用户触达-潜客获取-首购转化-复购增购-裂变拉新-用户留存全流程，提升用户的LVT。

2.会员体系产品的搭建

本人的拙见中，会员体系的搭建应包含会员等级、会员积分、会员权益、会员成就、会员风控和优惠券，其中现在热门的付费会员也应包含在内，但是本人能力有限，对这块不是很熟，就不细讲了。以下详细介绍会员产品体系的搭建

2.1会员等级

通过设置不同等级的会员，给予不同的权益，提升会员的粘性，并进行复购和增购。在进行会员等级设置时，需要考虑到不同等级的阈值以及等级的规则。

2.1.1会员等级规则

在会员等级中，需要设置等级的名称、阈值以及等级的有效期，如下

在设置会员等级时，需要配置会员等级名称、升级阈值、等级有效期和降级的方式。以下详细说明：

升级区间：进入等级的门槛。当成长值大于等于这一阈值则升级到这一等级，代表的等级的升级门槛。

降级区间：在保级计算时使用到。在保级计算时长内的成长值小于降级阈值时，则保级失败需要降级。

降级方式：指的是当用户等级降级的规则。分为：下一级(降到该等级的下个等级)对应级别(累计的成长值与升级阈值做对比，属于哪个等级)，最低级别（降到最低的等级）。

等级有效期：升级到某个级别的有效期。分为长期有效、年固定日期、若干月末和若干月后。当等级有效期不是长期有效，需要考虑保级规则

长期有效：指的是升级到某等级后，等级不过期。

年固定日期：值的是升级到某等级后，在设置的某个固定日期后等级到期

若干月末：指的是升级到某等级后，在设置的多少个月末等级到期。比如今天等级升到了黄金，设置了1个月，则在下个月末24点等级到期。

若干月后：指的是升级到某等级后，在设置的多少个月后等级到期。比如今天等级升到了黄金，设置了1个月，则在下个月的今天24点等级到期。

保级计算周期：在会员等级到期日，保级计算时使用。 例如设置了12个月，则以到期日为起始点，往前推12个月；以此时间段内的累积变更量和会员等级中的降级区间比对，从而确定新的等级。

除了上述需要在会员等级中考虑，还需要进行等级的风控，比如配置等级到期后的冻结策略，此时有两个策略，第一个长期冻结，不管会员降级多少次，只要达到了解冻的阈值就可以回到对应等级；第二个是冻结固定时长，只要会员在配置的固定时长内达到解冻阈值内才能回到对应等级。

2.1.2成长值规则

所谓成长值就是达到多少成长值后成为某个等级。比如满20成长值成为青铜等级，成长值需要设置哪些行为能产生，并且产生的规则是多少，下面为表格示例

在成长值设置中，需要明确具体的行为、适用的等级、生效时间段和对应的计算方法。

适用等级：表示成长值规则适用于哪些等级。

生效时间段：表示该成长值的有效期

具体的行为：表示哪些行为能产生成长值，比如签到打卡赠送12成长值，实名认证能赠送20成长值。在行为的配置中我们是使用事件，比如进行埋点，设置原事件，当用户满足某个事件后发放成长值，事件的阐述我们放在后面章节。

成长值赠送的计算方法：赠送方法需要满足多种计算场景，比如倍率计算(计算基数*倍率)定额赠送（固定赠送X成长值）倍率+定额(计算基数*倍率+固定值)计数（完成后+1）

2.1.3等级升降级处理

     等级升降处理逻辑是通过成长值与等级区间的对比进行登记升级和降级处理。

正常等级升级情况：

用户完成正常的成长值增加或者减少，满足对应的等级区间。

正常等级升降情况：

等级到期时，在保级计算周期内，没有达到保级标准引起的等级升降情况：

2.5优惠券
      优惠券是会员激励以及会员促活的重要工具。

优惠券完成的闭环是制券-发券-用券。下面依次介绍

2.5.1优惠券制作

优惠券分为代金券、折扣券、兑换券和随机金额券。分别配置优惠券的基本信息、领取规则、使用规则。

优惠券基本信息包含券的名称、使用门槛、使用场景、库存、核销方式、适用商品、适用门店。

优惠券的领取规则包含领取方式、领取条件、领取时间和领取次数。

优惠券的使用规则包含使用有效期和说明。

2.5.2优惠券发放

优惠券发放需考虑的场景是手动发放优惠券、通过会员任务发放优惠券、系统发放。同时需要优惠券明细查看发放具体的明细。

2.5.3优惠券使用

优惠券的核销，可借助外部硬件设备进行核销，也可以通过二维码的方式进行核销，在设计过程中需要考虑到财务对账的问题，不同业务部门需要进行成本计算和对账，通过优惠券统计设计相关报表

2.5.4券包

券包现在在很多零售有很多场景，券包是将若干个优惠券组合一个券包发给用户。券包在产品设计中，需要考虑券包的失效条件，包含两张场景：

任一优惠券失效，券包失效：该券包会在A、B、C三种优惠券任一失效时停止发放，效果是每个用户领到的券包都包含A、B、C三种券；

全部优惠券失效，券包失效：则该券包在A、B、C优惠券其一或其二失效时都不会停止发放，而是会发放到三种券全部库存用完为止，效果是可能不同用户领到的券包不同，有的用户领到的券包包含A、B、C三种，有的用户领到的券包包含其中两种，有的用户可能只能领到包含其中一种券的券包。

2.6会员数据

在数据的设计上，可以对会员进行分析，积分的明细和统计、优惠券的统计。

2.7元数据管理

上面章节中，各种行为的配置需要用到事件，本章来介绍元数据管理(具体细节会在后续CDP中进行介绍)，将会员数据进行上报，经过会员相关规则产出成长值、积分和等级。

元事件是采集用户行为事件的总称，包含用户浏览、点击和支付等一系列行为。元事件需要有事件属性，事件属性是指某个用户行为事件发生时采集的事件特征，比如一个用户浏览行为事件发生的时间，浏览的具体网页标题等。通过元事件和事件属性就可以描述会员在什么时候做了什么事情。

2.8接口设计

由于会员产品的类型多种多样，有的只做会员引擎，会员做全闭环产品，因此在产品设计时，开发接口的设计格外重要，结合之前经验，建议做以下（仅作为示例）：

3.会员产品后续方向

从小的方向来说，以上产品设计能自闭环，但从目前的产品大环境来说远远不够，比如权益卡、付费会员、联合会员和会员分析模型等。希望以上分享能帮助你对会员产品有个初步的认识，在产品设计中能给你灵感。

现在 ChatGPT 太火了，网上关于它的用法，真是五花八门，有人把它当搜索引擎，有人用它写文章写周报，有人用它写代码，有人用它做翻译。

作为在移动互联网浪潮成长起来的产品经理，我能感受到，未来几年 ChatGPT 和各种 AI 工具将改变我们的工作方式。

因此，我最近在探索如何用 ChatGPT 来提高工作效率，提升竞争力。经过一系列的尝试和实践后，我总结出两点用好 ChatGPT 的体会：

• 学会提出好问题：了解 ChatGPT 的特性，写出清晰明确的 Prompts（提示词），可以获取高质量的回答；
• 根据具体的工作流程和场景，明确目标与问题：做产品涉及很多环节，需要针对具体的工作场景和问题，有针对性地设计 Prompts ，能帮我们提高工作效率。

下面，我将围绕这两点，介绍如何写好 Prompts ，再分享 4 个产品经理可借助 ChatGPT 提高效率的场景与用法。

1、如何写好Prompts

伴随 AI 工具的流行，也产生了一个新的概念：Prompts（提示词）——我们与 AI 进行对话时，输入的问题或内容。它可以是一个问题，或一段文字描述。

想要获得高质量的回答，很大程度上取决于你所提供的 Prompts。

要写好 Prompts，就像产品经理向程序员提需求一样，既要对工作目标、内容和流程有清晰的认识，知道要解决的具体问题，才能提出明确的问题。还要了解“程序员”的风格，才能做好沟通。

网上关于如何写好 Prompts 有许多方法和模板。其中 Elvis Saravia 总结的框架较为实用，他指出一个 Prompt 应包含以下几个元素：

• 指令：希望模型执行的特定任务或指令。
• 上下文：提供背景信息，包含外部信息或额外的上下文信息，有助于引导模型更好地响应。
• 输入数据：告知模型需要处理的数据。
• 输出指示：指定模型要输出的类型或格式。

当然，并非所有任务都需要以上所有要素，具体取决于你希望模型完成的任务类型。

光看这些元素，你可能还不知道怎么用，下面我们结合产品经理的实际工作场景，看看具体如何使用。

2、撰写文案文档

产品经理的日常工作有大量内容和文档需要输出，比如写产品说明、推广文案、用户手册、项目申报材料、市场调研报告、竞品分析报告、PRD文档等等，这些都要花费非常多的时间。

作为一个大型的自然语言处理模型，ChatGPT 特别擅长文本的生成与编辑，用它来帮我们写文案、写文档，效率极高。

结合上述框架，我总结一个写文案/文档的 Prompt 参考公式：

【背景：产品/项目介绍】+【指令：撰写/修改 + 文案/文档类型】+【输入数据：模仿对象内容/修改内容（可选）】+【输出指示：关于主题/产品的要点 + 结构/字数等】

以写产品说明文档为例，假设要做一个在线教育平台，可以这么提问：

我要做一个在线教育平台（背景），请写一篇产品说明文档（指令），核心功能包括在线课程、实时答疑、学习社群，按照介绍、功能、优势三个部分组织内容，不超过1000字（输出指示）。

有这样的框架，可以帮我们快速写出比较全面的 Prompt ，然后我们再结合实际情况，修改 ChatGPT 的回复，得到我们需要的内容。

3、协助竞品分析

竞品分析是产品经理工作中的重要环节。通过深入研究竞争对手，我们可以洞察市场趋势、发现用户痛点，从而改进自家产品。

做竞品分析，要先找竞品，收集竞品信息，进行分析，最后得出报告。这每个环节，都可以用 ChatGPT 来协助我们，先提供一个 Prompt 的参考公式：

【背景：竞品领域/行业】+【指令：进行竞品分析/提供竞品列表/分析报告】+【输入数据：提供参考大纲结构/产品内容（可选）】+【输出指示：分析类型/关注点 + 格式要求（表格/列表/段落）等】

1）快速获取竞品列表

以往收集竞品的方法费时间，还可能遗漏重要竞品，而 ChatGPT 能快速列出比较全的竞品清单。

以知识付费产品为例，可以这么问：

我们准备进入知识付费行业（背景），列出目前市场上的知识付费产品（指令），提供产品名称和简要介绍的列表（输出指示）

它可以做到秒出竞品清单，还提供竞品介绍。这让我们在短时间内获取大量有价值的信息，节省查资料的时间（当然要小心它瞎编，需要检查核实）。

2）明确分析思路，深入研究竞品

明确目标竞品后，我们让 ChatGPT 输出一份竞品分析的大纲。我们即可参考这些维度自己分析，也可以逐一向它提问。比如，进一步问：“某竞品的优势和不足是什么？”、“某竞品的用户评价如何？”等等。

现在指定竞品进行分析，可以这么问：

我正在研究在线教育行业中的竞争对手（背景），（指令）请对（输入数据）得到APP、极客时间、樊登读书、三节课、喜马拉雅进行竞品分析，分析各竞品的竞品定位与核心价值、产品特点与功能、用户评价与反馈（输出指示）

通过这些问题，我们可以更全面地了解竞品的特点，为制定产品策略提供参考，最后还能让它完整输出分析报告。

需要注意的是，虽然 ChatGPT 可以帮我们快速找到竞品信息，理清分析思路，但我们还是要亲自体验竞品，与竞品的用户交流，思考竞品「为什么这样做」、「为什么不那样做」等问题，以获得第一手信息与深度思考。

在获取 ChatGPT 的分析结果后，我们再结合自己的实际经验和思考，对其进行核实、调整与整合，确保竞品分析的准确性与实用性。

4、协助产品设计

产品功能设计是产品经理的核心工作之一。这个阶段，我们需要准确地捕捉用户需求，将其转化为具体的产品功能，去解决用户的问题。

1）获取设计建议与参考案例

在设计产品时，有的人很快就想出产品方案，有的人想了很久依然没头绪。为啥呢？

我的体会是，这取决于您了解和掌握了多少不同的产品方案。

看过的产品多，脑海中有大量的方案可以选择，并且理解它们的设计原理和优劣，遇到需要解决的问题，即可快速搜索你的「方案库」，结合实际情况进行调整和设计。

ChatGPT 拥有海量的数据资源，其中包含了大量的产品功能设计案例，这些案例远比我们接触过的要多得多，能为我们提供丰富的创意来源。

所以，在设计中遇到困难、缺乏灵感，赶紧请它提供建议和参考案例。

2）检查与优化设计方案

在完成产品功能设计后，我们可以利用 ChatGPT 来检查设计方案的合理性，并提出优化建议。

同样，献上产品设计的 Prompt 的参考公式：

【背景：产品类型/现状】+【指令：获取设计建议/优化方案】+【输入数据：参考案例辅助说明等（可选）】+【输出指示：设计元素/参考案例 + 格式要求（图文/列表/段落）等】

现在假设要做一个在线教育平台的用户积分体系，尝试写提问：

我们在做一个在线教育平台（背景），希望增加用户参与度和活跃度，（指令）请为在线教育平台提供用户积分体系的设计建议，列出积分体系的关键要素和激励措施（输出指示）

你看，用好 ChatGPT，即可帮我们启发思路，还能避免盲区，完善设计方案。

此外，跟开发团队沟通时，也能把产品设计思路讲得更加透彻，提升沟通质量，确保研发效果。

5、协助数据分析

数据分析对产品经理非常重要。通过分析用户数据，我们可以更好地了解用户行为、发现问题、挖掘需求，进而优化产品。

我们工作中有大量的数据需要分析，每天看产品数据，及时发现产品是否有问题，研究用户的行为特征，发现产品可优化的地方。一旦数据出现问题，我们还要尽快找出原因，解决问题。

ChatGPT 有强大的计算能力，用它来分析数据，可以帮我们快速发现潜在问题、提高数据分析效率与准确性。

照例，先上数据分析的 Prompt 参考公式：

【背景：数据类型/业务场景】+【指令：发现原因/趋势/优化建议】+【输入数据：要分析的数据】+【输出指示：问题/现象描述 + 格式要求（图表/列表/段落）等】

举个例子，产品日活数据下跌，让它帮忙分析，我先把简单的日活数据发给它：

我正在做一款知识付费产品（背景），近期发现产品的日活数据下降，（指令）请帮我分析下这些数据，看是否正常，有没有问题？（输出指示）列出数据特点，如有问题，分析可能的原因，并提供优化建议；（输入数据）以下是具体的日活数据：
日期 日活

刚开始，它给的分析原因和建议还比较泛，然后我再补发渠道的日活数据，它便提供更具体的分析与建议。

你看，这比我们自己人肉研究要快太多了，尤其在大数据量和规律特点不明显的情况下，借助它可以大大提高分析效率和准确性。

需要说明的是，由于产品数据涉及到公司的商业机密，如果要用 ChatGPT 做数据分析，要得到公司的许可，并且把数据中一些敏感的信息隐去。

最后，特别提醒一下，这些公式与案例只是提供一个参考，方便你更快上手实践，写出有效的 Prompts，实际提问时还需要根据具体情况进行调整。

6、总结

文章末尾，照例总结一下。

产品经理想利用 ChatGPT 高效工作，需要学会写好 Prompts ，结合产品具体的工作和场景，如从写文案文档、竞品分析、产品设计及数据分析等方面，提高工作的效率与质量。

通过这些案例，相信你也能感受到 ChatGPT 的强大，它就像一位资深产品经理可以随时给我们指导、解答疑问，又像一位得力助手能帮我们完成耗时、重复性的工作，使得我们在高效完成工作的同时，还能学到东西。

当然，想让 ChatGPT 更好地为我们服务，除了写好 Prompts，还要多给它一些数据，对它进行训练，这涉及如何调教 ChatGPT ，由于文章重点不同、篇幅有限，这里先不展开，以后有机会再专门分享。

最后，需要注意，ChatGPT 虽然很强，但它并不能完全取代人的判断和实际经验。

在使用 ChatGPT 时，我们应结合自己的知识和经验对其提供的建议进行判断、交叉验证和完善，以确保最终的工作成果的准确性和实用性。

总之，作为产品经理，结合自身经验并充分利用 ChatGPT ，一定可以帮我们在工作中取得更好的成绩，提升个人的竞争力，升职加薪。

赶紧试试看吧。

— END —

你好，我是四月同学，10 年产品经理，三节课讲师

职场过来人，从菜鸟成长为产品部负责人，带过产品与运营；

专注分享产品经理知识技能、实战干货，以及求职面试经验。

公众号：四月喃哗，快，收藏关注，做产品不迷路！

前言

伴随着工作时间越来越长，逐步发现在产品中的文案表达愈发重要。优秀的文案表达法可以用户在使用产品的过程中迅速体会到阅读-尝试-反馈-开心的循环，而劣质的文案常常会让用户在面对优秀的功能设计时找不到或者不敢尝试第一步。面对着B端用户，优秀的文案能够让用在阅读B端产品时会带着一种工作状态去搜寻想要的服务，并且能够从表达的描述中确认这个服务是不是自己想要的；在使用中会明确知道如果我进行了操作，下一步将面对什么。劣质的文案会让用户不确定搜寻到的结果是否能够正常使用，进行操作后将面对的是个未知数。因此，无论是C端产品，还是B端产品；无论是消费导向型产品，还是销售导向型产品，亦或者是公共事业主导型产品，优秀的文案均是主力产品达到可用性的第一步。

这是一篇相对头重脚轻的内容，逻辑讲述基本放在了第一节，实际应用放在了第二节和第三节，第四节第五节则主要强调了收益和总结。因此如果仅希望本篇文章作为工具阅读，可直接阅读第二、三节。

一、产品文案的通用表达法

产品文案的表达方法大致可以分为表达原则和表达方式两个方面进行阐述，所谓的表达原则指的是在产品设计中的文案不部分在书写中需要注意的原则，表达方式则是需要梳理现在常见的文案说明是通过什么样的方式呈现在用户眼前的。两者结合便形成了一个产品的文案表达中的通用方案。

1.1 产品文案的表达原则（重头内容）

你在使用一个产品时，有没有发现因为文案跳出位置导致不知道下一步应该点击哪里？没有有在填充完成信息后不敢点击下一步的情况？我想在使用产品时或多或少会遇到上述的问题。那么解决产品中的文案表达，便是一项ROI非常高的促进增长的手段。

对于产品文案而言，如果希望用户看明白希望用户后续进行什么样的操作那么文案描述的准确性变成了产品文案设计的重要标准。对于用户打开产品以后，这个产品的基本介绍，用户能够在这里做什么事情，完成什么样的愿望，这类型的文案介绍，则是非常考察产品设计者对于文案全面性的要求。由于目前市面上绝大多数产品是无法通过一个页面解决所有问题的，因此，页面之前的功能文案是具有很强一致性的，有些功能除了本身产品之外全行业都可能用到当前功能，因此，在文案设计中一致性的原则也是非常重要的。本节便会从文案设计中的全面性、准确性、一致性三个方面进行详细叙述。

1.1.1 文案设计注意1：全面性原则

文案全面性原则主要应用于产品的表现层，需要产品介绍时非常清楚明白的告知用户当前产品能够给用户提供哪些服务。如我们经常能够见到的app底部TAB文案，都会通过TAB文案的方式告知用户可以在这款产品中体验哪些东西；在用户冷启动APP后，通常一次性告知用户使用app需要同意哪些隐私政策条款，如果在这里不告知明确的话，很可能用户就选择替代品了；对于付费也是有相似状态的，如果在一款连续订阅的产品中，没有完整告知用户不修订规则，退费规则的话，就会导致用户没有勇气进行下一步付费操作，从而丧失一个付费用户。因此文案全面便是非常重要的一环。

使用场景下的全面性：文案书写首先考虑的是在当前使用场景的全面性说明，也可以认为是用户处于当前页面中所有第一眼需要告知用户的文案需要列举完全。举例来说当我们打开app以后，底部TAB会告诉我们这个app能够帮助我们干什么，每个TAB的数据是从哪里来了，所以市面上绝大多数app的底TAB都是存在文字描述的。

关联场景的全面性：关联场景应用最为广泛的地方在于用户处于某一产品流程中。需要告诉用户如果要完成当前步骤，用户要做哪些事情，用户为了什么要做这些事情。如我们常见到通用类MP（Media Public）平台，用户在入驻的时候会告诉他们为什么要提交身份证，身份证提交完成以后需要通过人脸OCR识别才能到达下一步，此时就需要告诉用户，从入驻场景中，身份证和人脸双重校验主要是为了保护用户在媒体平台身份不会被盗用。同时要清楚告诉用户，在个人自媒体平台发文因为相关合规的要求，需要用户上传用户身份信息用以承担相关法律责任。因此在场景中需要文案告知用户要做什么，为什么需要这么做。

1.1.2 文案设计注意2：准确性原则

相信大家在日常产品体验中会发现很多产品的文案让自己不知道每个模块是干嘛的，按钮会出现不敢点击的情况，因此产品文案设计中文案的准确性便十分重要。文案在产品中呈现给用户，用户必然是希望通过看完文案知道当前功能是干嘛的，以及进入该功能以后会出现什么，用户需要付出什么，因此准备性的原则则是基于对当前的解释和对预期的管理。

当前解释：对当前用户所处场景的解释，主要包括两个方面，第一个方面是提供给用户这个功能是干什么的，比如说我们在B站上看视频，有一个模块是我不想看，下方会给出不想看这个视频的原因，需要用文字准确枚举用户在当前场景以及基于产品类型不喜欢看这个视频的原因，比如不喜欢这个作者，不喜欢这类视频，不喜欢这个封面等等，让用户清楚明白的了解这里面每个功能按钮是干嘛的。第二方面是对策略的解释，最直接的就是Amazon这样的电商平台在商品推荐时给用户的推荐理由，如果在北京的男性很多人都买了这个商品，买了A商品的用户他们同时买了B商品，B商品是跟着A商品配套用使用效果更佳等等，这类型的文案需要清楚的告诉用户为什么我推荐给你这些东西，核心是给用户解释清楚我的推荐逻辑，让用对平台有更多的信任感，同时也能促成推荐转化。

预期管理：产品文案准确性原则之二便是对用户的预期进行管理，需要通过按钮文案，按钮旁边描述性的文案告知用户如果你点击了这一步，下面你将面对的是什么。比如说我们常见的流程性的事情，大多会通过按钮文案“下一步”与“提交”进行区分，让用户知道我接下来会看到什么。这样做的目的是不让你的产品给用户带来更多的不可预见性，降低用户对未知的恐惧感，提升流程转化。

1.1.3 文案设计注意3：一致性原则

产品文案的一致性原则主要体现在功能入口，功能流程两个地方。从功能入口而言，一个功能应用在多个页面时，需要告诉用户这是一个功能的入口，点击这里和点击其他页面是一样的。从功能流程方面来看，需要告诉用户你在这里生效的数据会一直沿用到这个流程结束，比如用户获得了一张价值5元的爱奇艺会员优惠券，那么从用户看到这张优惠券-购买使用-收银台展示的整个流程中，都需要明确告知用户这是一张购买爱奇艺会员减5元的优惠券。

1.2 产品文案的表达方式

上文中已经对产品文案的通用表达原则进行叙述，本节主要希望帮助大家了解产品文案的表达方式。如果是表达原则定义为文案需要表达出哪些含义，表达方式则是定义了产品文案应该遵循什么方式给用户说明白。因此产品文案的撰写主要是希望能够让用户看得明白、看得舒服、主次清晰、知道下一步应该怎么行动。所以，产品文案的表达方式除了文案本身的撰写之外，还有文案的表现方式选择（如加重、斜线、醒目色等）。

1.2.1 文案如何书写

一般用户使用app时，除非重点需要进行合同阅读场景，其他场景下对阅读大篇幅文字是缺乏耐心的，因此文案的说明更需要为功能做出合理的解释（如果产品功能做得足有优秀，通过用户的常识，操作习惯，文化认知就可以不书写任何一个文字，那么这无疑是优秀的。但是目前大多数产品设计者还达不到这样，因此还需要通过文字和用户进行沟通）。正是由于用户使用产品的场景下对于文字缺乏耐心，因此在文字说明时需要做到简洁、易懂。简洁主要的方式是可以通过限制文字的个数，做最简单的主谓宾描述。易懂的重要方式是使用通用的词语，不要使用地方方言产生的词语，同时最好使用最简单名词组成句子告诉用户。除了上述两点之外，对于一些对专业知识要求较深行业的产品而言，行业术语便是最基本的表达方式。如果这个行业正在逐步大众化，则可以考虑将行业术语中的名词做稍加变更，让业内人能听得懂，让小白看到也能大概明白。这点目前看，剪映APP无疑是成功的，视频制作环节中我们在剪辑渲染时所有的操作在属于中叫做工程文件，这个术语对于新手小白而言无疑会造成新的理解成本，剪映的处理逻辑则是参考了绘画、写作这种相对基础内容编辑中常用到的术语，将工程文件的名字变成了草稿，这样做的意义是小白很容易就能够理解，专业认识虽然不屑但是也理解草稿是干什么的。

1.2.2 表达如何高效

用户对于产品使用时的文字提示记忆力是有限的，那么除了通过文案本身让用户能够看懂产品想要表达什么之外，我们的文案还需要用过一些效果让用户深刻的记住产品对用户的提示与反馈。一般重点提示时通常会用变色、加粗、斜体等方式告知用户，一般对于用户错误的反馈则是会通过文字抖动的效果告诉用户这步是错误的。因此，通常情况下，我们会对文字中的重点内容进行色彩、样式、动效的方式进行包装，用以高效对用户表达。

共识表达：在产品设计中，作为说明部分的文案，通常在文字选择中选择达到共识性的词语。

简约表达：简约表达涵盖的意思是如果通过数量少的文案和更容易理解的文案进行表达。比如我们常见到的在视频产品中会出现通常用专辑的文字来描述相同主题组成的视频合集。在银行类app中用户的储蓄金额，贷款金额主要是用阿拉伯数字进行描述。

突出表达：一般情况下，如果某些内容非常重要，是用户理解我们产品的关键描述。那这部分描述需要用最具有吸引力的方式进行渲染。

二、To C产品文案如何表达

To C产品的使用者主要是我们的面对的一般用户，由于C端业务的特性，因此根据业务划分，用户主要是两种类型，其一是对当前业务已经熟悉的用户，其二是新入门的用户。因此针对于这两部分用户我们都需要做处理，处理的核心逻辑是让熟悉业务用户的适应成本更低，让新入门用户的理解成本最低。

2.1 让熟悉业务用户的适应成本更低

当一款产品推出的时候，无非是面对新踏入业务的用户和已经熟悉当前用户的老用户。那么让熟悉业务的用户适应成本更低是在产品发展初期快速积累种子用户和核心用户的重要方式。让熟悉业务的用户适应成本更低，总结下来的两种方式是以下两个方面。

2.1.1 使用原有用户熟悉的描述

使用原有描述是让用户最熟悉的方式，最简单的方式是从业务书籍中翻阅和通过田野观察法，用户访谈法获取用户对名词的认知。描述获取的方式可以参考从专业书籍、课本、实地业务获取。

2.1.2 使用原有用户可以很快理解的描述

一般情况下，原有用户很快理解的描述，主要是3种方式。其一是用学术描述中偏向通俗口语化的词语，比如剪映在对工程文件的描述变更为了草稿。其二是通过关联性质词语进行替代，例如我们在制作一个视频时，对视频色彩方面的处理一般称之为渲染，为了能够照顾到小白用户，有时会使用包装这个词语进行替代；其三是使用行业曾经使用过夜的词语。

2.2 让新入门用户的理解成本最低

在业务起步阶段，除了需要让你的核心用户快速理解产品中文案内容，还有个很重要的是让新入门的用户能够快速理解产品的功能，能够快速理解产品功能所要表达的内容。因此，产品文案对于降低新手理解成本起到了至关重要的作用。

2.2.1 多联想生活常识的词语

面对新增用户的时候，我们在产品中撰写的文案如果需要让他们能够快速理解，使用他们生活中所用到的词语是非常有益处的理解描述。比如说电商产品最早使用购物车概念，希望用户可以一次性将所需商品放到集合中，那么在生活中人们逛超市用的东西普遍是购物篮和购物车两种产品，这个时候我们在产品功能设计和解释中，对于当前合集功能描述可以参考使用购物车和购物篮两个方式。

2.2.2 让用户保持轻松

基于2.2.1中对电商产品合集的描述，对于当前场景下我们有两个描述（购物车or购物篮）供选择，我们应该选择什么呢？在生活中，我们去超市，拎着购物篮逛超市的时候，当我们装了较沉商品时，手臂负担是非常重的，所以通常去超市购物的时候，如果只有购物篮的情况下，我们选择商品时会保持着谨慎的态度，尽量不买很沉的商品。如果是购物车的话，用户可以推着车到处跑，对身体的负担是极小的，因此在整个逛超市环节是轻松的。所以我们发现，在电商网站中，大家对于用户希望购买商品的合集名称会选择为购物车，也便是这个原因。记得在文案选择中尽量选择让用户感觉轻松的文案。

2.3 寻找多方共识的文案表达法

我们在2.1、2.2两个环节中分别讨论了文案对于新用户和老用户的表达要求，由于产品不可能仅针对于某一类用户，因此在文案选择中，需要考虑到两部分用户的使用方法。通常在这部分中，我们要讨论业务发展、产品属性、文案侧重三个方面。业务发展的角度来看，我们需要明确清楚我们目前的业务是让小白专业化还是普世大众，这决定了一个功能的描述是应该更加朝向专业化还是大众化。其次产品属性而言，我们的用户规模是什么样的，未来的规模是什么样的，对应的用户构成是什么样的，通过以上3点分析，我们的产品是对小白多还是对专业多，未来在获客承载上文案应该如何设计。最后，就是基于上述两点，我们可以确定文案侧重应该在哪些时期怎么撰写，当然有一点还需要记住的，关于功能文案，尽量不要随便改名字，所以需要尽可能一次性想清楚。

三、To B产品文案如何表达

前面我们主要讲解了To C文案如何表达，下一步便是关于To B产品文案如何表达的问题。

3.1 To B产品的用户

在这里不对To B用户做详细分析。To B用户在使用产品时主要是在当前使用场景下具有一定专业基础和能力的用户，因此对于你的用户而言，产品设计中的文案表达需要的是专业度。如果用户不具备专业能力，那么这部分用户是需要学习专业知识的，因此，在产品文案设计的过程中，可以忽略到培养的过程。

3.2 To B产品的文案设计准则

对于To B产品的文案，前文有写，面对的用户可以定义为具有极高专业基础和专业能力的人，他们在使用产品的过程中主要是在办公场景下，因此，在整体文案设计中，需要的是契合办公场景而非休闲娱乐。因此，在文案设计中专业性、准确性便成为To B文案设计中最重要的部分。除此之外，由于在产品设计中，会出现创新业务的场景，那么对于这种场景下，希望你的用户能够快速理解，尽量少的找你问问题，那么文案的易懂性便成为创新业务B端文案的重要设计方法。

首先我们来说To B文案专业性问题。由于B端产品面对的用户都是专业领域的行家，他们对于当前专业有丰富的基础知识，因此在文案设计中，重点考察的是产品文案的专业性，需要让用户打开产品以后，就能快速进入到业务工作状态，这便是To B产品设计专业性的目的。

其次探讨产品文案设计准确性的问题。B端用户，在使用产品时其实是再做一次效率工程。那么，这个时候文案的确定性决定了B端用户是否敢于做动作（事件），能否预知下一个事件会发生什么，发生以后有没有相应的降级方案。因此，在B产品产品设计中，为了能够让你的用户知道功能怎么用，敢于使用功能，在使用功能时不出现失误，那么文案的准确性便是B端产品文案设计中非常重要的一环。

最后我们来针对创新产品聊一下文案易懂性的问题，面对新业务时，B端用户相比于纯粹的C端用户，了解更多的是专业的事情，对于之前0基础的事情和C端用户差异性很小。因此在整体产品文案描述中，同样需要让你的用户能够快速理解并上手新的业务，因此降低理解成本便成为设计中的关键一环，可参考2.2中所陈述的设计方法。

四、优秀文案带来的收益

对于产品而言，面对你的用户主要是通过功能交互、视觉效果、文案解释三个方面让用户能够使用明白。优秀的文案在用户使用的过程中可以让用户更加敢于做动作，增进与产品的耐心与信心。同时还有可能因为在用户已经了解固有功能的基础上激发用户的创意。这便是优秀文案对客阶段带来的收益。由于在很多解释场景下，通过文案给用户讲解清楚，因此在整个业务环节中，可以降低客户服务等成本，对于整个公司业务人员，业务系统也可以更加精简，成本更低。

五、总结

最近一段时间，在打磨产品的时候，经常会发现越来越多的场景下，需要通过文字与用户沟通。对于一些复杂的业务逻辑，能够在产品上给用户说清楚是一件很复杂的事情。因此在设计文案中，除了上述所说的，可以在文案梳理完成后，借助公司其他小伙伴帮着自己看看，文案和交互是否能够看懂，他们理解的和你想表述的意思是不是一致的（选择小伙伴时，也一定记得选择和自己当前设计方案尽量少业务往来的小伙伴，尽量找0基础的小伙伴帮着看）。通过这样的方式，也可以帮着自己提升产品文案的设计能力。

六、写在后面

最近一段时间比较疏于写作，后面需要尽快写起来。今年给自己定了个OKR，希望能够写完4篇文章，不能像去年那样颓废了。所以，还是要继续加油啦。

前言

一晃又好多年没有好好更新过文章了，时光如梭，岁月如流啊，翻了一下之前的文章，中途夭折的不计其数哇（其实也就两三篇。。。咳咳~~），每次看到一个半截文章，就感慨，咦，原来我还写过这个，嗯，好像有点印象…只是后面要写啥早忘的一干二净了，为那些文章默哀一分钟~~

不过呢，最近这半年终于在懒中偷忙，整理了之前家装领域的一丢丢经验，可以简单写写，供各位大佬和大神参考。

今天要聊的话题呢，其实就是家装领域中的BIM，怎么说呢，其实行业内研究和发展了挺长时间的了，但是似乎一直没有看到一些特别成功的东西出来，它面向的用户对象是谁，到底解决什么问题，能带来什么价值，到底怎么才能落地执行，似乎每个公司都有每个公司的侧重点和考量，并且每个公司对其的预期也不太一样。

落地过程中呢，也总会遇到各种各样的困难和问题，所以也衍生了一些很奇怪的现象，似乎是大家都认为家装的未来在BIM，但是却没人知道为什么在BIM，到底它有什么用？它到底是不是一块鸡肋，食之无味，弃之可惜呢？

而对于我，作为一个运气比较好一些，有幸落地过BIM，并且稳定运行了几年的产品来说，也希望能通过自己对这件事情的分享，将自己对这件事情的思考和做法分享给大家，如果恰恰能够给大家带来一些新的思路和启发的话，那就最好不过了。

（如果真的有用，记得请我吃饭，哈哈~）

首先，什么是BIM

BIM（Building Information Modeling）技术是一种应用于工程设计、建造、管理的数据化工具，通过对建筑的数据化、信息化模型整合，在项目策划、运行和维护的全生命周期过程中进行共享和传递，使工程技术人员对各种建筑信息作出正确理解和高效应对，为设计团队以及包括建筑、运营单位在内的各方建设主体提供协同工作的基础，在提高生产效率、节约成本和缩短工期方面发挥重要作用。

（该段内容来自百度百科）

BIM，建筑信息模型（Building Information Modeling），其实是从建筑领域来的。只是说在家装领域，室内设计也在行业内逐步的开始由2维的CAD绘图，开始转向3维的工具辅助设计，初期呢，其实只是为了呈现设计效果，用户可以直观的感受自己未来的家会装修成什么样子。后来呢，因为天然是3维的设计，天然有一些数据化的内容，比如房屋户型、空间、面积等信息，基于行业本身的数据化发展的进程，对于算量、计价等也逐渐有了自己的诉求，也就慢慢的开始有了家装领域的BIM。

其实，BIM自身在建筑领域的定义，就已经决定了BIM未来是什么样子，只是在不同的公司，也是各有侧重，这个后续在慢慢细说~

OK，大概了解了BIM的概念之后呢，我们就来看下BIM到底是个什么样的工具。

BIM是一个什么样的工具

这里呢，也就简单介绍一下，大家知道个前因后果，不做深入探讨和分析。（因为一分析就又是一篇巨长巨长的文章了，后续有心情了再写吧，咳咳）

在行业内，目前比较出名的几个软件工具，大概就要数酷家乐，三维家、每平每屋（原躺平）、打扮家等，以及贝壳旗下的一些自研BIM，如视的未来家之类的。

这些工具中，酷家乐，应该是最广为人知，因为它除了面向B端，也同时面向C端开放，这个原因，也促进了它本身的迭代和知名度。

这些工具呢，因为侧重方向不同，大概上能分为下面两种：

我们来聊一下这些工具的类型，这些工具呢，首先肯定是一个设计工具。因为设计是整个家装的上游，没有设计，就谈不上后面的所有的算量、图纸、交付之类的东西。所以，设计工具在之前一直是这类工具的核心，我不关心之后能不能实现，现在我得先要好看，是吧。所以最初的时候，大家的精力都会在这些工具如何才能更好的促进转化上来。

慢慢的，开始有一部分企业开始思考，既然设计已经数字化了，那设计过程中到底用了哪些材料，材料用了多少，主材多少，辅材多少，这些用量是不是也可以数字化呢，如果这些量可以数字化，那是否意味着可以以BIM中的量为整个工程的计算依据呢？

（要知道，现在整个行业大多数还在手扒CAD，拿计算器算量呢。）

因此慢慢的也开始出现了一些主打交付工具的工具，以算量为核心，主打所有的用量由系统计算得出，减少人工计算的误差和偏差。当然，现在似乎每个工具都会有算量等负责交付的团队，不过底层的不同，也必将会带来上层的不同，某些时候底层结构的缺失，也会导致某些算量完全无法计算。不过这些后续有机会再详细聊好啦。

那对于BIM，它到底应该是个什么样的工具呢？

其实上面聊得已经比较清楚了，根据BIM本身的概念，还有家装行业工具的发展轨迹，BIM的未来大概率上是以算量为核心的一套设计+交付的工具。也就是底层要按照能支持算量的结构搭建，而在应用层，也要能充分支持设计本身，做一个好的设计工具~

家装业务存在的问题

在聊BIM能解决什么问题之前呢，首先得先聊下在实际的家装业务中存在哪些问题。一般情况下三大问题比较突出一些，分别是人员效率问题，材料成本问题，项目利润问题。

为什么说有这三块的问题呢，我们分别来看下。（这里也就是简单聊下BIM能解决的问题，不能覆盖所有可能存在的问题）

人员效率问题

目前整个家装行业的报价部分信息需要设计师手动计算和填写，过程较为复杂，用量计算较多，时间消耗大约1-2小时。这还仅仅在报价，还有本身方案的沟通，图纸的绘制等等。设计师是签约的核心转化成员，若系统能让设计师的作业效率提升，也就意味着设计师会有更多的时间接待和转化更多的客户。

材料成本问题

由于装修过程中涉及的材料用量，是完全由人工计算然后录入系统中的。

在这个过程中，对于损耗的预估不同（比如A认为8%的损耗就够，B认为需要12%）；对于自身利益的取舍（比如多下点材料，避免后期补货）等等。你会发现，同一个客户，同一套方案，同样的材料，不同的设计师肯定会报出不同的材料用量。

而在某些极限情况下，可能还会存在60平米的屋子，下单200平米的地板；有些工地会出现几百个插座等等材料问题。材料成本极其不可控。即使很多企业中间还有一层中控进行审核，但是依然很难完全避免。而且材料在人工计算无法精准的基础上，后期的退补货也会较多，也会让成本上升更多。

项目利润问题

在整个项目的利润上，大多数项目的毛毛利润率差不多在20%-30%，基本上都会是入不敷出的状态，每年的现金流都很好，到年底一算账，发现不赚钱。咳咳，在流量增量比较可观的时候，可能问题都不太大，毕竟有很优质的现金流，但是一旦出现了增量减少的时候，如何精细化运营，在整个项目中尽可能的减少开支，节约成本就变成了一件很重要的问题。

BIM能解决的问题

那BIM能不能解决上面所说的问题呢，咳咳，估计大家用脚指头都能想到了吧。

嘿嘿，但是还不够。

在仔细研究了BIM工具之后，你会发现在报价层面、算量层面、体验层面和图纸层面都会有完全截然不同的体验提升，而这整套体验，其实带来的是整个设计和交付行为的重大变革。

报价层面

BIM本身作为3D的设计工具，户型的结构，面积，空间信息，空间中的材料信息一应俱全，那么完全可以从BIM工具直接生成用户的报价单啊。

对了，这里多废句话，现在家装行业的报价功能设计的底层逻辑都是人如何在做报价的时候做的齐全还不缺项漏项。所以所有的顶层设计都会围绕这个底层逻辑在做，你不管看多少家报价体系，都在基于这个底层做事情。当我们接入3D设计工具的时候，是否可以换个视角，设计师是否可以不再做报价单了，而由系统来做。当视角不一样的时候，你就会发现顶层设计就会变的完全不同了。咳咳，这里就暂时不再延展开了。

还有就是，报价单是表格这件事情，咳咳，这个行业都几十年了吧，这都2202年了，是否可以考虑换个形态，比如图文或者什么的。如何更清晰、易懂的向用户传递装修的基础信息，其实可以换个角度来考虑。

怎么做，有多少困难，困难都如何解决，就先不聊了哈，废话扯得有点多了，咳咳，勿怪勿怪。

算量层面

BIM哎，3D设计工具哎，基本上都可以由系统直接计算所有材料用量了和施工用量了。由于完全依据系统规则生成，只要设计方案是准确的，用量也自然会是准确的。完全可以屏蔽人为因素的影响。同时这些数据也完全可以用于后续的发包和下单。

（咳咳，当然，完全一点都不差也不现实，部分小的偏差，瑕不掩瑜，不影响大局。）

体验层面

BIM本身是3D设计工具，即方案完成后，用户可以直接进行3D漫游体验，甚至可通过可穿戴设备进行VR体验，所见即所得。再也不用全靠2D的图纸想象了。

未来你的家如何，是否让自己满意，完全可视可见。对于空间想象能力较弱的用户，这简直就是巨大的福音。

图纸层面

BIM本身也会根据设计师的方案生成全套的施工图纸，可以节省很多CAD绘制的时间。

（这个根据工具的发展阶段不同，有些工具支持，有些工具不支持，有些工具只能支持部分。）

当这些层面都发生变化后，你会发现，这完全就是设计行为、报价行为、发包行为、结算行为等数据产生和传输行为的重大变革。

设计不需要在CAD中进行，用户无需靠自己脑补想象未来家的样子，报价不用做了，系统一键生成，所有的材料用量根据系统规则生成，摒弃了人为因素带来的偏差，施工图纸自动生成，后续的发包，下单依据准确的用量进行，支付和结算也有了相应凭据。

家装行业的产品分层

既然说BIM这么好，到底好在哪里呢，他在家装整条业务线条中，到底处在什么位置，有什么重要作用呢？

再聊位置的之前呢，先聊下整体的家装业务吧，从产品底层来说的话，整体大概可以分为五层，分别为业务层、数据层、预算层、支付层、结算层。

五个层面分别面向不同的问题，提供各自的解决方案，家装整体业务体系也基于这五层进行构建。

业务层

业务层主要提供家装全链条业务侧解决方案，也是最重要的一层，所有的业务流程和逻辑都可以划归进该层。

整体的结构基本包含以下部分：呼叫中心、销售中心、客户中心、智能交付中枢、合同中心，订单中心，交付中心，供应链中心，财务中心，售后中心，智能设备中心等。

基本涵盖了家装行业全链条的业务内容，所有的业务数据都在该层中处理。

（哈哈，此处也先卖个关子吧，内容暂时就都打码了，后面应该会有个系列专门说业务层的所有框架和内容。。。咳咳，应该是应该吧，但愿不会再是两年后了~ 咳咳）

数据层

数据层主要指装修项目中的施工数据、材料数据等信息，这部分信息既包括了用户的报价，也包括了向下游的各个端口的发包、订单信息。

（业务层的业务数据在业务层处理，不在该层中处理。）

该层面主要处理从设计开始的所有户型和家装全量数据，包括施工项目数据和材料数据，以及后期所有的变更数据，贯穿了家装过程的始末，而这部分在大多数的公司和企业里面，也是完全需要靠人来处理的。所有用量的计算，报价的计算，施工过程中的变更，后期的退补货，这也是链条中最难控制的部分。略微有点像那种，看起来每个地方都没花什么钱，但是就是钱都花完了的既视感。

而作为BIM工具，也是在这层中发挥自己最大的价值，全部数据由BIM统一输出，下游依照上游数据执行，从最大程度中规避过程中的数据风险。

预算层

预算层主要用来衡量项目层面的预计收入、预计支出和预算毛利率。算是整体项目预算的最关键的部分了。这个项目到底能不能赚钱，能赚多少钱，毛利率多少，是否能覆盖全部成本，我到底能不能盈利，这些问题，不能等到项目结束才知道，而要提前预测。并且尽可能的让决算与预算相接近，这种情况才能最大程度上节约成本，从而盈利。

这部分主要涉及到项目内容、后台的成本构成，税率关系等内容。需要依据数据层提供的数据进行准确预估。从而达到在项目未开始前，整体项目的收入、成本、增值税、附加成本以及毛利率直接可预见。

这层的准确性依赖于数据层的准确性，所以，能不能搞好数据层的数据，就决定了能不能搞好预算层的数据。

支付层

支付层主要提供用户支付的解决方案，包括微信支付、支付宝支付、POS机支付、现金收款、对公转账等等。

支付链路横跨整个用户生命周期，特别是在家装业务上，项目周期比较长，支付频次（定金款、首期款、变更款、中期款、尾期款）比较多，支付金额比较大（大多数会超越在线支付单次5万的限额），支付方式比较多变（在线支付、POS机支付、转账等），付款逻辑和场景也比较复杂，如何更好的处理用户的支付场景，完美衔接自己的业务体系，就需要更多的花费一些心思。

这张图呢，基本上介绍了这个行业支付这块的关键信息，之后应该会有一片专门的文章说这块，这里就不一一展开了。

至于里面为什么微信、支付宝既有线上支付，又有线下支付，这里主要是区分是否能自动线上对账的，如果能线上自动对账，那就算线上，否则的话，即使支付了，也需要重新在线上认款到对应项目中，这个就算线下支付。

（咳咳，感觉这篇文章，直接挖了两个文章的坑啊，不知道填不填得上。。。咳咳~）

结算层

这层相对下游一些，也是狭义的结算，主要提供工程结算、供应商结算的解决方案，也就是主要解决如何向对应的服务者结算的问题。

其实没有太多需要说的，相对比较简单，在上游数据完备的情况下，相对比较好处理，只需要按照结算规则、账期和结算方式落地就行，大多数都是发起结算，审批结算，对账，打款等。

唯一需要考虑的是要尽可能多的覆盖异常场景，这样的话才会形成一个完整闭环，避免某些特殊情况的行为、支出、扣款等导致系统无法进行正常结算。

BIM在家装业务中的位置

上面已经清楚的讲了五个层次的基本分法和概念，那么BIM在整个业务中的位置就清晰可见了。

BIM在数据层提供完整的、精确的原始数据，通过业务层产品规则（套餐规则）的转化，形成面向用户的报价单、变更单、同时形成面向施工方的发包单，面向供应商的发包单。贯穿全业务流程，为预算层、支付层和结算层提供准确和完善的数据支撑。

而这些单据，面向用户的代表收入，面向服务商的代表支出，也就同时会产生预算单，也就意味着，在一个装修项目开始的时候，就能很明确的知道项目的收入、成本、利润率，从而为项目后续的进展提供准确的参考依据。

聊了这么老久，终于可以开始聊一聊BIM到底是如何应用与实践的了，咳咳，五千字才进入正题，不会被打吧~~

BIM应用的框架结构

上面很详细的聊了家装业务的产品分层，并且也说明了在这套分层结构里面BIM的位置，那么BIM在整套业务体系里面，到底如何规划和落地呢。

其实通过上面的这些内容，可以大概梳理出来，BIM在整个家装业务体系中的数据流转结构。

从BIM中获取基础数据，流转至业务层的套餐规则中，进行转化和输出，输出报价单和发包单。而销售和成本直接的关系依靠底层数据进行拆分和关联。从而将所有收入和支出引入财务体系，完成预算和决算。

BIM框架中的三大难题

在这套结构中，核心会存在三大难点问题：BIM的数据问题、报价规则和发包规则的抽象问题、销售与成本之间的转化关系问题，而这三个问题，恰恰也是整个系统结构流转衔接的关键点，也就是说只要能解决这三个问题，整体的产品方案就能落地。

那么既然定位了核心问题，那么接下来要做的就是一个一个解决掉它。

BIM的数据问题

BIM的数据问题，决定了BIM将向业务侧传递什么样的数据，业务侧需要接收什么类型的数据。数据的格式如何界定，如何隔离BIM和业务体系，做到低耦合，同时通过数据通道相连。这里面还需要解决两个问题：BIM能提供的数据是什么，业务侧需要的数据是什么格式的。

这里就会涉及到两部分，BIM能提供什么类型的数据，而业务侧需要什么样的数据。

对于业务侧需要什么样的数据，这里解决不了，因为业务侧需要什么样的数据，需要在抽象规则后才能知道。产品实现的过程是由底层数据到上层建筑的过程，但是在产品构思阶段，却是由顶层结构拆分至底层数据的过程。两个完全相反，所以，这个问题会在下一个节点来说。

这次我们就聊聊BIM能提供什么类型的数据。至于BIM工具本身，就不多讲了，一讲起来就又是一篇长篇大论，等以后了，咳咳，我也不会写，工具写起来累人。。。（再说了，emmm，前面已经埋了两个坑了，再挖怕是。。。。不厚道了）

虽然这里不打算讲BIM，但是你怎么才能知道BIM能提供什么样的数据呢，那就需要小小的研究一下了，嘿嘿~

其实也不用研究的很细，就。。。就。。。把它整个功能结构扒下来，基本上你就能大概清楚他的数据结构和底层逻辑是怎么处理的了，咳咳，是不是很简单。

因为工具本身存在了前端应用的结构和管理后台，所以扒的时候不要漏了~

前端结构主要用来了解基础性质的原子数据，后端结构主要用来了解底层的数据支撑和结构，两者都不可或缺。

前端结构的数据和后端结构的数据如下图，具体是哪一家的，就不做细说了，自己看吧。限于结构图太。。。长了，所以只截取一小部分。对全部结构图感兴趣的，可以关注「脚量产品路」微信公众号，发送“BIM”获取脑图源文件~

所以，当你扒完BIM工具的整体结构之后，你就会发现，BIM本身提供的是原子化的数据，他可以提供你很精确的底层数据，比如户型的面积，结构，每个空间的名称，空间的长宽高，空间面积、空间周长，门的高宽厚等等原子数据，所以这些数据如何才能变成业务切实可用的数据，就需要依赖于业务侧到底需要什么样结构的数据了。这就是我们下一个问题需要聊的了。

规则的抽象问题

我们前面有聊到，BIM的数据经过规则的转化之后，会转化为报价数据和发包数据，一则面向于用户进行报价，一则面向于下游进行发包。所以，规则的抽象其实就是两套规则的抽象。也就是产品报价规则和向服务者的结算规则抽象。

先聊报价规则吧，报价规则应该算是一块最难啃的骨头，因为这个领域，报价规则，那是手册啊。。厚厚一本。。。

没办法，只能采用老办法，也是笨办法，有可能也是最有效率的办法，将整个手册全部扒下来，然后从一堆规则中去提炼和抽象核心规则。产品手册的规则一般包含几个主要部分，分别是计价规则、主材配置、升级、限量规则、水电点位规则和个性化施工项目规则。

任何一个复杂的结构里面，底层一定有一条或者几条规则，是整个结构的核心，支撑着整个结构自由运转。而我们要做的就是在复杂的、冗余的、拥有极大干扰的巨量因素里面，去剖开表象，剥离出最本质的几条规则。这也将会是我们突破的核心点，以点才能破面。

具体的过程我就不多描述了，如果感觉体会不深，咳咳，可以联系我，我给你个手册你自己剥离一下尝试一下，不用担心，不要钱，咳咳~

这里就只说结论了，在将所有的规则都扒出来之后，果然发现了最核心的一条规则，这条规则就是产品报价的核心：在XX空间下，XX 材料/施工项是标配的？还是升级的？还是加载的？行业内的同学会不会觉得跟自己现在做的好相似~ 虽然像，但好多事情差之毫厘…希望我的做法能对大家有一些新的启发。

（这里简单解释一下，对于一般家装行业套餐制公司，家装的收费是按照房屋面积收费的，比如999元/平米，所以这里的标配指的是不需要额外花钱的，包含在套餐内的。升级指的是不在套餐内，但是你可以补差价升级，比如你想用更好的地板/瓷砖时，可以补一个差价。加载的话就是指套餐内完全不含，需要付全部费用购买的。）

在这条规则之下，你会发现绝大多数的（80-90%）场景都能覆盖，而且它也将直接决定业务需要的BIM数据是什么格式的。

在这条核心规则的基础上，并不是所有的规则都能满足，所以还需要一批其他的特殊规则进行补充。包括水电点位规则，门的超高/超宽/超厚规则，垭口超厚规则，窗套超厚规则，地板/铝扣板异形规则等等。而这些规则在一起将支撑整套报价体系自动生成。

报价规则抽象完了之后呢，就是如何抽象结算规则了，用来决定如何发包，这套规则比较简单，核心其实就是售价和成本的问题，然后对于工程会有一些套餐包的计价，比如施工部分包给工人多少钱这样，相对比较简单一些。

结算的转化问题

最后来一下结算转化的问题，这个东西主要界定销售和成本之间的关系，看起来比较简单，其实也的确比较简单，咳咳~

只是会有一些特殊场景，所以会跟正常的通过sku管理销售和成本的关系不太一样。举个简单的栗子大家就能明白了。

所以，看完上图也就不难理解，为什么需要独立关系处理了吧，因为转化关系并不完全是同一单位的数据转化，而会是不同单位的数据转化。

聊到了这里，大概就可以理解，为什么在BIM应用的框架结构（不要问框架在哪？往上翻翻，咳咳~）中，会单独拆出来三个库来处理内容了吧。

而对于仓储，因为同样涉及到了出入库的内容和采购的内容并不一定是一一匹配的，所以也将仓储的部分独立拆分了库，进行独立管理。

BIM的落地产品方案

聊了这么多，也说了这么多问题如何解决，那么到底实际的落地方案会是什么样子呢，会不会很好奇，以下将是重磅内容，哈哈，期待一下吧。

上面聊了所有的框架、结构、要解决的问题、以及如何解决，那么接下来就看看到底在系统中如何落地吧~

功能结构图

在开始落地之前呢，肯定还是要大概梳理下功能结构的，虽然上面其实已经聊得差不多了。

数据流程图

然后就是数据传输过程中的流程图，用来更清晰的表现数据过程。

BIM的数据方案

上文已经界定了BIM需要提供的数据格式为，空间/施工项、材料/用量，那么BIM工具就需要提供该种类型的核心数据，同时也需要提供BIM的基础空间等信息数据。

• 基础项目、方案数据

包含基础的项目、方案信息、该户型结构及基础内容。

• 施工、材料数据

详细的施工和材料数据信息，也是最核心的信息。业务规则将依据该部分内容进行相关报价数据和结算数据的生成。

（注：木作数据比较特殊，此处不详细聊，有兴趣的关注公众号之后，加我微信详聊）

规则的抽象方案

规则的抽象核心是各种规则的提炼，上面核心规则和分支规则已经聊得差不多了，下面就是具体的产品方案。

规则的抽象和提炼总共分为了8步，分别为：套餐规则管理、套餐商品管理、商品规则管理、附加规则管理、拆除包管理、水电包管理、补充报价管理、发包管理。

• 套餐规则管理

主要用来管理套餐的基础计价规则，及相关内容介绍。

• 套餐商品管理

主要用来界定该套餐包含哪些商品。对于纯粹的装企来说，那就是包含所有内容。

如果对于复合型企业来说，比如有自己的大店，有自己的电商，并且与家装业务有明确区分的时候，这里可能需要额外的关注下。

• 商品规则管理

主要用来界定最核心的材料和施工项规则，即某个空间是标配的，升级的还是加载的。

• 附加规则管理

主要用来解决附加规则管理的问题。附加规则上文已经说的很清楚了，这里就不在赘述了。

• 拆除包管理

拆除包主要用来定义计价规则和收费内容。

• 水电包管理

水电包管理主要用来管理水电包的计价规则、水路点位规则、电路点位规则等。

• 补充报价管理

主要用来兼容部分无法在BIM工具中算量和计价的项目。比如我们之前对接的BIM工具不支持复式、别墅这种多层设计，那么一旦在实际过程中遇到该类户型，就需要采用一些方式，兼容该类特殊设计。

当然，既然作为一个入口，那么一些特殊场景内无法满足的，都可以在这个入口兼容。

• 发包管理

发包管理主要用来管理施工部分的发包规则，其他材料部分，由关联关系可以直接衍生，但是施工侧会有一些独立发包规则，因此需要独立管理。

结算的转化方案

这个呢，其实就是3个基础库如何进行拆分转化，其实没啥太大难度，基础库需要区分一些类型和属性，比如不同类型的施工库和材料库分开管理，结算库里面要有税率，库存库里面要有库存等等，就不详细赘述了。

转换公式里面有一些需要关注，比如一些基本参数，比如户型面积、损耗系数、库存的尺寸等等可以作为基础参数进行定义。公式的本质是数学运算，所以能提炼的就尽可能提炼就好了。

前端应用

三大问题解决了，数据可以传输了，规则也已抽象完成，转化关系也已建立，那应用时是如何应用的呢。

• 获取方案

在BIM工具中完成方案后，只需要一键获取就可以了。

• 生成报价

获取后呢，系统根据规则自动生成相应的报价和详情。因为是图文，所以也完全可以在手机上进行呈现，虽然表格呈现信息的组织性和逻辑性很好，但是可读性并不太好，毕竟是给用户看的，所以，看的爽和能看懂才是第一要素，其实也不用过于拘泥于之前的行业方式。

因为报价单本身内容太多了，所以就不展示全部截图了。需要的到时候关注公众号「脚量产品路」输“BIM”获取相关内容吧。

Web报价详情

App报价详情

• 生成发包、预算

根据转化关系自动生成发包和预算，直接获取所有项目的收入、成本和毛毛利率~

OK，整个项目上，基本上到此就打完收工了。。。至于变更怎么做，财务如何处理，这些地方按照自己的业务逻辑和规则处理就好啦~

但是，但是，真的完了么？

PLAN B的必要性

在对接BIM的时候，一定要考虑的一个点，就是一旦BIM跪了，业务怎么办？如果是三方的BIM，业务肯定不能一直等着三方BIM团队来解决问题。（你一个月没法解决，难道我还能等你一个月么，咳咳~）

所以在架构上的拆分就很有必要了，BIM作为数据的输入方，如果BIM一旦跪了，那么就需要有一个路径将数据输入这套体系。

这就是PLAN B了，任何时候要给自己的业务体系留好后门，别过于受其他方掣肘。

至于这个PLAN B是什么样子的，既然你都看到了这里，应该就不用多说了吧，嘿嘿~

当然，这其实也是一个好事，当你考虑到这个点的时候，其实也意味着，你的业务体系就可以接多个BIM工具了，备胎多点，自己的业务体系就会越稳定~而且，你也不用担心某个BIM忽然某天黄了，自己的业务就废了~哈哈~

当然，这里其实也抛出了一个问题，如果没有BIM，这事能不能搞，能不能搞哩？

当然是废话了，没有BIM当然能搞拉，BIM的核心在于提供基础数据，如果有一套体系可以脱离BIM提供基础数据，是不是就~~~~~

这套体系是啥呢，可以自己想想，它的确存在且切实可行，并且我并不打算写，哈哈~（主要是市场上BIM工具还挺多的，着实没有必要~）

数据的对接与维护

任何一个体系总要落地执行吧，所以业务体系和BIM工具，双方数据的统一和维护就需要保持一致和统一。

如果刚好你自己的公司就在搞BIM，那就最方便不过了，直接底层数据打通，用一套数据就好啦。

如果没有自己搞BIM的这个实力，也没关系，这也是件好事，就意味着你可以接市场上所有的BIM，毕竟备胎还是要多来几个的，要不然一旦接的那个BIM工具黄了呢，咳咳~

在这种情况下因为本身在两套体系里面维护数据，为了确保数据在维护层面准确，可以建立一些数据维护的SOP，这样就能很方面相关方维护相关数据啦~

产品的培训与使用

因为这种方式呢，其实跟设计师之前的处理行为截然不同，所以，培训和使用过程必将面临着巨大的难题。所以，公司上层的老板们要考虑好，这件事情到底能带来什么，是否需要付出这种成本，收益到底如何。这将会是一个一把手工程，因为这个在执行层面会遇到极大的阻力。

抛个一定会出现的问题示例一下吧，咳咳。那就是一定会有人反馈，这个算的量不准啊~面积少了，面积多了，量少了，量多了~

这种问题应该是最影响业务运行，也最容易让人恐慌的了，所以这种问题，解决的方式也很简单，拿到设计师原始量房图，从每一条线开始核对户型数据是否准确，从而解决面积误差问题，这个问题很重要，因为涉及到了按平米计价。

对于用量问题，就是查看设计方案，去一点一点扣量是否准确，设计师的操作问题（比如某个地方忘记了铺瓷砖），还是BIM工具问题（比如工具计算错了用量），还是业务体系转化的问题（比如转化公式有问题），然后去解决对应问题。

（其实误差的确天然存在，只要在合理可接受的范围内其实就好~）

BIM工具的落地本来就是个全新的尝试和变革，这个过程中会有各种各样的困难和阻碍出现，所以最好有一个团队可以持续性运营和解决出现的问题（当然，产品其实最合适，咳咳），需要持续一些时间，在走过最开始最艰难的时刻后，后续就会逐渐走的顺畅。

产品的效果和收益

体验上，VR效果的所见即所得效果其实非常好，不过呢，也会遇到一些小小的问题，咳咳，就是用户感觉太爽了，终于不用靠脑补来想象是什么样子了，所以呢，用户就很开心的期望这里换个瓷砖看看，那里换个地板看看，略微微的会影响一丢丢签约转化的时间~~

时效上呢，因为不用再出报价单了，而且图纸方面也不用独立绘制了（部分图纸），所以整体上大约能提升2-3小时的工作时效，设计师们终于可以有更多的时间接待更多的客户了~

结算的毛毛利润率方面的，采用了该种方式的话，毛毛利润率可以提升10%-20%。是不是感觉很震惊，这怎么可能，其实我也很震惊。。。不过这就是事实，所以，也可以看得出来，在之前的那种行为模式下，这个过程中到底有多少的额外支出~~

Emmm，就算你不相信，觉得提升不了这么多，提升个5%是否值得呢，如果按照一年营收10个亿来算的话，这是多少钱来着，手指头有点算不过来。。。

最后想聊的几个小点

第一呢，这一定是一个自上而下的过程，甚至可以说是一把手工程，有些事情是看见所以相信，有些事情是相信所以看见，所以，从上而下达成一致其实很重要。否则任何一丁点的困难都会成为这个事情失败的原因。

一件事情的成功，不仅仅取决于它的规划，同样也取决于它的执行。

第二呢，就是不要老路，新路一起并存，总觉得我额外提供一种新的方式来解决这个问题，但是我依然保留着老的路径。这种情况下，根本不可能成功，因为没有人会走新的路径。这就像当年福特造汽车时，刚开始汽车速度还不如马车的时候，那么他是要回去继续做马车呢，还是迭代和改造汽车？其实道理有点类似，在新的路径上画更多的时间和精力让他更好用，更易用，而不是给大家一个老的路径可以继续使用。这样铁定大家都会回到老的路径上去。。。

（当然，这个嘛，是个人看法，也不一定对）

第三呢，有所选择，有所放弃。如果你想满足现在线下的规则中的每一个字，那我可以很负责任的告诉你，放弃吧~ 别搞了，因为绝对搞不定。所以，如何在线下运行的规则中，找到合理并且合适的规则，放弃掉一些不是那么合理和合适的规则就会显得很重要。

这将会是一个艰难求索的过程，预祝各位能够顺利前行~ 我们下一篇不知道啥时候才会写的文章见~~

“大家好，我是阿境，人称产品届的吴彦祖，一个沉稳又不沉闷的男人。”

这次比较不同，先抛出大家可能的收获知识点，再聊文章内容。

看完文章，你能够得到什么？

①解决80%有关产品需求的疑问点，包括面试中涉及需求的相关问题

②获得包括《需求挖掘分析pdf完整版》《需求文档范例》《需求自检表》《需求排期表》《需求分析ppt》等多份阿境独家实用文档

③一套完善的需求挖掘与分析的方法论

“阿境，用户想要在动态上加一个话题功能，我们规划一下吧”

“这是用户需求，不是产品需求”

“本质上用户是为了能给自己发表的内容打上标签是吗？”

“是的，并且需要先判断是真实需求还是伪需求，再进行定义，我们也可以通过用户需求，来分析出我们的产品需求，从而确定我们要做的方案”

若你是个PM，想必上述对话的场景，屡见不鲜。

需求是一个被互联网人说烂的词，却也是最基础的词，产品说需求、运营也说需求、市场也说需求。

那么有几个问题大家思考下，

他们说的需求是同一类吗？

究竟什么是需求？本质是什么？

什么是产品需求跟用户需求？

真实需求与伪需求怎么辨别？

对于需求分析你有一套明确的思路吗？

需求的来源、管理、优先级排期等你能够侃侃而谈吗？

......

在看过这些问题之后，若你能够在很短的时间内有了明确想法，那阿境觉得可以关闭掉文章，因为这是浪费你的时间。（花个10分钟去炖个排骨享受生活都比看这篇文章值得一些）

如果没有，那么！且听厦门吴彦祖阿境啰嗦一下吧。

产品经理的职责便是在最短时间内最大化地创造价值，那么接触最多的的便是日常处理的需求，而需求分析也是非常关键的一步。

如果在看过问题之后，对于部分实施的方法还有疑问，或者是想要系统地进行需求的认知，那么不妨往下看看。

另：

①附上本文导图框架，节约时间。若您感兴趣，可继续深入阅读；若不感兴趣，感谢光临。

②要获得独家需求分析资料，可关注公众号<梦想家阿境>，并回复“需求分析”，有具体获得的方式。

（长得好看的人会啰嗦一些，大家谅解下~）

一、需求基础概述

1、什么是需求？

什么是需求？

百度百科的定义是：需求是在一定时期，在一既定的价格水平下，消费者愿意并且能够购买的商品数量。

这个定义也是基于经济学当中的定义，如果把它套上产品的帽子，那么我们可以转变为：

需求是在一定时期，在一既定的场景下，为了解决某个问题而激发出用户对于某种目标的渴望。

从中，我们可提炼出几个点：时间、场景、提出者、使用者、方案。

而在实际工作中，脱离了时间、场景的需求，也往往容易被我们忽视。

综上所述，简单来说，需求就是在特定的场景下，用户所产生的问题。可以用“用户+场景=需求”的方式来理解，也可以说，需求是预期与现状的差值。

2、需求的本质

天主教教义当中，有七宗罪，分别是：傲慢、嫉妒、暴怒、懒惰、贪婪、暴食、色欲。而我们的产品，正是解决人身上所带来的原罪的产物。

而从马斯洛需求模型来看，有自我需求、尊重需求、社交需求、安全需求、生理需求。

从这两个方面上来看，需求源于人，最初的源头在于用户。而用户的存在，必然会遇到这样那样的问题。

一个需求归咎到底，还是满足了用户不同等级的欲望。

需求的本质是对用户欲望的满足，以及消除用户的恐惧感，从而解决用户的实际问题。

一款好的产品一定是能满足人性或者欲望的。

而产品本身是众多需求的集合体，根据不同的组合而成为当前产品的形态，产品功能则是满足了用户的目的，而需求和产品功能是一一对应的。

所以我们说，产品经理在处理需求的时候，所具备的同理心这一特质，才能够更好的洞察需求，洞察需求的过程也是在洞察人性，即洞察需求的本质。

3、用户需求与产品需求

先来看一句话“用户给产品经理提了一个需求，研发评估了下这个需求不能做”。

这当中出现了两个“需求”，这两个是同一个意思吗？

很显然不是。（说“是”的，阿境要揍你们了！）

从这个简单的例子可以看出，无论是用户，还是产品经理，还是业务人员，都在谈需求。

而需求被赋予了更多的含义时，就需要引入其他更深层此次的概念加以区分。

比如，上述例子中，前者是用户需求，后者是产品需求。

用户需求主要是指出用户想要怎么做，产品需求则更多的是指导产品需要怎么做。

1）什么是用户需求？

用户需求是用户当前尚未满足，又渴望被满足的欲望，并由此产生的方案。当用户使用得起产品，并且产品并不能够满足用户当前使用时，用户才会对产品产生新的需求，也就是我们所说的用户需求。

用户需求有个较大的特点，不能够指导产品开发，更侧重描述用户想要达到的目的，借此所提出的需求方案（想要的东西），则为用户需求。

2）什么是产品需求？

产品需求是用户需求经过产品经理的“加工”后所诞生的产物，输出具象的产品方案后实现，在实现之后完成产品既定的数据目标，则为产品需求。

产品需求更侧重能够指导产品开发，并且指导产品完成自身的目标（以数据指标作为目标的依据）

3）用户需求如何转化成产品需求？

当我们清楚用户需求与产品需求之后，那么我们如何将用户需求转化成产品需求呢？

作为产品经理，我们需要收集清楚信息，经过严格且缜密的需求分析，才能达到将用户需求转化成产品需求的目的。

4、真实需求与伪需求

要解释真实需求与伪需求的区别，可以看个例子：

做个市场调查，问1千个用户是否喜欢黄金，几乎所有用户都是肯定回答。那么这个时候就认定黄金是当下用户的需求，那么便过于草率了。

因为再深究下去，用户买了黄金干什么？对黄金的了解清楚吗？等等问题，深入了解完一番之后，用户可能就不会买了。

人性是贪婪的，“需要跟购买”是两回事，用户总是“说一套，做一套”。

再举个例子，用户告诉我们他需要钱，如果你不追问，可能只是知道他需要钱，并不清楚拿着钱去做什么。用户告诉我们的是他“想要”的东西，而我们需要知道的是“用户内在的心理预期”，从而了解用户的真实需求。

可以说，某些情况，用户“欺骗”了我们（厦门吴彦祖被欺骗，在线哭泣！）

那么这完全是用户的错吗？

不是的，用户有时候都不知道自己更需要什么，他们更倾向于给出解决方案，当他们描述出他们的意向内容时，作为产品经理的我们，需要去剖析，从“伪需求”的表层下，挖掘出用户的“真实需求”

“伪需求”指的是当前用户并不一定需要，而是根据他们遇到问题所提出的解决方案之一，但并不一定能够完全解决他们当下的问题。

“真实需求”是通过梳理需求提出方当前的情况，遇到的问题所分析出来的结果。

二、需求挖掘与分析

1、用户是如何阐述需求的？

有一句话在产品界流传甚广：

“如果我当初问人们想要什么的话，他们只会告诉我想要更快的马。”

从而我们知道，用户的需求是想要一个比走路更快的交通工具。

这其实是个谬论，交通工具并不是结果，而是过程。

不妨再问一句：然后呢？

可能事实上是利用交通工具去上班，去自驾游等，目标不同，所能满足用户需求的产品也不同。

由于阿境处于游戏分发行业，恰逢近期接触到了许多用户的反馈，拿其中一点举个例子：

“我想要更快的游戏速度体验”

在没有深入挖掘之前，我们可能会一股脑地去提升服务器容量、优化游戏代码质量，从而提升游戏速度，但用户是否是真的单纯地想提升游戏速度呢？

做几个假设

“更快的游戏速度体验→在有效的时间内玩到更多的游戏内容”

“更快的游戏速度体验→获得与游戏对手相同的速度→击败对手”

“更快的游戏速度体验→获得成就感”

......

就这几个假设来看，相同的需求描述，是不同的需求点。

A目前遇到的问题是游戏时长少；

B的问题是游戏卡顿引发地对战失败，想要赢得胜利；

C的问题是在游戏中获得成就感；

那么，我们是不是可以这么解决呢？

针对于A，提供个防沉迷账号；

针对于B，提供个游戏加速器；

针对于C，提供相应的成就徽章体系等；

乍一看，毫无毛病，仿佛一下子解决了用户的需求，于是又是一番大刀阔斧地改动优化。

让我们把自身再抽离来看，ABC是否有更隐蔽的点需要我们去挖掘呢？

别忘了，人在描述一件事情的时候，往往会将观点以有利于自身的角度加工并阐述。

A可能是因为家长限制了娱乐的时间，从而无法获得更多的娱乐时间，即使提供了防沉迷的账号，也无济于事；

B可能是自身技术不太好，即使在相同的速度体验下，依然打不过对手；

C可能是对于游戏投入的不够多，导致在游戏当中无法获得更高阶的奖励（物质与名气）；

若是如此，那么所应该提供给ABC的功能，可能又是另外一番答案。

从上面几个简单的例子，抽象来看，可以剥离出几个观点

1）对于提出问题，用户更倾向于给出解决方案

人们往往倾向于解决问题的方案，而很少关心问题本身。所以我们常常会得到“我想要一匹马”的这种声音。

并不是用户提出的解决方案对于产品没有建设性，而是往往人在迫切解决自身问题时，提出的观点并不能查观全貌；

且用户并非产品的主导者，仅对部分功能有使用，那么在这个前提下，用户提出的解决方案能够一定程度地解决用户当前遇到的问题，但却可能延伸出更多的问题；

作为产品经理，通过自身对于产品的目标定位及价值理解，重视用户的解决方案，衡量解决方案底下所埋藏的需求的价值，才是重中之重。

2）在描述需求时，用户往往会将自身观点进行或多或少地加工

当用户对自身需求有隐瞒时，我们也就对需求的理解有偏颇，相同的解决方案，可以延伸出不同的需求。

由此，通过设定不同维度的问题，引导用户以描述性的角度，阐述自身的问题，才能够最大化地避免用户对于自身需求的美化加工。

3）需求并不是绝对的，在不同的阶段，用户会给出不同的需求观点

在初入游戏的时候，我们更需要的是一个教程带领我们了解更多的游戏攻略；

在游戏中度用户的时候，我们更需要的是游戏的体验性，攻略、工具等可能是在这个阶段中较为合适的需求。

在成为游戏深度用户的时候，我们更多的是在游戏中得到成就感，游戏成就体系等则应运而生。

由此可见，需求并非千篇一律，不同的阶段，用户提供到的是不同的需求观点。

“小时候我想要一颗糖，长大了我想要一辆跑车”也就是这个道理，需求受制时间的因素影响，也受制自身的发展影响。

2、如何挖掘需求？

这边的挖掘需求更多的是指主动地去挖掘产品需求。

这边有两种方式，一是从用户身上入手，从用户身上了解需求；二是从产品数据上入手，从数据上洞察需求。

1）更好地洞察用户需求

洞察用户的需求本质是还原用户真实的需求，一般会采用直接访谈、问卷的形式，但是用户全靠一张嘴，因为所处的环境、心境的不同，往往得到的结果会有偏颇，在此阿境介绍两个方法。

一是深度访谈的方式，二是真实融入用户场景，通过这两种方式来进行洞察用户需求。

①与用户进行深度访谈

与用户进行访谈，是需求的来源之一。

而由于用户更多地是站在自己的角度上去体验产品，所以难免有些片面。

在访谈的方式，有比较详尽的方法，阿境后面会单独开一篇文章来介绍，这边就简单概括下。

包括①结构性访谈、②非结构性访谈

• 非结构性访谈：是访谈者提供一个开放性的主题或问题，由报道人自由阐述；

• 结构性访谈：是访谈者根据研究主题事先设计好的具体问题，系统地访谈研究对象；

这两个的区别是：

非结构性访谈能够通过开放性的问题，了解用户处理某个事情时的方方面面，但需要访谈者记录下全程并且提炼有效信息；

结构性访谈则更多的是根据固定设计好的问题进行，可以理解为问卷调查的线下版，对于访谈问题的设定有一定的要求，否则容易造成无效访谈。

通过这两种访谈方式，收集用户的真实情况：

①用户遇到的问题是什么？

②用户当前在处理问题的时候是怎么做的？

③用户想要的是什么？

在这个过程中，也有几个注意事项：

①客观真实很重要，访谈者要剥离开自身的主观想法

②在舒适轻松的环境下进行访谈（最好是用户熟悉的环境）

③掌控整个过程，引导用户表达自身的想法

②真实融入用户所在的场景

通常我们在做访谈的时候，是以“设计者”的思维对“使用者”的采访，得出的结果相对来说有一定的片面性，同时我们作为“设计者”，不一定能够设身处地的作为用户的身份来考虑问题。

这也就是产品经理拥有“同理心”的重要性。

花费一定时间，成为产品的用户，融入到用户的真实场景当中，借此观察用户的在相应场景的行为及感受体验。

在这个过程中，我们可以观察几点元素。

分别是：用户、环境、任务、目标、行为。

用户：用户是怎么去做这件事的？

环境：用户当前所处的环境如何？

任务：用户当前的任务是完成什么事？

目标：这件事完成的目标是什么？

行为：用户用什么方式来完成这件事？

通过真实融入用户所在场景，并且观察这几个元素，来实现“边参与边观察”的目的。同时在这个过程中去真实的感受用户的情感变化，再将情感变化具象化为实际的数据或者描述

2）从产品数据表现发掘需求

做产品，数据是很重要的一环。

往往每个团队会搭建自身产品的数据概览，包括用户行为数据和业务数据。

具体数据不过多展开。

通过产品的数据，包括渗透率、留存率、页面转化等，长期观测，能够结合着察觉到产品数据的变化，而数据变化的背后是用户行为的改变，从而发现用户的需求迁移。

一般看数据，看现状与看变化。

看现状主要是了解业务距离产品目标的差距，能够加深PM对业务的认识。

看变化主要是养成数据感，通过数据变化，发掘产品问题，从而制定解决方案。

3、需求的基本要素

在拿到手一个需求的时候，如果是一句话需求“在直播tab想要添加一个悬浮球”，那么作为产品经理，没有充足的信息，很难评估该需求是否成立。

那么，作为需求本身，提出的同时，我们需要得知哪些必要信息呢？

包括需求的场景、解决的问题、目标等。

之所以需要理清需求的细节，一是因为有部分需求是伪需求，那么当提出人在梳理需求细节的过程中，可能就会幡然醒悟该需求也许是个伪需求；二是对于产品经理来说，清楚需求的基础信息，才能够更好地去评估需求。

可以看下阿境整理的需求九要素，当这些问题在需求的提出时也能够一起提交，那么便能够比较好地进行需求的评估。

可以关注公众号<梦想家阿境>，并回复“需求分析”，有阿境整理的《需求提交文档范例》《需求九要素》。

1）需求的类型

一般分为两类，政策需求、线上bug需求、线上漏洞需求、合同期限需求、普通需求等。

政策型需求一般是根据国家颁布的法律法规所衍生出的需求，普通需求则为除了政策型需求以外的需求。

之所以需要区分需求的类型，则是因为政策型需求的必要性及严重性，故无需过多的分析，在满足政策的要求下，最小化成本执行即可。

2）需求的场景

根据百度释意，需求的场景是指在一定的时间、空间（主要是空间）内发生的一定的任务行动或因人物关系所构成的具体生活画面。

需求的场景有几个要素：用户（who）、时间（time）、空间（where）、动机（why），行为（what）。

即，什么用户在什么时候，哪个地方，因为什么动机做了什么事情。

3）需求解决的问题、解决的痛点

在需求对应的场景下，用户遇到了什么问题？在这个问题下，是完全无法进行下一个步骤，还是仅仅是操作不顺畅等。

在描述问题的时候，需要越详细越好。

4）当前针对该需求的解决方案是什么？

针对于遇到的问题，当前是否有其他方式能够解决？

若有，则用户/运营/业务人员等是采用什么方式来进行解决的？解决的具体步骤是什么？需要详细的描述。

5）需求的目标

需求要达到的目标是什么？

一般包括数据性指标（提升多少渗透率/留存等）、优化型目的（eg：用户更好地回到顶部tab）。

通常目标尽量可量化，也需要了解当前的情况是如何，才能确定需求能达到什么样的目标。

6）需求价值判断

需求的价值判断包括需求的频次、覆盖用户、刚需程度，这几个维度主要都作为评估需求优先级的判定标准。

①需求频次

该需求的使用频率是多久？

一个月一次？每天一次？每天多次？不同的触发频率，在评估需求的优先级及选择解决方案的时候会有较大的不同。

②涵盖用户

需求的目标用户群体？

需求涵盖的用户是哪部分用户？该部分用户占据产品的占比是多少？

一般了解需求的用户，主要是清楚需求的涵盖范围，作为需求优先级评估的评定标准之一。

③刚需程度

用户对于需求的需要程度？（如果不做这个需求会怎么样？）

当前需求如果有其他的解决方案，用户是否能够使用？使用的情况如何？

7）需求的优先级如何？

这边的优先级主要指需求提出方基于自身所了解的信息，对于需求的评估。

另外，可以指出对于需求优先级的评估依据，能够更好地帮助产品经理准确判断需求的真实优先级。

8）需求的预期解决方案是什么？

对于需求的提出人（用户/运营/业务方等），针对于上述需求的基本情况，可以简单阐述需求的解决方案。

该方案虽然不一定是最终解决需求的方案，但能够清楚用户对当前问题的预期想法，作为我们做方案的参考依据。

9）其他基本要素

包括提出人、提交日期、期望完成日期。

主要是能够对需求进行溯源及整理。

4、如何进行需求分析？

需求分析，实际上的问题是“如何判断一个需求是否要做？”

在了解了需求的收集、基本要素以及挖掘需求的方式之后，下一步便是进行需求的分析。

但在需求分析之前，除了收集了需求本身的信息，还需要有其他的信息辅助我们做决策，后续才能够对需求进行合理的判断。

1）基础信息整理收集

①当前业务的数据（包括用户行为数据、业务数据）

②当前业务的运营情况

③当前产品对于该业务的规划情况

④竞品分析，了解竞品的情况

⑤用户调研访谈情况（调研问卷、访谈等）

再了解了业务方提供的信息之后，我们往往无法判断需求是否要做，此时结合上述的五部分内容，补充对于需求的了解，由外而内。

“外”指的是竞品对于该需求的处理情况，行业内的解决方案如何。

“内”指的是当前业务的数据、运营情况、自身产品规划、用户调研等。

两者相结合，能够对需求所处的环境有个全面的了解。

2）需求分析八步法

阿境总结了“需求分析八步法”，可以说是本篇文章的精品之精品了，不得不看！（比厦门吴彦祖阿境的脸还精品，你说精品不？）

分别是“析要素、挖场景、推价值、看用户、拆竞品、盯市场、查现状、定规划”，且听吴彦祖给你们一一讲解。

从这八步法分析过后，便能清楚需求是否要做，如何正确地剖析一个需求。

可以关注公众号<梦想家阿境>，并回复“需求分析”，有阿境整理的《需求分析八步法》。

①“析要素”

分析需求基础要素。

上述提到需求要素包括需求的类型、场景、解决问题、目标、需求价值、优先级、预期解决方案等，之所以是”析”，是因为从需求提出方接到需求之后，往往是不完善的，我们需要去剖析直到了解完整且正确的需求内容。

一丝错误的信息，比如目标不清楚，场景不正确等的偏差，都会影响我们对需求的评判。

②“挖场景”

挖掘需求对应的场景。

这其实是需求基础要素当中的其中一个，但之所以单独拎出来谈，是因为脱离了场景谈需求，是不合适的。

用户+场景=需求，场景占据了很大的一个部分。

充分挖掘需求所对应发生的场景，从而了解用户真实的问题，才能够得到合适的解决方案。

③“推价值”

推敲需求价值。

这个需求价值可以以用户、产品、企业三个维度的角度来分析。

对于用户来说，给用户提升了什么价值？也就是用户价值。

对于产品来说，提升了产品的什么功能指标？也就是功能价值。

对于企业来说，提升了企业哪部分的收益？也就是商业价值。

这三部分综合起来便是在分析过程中所应该明白的需求价值。

④“看用户”

看待用户对于该需求的看法，了解以及使用情况，这一步是摸<检查>的预期及日常使用情况，从用户视角看需求。

一般是采用用户问卷调研，用户访谈的方式，通过直接去接触用户，得到最真实的用户感受，当然，在这当中，合理的设计问卷，合理的设计访谈问题，控制访谈的整体节奏，也是重中之重，是能否得到正确且真实的用户感受的前提之一。

⑤“拆竞品”

拆解分析竞品（包括直接竞品、间接竞品）的现状，在明白竞品的用户、商业模式等基础信息的前提下，从竞品的角度去分析对应需求的作用。

借此达到管中窥豹的目的，结合自身产品，明白相似的需求我们能够从中借鉴到什么内容，给予我们什么样的灵感和帮助，同时也了解竞品的不足，在产品设计中能够适当规避。

⑥“盯市场”

紧盯市场动向，对于该需求，摸清市场上的看法以及各大产品各自的发展迭代逻辑，通过市场的反馈及发展，剖析该需求所对应的业务的长久规划。

⑦“查现状”

摸查产品目前现状。也就是产品经理对于当前产品业务的了解程度越高，那么在分析的时候，结合自身产品业务的现状来分析，便能够极大地减少判断错误的概率。

这包括产品当前所处的生命周期，业务的数据情况，业务的运营情况，共三大部分能够概括现状。

⑧“定规划”

确定需求所对应业务的短期、中期、长期规划。

根据规划，了解当前需求解决的问题，处在规划的哪一部分。从整体回归局部，以先总后分的分析思路，理清需求的位置。

3）需求其余条件评估

①需求是否符合当前产品发展的方向规划

②需求对于平台其他业务有什么联动影响吗？

③如果做了这个需求，成本层面与收益层面是否成正比？

三、如何管理需求

1、需求的收集

1）为什么要进行需求的收集及记录？

我们在做版本迭代的时候，往往有一定的需求需要消化，而需求的来源就较重要了。

平时缺少了需求的积累，那么在版本迭代的时候，便会手忙脚乱。

主要的原因有三：

①需求来源众多

②需求并不是当下就需要进行消化

③需求多级传递导致需求歧义

“少壮不努力，老大徒伤悲”，通过平时的需求积累，标注需求的优先级等，能够有效地扩大产品的需求池，从而在适当的时机，通过消化需求，解决用户的真实问题。

2）需求收集的本质及原则

需求收集的本质，在于“收整”及“归纳”。

原则是以用户为中心，以市场为导向，以行业动态为基准，客观地进行需求的收集，同时需要具有远瞻性，当下不符合产品发展的需求，不代表以后不符合。

但一定程度上，用户不一定是需求的来源，目标才是。

3）需求收集方式

需求的收集方式，通常来源于七个：产品规划、内部人员、业务部门反馈、用户反馈、产品数据表现、竞品分析、行业动态。

①来自产品规划

作为产品经理，对产品需要有明确性的规划，清晰自己产品定位所在，产品的规划也是极其重要的。

在产品/业务的不同阶段，产品经理依靠自己的规划，制定不同阶段的目标，从而延伸出相对应的需求。

②来自产品内部人员

产品内部人员包括产品经理、研发、交互、设计、老板等，主要代指产研线上的角色。

一个产品通常有多个产品经理，在日常迭代当中，产品经理有自己对于业务模块的思考，同时经过一系列的调研、数据等，能够发现自身产品的问题，提出需求。

研发、设计、测试等偏研发/设计侧的人员，则是站在自身对于产品的理解所提出的需求，更多的是单独模块，单独功能的优化。如调整主题色、调整客户端接口，优化页面交互方式等。

老板这个角色一般是提出战略性、大方向的议题，不一定是具体的需求。如确定产品的发展方向，从而产品经理经过论证确保可行后，根据方向进行分析拆解成具体的需求。

③来自业务部门反馈

业务部门通常包括运营、售前、售后、商务、市场、客服等。

不论是客服还是运营，这些岗位都是离用户最近的岗位，通常我们所说“倾听用户的声音”，而在客户与用户的沟通过程中，运营在工作的过程中，都能够结合用户的需求，以及产品可优化的部分去提出需求。

④来自用户反馈

用户反馈包括应用意见反馈、用户访谈、社区论坛、主动联系反馈等。

倾听用户的声音对于产品，是很重要的。

由此产品经理对内需要建立完善的用户反馈机制，对外需要搭建用户调研/访谈流程。

其中用户调研包括两种，定性调研和定量调研。

定性调研，主要调研文化背景与生活环境、用户的经验和习惯、探索用户行为背后的原因。最具代表性的是用户访谈。

定量调研，主要调研各个变量之间的关系，是通过各种数据呈现的客观事实。最具代表性的是问卷调查。

在倾听用户声音、用户访谈的过程中，需要注意的是进行信息的解析，也就是根据用户传递的内容，过滤掉失真的那部分，从而得出有效的结果，进而才能够转化成产品需求。

麻省理工大学的心理学家罗伯特·费得蒙研究表明，60%的人在10分钟的交谈中会撒谎2到3次，男人和女人撒谎的频率差不多。

“人们是无法告诉你他们真正想要的是什么，但是可以通过引导让他们说出来。”

准确洞察用户需求的基础是让用户对你说正确的话，有兴趣可以跟阿境单独聊聊，这边不再展开。

⑤来自产品数据表现

“用户会骗人，数据不会骗人”。

可口可乐公司在20世纪80年代，做了一个实验：一款新口味的产品，一款原口味的产品，让实验者挑选，在填写问卷的时候，85%的人选择了新口味的产品。

而真正投入市场后，这85%的人，有90%的人又反水选择了原口味的产品。

从这个试验中可以看出，用户是会骗人的。但是他们的行为数据不会骗人，最大化的还原了用户的心态，选择。

作为产品经理，我们需要根据产品/业务本身的数据表现，发掘问题。从用户层面上来说，在产品当中进行数据埋点，通过用户在产品当中的行为，最大化地了解用户所遇到的问题。

通过宏观数据，查看用户在产品当中的行为；比如渗透率、留存、页面转化、人均次数等行为数据的变化，可以了解并分析用户在产品当中遇到的问题，从而形成需求并解决。

同时，用户的行为表现在数据上，通过这些，能够清楚用户的行为方式，用户的关注内容，当看得多了之后，会抽象出这个群体用户的行为特征，从而帮助产品经理更深入了解不同的用户群体。

ps：下图为脱敏后的一些产品数据图，如渗透、留存、人均次数、打开路径占比。

要注意的是，产品的数据表现，并不能够单独来评判一个需求的启动与否，容易有失偏颇；往往需要结合用户调研，用户访谈，产品内部分析等方式加以评估。

⑥来自竞品分析

《孙子兵法》中提到“知己知彼，百战不殆”。这其中，“知彼”便是了解竞争对手。

竞品做的不一定是对的，但是一定是“行出有因”。

作为产品经理，需要尽量多地汲取外部相关信息、行业信息，以辅助各种判断和决策。为了跟踪竞品动向，以他山之石鉴己之发展，同时也能够与竞争对手进行抗衡，通过竞争分析来提升产品的竞争力。

从产品的战略层面来看，竞品分析能够为产品提供战略、布局规划的参考，同时，在产品设计上取长补短，也能够预警避险。

通过竞品分析，了解到竞品的动向后，也可形成具体的产品需求，从而为产品的后续发展做好提前准备。

一般对于竞品分析，有两个方面可以收集。

1、平时进行竞品的更新检测，了解竞品动向，收集产品需求。

2、针对于个别业务/功能，对竞品进行针对性分析，输出竞品报告，抽象出需求点。

⑦来自行业动态、政策方向

根据行业的政策动向，也会延伸出相应的政策性需求，如 《计算机信息网络国际联网安全保护管理办法》等的颁布，相应的产品就需要履行相关的法律法规。

通常政策性需求的优先级及紧急程度都是最高的，否则产品就会面临下架风险。

4）需求收集的几个要点

1、以用户为中心，而非以产品为中心

2、收集需求时，规范记录，保证信息不失真，且可回溯。

3、需求收集需要主动深入挖掘用户的真实需求，而非反馈的表面问题。

2、需求的记录方式

通常我们把需求的记录称为“需求池”，是产品经理将所有和产品相关的需求信息按一定的规则进行汇总记录的地方。

简单点说，就是一个存放需求的地方。

而需求的信息、类目繁杂，需要有一定的记录方式，才能够使得庞大的需求池多而不乱。

下面会讲讲需求的记录方式，以及需求记录的相应工具。

1）记录方式

①所属板块

一个公司可能有多个产品，一个产品可能有多个端，故当混杂在一起时，需要以板块的字段来区分

范例：wap端、安卓端、ios端、小程序端、客户端、服务端等，根据自己公司业务的情况来划分

②所属业务

标记需求对应的业务模块，主要便于后期能够根据业务来区分需求的归属。

范例：直播、视频、订单、商品、游戏下载等

③需求来源

需求的来源标识一般有：来自用户、竞品调研、产品规划、运营/业务需求、政策要求，共五大类。

具体根据各公司业务的不同标识来源字段略有不同。

④需求状态

状态一般分为：待补充信息、待讨论、需求调研中、需求设计中、开发中、已完成、废弃、暂缓

具体细节从描述中可窥探，这边不过多赘述，主要是描述需求从提出之后到完成/废弃的状态过程的记录。

⑤需求时间

包括开始时间、结束时间；

更重要的是结束时间，有个明确的截止时间；一个需求往往有多端参与，包括产品、交互、测试等等，所以在记录这个需求时间的时候，也可以一并考虑不同端人员完成各自任务的时间（涉及到项目管理部分）

⑥需求背景

需求背景描述的是需求当前产生的缘由，在什么条件、什么时间、什么场景、什么资源的情况下所产生的需求，重点描述问题所在。

可以从大环境趋势、行业动向、公司情况、产品/业务现状四个方面上来阐述背景。

⑦预期方案

预期方案主要是根据当前需求的信息（包括需求背景、业务运营情况、数据情况等），所得出的预期方案，但仅仅是当下的思考并记录，不一定合适；

具体的方案还需与设计者（产品/交互/需求提出方）共同协商讨论。

⑧需求价值

需求价值侧面反映需求的重要程度，有的会以“重要”“非常重要”来描述，但太过笼统，并且不能定性分析，故需要再拆分为用户价值及产品价值，来描述需求的重要程度。

用户价值重点阐述问题被解决的程度，站在用户的角度上思考这个需求是否能真正解决用户当下的问题，解决的程度如何。

从俞军老师的理论上来看，用户价值=（新体验-旧体验）-替换成本。

产品价值包括三方面，功能价值、情绪价值、商业价值，阿境简单说下。

功能价值指通过功能给用户提供服务，解决用户的核心问题；从技术壁垒人无我有、创新点人有我优、细节给用户带来惊喜、行业风口上的产品功能规划的方式去考虑功能价值。

情绪价值是产品除了基础功能外，满足用户的心理需求，如成就感、虚荣感等；放大积极情绪、减弱消极情绪是核心点。

商业价值代指产品的吸金能力。且先有的用户价值，再有的商业价值。

总的来看，产品价值以“提升功能价值、增强情绪价值、构建商业价值”三方面来入手分析需求价值。

⑨紧急程度

紧急程度一般分为：不紧急、紧急、非常紧急。

一般根据实际情况调整。

⑩需求难度

需求难度一般分为：高、中、低

偏主观性的一个字段，主要通过前期对需求的了解评估，将其与开发简单评估下，做出的评判。

⑪相关人员

若需求涉及多部门人员，则需要填写需求涉及到的相关人员，便于后期追溯

⑫备注

备注当中一般描述字段以外的自由内容。

可以添加相应与需求有关的材料，比如竞品调研、用户调研、当前业务数据等等，目的是为了更好的给这个需求做决策。

2）记录工具

可以采用excel进行记录、也可以采用teambition等协同工具进行记录，切记，工具只是协助我们进行更好的进行需求梳理。

3）需求记录原则

需求记录原则遵循四个“可”。

需求来源可追溯，需求场景可还原，需求分析可实现，需求推进可持续。

只有在记录的时候达到这四个，才能够保证需求的传递不失真，真实还原需求是需求分析的首要前提。

4）需求池的搭建方法

需求池可以说是需求管理的一剂良方，像是产品经理的“需求记账簿”，但是要搭建一个健康、不冗余且有效的需求池，还是不那么容易的。

一个健康的需求池要达到的几个要素是：容易查找、清楚需求进度、了解需求状态。

①以结构化的思维，根据产品实际情况，划分整体需求业务分类。

②规范各业务方提交需求的需求格式（极其重要！！！），保持需求原始信息的真实记录。

③进行需求规整，对需求原始信息进行补充，分析及加工。

④标记需求状态，进行需求信息的持续完善

⑤及时维护需求池。设定周期时间，在每个周期时间内都整理一下需求池中的需求，及时进行需求状态的变更调整，抛弃无效需求，完善有效需求。

3、需求的分类

当需求池中积攒了许多需求的时候，一团糟，这个时候就需要根据一定的方法进行需求的挑选、标记及分类。

1）需求标注及筛选

①标注

当业务方/运营提需求上来之后，需要进行需求内容的标注，往往会出现需求内容不全面、需求格式不对等问题，这个时候就需要产品经理对应的去与需求提出方进行深度沟通，挖掘需求当前的有效信息。

ps：在提交需求时，产品经理可以提供一份《需求提交规范》给到需求提出方，根据这份指南来走，往往提交上来的需求会相对有效。

可以关注公众号<梦想家阿境>，并回复“需求分析”，有阿境整理的《需求提交规范》。

②筛选

这一步骤主要是“去伪存真”，根据全面且详尽的信息，评估出该需求的真实与否，是否是“伪需求”，若是，则需求需要进一步考虑是否废弃。

且在需求筛选这一步中需要进行优先级的评估，高优先级的筛选出来，在近期的版本中进行迭代优化。

2）需求分类

需求的分类往往是根据业务类型、业务端来区分。

业务端主要是：小程序端、app端、服务端等

业务类型主要是：直播、视频、游戏等，具体看每个产品的业务而定

有的产品较大，一个产品往往多个产品经理负责，那么就需要根据不同的业务分配不同的产品经理进行负责。

4、需求的优先级及排期

为什么要排需求的优先级呢？

因为“这个很重要”“这个很紧急”“这个优先级最高”往往是业务方的口头禅，那么当那么多所谓的“优先级很高”的需求摆在我们面前，“双拳难敌四手”，总需要有个先后处理的顺序。

要记住，需求优先级的本质是“性价比”。

在前面提到的，我们会给需求标注“重要程度”、“紧急程度”两个维度，这两个维度怎么区分呢？

重要：以核心业务、核心用户、商业价值、竞争优势等方面去评估。

紧急：以严重程度、时间对比、需求频率等封面去评估。

清楚了“重要”“紧急”这两个维度后，那么按照时间管理四象限的思维。我们就可以分为四个方向。

• 重要且紧急：短期内一定要做的需求。通常是产品重大bug，政策需求，重点是“快且好”。

• 重要不紧急：重要但可以长期做的需求。比如某功能模块的规划等，重点是“有计划”。

• 不重要但紧急：对产品、用户的作用可能不大，但短时间内一定要完成的需求。

• 不重要不紧急：时间维度不敏感，且评估后重要性也低的需求。

当然，从四象限模型并不能够完全地解决现实中评估需求优先级的情况，需求优先级的评估需要结合更多的维度。

阿境这边总结几个常见的维度，大家可以综合自身业务情况来考虑。

1）需求的类型

主要包括政策需求、线上bug需求、线上漏洞需求、合同期限等，明确需求的类型主要是为了明确需求的紧急程度，不同类型需求的紧急程度不尽相同。上述提到的需求类型，紧急程度一般是最高的。

2）产品发展方向

一个产品通常在发展的时候，通常会经历四个阶段：导入期、成长期、成熟期、衰退期；根据产品的不同阶段，产品经理会相对做不同的产品规划，也就是确定产品的发展方向。

不同的发展方向，对需求的优先级也有影响。

比如一款产品，核心业务包括社区跟直播，但产品近半年的发展方向是社区的内容，那么同时社区与直播的需求，在其他条件相同的情况下，社区需求的优先级是会更高一些的。

3）业务价值

不同的需求通常涉及不同的业务，业务价值也是需求优先级的一个重点考量因素。

业务价值是产品价值的拆分，与之类似。通常包括两部分：商业价值、功能价值。

商业价值指的是该业务为产品带来的盈利空间；

功能价值则体现在产品的数据指标，如渗透率、留存率，流程转化等，通常是从侧面提升产品整体水平。

不同业务的价值是不同的，其他条件同等情况下，业务价值大的需求＞业务价值小的需求

4）影响范围

需求的影响范围包括该需求涉及业务模块的目标用户量，需求被用户使用的频率，这两个指标包括了需求的影响范围。

更细一步进行拆分，则可进行分析目标用户的用户价值。

举个例子：A需求涉及用户1w，B需求涉及用户5w，但1w用户的用户价值远大于5w的用户价值，那么虽然目标用户量A＞B，但其他条件同等的情况下，A需求还是优先于B需求。

5）需求成本

需求的成本也是需求复杂度及难度的体现，需求复杂度与需求成本成正比。

需求的成本包括产品成本、研发成本、交互成本、设计成本、测试成本等。

可以理解为一个需求从诞生开始到落地所能够涉及到的所有流程（其中也包括沟通成本等这类无形的成本）

往往我们在估算成本的时候只估算了研发成本，但那只是需求的实现，在实现之前还包括需求的调研、分析及讨论，以及可能涉及跨部门的沟通，这些都是成本之一。

评估需求成本需要全面、完善。

综上的五个维度，一般是评估需求“重要”、“紧急”的一些评估因素，结合每个因素，往往我们是去进行定性分析；

但当多方意见有偏颇时，就需要定量分析，大致的思路便是将每个维度进行打分，然后乘以不同维度的权重，再将其相加，从而得出该需求的最终得分。具体的实际操作方式若有疑问也可跟阿境探讨。

另外，需求的优先级不仅仅有上述的方式（ICE分析法），还有KANO模型等。

KANO模型由于其方式在真实工作中实用性较低，这边阿境仅简单介绍。

基本（必备）型质量——Must-be Quality/ Basic Quality

期望（意愿）型质量——One-dimensional Quality/ Performance Quality

兴奋（魅力）型质量—Attractive Quality/ Excitement Quality

无差异型质量——Indifferent Quality/Neutral Quality

反向（逆向）型质量——Reverse Quality

可以通过问卷的形式，获得较为准确的KANO分类，再通过Better-Worse系数确定需求所属的象限，进而判断优先级。

ps:

①优先级是相对的，没有绝对的高优先级需求。

②优先级不是一成不变的，随着时间、产品形态、市场形式的变化，优先级也会随之改变。

5、需求变更

1）为什么存在需求变更？

众所周知，开发小哥往往是听到“需求变更”脸色都变了。

需求变更有外界的因素（eg：对接不当），也有自身的因素（eg：优化策略）；针对于这两者，都可能存在需求变更。

需求变更并不是越多越不好，而是一种风险规避的方式，在项目的进展阶段，越早进行变更，则能够将未来发生的风险降到最低，也能够使需求真正达到原本的目的，解决实际的问题。

但需求变更存在项目资源的浪费，所以原则上，能少则少，若有必要，及早变更。

产生需求变更的因素有很多，其中包括一下几点：

①信息传递有偏差，一般发生在与业务方对接需求的时候，导致需求方向错误，且没有经过逐次确认。

②产品经理前期对业务思考不足，导致设计出的需求无法解决现有问题。

③撰写需求文档时，逻辑性、完整性、合理性等颇有不足，导致文档不符合开发标准。

④评审会上对需求的细节没有讨论到位，排期评估上对需求的评估也有偏差，导致需求在开发当中需要及时调整。

⑤在开发或测试的过程中，当需求涉及到真实数据的时候，发现产品原本的设计方案与预期设想的不同，于是需要进行变更。

⑥业务形态发生变化，当在需求的开发过程中，公司的商业模式或运营模式发生改变，则产品也需要进行及时调整方向。

上述六点需求变更的原因中，除了第五、六点，其他方面基本都是可以通过一定方法来减少需求变更的频次的，第五点的变更原因，则是为了更好地达到原本的需求效果。

2）如何减少需求变更？

①涉及业务方的需求，在前期对接，且需求产出之后，与业务方确认需求方案是否满足业务。

②加强对自身业务的了解，多查看行业内的报告，了解自身产品实际数据、运营情况，业务发展方向，从而能够更好地对业务需求进行决策。

③做需求之前进行充足的需求调研、需求风险评估，需求成本评估等。

④评审会前、评审会中、评审会后三个阶段，产品经理都需要及时的进行需求疑问点的沟通及确认，避免因需求完整性、逻辑性、合理性而产生的问题。

⑤对于需求内容，往往需求撰写者深陷其中，无法直观发现问题，可以内部进行评审/讨论，从而在需求评审前解决掉需求文档本身存在的问题。

⑥产品设计中，多留意往常需求变更的原因（例如后台的设计等），灵活总结变更前后特点，做产品需求的设计时多注重灵活性。

3）需求变更需要做的事情？

一个需求变更，往往不是一瞬间的事，而是一个过程。

在产品经理察觉到需求需要变更时，则需要做几个步骤

①预先周知项目组该部分内容可能产生变更，若正在开发，则需要及时中止需求，避免投入更多的资源。

②保证需求合理性的情况下，尽量在最短时间内处理变更方案

③周知项目组相关人员变更背景，变更内容，变更影响点；同时项目组重新评估需求

做到这三步，才算是需求的变更结束。（往往大家容易遗漏掉第一步，导致部分的项目资源浪费，因为在意识到需求需要变更的时候，距离变更后的方案还需要一段思考及修改方案的时间。）

6、需求评审与开发

需求的评审与开发涉及到项目的流程，这其中涉及项目管理中的项目监控的环节。

包括需求开发过程中的周会，用于监控需求当前的状态；产品需求的验收，用于验证需求是否能达到预期等。

本文主要聊需求的挖掘与分析，开发过程便不再过多赘述。

四、需求自检清单

这边的需求自检并不是指需求文档本身的清单，当然，如果要，阿境这边也有，详见《人手必备的产品自查表》。（厦门吴彦祖没有啥是没有的！）

需求自检清单指的是从需求的萌生后，产品经理所需要考虑的点是否完善且详尽。其诞生的本质是上述文章内容所涵盖的核心点。

1、是否了解了需求的目的、背景、来源等基础信息？

2、是否有对需求进行需求价值的分析？需求的核心用户、发生场景是否了解？

3、针对该需求，所涉及业务模块的数据是否了解？

4、针对该需求，当中涉及到的运营场景及日常运营操作是否清楚？

5、是否有与需求提出方进行完整、详细的了解？

6、对于该需求，其中背后存在的问题，其他竞品是怎么做来解决的？

7、需求完善清楚后，是否有进行需求内容的完整记录？（记录需求池）

8、需求的关键指标（目标）是否清楚？（可采用GSM模型来梳理）

9、需求的业务流程是否清楚？

10、当前情况的流程与需求完善后的流程对比，两者的区别是什么？

11、需求对于平台其他业务有什么联动影响吗？这些逻辑及流程是否了解？

12、现有功能是否能够解决需求所对应的问题？如果能，则还有多少可优化的空间？

13、需求是否符合当前产品发展的方向规划？若符合，处在哪一阶段？

14、如果做了这个需求，成本层面与收益层面是否成正比？

可以关注公众号<梦想家阿境>，并回复“需求分析”，有阿境整理的《需求自检清单》、《最全产品自查表》。

五、一些跟需求相关的tips

1、需求不会改变，但需求的解决方案会随着时间的改变而变化

2、需求需要根据用户的不同、场景的不同、时间的不同来考虑

3、只有较低层次的需求得到满足后，用户才有动力去追求更高层次的需求

4、需求可做大可做小，就看本质是想要达到一个什么样子的目的（不为了做需求而做）

5、需求考虑性价比（如果做3个需求能够满足80%的要求，做20个满足100%的要求，那么选择前者）

六、写在最后

这是阿境近来输出的一篇较为系统性的文章，从需求的概念、本质入手，逐步讲到需求的收集、评估以及分析，从概念理解到落地实践，由浅入深，希望能够对需求分析有疑问的朋友有一个系统的认识。

也相信认真吸收了文章内容之后，一些关于需求的面试题基本都能够解决了。

想说的是，需求分析只是一个思路，但并不是一个固定的框架，用户的需求会变，同样的，需求的分析方式也会随之改变。

“要了解怎么分析，并付诸行动，但不能仅仅局限于条条框框按部就班地分析”

需求分析需要结合自身对市场的洞察，用户的研究，产品的思辨，但同时也需要考虑其他多种维度，比如人性。需要“理性+感性”相结合着来。

毕竟做产品，是为了有趣。

写PRD是产品经理的基本功，大部分需要做执行的产品经理，都会花很多时间在写PRD上，写好PRD，才能将用户需求更好的转为产品需求，让产品方案落地。

PRD分为很多个模块，一份完整的PRD应该包含如下这些模块：

完整PRD模块，可关注公众号『刀哥说』获取模板

在实际的功能中，耗费时间较多，又主要是具体的用例（功能）模块，因为每个产品，都可以拆分成一个个独立的用例，用例的拆分，可以按步骤或者按功能模块，详细的拆分方法，可以看刀哥之前的文章，这里不详述。

本文的重点是分享具体用例的详细写法，把一个个的用例写好，可以极大的提升整个PRD的质量，减少和前后端开发撕逼，减少需求的变更，可以腾出更多的时间去研究行业，研究竞品，研究用户。

产品经理的核心竞争力，一定是对行业、用户的认知，产品的基础工作，花的时间越少越好。

01.用例

在说如何写用例之前，我们先来说一下，什么叫用例。用例是对用户通过系统完成目标的一系列过程的描述。用例是一个逻辑过程，一个标准的用例名称应该是动宾结构，比如登录系统、录入资料、找回密码……

一个完整的用例，我把它分成几个核心部分：1、前置条件/后置条件；2、业务逻辑；3、界面交互。完整的结构如下：

一个用例包含的关键要素

用例是UML里的标准术语，在实际和业务或者研发打交道的时候，经常叫做功能模块，功能模块也好，用例也好，产品经理自己一定要清楚这些概念的底层含义。

02. 前置条件/后置条件

需要提醒一点的是，在写具体需求的时候，不一定要按照某种严格的格式去写，除非公司有严格的要求，刀哥也有比较规范的PRD模板，关注公众号『刀哥说』，回复1可以自取。

但是在写的时候一定要按照这个思路，第一步，是先思考前置条件和后置条件，这个部分写的内容并不多，但是通过这部分的描写，就能弄清楚用户在执行完这个功能后，系统处理的结果是怎样的。

前置条件比较常见的就是用户状态、等级和类型等，比如用户要成功登录系统，前置条件是用户状态正常，后置条件是成功登录，进入系统。

比如用户要在系统里面新增一条数据，前置条件是登录状态，具备功能的操作条件，后置条件是完成在系统里面添加条数据，完成数据创建。

前后置条件有时甚至都不用写，比如用Axure写PRD的时候，但是产品经理心里一定要有数。

03.业务逻辑

这个部分，我觉得是最重要的模块，比界面交互还重要，也是产品经理的核心，产品经理的交互能力比较差还可以通过UED团队来弥补，如果业务逻辑差，那真是没得救。

业务逻辑我把它分成几个部分：主流程、分支流程、业务规则。

主流程，是通过活动图的方式，说清楚用户和系统的交互主流程。

分支流程，是在主流程的基础上，梳理各种分支和异常情况。

业务规则，则是流程判断的依据。

我拿一个审核工单的用例为例：

审核工单的主流程、分支流程和业务规则

实际梳理业务流程时，可以将分支流程和异常流程也加入到流程图里面去，颗粒度也需要自行掌控，根据团队情况。

这种业务流程图，也叫活动图，是用户和系统的交互过程，也是业务逻辑部分重要的分析工具。

系统在处理或者判断的时候，需要根据一系列的规则来执行，在梳理主流程和分支流程的时候，可以针对具体的流程节点，梳理业务规则。常见的业务规则如排序、数量、状态、顺序、时间。

梳理业务规则的时候可能会用到ER图和状态机图，有兴趣可以刀哥之前关于业务流程的文章。

04.界面交互

按『用户体验的五个要素』来划分，界面交互属于表现层和框架层，界面交互涉及到细节比较多，如果考虑不全的话，会产生很多细节问题。

业务逻辑部分，后端开发更关注，而界面交互部分，前端开发更加关注。

界面交互有几个核心部分：字段规则、界面展示、控件、页面跳转。

界面交互的要素

1）字段规则：字段规则主要是输入类的字段，所有输入的字段，需要考虑输入控件的类型、是否必填、字段规则、提示这几个要素，在写PRD的时候，可以通过表格的方式呈现。

2）控件：界面上有哪些交互控件，控件在不同状态下的展示样式，比如输入框默认状态、失焦状态，输入内容时，是否支持一键清除等，输入错误时，边框是否变红等。

3）页面跳转：点击链接或按钮，跳转到哪个页面，跳转到页面时，是否会带上参数，跳转页面后，再返回，界面上的数据怎么处理。在加载页面时，是否显示loading，加载失败怎么展示，页面404、500等缺省页面是否有准备。

4）展示：数据展示的规则，界面展示的每一个数据的来源是哪里，如果超过长度怎么展示，不同状态下怎么展示，空状态怎么展示。

其他还有一些常见的比如列表排序，数据埋点等，都是属于界面交互的部分。

05.写在最后

之前刀哥写过一篇文章，把做产品当做玩游戏，一共有四关：

只有过了基础的第一关，才能进入第二关，而要过第一关，就需要踏实的基本功，如果基本功不好，永远过不了关，一直在做功能，而不是做产品。

写好PRD还有一个很好的方法是，把写PRD梳理成一个SOP，归纳一套组件库，汇总一份自查清单，有标准模板，也有标准的写作思路，这样就能保证输出高质量的PRD。

组件库、自查清单、PRD模板，刀哥的资料库里，已经有比较详细的了，如果有需要，关注刀哥公众号：刀哥说，回复『1』即可自取。

微信公众号：涵小仙女。文艺女青年一枚，白天工作，晚上码字，爱美、爱跑步、爱旅行，愿我手写我心，余生不将就。

日常工作中，除了时间和精力管理 \ 目标、计划与执行2种方法，还会再谈思维方式。老话说：让你与众不同的不是努力，而是思维方式。

思维方式是个很大的话题，在一些营销号上会讲“掌握50个思维模型，建议收藏”。更有著名的查理芒格的100个思维模型。100个门槛太高，今天只讲两个基础版：逻辑思维与结构化思维，也是我每天工作反复被调用很多次的两种思维方式。

从100个思维模型中专挑这两种花5、6千字来讲，是因为这两种思维方式极其重要，相比于各种方法技能，逻辑思维与结构化思维欠缺是工作混乱的根本原因，是大脑CPU运行的内核。

如果你不懂或者没这方面的意识，相当于大脑直接宕机。但是，从你知道到刻意练习并且在工作中真正践行，可以慢慢从混乱中解放出来，与人沟通也会顺畅很多。

在职场上你应该看到过那种初次见面，便感觉到工作能力很强的人。

• 听他发言，说话非常有条理。短期、中期和长期行动是什么；第一、第二、第三原因是什么；
  

• 看他文档，目录层级清晰、各部分内容之间逻辑清晰，看他文档本身变成一种享受；
  

• 听他给解决方案。有框架、有依据，直击问题要害。

这种感觉从哪里来的，依托于清晰的逻辑思维与结构化思维。

让你可以快速获取到他人想要传达的信息，提高你接受信息愉悦度的，逻辑思维与结构化思维发挥了极大作用。

在众多的思维方式中，我首选逻辑思维与结构化思维。其他的思维方式，如批判性思维、创造性思维等也很重要，更多影响你自己如何看待问题。

但逻辑思维和结构化思维核心影响你与他人的关系，影响信息传递效率，影响你的个人影响力，是非常显性化的两种思维方式，是其他思维方式的基础。显性化是你只要刻意练习，你便能习得这项能力，并且很快在工作中应用得到正反馈，提高你的工作效率、加强你的沟通表达能力。

思考和表达没有逻辑与结构，是种灾难。核心不是让自己怎样，而是非常浪费别人的时间。大家的时间都很宝贵，你浪费了别人的时间，别人怎么还会有耐心信任你。尤其是对领导，你应该常常想几分钟内还没把事情讲清楚，他就没了耐心。同事之间沟通也如此，你讲了几分钟，对方还听不懂，那么他下次就不再想跟你沟通。

同样一件事情，能有逻辑地结构化思考和表达，可以节省双方更多时间，提高效率。逻辑与结构化思维可以让接受信息的人快速明白你要讲什么，也可以把你想表达的重点传递给到对方，它让我们在沟通交流中提高自身说服力。

职场人首要学习这两种思维方式，逻辑思维提高自身说服力，结构化思维提高信息传递效率。越早期越有这种意识，刻意培养自己，越能较早形成自己的核心竞争力。

如果你说你不知道自己核心竞争力是什么，那么刻意培养的逻辑思维与结构化思维也可以让你在一堆人中脱颖而出。

这些东西我写出来是我经历过那种职场混乱期，所思所悟皆为自己真实工作经历所得。思维方式听起来虽然高深，但是日复一日的复盘、反思、总结，刻意练习均可以习得，关键看你有没有觉醒，知行合一后发现是另外一片天空。

本文内容如下：

01  逻辑思维

在产品经理日常工作中，偶尔会发生与开发的争吵。开发怒气冲冲之下可能说：需求逻辑有问题。

抛开主观立场地说：绝大多数确实是产品经理自己没想清楚。开发之所以如此强调逻辑，是开发写代码需要真实一行行代码堆砌而成，缺一个环节代码无法跑通，需要逻辑一环扣一环。产品经理讲述听上去“非常完美”的方案，毕竟是理论，逻辑不严谨到了开发那里无法实现。

虽然逻辑思维是每个职场人必备素质，但是对于产品经理来说应该更佳，逻辑不严谨对于产品经理来讲是种致命的伤害。

逻辑不严谨最终导致功能上线后出现问题，是会真实产生损失的。比如做了新功能改动，但是没兼顾到旧数据，那么使用旧功能的用户可能就没法使用。

逻辑不严谨导致给出的解决方案没法真正解决问题，浪费资源不说，还错过了时间窗口。换句话说，功能做了个寂寞。有时候项目上线后看不到明显的转化，根本原因在一开始分析问题的思路就出错了，问题和解决方案之间没有形成逻辑闭环，你预想的“好”其实是错的。

在这个case 里可以发现业务想要做的行动跟原因并不匹配。假如真改了文案，退换货满意度就能提升到跟天猫京东一样了吗？如果事先不进行因果关系的纠正，没有想清楚匆忙投入开发，最终导致功能上线了实际问题也没得到解决。

在实际工作中此类问题数不胜数，此类问题皆是逻辑思维不缜密所致，你以为的解决方案不是问题产生真正的原因。

什么是逻辑思维

百度百科：逻辑思维（Logical thinking），人们在认识事物的过程中借助于概念、判断、推理等思维形式能动地反映客观现实的理性认识过程，又称抽象思维。

它是作为对认识者的思维及其结构以及起作用的规律的分析而产生和发展起来的。只有经过逻辑思维，人们对事物的认识才能达到对具体对象本质规律的把握，进而认识客观世界。它是人的认识的高级阶段，即理性认识阶段。

这段话挺难懂的，换个白话文来讲。逻辑思维是建立在因果关系之上的反映客观现实的思维方式。在表达上的体现就是，说话有理有据，条理清晰。

逻辑思维强体现在被问及“为什么”的时候，你能够以所有人都能理解、并且具有说服力的方式，来清晰阐明得出结论的原因。或许可以说，让别人去接纳你所断定的结论，正是逻辑思维的职责所在。

逻辑思维十分讲究因果关系，你给出的每个结论，是确切的不是模棱两可的。你得到的每个结论，足够的理由经得起推敲。你给出的论据，是大家熟知的“常事”。

提升逻辑思维

工作中大大小小的事情都需要做决策，回答一些问题，给出解决方案。当你尝试给出一个结论时，这个结论尽要符合逻辑。那么，如何去体现你的逻辑思维呢。

// 因果关联

因为（事实）—所以→结论1—所以→结论2……→决策（最终结论）。从最初结论一路倒推到最原始的“事实”，指现实情况和大众普遍接受的道理、原理、原则，这个点无法再产生任何质疑。

世间万物都存在普遍联系，逻辑思维中最重要的就是找准结论与事实之间的因果联系。运用因果逻辑进行推理，一定不要仅停留在单一的因果层次上，必须从多个角度去研究事物发生的原因以及推出的结果。

比如，分析事物之间不同因果联系产生的不同结论。通常情况下，我们在进行因果关系推理时，必须重视因果分析，需要注意的有以下几方面：

① 有明确的结论产生

工作很忌讳给出模糊结论甚至不给结论，是就是，不是就不是，可以做就说可以做，不能做就说不能做。

但是不要回答：也许吧....先看看....不知道结论是什么。再或者出现了问题讲述了一大段原因，但是否产生影响或损失无结论，下一步有无行动也无结论。没有结论的表现就是别人听了你的阐述，像没有听一样，也不知道下步该什么。

讲因果关系时首要明确结论，且结论肯定不模糊。听到结论的人明确知道自己下步要做什么行动。明确得出下步不做什么也是一种结论。

② 分析产生问题的真正原因

有些情况下，原因可以分为很多层次，有些现象在表面上看来是引发结果的原因，但其实不然，因为在它们背后还存在着引发它们的原因。

对于拥有多个引发原因的结果，如果仅停留在某个单一层面上，将这一原因当作引发结果的最终因素，论点就会变得相对肤浅，并且很难将分析的问题理清楚，这样的因果逻辑推理得出的结果所拥有的说服力必然不大。

我们常说的第一性原理是讲此点，从头算起，只采用最基本的事实作为依据，然后再层层推导，得出结论。有经验虽好，但有时候人们由于惯性陷入经验主义，而忘记质疑自己“为什么一定是这样”？

用5W1H多问自己几个为什么。平时工作只知道自己在做什么，那就是What，这样当然是不够的，还要常问自己，再来一遍what（我做这的这个到底是什么？），why（为什么要做，为什么要这么做），how（怎么做比较好），why not（为什么不能那样做呢？）。如果你在尝试得出一个结论时，自己没先在内心先演练一遍，跟他人交流时，很容易受到挑战。

找不到产生问题的真正原因对产品经理来说，就是做需求\项目，等所有功能上线后做了个寂寞，看不到任何价值反馈，十分消耗个人信任度。

③ 分析主要原因和次要原因

很多情况下，一种结果的引发原因可能有很多种，这时我们必须分清其中的主次原因，准确抓住主要原因，通过引起结果的最基本因素来进行逻辑推理。

分析主次原因才会懂真正的MVP。MVP高度训练你对问题做拆解的能力，锻炼把一件事儿做成的能力。什么是当下最主要的矛盾，最应该被解决的痛点是什么，为什么是先做A而不是先做B的逻辑依据。如果一个人一上来就要做大而全的解决方案或者想要走捷径去做很容易实现的次要原因，也容易被受到质疑。

MVP 核心用最少的资源去做最应该被解决的问题，前提条件可以拆分得出主次原因，优先解决主要原因的问题。

// MECE 原则

因果关系强调纵向思考逻辑，一环扣一环，回答“为什么”，MECE原则强调横向思考逻辑，思考无遗漏。

MECE原则来自《金字塔原理》，指相互独立不重复，完全穷尽无遗漏。

• 各部分之间相互独立（MutuallyExclusive），没有重叠，有排他性；

• 所有部分完全穷尽（CollectivelyExhaustive），没有遗漏。

干一件事情之前，我们先把它可能涉及到的要素全部列出来，运用思维导图工具，一层一层剖析到底；将这些要素按相同的性质来进行整理归纳，划分层级，最终呈现在你眼前的思维导图架构就会清晰明了，所有可能触发的点一目了然。

① 时间顺序

时间顺序强调一定要在某个时间节点发生了什么事情对下个时间节点产生影响。有明确时间差的按照时间顺序思考。比如说，过去—现在—未来，阶段1—阶段2—阶段3。

② 流程顺序

按照事物发生的流程顺序思考，先有什么再有什么，什么数据的变动会导致另外一块数据变动，这样避免我们改动了某块功能而遗留另外一块的功能。比如用户在电商网站上下单支付，先后有订单系统和支付系统均要参与这个过程。

③ 结构顺序

做完某件事情一定要所有相关点都能实现，如果一个点遗漏，导致整体无法完成。比如某个支付方式在指定金额区间范围内有效。

小结

逻辑思维是所有思维方式的基础，核心在于如何思考。只有思考有逻辑，表达才会更有逻辑。在第2部分来讲述表达上的结构化思维。

02  结构化思维

• 同样沟通事情，有的人三句话就能说清楚，而你可能说了10分钟也说不到核心；

• 同样是做汇报，有的人用5页PPT就能说服对方，而你可能写了20多页还要被反问想表达什么；

• 同样是阐述解决方案，有的人清晰讲出背景、问题、原因、影响和举措，而你挤牙膏式的回答一句紧接着再被问一句。

如果说一个人沟通表达能力差，情商是一个因素，但还有一个更关键点：结构化思维。如果对方听了半天都不知道你在表达什么，情商再高也失去色彩。

人类大脑在处理信息的时候，有两个规律：

第一，不能一次太多，太多信息会让我们的大脑觉得负荷过大；

第二，喜欢有规律的信息。

人的大脑最多仅记忆7个思想，当处理过多思想的时候需要建立逻辑关系，形成立体结构，完整、清晰地看到每一面和每个点。

表达能力强的人，不是比你更聪明，而是知道大脑这个特点，更懂得通过有效的结构化思维，快速对信息进行归纳和整理进行传递。

大脑容易记住有规律的东西，那么你在信息传递时尽量使用规律的东西来传递。把无序变得有规律的过程即结构化思维。

什么是结构化思维

结构化思维是一种从整体到局部、从框架到细节的思维方式。它要求思考者不先入为主，不会过快地陷入细节，而要经常留意事物的整体框架，在框架的基础上去拓展细节。

先看能够解决问题的关键方面，然后再往下分析，从而实现从总体到局部的鸟瞰，最典型的就是金字塔结构图。

结构化思维渗透在工作的方方面面，是建立在逻辑思维之上的另一种显性化思维方式，不可或缺。结构化思维可以带来显著的工作效率提升，尤其是在沟通中。

为什么在沟通中结构化思维可以发挥巨大作用？

因为人和人之间信息差。结构的越上层，彼此之间信息差越小；结构的越下层，彼此之间信息差越大。如果一上来陷入到最下层的细节之中，对方大概率听不懂时沟通出现低效。

提升结构化思维

如果说逻辑思维一定程度上跟人天生智力水平有关，即我们常说的一个人聪不聪明，那么结构化思维则可以通过刻意训练习得。

结构化思维完全由自己从0到1主动规划所得，就如同有些人可以做出好看的PPT，其实也是懂得了PPT背后的套路。

提到结构化思维，不得不去看的《金字塔原理》一书，主要有4个原则：结论先行，以下统上，归类分组，逻辑递进。

• 论：结论先行。
• 证：以上统下。
• 类：归类分组。
• 比：逻辑递进。

结构化思维有2种方法：自下向上组结构和自上向下套框架。

// 自下向上组结构

自下向上组结构核心在于这个结构是你自创的。根据你自己对接收到信息的理解，把信息重新组装的过程。比如我写这篇文章的框架结构，你日常整理会议纪要的结构。没有统一标准，你按照一定逻辑重新组合信息。

我的结构化思维正是通过写文章被训练很多年得到提升，到现在工作中有结构化思维已经成为我的个人标签。在我脑海里，日常对大量碎片化信息进行重组，把碎片化的东西像盖房子一样一层一层自下向上组装起来，等到溢出时一篇文章完成。

比如我给领导讲业务数据的PPT，首先会介绍我分析数据的整体框架，其次再给一个实际的数据分析的概览，再往下去细看每块的细分数据，针对每块的数据给出结论和TO DO。

• 整体数据指标体系（理论）——一页PPT

• 总体数据指标概览（实际数据）——一页PPT

• 分模块1数据指标——一页PPT

• 分模块2数据指标——一页PPT

• 分模块3数据指标——一页PPT

• 每页PPT里的结论和TO DO

• 总结——一页PPT

先框架后细节，先总结后具体，先结论后原因，先观点后建议，先重要后次要。这样，才能让对方第一时间抓住重点信息，知道我们要传递的核心内容。

站在自己视角时，先把所有零散的点穷举，再看点与点之间的关联性连接成面，面最终再成体。概括起来大致分为以下4步：

• 尽可能列出所有思考的要点

• 找出关系，进行分类（找出要点间的逻辑关系，利用 MECE 原则归类分组）

• 总结概括要点，提炼观点

• 观点补充，完善思路

// 自上向下套框架

如果你是做已存领域的问题解决方案，那通过自上而下找结构：思考一个框架，然后将信息或解决方案放入框架。

比如，提到规划，可以使用五看三定框架；提到制定目标，可以使用SMART原则；提到制定任务计划，可以使用WBS任务拆解。

自上向下套框架依赖我们自身积累了多少种框架，在实际场景中可以随时被调用。

这里就给一些日常的积累。（如果大家需要完整版本的就加我微信获取）

一、学习能力

• 学习金字塔

• 费曼技巧

• 刻意练习

• RIA阅读法

• 二八定律

二、思考能力

• 黄金圈法则

• 5W1H分析法

• 思维导图

• SWOT分析

• 10/10/10法则

• 冰山模型

三、创造能力

• 六顶思考帽

• 头脑风暴

• 逆向思维

• 类比思维

• SCAMPER创新思维

四、设计能力

• 设计思维

• 最小可行性产品（MVP）

• 峰终定律

• AARRR漏斗模型

• 上瘾（HOOK）模型

五、共情能力

• 五大圈层模型

• 高效倾听模型

• 情绪ABC模型

• 乔哈里视窗

• 冰山模型

六、演讲能力

• 故事五要素

• SCQA模型

• SRAR模型

• STORY模型

• “英雄之旅”模型

七、领导能力

• 领导力梯队

• 情景领导力模型

• GROW教练模型

• 管理4C模型

• TOPIC模型

八、整合能力

• 杠杆思维
• POA行动
  
• 系统思维
  
• 整合思维模型
  
• 多元思维模型

小结

结构化思维是一个建立清晰、稳定、有序的思考结构，学到这个结构之后，知识体系从零散化到系统化，从无序到有序，从低效到高效。

不断的进行归纳和总结，养成做任何事都进行阶段性总结和复盘的习惯是训练结构化思维的核心。思维如果懒惰任何种方法技能也无济于事。

结语

刚毕业时，因为不懂这最核心的2种思维模式，在工作上举步维艰。后来通过刻意练习提升这2项最核心的思维，找到工作的掌控感。

混沌大学创办人李善友教授说过：成年人学习的目的，应该是追求更好的思维模型，而不是更多的知识，在一个落后的思维模型里，即使增加更再多的信息量，也只是低水平的重复。

逻辑思维与结构化思维本身是专门的学科，并不是本文几千字就可以讲清楚，只是抛砖引玉提出观点建议大家刻意学习提升。一些行业内的通用书籍，如《金字塔原理》、《结构化思维》或《逻辑思维》值得反复阅读并且在日常工作中训练。

思维决定了你的认知水平和成长速度。工作上没有好的思维方式，再努力也是无效努力。思维方式需要主动意识到高价值然后刻意训练习得。愿我们都能拥有更好的思维模型，开启不一样的人生。

《电商产品经理从0到1》系列文章面向从事电商类、交易类产品方向并希望在该方向深耕的产品经理。

本系列文章将详细介绍电商核心系统的产品设计方案，帮助你体系化的认识电商产品。

本文章为《电商产品经理从0到1》系列第 三 篇：电商·营销中心

看完本文，你将对以下问题有所了解：

1. 什么是促销？

2. 促销的作用是什么？

3. 营销中心有哪些核心能力？ 

4. 营销中心从0到1如何设计？

    4.1 促销工具

    4.2 促销叠加互斥规则

    4.3 促销命中规则

    4.4 实时价格计算

    4.5 优惠分摊计算

本文除了详细的功能设计说明外，同时也会解释设计背后的思考，非常适合新接触电商营销或者想要体系化掌握电商营销中心的产品同学们，看完本文，相信大家能掌握与营销相关的大部分功能模块的设计思路。

全文15000+字，阅读时间大约需要1.5小时，建议收藏和使用电脑阅读。。

前言

电商产品经理从0到1系列文章第一篇《一文读懂电商产品架构》整体介绍了电商的基本业务、系统流程以及产品架构，通过三张大图初步窥探了电商的基本面貌，了解了一个完整电商系统的核心组成，对电商有了概念层面的全局认知。

那么本文将带来《电商·营销中心》的具体设计思路和方案，深度解析一个大型电商平台的促销系统都有哪些核心模块以及促销系统是如何设计的。

（图片过大无法正常显示，请用电脑放大查看）

本文将从促销的业务、促销的场景开始，先探讨分析电商为什么需要促销，促销的作用是什么，然后再深入的、体系的介绍电商营销中心各个模块的设计逻辑。

01 促销业务概述

1. 什么是促销？

促销是指卖方通过对消费者提供短期激励，以诱使其购买某种特定商品的过程。

促销实质上是一种沟通活动，即营销者发出作为刺激消费的各种信息，包括营造出价格优惠、限时限量等氛围，把信息传递给一个或多个特定目标对象以影响其对商品的态度和行为。

2. 促销的作用是什么？

促销是运营工具，作用是帮助运营者完成其对用户的拉新、转化、促活、留存、传播的目的，完成对商品入市推广、销量提升、客单价提高、滞销库存清理的目的。

促销有别于常态化的销售，它有限时、限量、限消费群体以及优惠等特点。它是业务在运营过程中为了完成某种目标而使用的一种手段。

如业务冷启动阶段，平台通过促销来获取流量，新商品通过促销来快速打开市场。如激活阶段，通过促销来激活用户、提高客单价；如留存阶段，通过促销持续吸引用户购买使平台进入相对稳定的状态，或通过促销来清理尾货滞销库存；当业务进入稳定变现阶段后，通过有节奏的促销来稳定波动的流量和短期的GMV达成等目的。像京东、天猫这样非常成熟的平台也需要不断地通过促销来维持平台的活跃与转化。

稳定增长的流量和长期留存（电商中定义的留存≠登录）是衡量一块电商领域的业务是否健康的标准，而任何业务在达到健康的状态之前都会面临流量的短缺和留存的困难，即使业务进入相对健康的状态下，依旧会面临流量的波动或者留存的不可持续。因此促销就成了帮助业务进入稳定状态或持续处于稳定状态的有力工具。

3. 促销与营销的区别？

在专业概念上，营销有别于促销，营销是为了与消费者建立信任关系进而对企业自身、品牌以及产品进行长期的价值塑造的过程；而促销只是营销的一部分，主要是通过促销活动的方式向消费者提供短期激励促使消费者购买产品的过程；

但是在系统设计层面，营销在很多场合上都等于促销，营销中心只是一个系统命名，其实就是促销系统。当我们说促销或营销时更多的是在说促销活动（而市场部、企划部等专职营销的部门说营销时，就真的是营销了，比如地铁上投放企业广告之类的）。本文的目的主要也是介绍促销功能的设计方案而非科普专业术语，因此本文的营销和促销也都是表达同一个意思。

4. 促销形式与促销场景

电商的促销工具的种类非常多，不同的促销工具能做不同形式的促销活动，常见的有：特价促销、秒杀、满减、满赠、满折、优惠券等（具体分类见下面章节）。前面说过促销是帮助运营完成某种目的的工具，那是不是任意一种形式的促销工具都可以完成任意场景下的运营需求呢？其实不是，一种促销工具一定有它的作用边界。

那电商有哪些促销场景呢？我们可以分别从商品和用户的生命周期进行梳理并抽象：

上图就是从商品和用户的生命周期进行拆解梳理的结果，不论是针对商品还是用户，在不同阶段都有不同的促销场景：

那针对特定的促销场景，什么样的促销形式最适合、效果可能最好呢？例如最常见的用户拉新场景中，是选择做满减活动还是发优惠券？

大部分电商平台中，拉新最常见的方式就是发新人券（新人大礼包，包含多张面额不同优惠券），因为对于消费者而言，一张不限品类的低门槛优惠券带来的占便宜心理是最直接的，而满减活动则有凑单的心理认知，凑单意味着门槛，因此从心理上就不如优惠券简单直接。所以为了使促销效果最理想，不同的促销场景也需要不同的促销形式，我们按照场景简单梳理如下：

上图是根据促销场景分析出的简单模型，目的是让大家对促销工具和运营之间的联系有一定的认知。从专业角度看，产品经理作为促销工具的设计者，需要知道不同的促销形式（策略）分别适合哪些促销场景，需要有相当程度的业务知识，避免在做产品设计时被需求方牵着鼻子走而成为一个简单的执行者。

02 营销中心概述

1. 营销中心的职责是什么？

营销中心是负责管理与营销活动有关的数据和能力的系统，其主要职责包括：

1. 负责创建和管理营销活动，包括平台活动和店铺活动

2. 负责对前台以及相关系统提供促销价格、促销信息、促销规则等促销能力

2. 营销中心有什么？

2.1 营销工具

大部分人最开始接触促销系统的时候，最先接触的可能是创建营销活动的后台，主要功能是创建营销活动，如创建单品直降、满减、满赠、秒杀、优惠券等活动，这部分功能我们称作营销工具，是营销中心最基础的部分。

2.2 规则中心

当我们上线了创建活动的功能以后，紧接着可能会面临一系列逻辑问题，比如：

Q1：某sku已经参加了一个直降活动，同时段下还能参加另一个直降活动吗？

Q2：某sku已经参加了一个直降活动，同时段下还能参加另一个满减活动吗？

Q3：某sku如果允许同时参加两个直降活动，那用户购买该sku时以哪个直降活动的价格购买？

Q4：某sku如果参加了8折的折扣活动，同时该sku针对学生用户打7.5折，此时一个带有学生标签的用户购买该商品时，到底是以8折价格购买还是以7.5折价格购买呢？如果该sku同时针对粉丝会员用户打7折、针对新人打6折呢？

Q5：如果一个sku允许同时参加秒杀活动、直降活动、满减活动，那用户购买该sku时，最终到手价到底是多少钱？

Q6：如果用户购买了5个不同的sku，而这5个不同的sku分别参加了3个不同的活动，而其中3个sku又用了一张现金券，那每个sku最终的实付金额又是多少呢？如果用户下单后申请其中2个sku退款，平台应该给用户退多少钱呢？

······

以上列举的关键问题引出营销中心的一类核心功能，这些功能没有界面，只是一个个底层服务，这些服务打包在一起，称之为规则中心，是营销中心最为核心的部分。

这些功能决定了sku能否同时参与多个活动，决定sku参加了多个活动时应该命中哪个活动，决定参加了多个活动时如何计算sku的实付金额。

2.3 内容管理系统

当我们解决了活动创建、解决了逻辑问题后，运营说要把同一个满减活动下的sku放到一个活动页中，方便用户选购。那活动页从哪来呢？是让研发同学临时开发吗？这里引出另一个非常核心的系统——内容管理系统，它可以通过搭积木的方式实现在线搭建任意样式、功能的页面。

2.4 平台活动管理

如果你负责的是平台型的电商产品，而且平台体量比较大的话，那么发展到一定阶段后很可能会涉及到平台型活动，即由平台官方发起，商家自主报名的这类活动，如淘系的聚划算、天天特价，京东的秒杀、闪购等，这其中又会涉及到提报规则、竞价规则等一系列复杂的系统逻辑。

2.5 审核与风控

当做完基础系统后，有一个很重要的问题就是风险控制问题，需避免一个sku降价力度过大或恶意套现等问题造成资损风险，因此我们要需要有促销审核功能以及风控系统。

2.6 营销活动分析

当活动结束后，我们需要分析活动的效果如何，分析活动的投产比，因此需要有对应的数据分析的功能

2.7 对接上游系统

当我们成功创建了活动，解决了逻辑问题，实现了活动页面搭建功能，并且有相应的风控和数据分析功能以后，基本上就完成了营销中心80%的功能了，剩下需要解决问题还有从商品中心获取商品、从价格中心获取基础价格、从用户中心获得用户标签等，这些都是营销中心的上游系统。

最后我们将这些系统或功能按照依赖关系进行组织一下，就能得到营销中心的系统架构图：

（图片过大无法正常显示，请用电脑放大查看）

营销中心各核心模块能力总结如下：

1. 营销工具：用于创建营销活动、管理营销活动

2. 规则中心：用于控制活动的叠加互斥、命中，提供促销价格计算，提供优惠计算规则等能力

3. 内容管理系统：用于在线搭建促销页面、频道页、公告，装修店铺等

4. 平台活动关系：用户创建、审核和管理平台类活动，平台类活动由提报系统管理

5. 促销审核与风控：用于控制、预警和管理活动风险

6. 营销分析：用于分析营销活动、活动的效果

7. 前台促销能力：提供促销价、促销标签、促销信息展示的能力

当我们知道营销中心有哪些核心模块以后，下面，我们就营销中心的几个核心模块的通用设计方案分别展开说明，详细的介绍每个模块应该如何设计。

03 营销工具设计（基础篇）

~~~如果对营销工具比较熟悉，本章节可跳过。~~~

1. 营销工具（活动）的分类

在促销业务概述中，我们了解到促销活动的本质是优惠，而优惠的形式有很多种，有的促销活动是在商品原价基础上直接降价，有的促销活动需要满足一定的门槛后再进行减免，不同的的促销形式满足的促销场景不同，带来的效果也不同。

不仅在业务层面有促销形式上的区别，在系统设计上也需要区分促销类型，在介绍营销工具的设计方案之前，我们有必要详细了解一下营销工具（促销活动）的分类，对于前端，不同类型的活动有不同的设计侧重，对于后端，规则中心有很多逻辑都与分类有关。

首先我们将营销工具分成两大类，一类是基础工具，一类是衍生类工具，我们主要是针对基础类工具进行分类，根据促销优惠形式的不同，我们将基础类工具分成如下几类：

1. 单品类：指在商品原价基础上进行直接降价，如：一口价、直降、折扣、秒杀等

2. 总价类：指在小计金额基础上进行减免，当一个或多个商品的小计金额满足优惠条件后，对小计金额进行减免，如满减、满折、满赠、加价购、套装等

3. 抵扣类：指在订单应付金额基础上进行抵扣，如优惠券、余额、红包、积分等

4. 满返类：指在订单实付金额基础上或基于策略进行返还优惠，如满返积分、满返优惠券等

其中秒杀活动虽然属于单品类活动，但是由于秒杀活动的特殊用户心智，在各大电商平台都处于首页焦点图位置，具有极强的引流效果，因此秒杀活动一般被设计成提报类活动，无法由商家自行创建，属于提报系统的职责。类似的还有淘系的淘抢购、天天特价、聚划算等。

而衍生类工具，如分享有礼、收藏有礼等只是基于基础工具衍生出来的玩法，比如分享有礼一般都是基于优惠券体系的一种裂变营销玩法，即A分享给B，AB都获得优惠券，本质上还是优惠券的一种发放方式，不影响前台设计和规则中心。

促销活动分类对于前台设计以及规则中心的影响请见后面章节。

2.营销工具的设计

营销工具的产品设计大同小异，可抽象成3个关键要素：

1. 基本信息：活动名称、活动时间、活动地区、准入用户···
2. 活动商品 ：商品池、活动限购、活动限售
3. 优惠规则：如满减活动的阶梯满减、重复满减

这3个关键要素也恰好体现在创建活动的3个步骤中，下面分别以单品类和总价类活动各举一个示例来介绍一下

2.1 单品直降活动

① 步骤一：设置基本信息

单品促销活动一般有多种优惠方式，常见的有一口价、直降、折扣：

• 一口价指直接设置优惠后的促销价

• 直降指基于平台原价设置直降力度，促销价=平台价-优惠力度

• 折扣指基于平台原价设置折扣力度，促销价=平台价*折扣力度

在后台设计上，可以设计成在一个直降工具中，创建活动时可以选择三种不同优惠方式，也可以设计成三种独立的工具，每一种工具就是一种优惠方式。

推广平台指投放的渠道（即架构图中的渠道和终端），在大型电商平台中，由于其业余形态非常多元，因此会有很多不同的销售渠道，如京东除了主站外（京东APP+PC），还有极速版、1号店、微信端等；淘宝有手机淘宝、天猫、淘宝特价版等；不同的渠道有不同的消费群体，因此针对不同渠道有做不同形式或者不同力度活动的需求，甚至有时候在战略上有推广特定渠道的需求（如阿里在2011年提出all in无线战略时，很长一段时间内都采用了APP端价格低于PC端的策略），所以在营销工具中应支持活动定向渠道投放。

活动地区指控制特定地区的用户参与活动，一般采用行政地区，如果需要限制特殊地区用户参与（比如疫情区域用户），则可以结合电子围栏功能给圈定地区下的用户打标即可。

活动用户即准入用户，指允许参与活动的用户，此功能需要调用用户管理中的用户标签功能，如只允许“学生用户”享受活动，则在用户中心给属于学生的用户打上【学生标签】，然后在活动用户设置中选择【学生标签】即可。注意这里一般采用的白名单方式，即被添加了准入的用户可以参与活动。也可以设计黑名单逻辑，即被添加了黑名单的用户不可参与活动，若同时存在黑白名单，则需要定义黑白名单的优先级，具体设计方案根据自己的平台特性和业务需求判断即可。

限购用于控制单个用户的购买数量，设计上分最少购买量和最多购买量。限制最少购买量的目的是销售的更多（如针对滞销品清库存的场景）；设置最多购买量的目的则一般是推广目的，为了获取更多流量需要让受众用户尽可能多，避免被同一个用户全部抢光；限购的力度也有多种，如按单笔订单限购（单个用户一笔订单限购xx件）、按活动限购（单个用户一场活动限购xx件），针对单个用户的口径也有不同的定义，如按照用户ID限购、按IP限购等。

活动库存即限售，限售的场景是避免亏本过多。当我们推广新品时或者用爆品引流时，一般会采用降价的方式，由于商品并不是直销库存，为了避免亏本过多，只能拿一部分库存出来做活动，则此时可以设置限售数量，抢完即止，售空后的设计逻辑一般有售空停止销售和售空恢复原价销售。

注：在设置限购限售量时，可以设计成在设置基本信息时填写，设置成功后批量应用到该活动下的所有商品中，也可以设计成在设置商品优惠规则时填写，同一个活动中不同的商品可以设置不同的限购限售数量。

活动宣传语一般是展示到商品详情页的标题下方，主要起到一种广告宣传效果。

在常见的三方后台中，创建单品促销活动第一步需要填写的基本信息差不多就是上图所示的内容了，像一些自营平台需要填写的信息则比三方后台要更复杂一些，比如需要填写费用承担部门、承担比例等。

② 步骤二：添加活动商品

添加活动商品的方式一般有两种，在线选择和批量导入。

在线选择即在界面中点选商品，需定义可选择的商品范围（如售罄的是否需要漏出），如果是三方后台或者小型自营电商（SKU量级不多），也可以设计快捷选品的方式，如全部商品参与活动、部分商品不参与活动。

Excel批量导入即根据定义好的模板批量导入到系统中，模板中一般以skuID作为唯一主键，支持sku级别导入和spu级别导入。

③ 步骤二：设置优惠规则

设置促销价时，需校验促销价必须低于平台价，特殊单品促销活动则需要设计更加严格的价格控制，如京东秒杀或者天猫聚划算提报活动时，活动价需要低于7/15/30天内最低价（为了延续特定活动在用户心中的低价心智）。

上图是常见的单品促销活动的创建流程，下面简单介绍一下总价类活动的设计。

2.2 总价类活动

总价类活动的创建流程与单品直降类活动基本一致，只有在第三步设置优惠规则时不一样，单品直降类活动的优惠规则是设置在单个商品的粒度上，而总价类活动的优惠规则则是设置在活动的粒度上的，以满减活动举例，优惠规则界面如下：

• 满金额：指活动商品的小计金额满足条件后可享受优惠；

• 满数量：指活动商品的小计数量满足条件后可享受优惠；

• 阶梯满减：指活动商品满足不同的阶梯条件时，享受对应的优惠；

• 重复满减：指活动商品每满足条件一次，就享受一次优惠，如每满1000元，减10元，则当活动商品购满1000元时，减10元，购满2000元时，减20元，以此类推；

以上就是创建活动的功能设计说明，其他营销工具的设计大同小异，关键就是活动三要素：活动基本信息、活动商品、活动规则。

营销工具属于营销产品领域中偏基础的部分，也是大部分人比较容易接触到的部分，即使是初学者，通过调研和分析一些主流电商后台的设计，也能比较快的掌握营销工具的设计关键点，进而也能很好的将需求有效落地。

而营销中最关键核心的部分属于底层那些看不到的规则，这些规则没有界面，没有后台，因此初学者想要调研分析也比较难以切入，下面就详细介绍营销中心的核心-规则中心。

04 营销-规则中心（核心篇）

规则中心由多个职责不同的、独立的服务组成，这些服务决定了sku能否同时参与多个活动，决定sku参加了多个活动时应该命中哪个活动，决定了sku在前台的促销价格，决定如何计算订单中每个sku的优惠分摊金额、实付金额。

1. 叠加互斥规则

叠加互斥规则的作用是什么？

1. 用于控制同一个sku能否同时参加多个活动 

2. 如果同一个sku参加了多个活动，用于控制购买该sku时可以叠加几个活动优惠

不同类型的活动，其叠加互斥规则不一样，我们根据营销活动的分类，分别简单分析一下：

1.1 单品类活动

单品类活动指在商品原价基础上进行降价，如秒杀、单品直降等。

可以想一想，一个sku如果同时参加了两个单品促销活动，意味着该sku有两个促销价，此时就存在逻辑矛盾了，比如秒杀价90元，特价80元，很显然用户购买这个商品时肯定只能以其中一个价格购买，不可能既享受90元秒杀价又享受80元特价。

因此单品类活动最终只能以其中一个活动生效，所以我们可以给出2种设计方案：

方案1：创建活动时校验一个sku只能参加一个单品直降活动

方案2：创建活动时不限制，即一个sku能同时参加多个单品直降活动，但是控制最终只能以其中一个活动生效，即单品活动与单品活动之间，生效时互斥

进一步分析两种方案的优劣会发现，方案1简单粗暴，虽然保证了逻辑自洽，但是却有很多局限性，比如两个单品活动面向的准入用户完全不同时，此时应该是允许同一个sku参加这两个活动的。因此主流的做法都是创建时允许参加多个活动，购买时互斥。

1.2 总价类活动

总价类活动指在小计金额基础上进行减免，如满减、满折、满赠、加价购、套装等。

假如一个sku参加了两个总价类活动，比如活动A满1000-100，活动B满1000送购物袋，从逻辑上讲，理论上购买时是可以叠加的，比如用户购买1000元活动商品时，减100元的同时再赠送一个购物袋。

但是实际上主流的设计方案并没有采用叠加的方式，主要的原因是总价类活动主要满足的是“卖得更多的场景”，因此总价活动在前台体现在购物车环节，故而设计了活动分堆逻辑——即同一个活动下的商品在一个分组中（下图左），方便“凑单”。

因此当同一个sku参加了两个不同的活动时，就会面临一个问题——这个sku应该被分到哪个分组中展示呢？有人说在两个分组中都展示这个sku（上图中），那加减数量的逻辑该怎么设计呢？加减上面的sku，下面sku数量不变吗？所以可见该方案会面临很多逻辑矛盾。

除了上述的前台设计原因外，还有更重要的优惠风险的考虑——即避免优惠力度过大，因此目前主流的设计都是采用互斥的逻辑——即同一个sku在购买时，只能以其中一个总价活动生效。

那这时候就有人会问：“用户购买1000元活动商品，享受减100元的同时再享受赠送一个购物袋”的场景如何满足呢？用过京东的人应该有印象，京东有一个促销活动叫“满减赠”，即满减的同时又赠送赠品，这样的话，对于活动分组而言，同一个sku就不用担心应该在哪个分组中的问题了（对于“京东有满减活动、满赠活动，为什么还要弄一个满减赠活动”的问题是不是就解惑了）。对于参加了多个不同总价活动的sku，用户购买时可以自行选择其中某个活动进行生效（上图右）。

因此我们给出结论：总价类活动，创建时允许参加多个活动，购买时互斥。

1.3、抵扣类活动

抵扣类活动指在订单应付金额基础上进行抵扣，如优惠券、余额、红包、积分等。在逻辑上，这类活动相互之间不存在叠加矛盾，只有运营控制的需要，因此如果没有特殊运营需求（如使用了红包就不能用优惠券），从系统逻辑上讲，抵扣类可设计成：创建时允许参加多个活动，购买时叠加。

1.4、满返类活动

指在订单实付金额基础上或基于策略进行返还优惠，如满返积分、满返优惠券等。满返类活动与抵扣类一样，在系统逻辑上没有叠加矛盾，也只有运营的需要。因此，满返类活动也可设计成：创建时允许参加多个活动，购买时叠加。

1.5、不同类型活动之间的叠加互斥规则

不同类型的活动之间，也不存在逻辑矛盾，如一个sku参加了特价9折促销，同时参加了满1000元-200元满减活动，并且该sku支持使用满500-10元的商品券，很显然这几个活动之间是可以同时享受的，因此不同类型的活动之间：创建时允许同一个sku参加多个不同类型的活动，购买时，多个不同类型的活动之间相互叠加。

各类活动之间的叠加互斥规则总结如下：

1.  单品类活动：创建时可参与多个单品类活动，购买时只能以其中一个生效 

2. 总价类活动：创建时可参与多个总价类活动，购买时只能以其中一个生效

3. 抵扣类活动：创建时可参与多个抵扣类活动，购买时相互叠加生效

4. 满返类活动：创建时可参与多个满返类活动，购买时相互叠加生效

5. 不同类型活动之间：创建时可参与不同类型的多个活动，购买时相互叠加生效

以上就是营销中心的第一个核心规则——叠加互斥规则的详细说明，核心在于规避逻辑上的矛盾，对于没有逻辑矛盾的活动，在设计上可叠加也可互斥，甚至可以增加开关控制，完全取决于平台或业务的特性，针对性的设计功能即可。

2.促销命中规则

2.1. 促销命中规则的作用是什么？

在上一小节叠加互斥规则的介绍中，我们知道一个sku存在同时参与了多个同类型和不同类型的活动的情况。叠加互斥规则控制着用户购买该sku时，是叠加生效还是互斥，不论是叠加生效还是只能以其中一个活动生效，那最终享受哪一个或哪几个活动呢？这个时候就需要通过命中规则来控制了，如果说叠加互斥规则决定能不能，那命中规则就决定了谁和谁。

2.2. 促销命中规则如何设计？

首先强调一点：促销命中规则的设计方案完全没有标准答案，纯粹取决于业务的需求，只需要根据业务确认好的逻辑进行设计即可。

与叠加互斥规则一样，不同类型的活动，其命中规则不一样，我们还是以不同类型的活动分别展开说明：

单品类活动：

1. 秒杀活动优先命中，无论价格高低，优先命中秒杀活动；

2. 多个秒杀活动按照价格从底到高排序，价格最低的优先命中；

3. 秒杀价格相同时，则按照创建时间排序，最新创建的活动优先命中；

4. 非秒杀活动按照价格从低到高排序，价格最低的优先命中；

5. 非秒杀活动价格相等时，按照活动创建时间排序，最新创建的活动优先命中；

秒杀活动之所以优先命中，是因为秒杀活动在很多平台中都是平台型活动，平台型活动要么有资源位，要么有平台加权引流，因此平台型活动意味着流量，因此需要优先命中。

总价类活动：

1. 按照活动类型定命中优先级：跨店铺类活动>满减类活动>满折活动>满赠活动>满减赠活动····（完全没有标准，可自行根据活动重要程度或者其他场景设计即可）

2. 同一个类型下有多个活动时，按照创建时间排序，最新的活动优先命中。（如有两个满减活动，则根据这两个满减活动的创建时间确认命中顺序）

抵扣类活动：

        因为抵扣类活动基本上完全叠加，因此可视为全部命中，其中优惠券的抵扣又有其特殊性，优惠券本身是一个庞大且独立的系统，优惠券又分不同的券类型，因此优惠券本身也存在命中的情况，如同一个sku被挂在了3张不同的优惠券上，并且用户恰好拥有这3张优惠券，当下单使用优惠券时，能使用几张券也有对应的规则，本文暂不展开券系统的设计说明。

其他设计说明：

        ①命中保持：指sku命中了某个单品类活动后，如果这个sku的活动库存被抢光了或者超出限购数量了，sku要么不可购买要么恢复原价购买（取决于是否设置售罄库存和售罄后的购买规则），而不是再次计算命中其他单品类活动，只有当命中的活动失效（结束、下线）时，才会重新计算命中。

        ②sku命中与用户准入优先级：如sku参与了两个活动，根据活动命中规则，活动1优先命中，其次才是活动2，但是活动1的准入用户中没有用户a，活动2的准入用户中有用户a，此时用户a狗买该sku时，应该命中活动1还是活动2呢？针对这样的场景可以设计成用户命中优先，即在用户准入的活动范围下，再通过sku命中规则计算出最终命中的活动。（当然也有其他的设计思路，根据平台和业务特性自行判断即可）

以上就是命中规则的详细介绍，再次强调命中规则的设计方案没有标准答案，大家根据自身的业务特性确认规则即可。

3.实时价计算与双价格

影响价格的因素非常多，尤其是业务复杂的大型平台，如京东的价格体系中包含采购类价格、前台价格，其中采购类价格分进货价、采购价、仓报价，前台价格分原始京东价、划线价、前台京东价（红字价）等。

当价格体系非常复杂时，前台如何展示价格、用户以哪个价格购买就是很大的挑战，这个时候需要有一个服务来计算实时价格。

本章节暂不讨论价格体系的设计，主要说明影响实时价的因素中与营销相关的部分，那么影响实时价格的因素中，与营销相关的主要就是单品促销活动了，前面已经介绍过各类单品促销价的生效规则，那么本章节主要介绍另一种单品价格-用户价。

3.1.双价格-用户价

部分电商平台中，有一种较为少见的价格设计形态，即前台会展示两个售价（并非划线价），一个是正常的红字价（即单品优惠后的价格），另一个是其他高亮颜色的价格，当一个sku在前台同时出现两个价格时，也就是所谓的双价格设计了。

其中以其他颜色（非红字价）展示的价格其实是针对特定人群的促销价，即某一个商品在做促销活动时，针对普通用户设定一个促销价，针对特殊用户群设定另一个促销价。因此该价格也称为”用户价”。

如京东平台就经常出现两个价格的情况。在京东体系内，常见的用户价有：plus会员价、学生用户价、山姆会员价、粉丝价、新人专项价、令牌专属价等。该设计背后的逻辑也比较容易理解，即通过更好的服务（更便宜的价格）彰显这类群体的特殊身份，让其有被更好服务的体验，本质上是提升特殊群体的粘性，提供特殊群体对平台的认可度。

图左(1/2)是plus会员价，图中(3/4)是sam会员价，图右(5/6)是粉丝价

3.2 双价格的设计逻辑

因为双价格的设计主要是为了凸显特定人群的尊贵，通过更优良的价格让其觉得获得了更好的体验，因此双价格中的用户价一定会比前台红字价更便宜，所以对于用户价的创建和前台展示就需要做最基础的价格控制：

用户价的创建控制：

以京东PLUS价格为例，PLUS促销价格的优惠幅度要比非plus促销价高xx%；

用户价的展示控制：

以京东PLUS价为例，PLUS价最低且自营优惠力度大于实时价的xx%，POP的优惠力度需大于实时价xx%时，商详页才会露出展示，否则商详不露出；

其他用户价一般需满足用户价最低且且用户身份符合时才会在前端展示；

当双价格相等时：

同一个sku同时设置了不同的用户价，且用户价相同时，展示规则可根据特殊用户的群体数量从少到多设置优先级，群体越小则特殊性越高越需要凸显重视程度，如京东的逻辑为：企业会员价>新人价> Plus价>山姆价>粉丝价>学生价>令牌价>店铺会员价。

以上说明仅是京东平台的一部分逻辑，可以看出这些逻辑主要是为了控制用户价低于平台价，且在低于平台价的策略上有一定比例的讲究（如果仅仅低于几毛钱，可能就达不到效果了）。需再次强调的是，以上逻辑并非标准或者通用设计，甚至大部分平台都没有这类设计，如果大家所在的平台有类似的场景或者需求，在设计自己的系统时，可以此作为一定程度上的参考。

4. 优惠计算服务

4.1 什么是优惠计算？

我们回顾一下章节2营销中心概述中提的最后两个问题：

Q5：如果一个sku允许同时参加秒杀活动、直降活动、满减活动，那用户购买该sku时，最终到手价到底是多少钱？

Q6：如果用户购买了5个不同的sku，这5个不同的sku分别参加了3个不同的活动，而其中3个sku又用了一张现金券，那每个sku最终的实付金额又是多少呢？如果用户最后申请其中2个sku退款，平台应该给用户退多少钱呢？

通过以上两个问题我们大概能知道优惠计算服务是干什么的了？——即通过计算订单中每个sku的优惠金额，进而计算该sku成单后的最终应付金额，有了实付金额，那我们发生售后退款时就能知道退多少钱了。

所以，优惠计算服务的基本职责可概括为：

1. 计算订单中每一个sku所分摊的每一种促销活动的优惠金额； 

2. 计算订单中每一个sku的实际支付金额； 

3. 计算订单的应付金额

每个商品的优惠分摊金额计算并记录下来以后，我们就可以给到经分去计算每个商品的费用、每个品类的费用，进而能计算出各种口径的利润。而且优惠计算服务的作用远不仅应用于以上场景，当每个sku的每种促销活动的优惠力度可以计算出来后，还可以应用于成单前的很多地方，如在商详页、购物车或其他黄金流程中，系统可调用该服务计算出所有的优惠，进而在前台展示该商品的“预估到手价”，这对于刺激用户购买也有很大的作用。

如右图，勾选了两件商品后，系统马上计算出这两件商品的预估到手价，实现的原理就是系统根据这两件商品所命中的活动，包括叠加可用的优惠券，计算出最优活动组合，从而根据优惠计算服务计算出每个单品的最终应付金额。

4.2 优惠计算顺序

我们在营销工具的分类章节中介绍过，促销活动可分为单品促销、总价促销、抵扣类、满返类，不同类型的促销在交易流程中体现在不同的环节：

1. 单品促销体现在单个sku上，为最优先体现的促销类型；

2. 其次是总价促销，需要多个商品或多个数量满足条件，一般体现在购物车；

3. 抵扣类一般体现在结算页；

4. 满返类则体现在订单成单后；

当同一个商品参加了以上所有类型的促销时，其享受促销优惠的顺序就是以上顺序，因此我们按照以上顺序作为不同类型促销活动的计算顺序，即：

也就是说当一个商品参加了所有类型的促销活动时，我们：

1. 先计算该商品的单品优惠金额
   

2. 再计算该商品的总价优惠金额

3. 然后计算该商品的抵扣优惠金额

4. 最后计算该商品的满返优惠金额

4.3 递进式与平行式门槛

电商发展至今，主流的优惠门槛计算方案有两种，一种是递进式计算，另一种是平行式计算。

递进式计算规则：

根据优惠计算顺序计算每一层级的优惠金额时，以上一级优惠后的金额来判断是否满足下一级的优惠门槛。

平行式计算规则：

即每一层级的优惠都根据该sku的单品基准价来判断是否符合门槛（单品基准价是指单品优惠后的价格，一般为前台红字价）。

用一个例子说明：

一件商品原价3000元，现参加活动如下：

• 活动1：8折单品优惠活动

• 活动2：总价满2000-500元的满减活动

• 活动3：优惠券1满2000-500元，券2满1500-100元，两券可叠加

• 活动4：用户账户有可用余额400元

现在用两种优惠计算规则分别计算该商品的最终实付价：

可看出两种计算规则的结果不一样，平行计算规则下的实付金额小于递进式，逻辑更简单。早期各个平台都是递进式的计算规则，随着各平台活动越来越丰富，活动规则越来越复杂，各种活动叠加之后，用户最终已经不知道是否真的占了便宜，为了用户体验使逻辑简化，在2018~2019年期间，淘宝京东相继将优惠计算规则从递进式改为了平行式。相对的，在平行计算规则下，优惠力度会更大，对于商家而言更容易出现资损风险，因此对风控的要求也更高。

4.4 优惠分摊的计算逻辑

这一小章节非常重要，如果分摊计算的逻辑不设计好，极有可能出现商品分摊的优惠金额过大或者摊负的情况，也可能导致单个数量的实付金额与总计对不上的情况等等。

下面介绍一种方案：

1. 按照优惠计算顺序（单总券返）计算所有sku在每一层级的活动中所分摊的优惠；

2. 优先计算基准金额最小的sku，然后按基准金额从小到大逐个计算；

3. 以上一层级优惠后的金额作为下一层级计算权重的分子，第一层级计算权重的基准金额是商品的单品优惠金额，第二层级计算权重的分子是第一层级优惠后的金额，第三层级计算权重的分子是第二层级优惠后的金额，依次类推；

4. 用每个sku的基准金额（有多个数量则以基准金额之和）÷ 该sku命中的活动所适用的所有sku的基准金额之和*该活动的优惠总额；

5. 同一个活动中，最后一个sku的优惠金额=优惠总额 - 其他sku优惠之和

6. 计算过程四舍五入保留6位小数精度，最终需展示的结果四舍五入保留2位小数；

针对以上方案的解释说明：

1、第2点中，当订单中有多个sku时，为什么要按基准金额从小到大的顺序依次计算？——因为如果从大到小计算，当有一个sku的金额过大时，则其权重也过大，在四舍五入的情况下，则有可能将优惠全分摊完了。

2、第3点中，为什么要以类递进式的方式计算权重？——因为如果不按递进式的方式计算金额（与平行计算门槛不冲突），则可能出现摊负的情况，举例说明：

有A、B两个商品，A商品原价3000元，B商品原价100元  

其中A商品参加了直降活动，直降1000元

其中B商品参加了满100-50的满减活动 

用户账户内有一张全品类无门槛优惠券，面值1500元   

假如这个用户购买了A、B两个商品

①如果直接以基准价作为分子计算权重，则结果就会出现摊负的情况：

• A商品的基准金额=3000-1000=2000元

• B商品满减优惠=100-50=50元

• B商品优惠券优惠=100/（2000+100）*1500≈71.43元

• B的实付金额：100-50-71.43 = -21.43元（此时应付金额为负）

②如果按第三步的逻辑计算权重，则结果如下：

• A商品的基准金额=3000-1000=2000元

• B商品满减优惠=100-50=50元

• B商品优惠券优惠=（100-50）/（2000+50）*1500≈36.58元

• B的实付金额：100-50-36.58 = 13.42元（此时应付金额为正）

3、第5点，最后一个sku的优惠金额=优惠总额 - 其他sku优惠之和，这是的原因是为了所有使sku分摊到的优惠金额相加等于总优惠，因为在计算过程中如果出现除不尽的情况，加上四舍五入就会出现每个sku分摊的优惠相加小于或大于优惠总金额的情况。

以上就是优惠分摊计算的方案说明，同样的，这个方案也不是标准的、唯一的方案，不论采用什么方案，核心就是不要让金额计算出现摊负、或者对不上的错误结果。

小结：

规则中心就像十字路口的红绿灯和交通管理员，当车辆从四面八方汇集到十字路口时，规则中心就会启动交通管制，指挥所有的车辆按照正确的道路行驶。

规则中心的核心服务包括：叠加互斥规则、命中规则、实时价格计算、优惠分摊计算。这一章节所述的产品一般没有界面或者只有很少的界面，更多的是后端逻辑和策略，对于初学者而言可能需要一定的相关产品设计经验才能比较容易掌握。我们只记住一点，对于偏逻辑的后端产品，产品设计的核心要点是逻辑自洽且符合业务场景，没有实验，主观体验设计少，因此只需要多花一点时间就能摸透。这一章节的内容不仅适用于电商，对于交易类型的产品都会遇到相关的问题，如果大家碰到类似的产品，可以参考一下。

05  其他系统

CMS、前台、平台活动管理、审核与风控、数据分析

5.1 CMS系统

CMS系统（content management system）即内容管理系统，在不同的领域其产品形态不一样，在电商产品领域，cms核心用于创建和管理活动页面、频道页面、店铺装修等，使用过淘宝后台的同学应该见过店铺装修功能：

主要的能力就是将页面中常见的功能组件化（类似搭积木），通过拖拽的方式组合成一个完整的页面。京东平台的系统叫通天塔，功能也类似。因为cms系统本身是一个非常庞大的系统，通过一小章节无法讲明白，同时cms相对于营销知识体系较为独立，因此本文不做介绍，后续会单独出一篇文章介绍CMS。

5.2 促销在前台的设计

本文只简单探讨一下电商前台有关促销的设计思想，因为知道why比知道how更重要。我们看一下主流电商平台的交易动线中都有哪些与促销相关的设计元素，看看是否可以从中找寻一些共性，基于这些共性，我们再去分析背后的设计思想。

如京东APP在黄金流程中的促销元素：

（图片过大无法正常显示，请用电脑放大查看）

可以看到，京东黄金流程中不同的环节体现的促销元素的重心不一样，如商详页主要体现出单品的价格，用红字高亮并且价格区域有很重的氛围设计，这是在明示用户该商品目前在降价。在购物车中，价格的设计就不再是第一位了，因为购物车是展示的多个意向购买商品，这里就不能再强调单品的价值了，而要引导用户“多买“，因此在购物车环节需要加强总价类活动的设计，可以看到大部分电商平台在购物车中都会着重针对凑单进行设计。提单环节需要加强转化，减少“后悔”，因此提单环节就是使用券、积分、余额等各类虚拟币的环节，这里要方便用户直观的知道我有什么券可以用，我可用省多少钱。最后成单后，为了让用户下次再来，我们需要可以告诉用户订单完成后将获得什么奖品，让用户对平台有一个念想。

小结：

这些与营销相关的系统本文暂不做重点介绍，我们只需要知道营销体系中，除了几大核心系统外，还有一些很重要的系统都与营销相关，对于这些系统的设计，后面会单独出文章专门介绍。

06  总结

以上就是营销中心的主要内容了，再回头看看文章开始提的几个问题：

1. 什么是促销？促销的作用是什么？

2. 不同的促销形式适用的场景分别是怎样的？

3. 营销中心有哪些核心能力和模块？ 

4. 如果让你从0到1搭建营销中心，你知道怎么设计吗？

相信大部分认真研读了文章的同学都有自己的答案了，在此一起总结一下：

1. 什么是促销？促销的作用是什么？

• 促销是指卖方通过对消费者提供短期激励，以诱使其购买某种特定商品的过程。

• 促销是运营工具，作用是帮助运营者完成其对用户的拉新、转化、促活、留存、传播的目的，完成对商品入市推广、销量提升、客单价提高、滞销库存清理的目的。

2.常见的促销场景有哪些？适合使用哪些促销工具？

• 从用户的角度看，有：拉新、转化、复购、召回

• 从商品的角度看，有：新品推广、销量提升、提高客单价、清库存

• 不同的场景需要针对性的使用不同的促销策略，如多买优惠对提高客单价很有效
  
  

3.营销中心有哪些核心模块？如何设计？

我们通过一张全景图来回顾：

最后，还是再强调一下，上述所有有关具体模块的设计方案都不是标准答案，只是在特定历史背景下被验证过可行性。电商发展到现在，形态越来越多样，比如出现了拼多多的无购物车设计、短视频平台的内容电商等，新的业务模式有新的产品形态，新的产品形态也有新的营销玩法和设计逻辑，因此我们的设计思路也应该是发展的、与时俱进的。

如果大家对于拼团模式、新兴的直播电商模式也比较感兴趣，后续可以单独另起文章针对团购或者短视频为主的内容电商做一些分享。

这篇文章大体上涵盖了电商营销系统80%的知识体系，断断续续花了几个周末的时间才写完，写作不易，如果文章对你有启发和帮助，可以收藏点个赞哦~~~

本文由道格森咸鱼王原创发布于PMCAFF，转载请联系作者获得许可，并注明来源。

欢迎关注公众号： @道格森咸鱼王 

早上我给产品助理布置了一个任务：跟踪我们的竞品XXX，特别关注XXX功能有没有什么更新，然后写一份分析报告。到了下午，我就看到他在看“艾瑞咨询”，时不时截图粘贴到word里。

不知道从什么时候开始，“先分析市场和用户，再通过用户体验五要素逐层分解，最后总结”成了分析产品的标准格式。你会发现洋洋洒洒几千字中有关产品的各个方面都提到了，但通读下来又感觉没有实质性的收获，这就是这种模板文章的通病——大而全只会浮于表面，在实际工作中也不会这样去分析。而且对于市场和用户的分析，是需要靠实际去调研，靠数据去支撑的，直接摘取行业报告或第三方提供的数据是毫无意义的。

本文是根据笔者多年实际工作经验总结而成的竞品分析方法论，希望能够纠正产品新人对竞品分析的错误认知并且能够为其提供思路指导。全文包括以下六部分内容：

一、概述

1、什么是竞品

关于竞品有一个非常广泛地定义，即所有值得参照借鉴的产品都是竞品。比如我们要做线上考试系统，除了选择市面上已有的考试软件，还需要参考试卷、自助阅卷机、金属探测仪、信号屏蔽器等考试相关的产品。所以，竞品不是简单地选择几样相同或类似功能的产品，而是需要透过功能找到用户的本质需求。凡是能满足这类需求的所有产品、实物、服务等，都属于竞品的范畴，需要产品经理进行分析和参考。

2、竞品分析的作用

无论我们处于哪个行业，都要了解一下目前行业内是不是已有类似的产品了，如果有，其现状如何？哪些值得借鉴，哪些需要规避？通过分析，我们可以借鉴成功经验，少走弯路。

对产品来说，竞品分析有助于：

· 通过了解竞争对手的产品和市场动态，为制定产品战略、布局规划提供参考依据

· 通过竞品取长补短，有助于帮助自身产品实现反超

对产品经理来说，竞品分析有助于：

· 对于不熟悉的领域，通过研究竞品的设计方案为我们提供思路指导

· 对于无所措手足的方案，通过研究竞品选择最优策略

· 久而久之能够提高产品规划设计能力，培养产品感

3、竞品分析的一般流程

一般来说，竞品分析的流程包括：

· 竞品收集与选择

· 竞品体验与拆解

· 竞品分析

· 总结报告

竞品分析贯穿产品始终，根据不同的分析目的，拆解和分析过程又可整合为初步竞品分析（细化至功能）和详细竞品分析（细化至逻辑），详见第三四部分内容。虽然文中用了大量的篇幅介绍初步竞品分析，但实际上，详细竞品分析才是产品经理的工作日常。

 接下来，我会对竞品分析各环节逐一进行详细地讲解。

二、竞品收集与选择

竞品收集指的是通过各种方法获得可以借鉴的产品及产品信息，该过程包括三个步骤：

· 建立竞品选择框架：通过“用户场景方格”对竞品进行分组

· 竞品搜集：通过四种方式获得更多可借鉴的竞品

· 竞品选择：根据不同目的建立竞品选择的维度

· 竞品信息获取：通过各种渠道获取竞品信息

1、建立竞品选择框架

首先我们要树立两个跟竞品相关的正确认知：

· 用户需求是用户和场景结合的产物

· 满足用户需求的所有产品、实物、服务等都是竞品

据此，我总结出了用户场景方格这一框架模型，用来对竞品进行分组，并制定分析策略。

a. 什么是用户场景方格

以”用户“和“场景”为维度建立二维矩阵，坐标轴的远近代表重合度的高低，因此可以把矩阵划分为四个方格：

· A核心竞品：竞品的目标用户和使用场景与自身产品高度重合，需要重点关注

· B同类竞品：竞品的使用场景与自身产品高度重合，但目标用户有区别

· C相似竞品：竞品的目标用户与自身产品一致，但使用场景稍有区别

· D参考竞品：竞品的目标用户和用户场景与自身产品重合度较低，可以作为设计参考

PS：”同类竞品“和”相似竞品“仅通过命名不易区分，主要是暂时没想到更好地词语进行描述，读者理解其意即可。

b. 怎么使用用户场景方格

前面说了竞品可以是产品、实物或服务，在搜集完竞品后，我们将其放置于对应的方格中，并根据产品形态进行归类，如产品、实物or服务，这样就可以得到一个全面的竞品分布画布。以针对大学生的常态化线上考试系统为例，简化的竞品分布如下图所示：

有了这张竞品画布，相当于在战场上有了各敌对势力的兵力分布，即可用于规划战略方向，又可为制定战术计划提供依据。

2、竞品搜集

怎样能够保证画布中不同形式的竞品能被我们全面得搜集到呢？结合以往的工作经验，我总结了以下方法：

a. 通过第三方渠道寻找竞品

· 软件市场：包括APP和PC端应用市场，如Google play、AppStore、小米应用商店、华为应用商店、华军软件园、软件管家等

· 专业网站：聚合优质信息与人群的新媒体平台，如虎嗅、36Kr、芥末堆、果壳网、最美应用、GitHub等

· 行业调查报告：能提供行业数据、行业研究的网站，比如百度数据、七麦数据、艾瑞网等

· 主流搜索引擎：如百度、Google、360搜索等

b. 通过用户访谈寻找竞品

如果我们能够接触到用户，可以利用用户访谈的机会向他们了解遇到的问题以及通过什么样的方式或产品解决这些问题的，通过该方式普遍能够快速准确地找到核心竞品。还是以大学生常态化线上考试平台为例，我在跟学校老师沟通时，他们就直接道出了以前接触到的考试软件，并且依次指出了它们的问题，以及期望的需求。

c. 通过分解思维寻找竞品

这种方法指的是先分解业务流程，再以每个分解的结果为原点寻找相关的竞品。如线上考试平台按业务流程大致可分解为”组卷-排考-线上考试-阅卷-成绩公布“五个环节，可以分别对每个环节寻找竞品：

这种方式的好处是扩大了竞品的选择范围，增加了找到可参考竞品的几率。

d. 通过发散思维寻找竞品

· 发散产品形态：很多时候我们会将竞品限制为一个软件，但实际上任何有借鉴价值的对象（产品、实物、服务等）都应该作为竞品，因此从该维度发散是刻意地帮助我们打破惯性思维，站在更高的视角审视各个形态的竞品

· 发散使用场景：通过扩大用户的使用场景让我们得到不同方向的设计启发，如从”常态化考试场景“发散到”四六级考试、公务员考试、研究生考试“等，从而寻找到更多可借鉴的产品

· 发散目标用户：通过扩大目标用户让我们得到不同方向的设计启发，如从”大学生“发散到”小学生、高中生、职场人士“等

· 发散其他行业：通过寻找其他行业优秀的解决方案，也能够有效地拓展竞品范围，如可以参考驾考行业中身份认证、在线作答、自动批改、成绩公布、补考等一系列成熟的考试方案

最后对竞品搜集的常用思路和方法做一个汇总，如下图：

PS：别忘了将搜集到的所有竞品填入竞品选择框架（用户场景方格）中。

3、竞品选择

一般来说，搜集到的竞品都需要产品经理进行了解，但毕竟人的时间和精力有限，我们只能选择部分竞品来深入研究，但是要遵循四个基本原则：

· 所选择的竞品需要涵盖ABCD四类

· 所选择的A类竞品需要涵盖所有形态（产品、服务、实物等）

· 所选择的竞品需要有代表性，在该类中处于领先地位

· 在可能的情况下选择得越多越好

除了上述原则，还要根据不同的分析目的，从不同维度挑选排名较前的竞品（为了便于举例，下文专指互联网产品）：

a. 目的：了解竞品动态，为战略规划提供决策依据（初步竞品分析）

该目的下，重点关注竞品的发展方向，要挑选行业头部产品进行分析和学习：

· 市场份额：选择市场占有率高的产品，如要研究社交领域，微信是绕不过去的竞品

· 公司背景：有很多后来居上的产品，如当年的百团大战，对商家的扶持、对客户的补贴，都是靠着资本的驱动才能够完成的

· 市场口碑：不一定要选择用户口碑好的产品，竞品口碑不好的点恰恰是我们的机会点，如钉钉和飞书

· 热门程度：如果某个竞品在某段时间突然热度大增，也需要单独拿来研究

除了关注同行业，还要警惕其他行业的竞争者，有句话说得好”干掉你的不是同行，而是跨界“，这样的例子在如今的商业环境中比比皆是，小米挑战晨光中性笔，外卖挑战速食方便面、智能手机挑战单反相机、中国邮政挑战星巴克……我们不仅要居安思危，不断提高产品核心竞争力，还要在在危机中育新机，于变局中开新局。

b. 目的：了解功能逻辑，为方案设计提供详细参考（详细竞品分析）

除了初步分析需要考虑的四个维度，此目的下还要从功能维度进行筛选：

· 功能匹配度：选择功能匹配度高的竞品。注意不是功能越多越好，而是和我们所需的功能越匹配越好。比如要设计”随机组卷“功能，就要有目的地选择有该功能的竞品

· 功能亮点：是否有特色的功能。如果竞品的功能都千篇一律，那么选择其一即可

4、竞品信息获取

选择好要深入研究的竞品后，接下来就是全面收集有关该竞品的所有信息。

理想情况下，可以向公司内同类业务的产品经理请教，获取他们已有的竞品资料。对于大型企业，还会设立专门分析市场情况的部门，比如我的上家公司设立了一个”情报分析部“，需要什么竞品可以直接找该部门申请相关资料，相应地如果遇到了新的值得借鉴的产品，也可以向该部门提出研究需求。

但是大多数情况下，竞品信息获取工作都得靠产品经理自己完成。下文提供我在工作中常用的几种B端产品收集信息的方法，C端产品也同样适用：

a. 寻找官方出品的信息

通过竞品官网、发布会、宣传会、销售材料、QQ群等官方渠道获取信息。这种方式的好处是信息较权威，但要注意甄别水分，很多B端产品为了吸引客户，会包装概念（其实是新瓶装旧酒），或者是虚假宣传（其实还没实现）。

b. 从第三方渠道获取信息

与竞品搜集的方式类似，可以从专业网站、行业调查网站和搜索引擎中进行搜索。另外也可以从竞品的合作客户入手，比如有些企业会将竞品的使用手册、宣传视频等信息发布在公众号内，吸引有关人员查看学习，也有些用户会将竞品信息分享到抖音、小红书等社交平台。

c. 注册/申请试用

有些产品开放注册，可以方便地进行体验。但大多数B端产品都需要申请试用，这时可以伪装成潜在客户与其销售人员沟通，套取一些基本信息，最终目的是能够要到体验账号。当然了，在沟通前一定要做好准备，包括伪装企业的资料及背景、沟通话术等（做好对竞品销售人员的用户研究），要让对方销售相信你是确实遇到问题了，且正在寻找能够解决问题的人。现在销售人员的防范心理都很强，特别是行业头部企业，都会在这方面对售前人员做专门的培训。

PS：关于申请试用竞品的经验，可查看我的另一篇文章《产品经理“骗”取竞品资料的18个套路》

d. 向合作客户了解

销售/市场等一线人员在跟客户沟通时往往会获取到竞品的信息，比如客户经常会说”XXX产品有这个功能，你们有吗“，如果是有经验的一线人员会顺着这个问题深入询问”您能详细描述一下这个功能吗，在什么情况下会用到，我好找我们产品中类似的功能给您介绍“，这样一来一回就能摸清个大概。

如果有关系较好的合作客户，也可以利用销售与其的关系拿到竞品资料（因为B端客户不可能只接触一家服务商），甚至可以利用合作客户的身份直接联系竞品获取资料（事后别忘了表示感谢），不过这种方式过于依赖一线人员，属于没有办法中的办法。

至此，我们就完成了竞品的收集与选择，再次总结一下我们的输出：

· 一个全面的竞品分布画布

· 根据分析目的从各方格中挑选出的几个有价值的竞品

· 通过各种方式获取竞品的详细资料

我们永远也不可能将竞品的信息收集全面，但要学会在信息不完整的情况下做出分析。

三、初步竞品分析

定义：初步竞品分析是对竞品的前情和现状进行研究后做的宏观性分析

目的：了解竞品动态，预测其发展趋势

好处：有利于我们制定有竞争优势的战略计划和产品架构

场景：产品规划

核心：研究今天、了解昨天并预测明天

初步竞品分析需要衡量以下方面：

· 产品定位：通过分析竞品的定位，从中找出差异化的竞争机会

· 收费方式：分析竞品靠哪些方式赚钱，有没有值得参考的地方

· 产品架构：逆推竞品的业务流程和产品结构，同时预测变化趋势

· 用户体验：借鉴能提高用户主观感受的设计方式

· 产品功能：做到人无我有，人有我优

1、产品功能

a. 研究今天

最直接有效的方法就是对现有竞品进行功能拆解，即在体验竞品的过程中记录功能列表。下方是一份功能列表的模板，可先按照不同的系统、菜单模块进行区分，再依次罗列所有的功能，期间如果有需要留意的地方，可以将其填到备注中。

一份完整的功能列表，可以帮助我们了解到功能全貌，最重要的是通过这一过程，我们一定能发现竞品的缺陷或亮点。

如果没法体验到竞品，可以通过使用手册、操作视频等资料倒推产品功能。这也是产品经理需要掌握的基础技能之一——看到一个前端功能就能联想到背后一系列的系统支撑。比如一个交易订单的生成是靠商品系统、库存系统、营销系统、风控系统、支付系统等协同完成；一份成绩报告的背后有着组卷系统、阅卷系统、数据服务、考生系统等共同支撑。

其次还需要留意以下两点：

· 基于初步竞品分析的目的，我们只需全面地记录功能即可，不必深究功能背后的规则

· 注意记录功能列表对应的竞品版本，以便后期进行对比

b. 了解昨天

功能列表是竞品的”果“，我们还要探究是什么样的”因“造就了这样的果，即了解竞品的历史迭代记录，试图找到一些发展规律。

如果竞品有App的话，可以直接在“七麦数据”中搜索，十分方便。

但如果是B端竞品，还没有一个渠道能汇总历史版本，只能靠产品经理自己记录。而且只有少部分产品会在更新时发布更新内容提示，大部分都没有，这就又增加了难度。面对这种情况，只能尝试从其他资料找到一些蛛丝马迹，如官网的发展历程、用户使用手册的变更、QQ群中的官方消息等。

假设我们现在已经拿到了竞品的历史迭代信息，接下来就要利用时间轴进行梳理。绘制时间轴的形式不限，可以是excel也可以是图例（建议采用excel，便于后续数据分析），但都需要包含版本、更新时间、更新内容（如果是无意义的更新内容可省去，如修复已知问题，优化体验）。

可别小看了这个迭代记录，我们能够通过它获取很多有用的信息：

（1）纵向分析：

可以对比同一竞品历年的发版次数、同一模块下功能的更新频率等。以发版次数为例，网易云音乐iOS版本2021年共更新48次，平均每周1次，最多的是6月份更新过6次，2020年共更新38次，平均1.5周一次，最多的是4和9月份更新过6次。我这里只做了数据罗列，其实有很多值得深挖的地方，比如更新频率这么高？4月份因为什么导致两年都更新得频繁？2月份更新的少是因为过年吗？等等这些都需要结合当时的更新内容（体验优化/新增功能/改版）、外部环境因素（政策/节日/公司动态）等进一步分析。

（2）横向分析：

还是以发版次数为例，下图是2021年网易云音乐和QQ音乐iOS版本的更新次数的对比，能看出来QQ音乐明显更新频次要比网易云音乐低，这是为什么呢？为什么7月份QQ音乐会比网易云更新的多？等等这些疑问都需要再次结合当时的更新内容、外部环境因素进一步分析。

PS：写到这我担心由于这个例子太简陋，让大家误认为通过更新次数就能得到有用的分析，其实不然，更新次数只是一个的切入点，就像分蛋糕，可以对半切、可以十字切，也可以根据蛋糕上的草莓分布去切，更新次数就类似于蛋糕上的草莓。当然了，也不是每次分析更新次数就能得到有价值的信息，就像草莓不一定都是有规律的摆放。

c. 预测明天

了解了竞品功能的现状和发展历程，最重要的就是预测竞品的迭代方向。为了便于分析，我们可以将功能列表和迭代时间轴进行整合，形成竞品功能迭代画布，下图是示意图：

有了这个画布，我们就能清晰地看出竞品在某个时间段的关注点，为预测其下一步的计划提供基础。

还是以网易云音乐为例，在17年3月份上线了用户发布短视频的功能，随后的1年中陆续发布了4次有关短视频的优化，另一方面也在鼓励PGC和UGC。彼时，抖音刚成立一年，快手成立六年。

尽管现在复盘属于开了上帝视角，但若时光倒流，我相信还是能嗅出一丝味道：网易云音乐是要将短视频作为下一个发力点。果不其然，在下一个V5.0.0版本时，网易云音乐进行了大改版，将视频模块单独开辟成一个Tab（现在已整合到云村中了），这次改动在当时引起了很多讨论，我还因此写了一段随感：

PS：QQ音乐好像是到了2018年9月才开始布局短视频的，比网易云晚了一年多（我是通过关键字搜索的，可能不准）

综上，总结一下对于产品功能层面的初步竞品分析：

1. 通过功能列表了解功能全貌，记录缺陷和亮点

2. 通过更新记录了解功能变迁，以更新频率为切入点寻找原因

3. 通过竞品功能迭代画布预测其下一步方向

2、用户体验

俞军老师说过：用户价值=新体验-旧体验-替换成本，那么如何具体描述“体验”呢，我认为用户体验=有用+易用+好用=功能价值+情绪价值。在上一步中我们分析了竞品的功能价值，在此步骤中，我们主要分析竞品给用户带来的情绪价值。

a. 研究今天

《设计心理学3-情感设计》告诉我们可以从三个层面分析产品的情绪价值，分别是本能层、行为层、反思层。

· 本能层

本能层上的情感是产品给用户留下的初次印象，包括logo、主题颜色、界面布局、动效、音效等等。每个产品都会有所区别，比如下图，同样是问卷软件，为什么主题颜色都是蓝灰白？为什么腾讯问卷采用的是左右布局，而问卷网采用的是上下布局？腾讯问卷的logo清晰明确，问卷网的logo为什么没有文字描述，像一个用户头像？类似这些，是这个层面应该考虑的问题。

· 行为层

行为层是用户和产品交互时所体验到的可用性和满足感，包括四个要素：

a）功能性：竞品满足用户需求的程度，详见上文。

b）易理解性：竞品对同一个事物的描述或操作，是否容易被用户理解。比如对于创建好问卷后开始使用这件事，问卷网叫“发布并分享”，而腾讯问卷叫“开始回收”，不知道大家怎么看，回收这个词，在我的认知里代表把东西拿回来，开始把问卷拿回来，让我觉得有点歧义——问卷还没发怎么就要回收了。因此，我们要思考竞品和自身产品的设计是否符合不同经验和文化背景的用户认知和习惯。

c）易用性：遵循以人为本的设计理念，让用户在使用过程中感到舒适好用。比如当用户在编辑问卷时遇到了操作问题，如果使用问卷网，可直接查看使用帮助或联系在线客服，而如果使用腾讯问卷，必须得退出当前的编辑页面，返回首页才可在二级菜单中查看帮助文档。

d）真实感受：互联网产品大多是虚拟的，如果能在用户使用过程中感受到更多真实的体验，会使用户感受到亲切，比如网易云音乐的播放器就做成了唱片机的样子。

· 反思层

反思层是人通过对产品包含的信息、内容、文化和含义的理解与体会而产生的更深层次的反应，类似触景生情。在这方面可以关注竞品中是否有情景故事和人文关怀的元素：

a）情景故事：包括产品本身的故事，比如王者荣耀里每个英雄都有故事背景；也包括产品和用户的故事，如看到年度总结里的数据，会勾起人们的回忆；还包括用户和用户的故事，如”网愈云“的评论。

b）人文关怀：表现在对用户的尊重和关爱，如抖音声音开太大会提醒可能会影响其他人，半夜刷抖音会提醒早睡，还有苹果的旁白功能，展现了对视障用户的关爱。

b. 了解昨天

大部分产品在用户体验层面的更新都不会准确告知用户，在更新记录中只是用“修复已知问题，优化体验”一句带过，只能靠产品经理持续跟踪来发现。而且用户体验也不是总是往好的方向发展，也有迫于商业化需求变得越来越差的，比如XX网盘的限速。

在发现变化后，需要思考为什么要变化？属于哪一层次的哪一类？能够提升哪类用户在什么场景下的体验？相比之前的方式，用户体验真的变好了吗？为什么要在这个时间段优化该体验？……

以360导航为例，从本能层看，新版通过颜色将搜索区域进行了区分，比旧版更有层次感，但是下方区域，由于包含不同效果、尺寸的组件，显得比较凌乱，让人抓不住重点；在行为层上，新版弱化了第三方链接入口，突出了图文内容，以吸引更多用户点击，同时做的人性化的一点是保留了新旧版本的切换，让不同使用习惯的用户都能够找到喜欢的方式。

c. 预测明天

用户体验涵盖的范围很广，其变化往往伴随着功能、定位、商业等其他方面的变动，并需要结合本能层、行为层、反思层综合考虑。这里可以简化为对体验竞品过程中发现的缺陷预测优化方案即可。

综上，总结一下对于用户体验层面的初步竞品分析：

1. 通过本能层、行为层、反思层分析竞品体验上的优缺点

2. 通过持续跟踪了解体验变化并分析原因

3. 针对现有缺陷预测优化方案

3、产品架构

a. 研究今天

产品架构不是功能的叠加，而是业务流程和数据流向抽象的一种表现形式，研究竞品的产品架构能够帮助我们梳理产品思路，把握竞品的发展方向。

具体的绘制方法可以参考我的另一篇文章《手把手教你用“DDD”的思维构建产品架构》，这里不再赘述。不一样的是，这里是完全通过竞品的功能逆推出的产品架构，甚至有时功能都没有办法体验到，只能通过现有资料去推测“黑盒”的结构，虽然结果肯定不准，但这一步骤绝不能省略。

PS：产品架构和产品功能的关系类似于房型和家具的关系，我们可以回想一下第一次去别人家参观的场景，肯定会先观察几室几厅、面积多大，然后才观察房间中的家具装饰，这符合人类的思维习惯。所以在理解竞品时，不能只着眼于功能，产品架构能够帮助我们更好地理解功能的来龙去脉。

b. 了解昨天

产品架构一般不会进行大的变动，如果进行了升级，说明现有的架构模式已经承载不了未来1-3年的发展，我们要通过这个过程思考竞品升级的WHY、HOW、WHAT：

· 为何升级：架构升级是为了让新架构更符合战略发展，可能是有新的业务场景，可能是现有架构太臃肿不灵活，也可能是新技术的更新迭代

· 如何升级：如何在不影响原有业务正常运行的情况下，逐渐替换老的架构

· 升级了什么：根据不同的升级原因，找到具体的架构变化

c. 预测明天

竞品架构难以预测，但可以对竞品的发展动向略窥一二。再前面的内容里，我们都是以局外人的视角看竞品，可以比较客观地评价竞品哪些地方做的好，哪些地方做的不好，而当我们要预测竞品具体要如何发展时，就不能再用局外人的眼光了，因为缺乏“共通性”的思考只是我们的YY。应该把自己放在竞品产品经理的位置上，结合已有的分析，设身处地地去想几个问题：

· 产品的核心竞争力是什么，要怎么构建好竞争壁垒（找准内核）

· 现在产品好的方面有哪些，不好的地方有哪些（明确现状）

· 我作为它的产品经理，未来3个月要着手做哪些优化，为什么（近期目标）

· 围绕现有的业务/场景还有哪些可拓展的方向（发现机会）

· 在以后的一年中，我要怎么规划产品的走向（长期目标）

根据持续对竞品的追踪来验证以上预测是否正确。通过此方式也可以不断提高产品决策能力，培养战略思维。

综上，总结一下对于产品架构层面的初步竞品分析：

1. 通过产品功能反推产品架构图

2. 思考竞品架构升级的WHY、HOW、WHAT

3. 通过角色扮演预测架构发展

4、收费方式

成熟的收费方式无非几种：C端产品主要是核心功能免费，利用流量变现、虚拟产品、增值服务、抽佣金等方式盈利；B端产品包括定价、分销和交付等方式。最主要的区别还是体现在项目和定价上，需要我们详细了解。以阿里云和腾讯云对象存储服务为例，虽然都是存储服务，但是其中的资源包类型、地域等收费项目和单价各有不同，也就造成了最终价格的不同。

a. 研究今天

收费方式跟产品功能迭代息息相关，比如从抖音开始有直播功能后，打赏就成了新的一种收费方式，所以可以在竞品功能迭代画布上继续完善收费模式信息：

如果你再研究得深入些，你会发现同样都是收费功能，有的功能是按次收费，有的是根据版本买断，有的是按时间收费，有的是几种方式的结合，同一产品不同功能的收费策略反映了其对成本和需求的考量；同时，不同的产品对同一个功能的收费策略也会不一样，比如产品A使用一次该功能收费2元，产品B只收1元，这反映的是竞品之间的差异化定价和技术的竞争。

当然收费方式不应局限于功能层面，还要从服务、内容等纬度思考如何扩大商业价值。比如下图是一个线上考试系统的考试内容服务，我之前一直局限于功能收费，看到了这个图才茅塞顿开，重新构建了我们产品+服务+内容的收费方式，同时顺着这个思路还拓展了硬件服务。

PS：产品的收费方式信息可以参考竞品信息获取那一小节内容。

b. 了解昨天

收费方式不是一成不变的，会根据实际情况作出调整，大到收费方式的新增或更换，小到某一收费策略的变更，都体现出了竞品在一个阶段的价值主张、核心能力、收入来源、成本结构、用户细分和竞争策略，值得深入研究。

· 价值主张：具有用户价值的产品自然拥有商业价值，不过价值也是分高低的，这基于产品的定位，如线上考试系统能给客户带来的最大价值就是能杜绝考试作弊，如果某个产品不具备防作弊功能，哪怕免费也不会有客户用，相反的具有防作弊能力的系统就有极高的议价权

· 核心能力：围绕产品核心竞争力发展更多收费项目，如QQ音乐拿到了周杰伦的版权，就可以要求用户付费听歌；又如公司在全国各地都有办事处，那么就可以发展线下驻地支撑服务

· 收入来源：改变用户的付费方式，如著名的笔记软件Notability由买断制变为订阅制，一方面是为了获取更多利润，另一方面也降低了用户的入门条件，作为Notability的竞品要不要也跟随，还是要根据自身的实际情况分析

· 成本结构：根据成本变化调整价格，如油价上调，腾讯0.01元中标

· 用户细分：根据不同的用户群调整收费方案，如蓝湖根据企业规模分为免费版、初创团队版、企业版、企业内网部署版，假如哪天新增了大型跨国企业版，就说明这类型企业的需求比较特殊，需要单独调研

· 竞争策略：为了在直接竞争中获得优势而进行的临时性调整，如降低单价、增加套餐内次数、买一年送半年等

c. 预测明天

收费方式虽不是一成不变，但也不像版本更新那么频繁，预测竞品的收费方式，需要综合考虑内部因素和外部因素。

内部因素包括：

· 企业能力：判断企业是否能长期运营下去，包括企业背书、融资情况、老板影响力等，如美团从百团大战中活下来的大部分原因是资本的支持，使得补贴一直持续，用户一直留存

· 技术实力：技术实力强的团队可以达到降本增效，提高核心竞争力，如摩尔定律

· 产品定位：针对目标用户不同的需求搭配合理的收费方式，如考试星从考试平台升级成了培训考试平台，相应的收费方式也会进行升级

· 运营活动：以往的节日折扣、运营活动，如快到国庆节了，竞品去年打了8折，今年估计也是这个折扣范围

· 功能迭代：功能迭代与收费项目息息相关，如我们上线了一些竞品没有的功能，可以用于收费

外部因素包括：

· 市场环境：包括政策环境、法律环境、经济环境等，如双减

· 竞对动态：其他竞争对手的动态，如其他竞品普遍降价了5%，预计该竞品也会降价

综上，总结一下对于收费方式层面的初步竞品分析：

1. 通过收集信息了解各竞品收费方式（产品、服务、内容、硬件等）

2. 通过完善后的竞品功能迭代画布深入研究产品功能层面的收费差异

3. 通过比对收费方式的更新内容分析竞品的价值、能力、收入、成本、用户和竞争策略的变化

4. 结合内外部因素综合考虑未来收费方式的变化

5、产品定位

a. 研究今天

产品定位就是回答帮助哪些用户在什么场景下解决哪些问题。往往可以从产品slogan、官网、官方资料中总结出。

不过这样还是太笼统，产品定位的核心是找到差异化，用户的差异，场景的差异，解决问题的差异……世界上没有两款一模一样的产品。比如同样都是定位为短视频平台，抖音、快手各有不同；同样都是协同办公软件，企微、钉钉、飞书各有侧重。经过以上对功能、体验、架构、收费的研究，我们能更容易找到竞品独特的地方。

b. 了解昨天

早先导航网站的定位是“网址簿”，上面汇集着各种类别的网址，随着人们获取信息的渠道不断增多，网址不再是用户最终目的，网址中呈现的信息才是，于是导航网站纷纷从“网址导航”变为“信息导航”，增加了第三方的新闻、小说、游戏、购物等内容。再后来，企业为了吸引、留存、转化流量，开始涉足内容平台，导航网站又一次升级为“内容导航”，为自家内容产品做引流。

从上述的例子中我们可以看出，产品定位的变化体现出用户需求的升级和商业需求的拓展。通过研究竞品定位的变化，能够帮助我们把握市场需求，避免在发展战略和发展步骤上的失误，降低风险。

c. 预测明天

要预测竞品的定位变化，就要了解竞品在该领域下所处的地位：

· 领先者：一方面要巩固现有的核心竞争力，一方面要向客户的潜在需求深入，拓展更多业务场景，比如360导航针对儿童用户推出了少年版，同时还要预防竞争对手的挑战

· 追随者：寻找市场、用户、服务、价格等空位切入，利用差异化深入人心，比如拼多多之于淘宝、WPS之于office、去哪儿之于携程……

综上，总结一下对于产品定位层面的初步竞品分析：

1. 找到竞品的差异化定位

2. 找到定位升级的原因

3. 根据竞品不同的地位采取相应的定位策略

四、详细竞品分析

定义：详细竞品分析是有目的性地对竞品某些模块进行全方位拆解

目的：了解产品功能和技术设计背后的逻辑

好处：帮助我们少走弯路，弯道超车

场景：产品设计

核心：达到能倒推出产品需求文档和技术方案的程度

详细竞品分析是产品经理在进行产品设计时经常使用到的，大到几个功能模块，小到一个逻辑的判断条件，都可以成为详细竞品分析的对象，所以这一部分没有固定的方法，但是有一般的步骤：

1. 设立目标：详细分析的目的是什么

2. 制定计划：怎么样一步一步实现这个目的

3. 物料准备：提前准备好分析所有的材料，包括设备、软件、人员等

4. 功能分析：由产品主导，测试协助实施

5. 技术分析：由研发人员主导实施的逆向工程

1、设立目标

设立目标要遵循SMART原则：

· S代表具体的（Specific），目标要清晰明确，所有人都能看懂并达成共识

· M代表可度量（Measurable），目标是可以验证的

· A代表可实现（Attainable），目标不要太高或太低，努努力就能达到最为合适

· R代表相关性（Relevant），要与自身产品契合

· T代表有时限（Time-bound），需要有deadline

比如：在1周内调研竞品的进销存系统，了解并借鉴他们的业务流程和设计逻辑，输出分析报告；利用3天时间深入研究竞品有哪些防作弊功能，并与我们进行对比；花10分钟看看竞品在答题时的保存逻辑，是否可以借鉴；让开发协助调研一下竞品是采用了什么技术来解决上万人同时发卷造成的高并发问题，并给出我们的技术方案。

2、制定计划

为了更好地达成目标，需要提前制定好详细的研究计划和步骤。特别是对于B端软件，这一步必不可省，因为很多功能会有使用次数的限制，有可能你只有一次机会用来研究，所以要好好把握。制定计划有点像是制定测试用例，因为我们要通过遍历各种条件才能推测出背后的逻辑规则。

以我熟悉的教育信息化领域为例，目的是为了研究竞品在线作答时的保存逻辑，包括有哪些保存方式，每种保存方式的机制是什么，简答题是如何保存的，刷新、闪退这种异常情况的保存逻辑是什么，等等，都需要提前计划好。拟完初步的计划后，最好再发给测试、设计、开发等相关干系人，看看从他们的角度有没有要补充的。

3、物料准备

a. 人员

安排好相关人员与你一起测试，比如考试场景需要考生和考官共同配合；有些功能需要研究技术方案，可以叫上对应的开发人员。

b. 资料

准备好相关的文档资料，比如帮助手册、使用手册、宣传PPT、收费项目等，便于需要的时候查看。

c. 软件

根据分析的目的准备所用的软件，比如要研究竞品的技术，可以准备好抓包软件；要研究竞品的无网和弱网策略，需要准备好限流软件等。同时还要准备好截屏、录屏等用于留存竞品资料的软件。

d. 设备

根据分析的目的准备所用的设备，比如所需型号的手机、电脑；录像录音设备等。

4、功能分析

a. 体验

接下来就是一步一步地实施计划了，这里没有通用的方法可言，需要耐心仔细地围绕分析目的去体验竞品。在体验过程中可以根据实际情况对原有计划进行新增或调整，有条件的也可以体验多轮，直到搞透业务的流程、页面的交互、功能的逻辑和数据的流转。

b. 记录

在深入体验竞品的过程中一定要随时记录关键信息，避免事后遗忘，包括流程图、体验结果、关键页面截图等。

c. 分析

设计没有对错，只有适不适合。在详细了解了竞品之后，就要探究竞品为什么要这样设计，有什么优势和劣势，并结合自身的业务决定哪些地方可以借鉴，哪些地方需要摒弃。比如有的竞品在作答时是一个页面展示一道题，在切换题目时触发自动保存，这种方式就值得借鉴，既能清晰展示每道题又保证保存接口不会被调得太频繁（与每选择一个选项就自动保存的方式进行对比）；又如有的竞品在考场开始后，还支持修改试卷，对于已经在作答的同学来说试卷不会变动，对于还未作答的同学来说试卷会显示成最新的，这种方式适用于随来随考的场景，但不适合集中考试。

5、技术分析

不止产品设计，技术方案的设计同样也需要进行详细分析，因为技术方案在一定程度上会影响产品方案。比如上千人同时发卷，每个考生的试卷都是从题库中随机抽取的，竞品是如何做到在短时间内发完所有人的试卷且不出错的；音视频房间是有路数限制的，竞品是怎样做到同时监考上百人的；录制视频时，是采用本地录制然后上传云端还是直接云端录制，等等。这方面主要由开发人员利用逆向工程进行了解，这里不进行展开。

经过以上的研究和论证，我们能够理解竞品的设计逻辑，同时结合自身业务取长补短，达成分析目的。

五、竞品分析报告

不管是初步竞品分析还是详细竞品分析，得到的内容都是零散的，需要进行汇编整理，而整理的最好方式就是输出一份分析报告。好的竞品分析报告不仅汇集了整个分析过程的精华内容，还能够给阅读者启示，帮助他们制定决策。

1、报告的形式

大多数竞品分析报告都是要给上级或客户汇报的，基于易读性，常以PPT的形式呈现，如果是给自己或者团队内部看，形式就不固定了，也可以是Word、Excel、思维导图等，怎么方便怎么来。

2、报告的结构

不管是初步竞品分析还是详细竞品分析，都建议使用总-分-总的结构：

a. 总

先展示分析报告的概述内容，至少应包含：

· 分析的背景和目的

· 选择的竞品信息，包括竞品的名称、版本、产品形态及选择的原因

· 简要描述分析的过程，如果是初步竞品分析，可以说从哪些方面进行的分析；如果是详细竞品分析，可以展示制定的计划

· 总体结论，遵循结论先行的原则，在开篇就把主题论点阐明出来

b. 分

然后将初步竞品分析或详细竞品分析的体验过程和结果分维度展示出来，并且附上你对各维度的分析结论。需要注意两点：

· 结构化：结论先行、以上统下、归类分组、逻辑递进

· 可视化：能用图表就不要用文字，对重点语句进行标注，忌讳华丽花哨的动效，字体字号保持一致，使用严肃大方的PPT风格等等，如果用于重要的汇报，建议找UI进行美化

c. 总

最后再次总结分析结论，并要结合自身产品形成可落地的行动计划，否则就是纸上谈兵。

3、报告的四要素

a. 对比

前面我们已经纵向对比了竞品的变化，这里着重横向对比多个竞品的不同。呈现对比的元素有很多，比如功能对比图、表格、条形图等。

b. 分析

如果只是单纯的记录体验竞品的过程，那这不是一次有效的分析。竞品分析的真正价值在于产品经理对竞品的思考。为什么要这样设计？如果换成其他方式会怎么样？同一个功能，不同竞品为什么有不同的实现方式？为什么竞品没有做XX业务/功能？为什么竞品最近总是围绕XX模块进行更新？等等这类问题，都需要产品经理透过现象分析问题本质。

c. 结论

光有分析还不够，还要给出结论：经过以上分析，哪些地方要学习，哪些地方要优化，哪些地方要新增，哪些地方要改方案。就像向上汇报时，不能只给领导抛出问题，而是要连同你的解决方案一起告知领导做判断。

d. 计划

有了结论还要再进行深化，针对要改进的方向整理出具体的可落地的计划，比如把这些优化点记录到需求池中，根据优先级安排到某一期迭代中，这样也能够提高产品规划能力。

六、其他要说的话

1、竞品分析需要持续关注

在产品整个生命周期中都要持续关注竞品，但我们不可能对每个竞品都进行详细地分析，毕竟要考虑成本收益比，那么如何能够花更少的精力获取到更大的分析价值呢？还记得在我们之前建立过的用户场景方格吗，可以根据竞品所在的方格分类管理：

· 重点跟踪：从A类挑选出来的竞品必须要重点跟踪，大到产品更新，小到每一个功能逻辑都要把他们研究透彻，只有形成差异化，才能站得更稳

· 定时监督：BC类竞品属于潜在竞争者，尽管有场景/用户的区别，但是如果他们想进入我们所在的领域，也不是特别的难。所以对于这类竞品，需要定期关注，做好防御

· 偶尔关注：在有剩余精力的情况下，可以关注一下D类竞品，说不定能从中寻到一些启发

2、做好资料留存

在整个过程中要留存好有关竞品的所有资料，包括竞品原始资料、分析材料等。又由于竞品分析是一个长期的过程，所以还要注意按时间/版本进行整理。

3、取其精华去其糟粕

在特别深入地了解竞品逻辑后，产品经理在设计功能时很容易就陷入“抄”的误区，尽管可以减少试错成本、降低风险，但还算是要提醒大家一定要结合自身的业务取其精华去其糟粕。拿“题库组卷”功能举例，组好卷后，如果修改题库中的题目信息，试卷里的题目要不要同步更新呢？有的竞品会同步更新，而有的竞品不会同步更新，这取决于各自的考试场景。

同时还可以在抄的基础上做一些微创新。比如将登录验证码融入更有趣的方式，像刮刮卡、拼图等。

4、关于竞品分析里要不要做市场和用户分析

在日常工作中，分析竞品时确实不会做市场和用户分析，因为市场分析、用户分析、竞品分析是并列的关系，并不是谁包含谁，各自都有一套成熟的分析方法论。而且对于市场分析，其实是超出了产品经理的工作范畴，在大公司有专门的市场研究部门，在小公司要靠管理层敏锐的嗅觉，产品经理能做的贡献甚少，特别是对产品新人，基础都没打牢，就关注顶层的东西，又没有数据支撑，只能摘录第三方的资料，没有什么意义。

5、对产品新人说的话

我知道你们需要竞品分析作为敲门砖或是产品思维的练手，因为我曾经也是那样过来的——在大学时候为了入行写过几篇竞品分析报告（产品壹佰上还能搜到：手机K歌哪家强：唱吧&全民K歌竞品分析报告、移动电台竞品分析丨蜻蜓FM&喜马拉雅FM&企鹅FM）。但工作后就再没写过，因为我发现工作后的竞品分析远没有那样简单。

作为一个面试官，建议大家不要再套用“先分析市场和用户，再通过用户体验五要素逐层分解”这种大而全的模板了，对我们来说，除了看到你的主观能动性外，没有其他的任何意义。如果实在要写，不如聚焦于某个功能模块做详细分析，比如京东VS淘宝的会员体系分析、有赞VS金蝶关于库存管理的分析，不放过任何细微的区别并找到区别的原因，这样还能提高你的深度思考能力。

七、总结

竞品分析是一件及其费时费力的工作。分析竞品最好的时间是从它的第一版开始，其次是现在。

全文完。