活动是获客、留资、产品服务体验、促进转化、分享激励等运营执行中非常有效的营销工具，可以帮助企业实现客户增长、业务增长。本文从业务定义、业务流程、系统功能、整体架构、周边关系、ER模型、关键应用等全面解析活动运营所需的平台能力。

一、业务定义

企业要实现DTC落地，必须要保障活动的运营能力、运营工具在一线团队落地，原因：

1）活动运营能力对客户增长、业务增长有非常大的正相关关系。

2）活动运营的全过程，牵扯消费者、门店、区域、总部、供应商等组织，链路长、参与角色多、协同难度大，是DTC落地的试金石，即：只有让离客户最近的业务单元-门店-充分利用数字化的活动营销能力，与用户建立连接，高效互动、服务、交易，长期陪伴用户，挖掘和创造用户价值。

活动运营（与创意投放都是一个套路）的核心是5个合适：在合适的时间、合适的渠道，以合适的费用，将合适的活动推送给合适的人群，实现体验与交易闭环（针对C端用户），活动计划、过程与效果、资源、风控的运营闭环（针对运营人员），活动收入、活动权益发放、成本分摊与结算、活动费用结算、活动结果奖励的财务闭环（针对财务人员）。—没有碰到钱，你就是个中级产品经理。

从产品角度，活动可以分为3大类：社区活动、营销活动、促销活动。三者的区别如下：

活动玩法：

• 活动：不同类的活动底层模型不同
• 玩法：基于某个活动的不同玩法，即底层模型相同，而上层呈现、参与方式不同。比如团购活动，底层是促成交、修改商品交易单价，其玩法有普通拼团、团长带团、拼团砍价。

活动执行渠道与投放渠道：

• 活动渠道：活动的执行渠道，比如线下体验活动，活动渠道就是门店。
• 投放渠道：将活动投放到多个媒体，为线下活动导流，媒体就是投放渠道，仅负责流量。

3类活动在整个营销服平台中的价值定位，如下图中的社区/营销活动、促销玩法（以汽车行业为例）：

二、活动主流程

活动全过程中的要点：

• 活动发起方：品牌总部、区域业务组织、门店、消费者
• 活动参与方：消费者、门店、品牌总部/区域业务组织、供应商
• 活动形式：独立活动、联合活动
• 活动审批：涉及活动审批（活动能不能发起）、权益审批（权益发行审批）、费用审批（费用项目、费用额、费用分摊）、上架审批（APP/小程序/媒介投放/生态合作）
• C端参与方式：报名/报名审批、订阅、直接参与
• B端用户参与要求：明确活动邀请、参与、转化目标
• 关联线索：社区活动、营销活动的留资、促销活动的转化都要考虑是否与线索关联（适用于汽车、房产等高单价商品）

三、系统功能

• 活动管理：支持一个营销主题下的多个活动（联动）多波次开展，从活动配置到活动审核，以及发布、中止、结束。
• 权益费用：提前发行活动权益，并配置到活动中。对所有费用项目做预算，并提交活动审核。
• 活动执行：活动发布后，C端用户通过直接参与、报名签到、订单支付等方式参与到活动中。
• 费用结算：活动结束后，记录活动各项费用的实际支出，发放权益给C端用户，所有费用按照比例产生分摊明细，提交结算单、B端各方记账处理。
• 活动效果：分类分析活动量、活动参与量、线索贡献、转化等，并分析活动ROI、渠道贡献，帮助运营人员分析活动效果，总结针对哪类人群的哪类活动在哪个渠道效果更好。

四、整体架构

活动中心是整个营销服平台中非常重要、复杂、灵活的业务系统，核心部分由通用能力、活动模型、数据服务构成。在关键应用部分会针对3大类活动各类活动的基础模型和玩法配置进行说明。促销类活动涉及交易的促销计算引擎等，在订单部分说明。

五、周边关系

活动中心的价值定位决定了活动中心与营销服平台大部分业务系统发生关联，因此在活动中心的整体设计上就需要考虑好与各业务系统的边界和协作关系。

六、ER模型

各类活动、联合活动，都可以配置权益、活动商品，供应商分摊活动费用，投放到不同渠道上，部分活动有专项的费用管理。根据活动效果，有针对B端组织的业务奖励、也有分销激励。联合活动会有门店配额。

C端用户参与活动，会有参与明细，以及按照规则发放的权益流水。

七、关键应用-活动管理

• 营销主题：品牌方总部或区域发起的营销主题，所有活动围绕营销主题展开，比如某品牌的新款产品上市，会发起多个营销活动、促销活动。关键信息有：营销主题名称、活动时间段、关联商品（可多个）、发起方、业务状态、7个管理信息。
• 活动管理：活动从创建、审批到发布、执行、结束全过程管理。活动中配置的权益已发行。使用统一的活动模型，可以基于主流程快速迭代新玩法，丰富营销手段。

1. 活动管理-基础信息

• 活动类型：为方便运营人员快速创建活动，可以将各类活动以icon方式呈现，辅以流程说明，降低使用成本，运营人员可快速应用起来。
• 活动渠道、活动地点：约定活动的最终执行渠道，比如在某场地的新车试驾活动，执行渠道是外展，可以把活动投放到汽车之家、易车网等渠道来获客留资，这个场地就需要明确地址（配合导航）。
• 活动主图、活动介绍、分享图、广告词：是考虑用户浏览体验，以及分享出呈现的内容。
• 活动状态：新建、审批中、已发布、进行中、已中止、已结束、已关闭。

2. 活动管理-活动规则

• 活动总量：有些活动需要限制人数，比如活动地点为40人的会议室，场地有限制。
• 参与次数限制：比如抽奖次数、参与秒杀次数的限制。
• 每单限购：每单的购买数量。比如每人可以参加活动2次（参与次数限制），每次只能买1个。
• 活动预告：需要预告的活动就可以在预告时段内在活动区呈现出来，可设置活动开始N小时前预告。
• 活动订阅：支持用户订阅的活动，在活动报名、活动开始前通过APP消息或微信服务消息等方式通知用户。
• 报名时段：有些活动需要提前报名做活动相关的准备，会限定报名的时间段（早于活动开始时间）。
• 参与人群：可以所有人参与，也可以基于CDP设定的人群来设定哪些用户可以参与活动。比如必须是车主才能参加品牌年会。
• 线索关联：可使用活动规则中的“线索关联”来控制是否有表单、提交到线索中心。这种方式适合汽车、房产、家装、教育等重产品和服务体验的高单价商品，需要线索来跟进。线索上的商品来源于活动商品，可关联多个，但仅有设定线索的商品才会创建线索。
• 活动商品：参加活动的商品，可针对每个商品设置活动数量、关联到活动库存。活动商品可以不限，也可以指定，也可以指定哪些商品不参与。

关于活动中的商品，有活动商品、分摊商品、权益发放商品：

分摊协议中有分摊商品，区别是：

1）活动商品的范围大于等于分摊商品，分摊协议未包含的商品的营销费用由活动发起方承担。

2）活动商品的数量大于等于分摊商品中的数量，多出的数量的营销费用由活动发起方承担。

权益发放中的适用商品，在范围上也会小于等于活动商品。

• 优惠叠加：用于促销活动中，一般叠加的有活动、权益两类。如果选择了叠加，需要指定可叠加的活动或权益。优惠叠加的计算逻辑会在订单中的促销引擎计算中说明（是因为订单中还有其他一些影响最终结算金额的操作，比如调整单价）
• 包邮：是否包邮，根据商品和活动情况配置。
• 投放渠道：一个活动可以投放到多个渠道上。并可以通过投放计划对接媒体平台获取数据。
• 投放时间：投放开始时间会早于活动开始时间，提前为活动造势。
• 投放渠道：可投放多个渠道上，视频资讯、垂直媒体等，也包括自有的渠道，如APP、小程序、门店终端、产品终端（如车机）。
• 投放审批：投放自有渠道由产品端对应运营人员确认即可，外部渠道需要协同投放团队确认。
• 投放计划：如果有投放平台，通过平台中的投放计划与媒体的投放计划映射。如果没有，则记录媒体的投放计划ID即可，方便数据接收。前提是在营销活动大类下增加一个媒体投放的子类，不需要活动渠道、地点、报名、订阅等信息。
• 投放状态：可通过接口方式，或人为方式来更新投放状态。

活动费用：

• 费用项目：线下的一些活动项目会比较多，比如场地费、招待费、演艺费、运输费、印刷费等。投放费用需关联投放项目。每个费用项目都要关联商家（供应商）。
• 预算金额、实际金额：活动启动前的预算、实际执行后的结算费用。
• 费用凭证：供应商开具的收据、发票类证明实际要支付的费用。
• 活动图片：用于取证活动效果，可取自活动图库中的若干图片。

分摊协议：

• 独立活动：分摊协议有两部分，一部分是商品供应商承担的费用的分摊数量和比例，另一部分是活动费用的分摊金额（需要审批）。
• 联合活动：除独立活动中的两部分外，还会有活动配额，通过设定的每个门店的配额来约定每个门店的活动数量。
• 分摊商品：需要记录品牌、商品。品牌联动类活动，支持不同品类（按品牌）的优惠费用分摊，只需要记录品牌即可。
• 费用分摊协议：活动中的分摊协议解决的是用户参加活动的费用由谁按照怎样的比例来分摊。比如满100减10元，10元是活动费用，需要按照分摊协议拆分成本。活动结束后由活动组织方和费用承担方结算。
• 发行权益分摊：用户参加活动后给的奖励权益，在权益发行时已明确发行成本由谁按照怎样的比例分摊，或按照结算成本结算（按实际核销金额）。在权益消费后，由消费方与权益发行方结算。详细描述见权益中心。

活动参与：

• 活动参与：用户直接参与活动，或加入队伍、加入拼团。设置报名的线下活动，还会有报名审批、线下扫码签到。
• 组队组团：由用户发起组队，或发起拼团。
• 状态：开启订阅的活动，用户订阅后为“已订阅”。需要报名的用户报名后为“已报名”。参与活动的为“已参与”。
• 活动评价：用户参与活动后，部分活动会要求用户给予反馈对活动的感受，可以分活动形式、活动内容、活动组织、服务态度、整体体验等对活动进行评价。

活动总结：

• 活动总结稿：活动完成后，部分活动会发出面向C端的总结稿，进一步引导用户关注、互动，吸引更多用户参加未来的活动。
• 运营总结：活动亮点、经验、教训等运营层面的总结，不断提升活动运营水平，逐步掌握哪类人群适合哪类活动，以及可以推广到其他门店。
• 活动互动：类似内容的互动，会有收藏、点赞、评论、转发。
• 活动激励：由分销激励中心提供相关服务。分2类激励，面向B端和C端。
• 业务奖励（面向B端）：品牌方为激励门店积极引导用户体验产品或服务，会奖励门店，比如试驾一次、奖励门店50元。
• 分销激励（面向C端）：会关联分销激励政策，奖励老带新、员工营销、创客营销带来体验用户（部分业务会关联线索）。

有兴趣的同学可以将3大类活动、子类活动、玩法、发起方、发起形式、以上提到的活动基础信息、活动规则全部罗列出来，并抽象成统一的服务能力。营销主题、联合活动属于基础的活动玩法之上的，也可以梳理下。

八、营销活动

采用产品体验、产品展销、品宣体验等方式来获客或留资，获客采取扫码等方式，留资时一般采用表单来记录信息，与线索关联。

采用亲子活动、公益活动、粉丝沙龙、演艺赛事、自驾旅游等形式，线上线下互动，进一步提升粉丝活跃。线下活动大部分会有报名、签到的环节。

• 带客有奖：分老带新、员工营销、创客营销3类，对应到3个渠道。高单价商品还会分阶段支付奖励费用。
• 老带新：老客户邀请新客户成交，双方都有权益。部分会给老客户发现金，可以通过分销激励的能力与结算中心对接、提现。
• 员工营销：非营销销售线的员工带客成交，给予现金奖励，对接结算中心处理。
• 创客营销：C端用户认证为创客后，带客成交，按照分销政策给予现金奖励，对接结算中心处理。

九、促销活动

丰富多样的促销活动，通过满足消费者占便宜、炫耀、惊喜期待等心理，帮助商家可以有效的拉新、促活、销库存、新品销售、提高客单量/单价。促销活动直接影响的是订单上的商品单价、数量、商品订单金额、订单金额。促销活动与优惠券，都可以分单品、订单类（店铺级、平台级-跨店铺）两大维度。

促销活动的核心内容包括活动配置、活动优先级与叠加、活动权益、成本分摊、退货处理，促销与优惠券、修改单价等相关计算的优先级、计算逻辑，会在订单中心的促销计算部分说明。另外，有平台把促销活动中的权益返还也作为一个活动类别，从业务角度是合理的，但从产品角度，不能纳入活动中的。权益的发放应该是个公共服务，除了活动、订单可以调用外，内容互动、会员任务等等，都可以调用。

促销活动都要设定是单品促销还是订单促销。不同活动类型的活动影响、玩法分类、互斥与叠加如下（罗列常见的促销玩法供参考）：

单品促销活动：

• 影响单价的活动与所有单品类、订单类促销活动互斥，只可叠加订单总额的抵扣券。单价类活动的单价已较低了，再叠加其他活动，利润会很低或亏本。
• 影响子订单金额的活动，与单价、数量类活动互斥，活动子类满折与满减互斥。可叠加单品优惠券（抵扣券）和订单类的活动、订单优惠券（满减或满折券+抵扣券），实现折上折、减了再减的效果，让用户觉得非常优惠。
• 影响数量的满赠活动，与所有促销活动互斥，只可叠加订单优惠券（抵扣券）。满赠也是优惠较大的一类玩法，叠加其他活动，利润会很低或亏本。

订单促销活动：

影响订单总额的满减与满折类活动互斥，可叠加订单优惠券（满减或满折券+抵扣券）。

互斥与叠加是常规打法，可以通过叠加指定的活动或优惠券的方式来控制亏损风险，也可以通过测算来预估利润高低。

预售活动比较特殊，拿出来分享下，其他10多种促销玩法比较常规，大部分平台中都有介绍。

十、预售

预售适用于高价值商品的新品发售，在商品正式售卖之前采用预付定金、享受定金权益，后续再补齐尾款。预售可以分为2或3个阶段，分小订、大定、尾款。

• 小订为小额订金、可取消订单实现退款。小订也会用在盲订业务中，即不告诉消费者商品售价，依据用户的小订来测试市场反应，调整价格策略和交付策略。有些企业还会设定犹豫期，即小订后的某个时间后自动转大定，启动后续的履约流程。也有明确大定或尾款的具体时间。
• 大额定金确认后会执行后续的履约流程，比如生产；如果要退款，就要走较复杂的退货退款流程。
• 尾款支付完成后，即执行发货交货流程。
• 小订、大定、尾款3个阶段都可以配置不同权益，且权益的生效和使用，可以前置约定。比如汽车的预售，大定阶段会赠送智驾体验1个月的权益，而交车后才能激活生效、去体验，还有优惠券等，也可以先发放、某个业务达成后才可以激活。权益的发放、生效、消费规则见权益中心。
• 预售比较特殊，与所有活动、优惠券互斥，不可叠加。

需要强调的是：促销活动与活动权益是2件事，参加活动、用户可即时感知的，而活动权益是参加活动后获得的权益，是未来感知的。

我们可以在活动玩法有返券活动，但产品功能上要分离，不能混为一体，活动可以没有权益，也可以有权益，而且活动权益有很多种，比如参加某活动，可以同时发放积分、成长值、优惠券、勋章等。

2020年疫情加速线下品牌连锁店数字化进程，很多线下连锁品牌开始发力建设线上渠道。今天分享一个客户案例，采用中台建设模式，打通线上和线下渠道，门店每日营业额提升30%-80%，建设数据中台+ai算法指导日常运营，有效降低门店管理和运营成本。

一、客户市场情况

老板是某水果品牌连锁店创始人，门店主要分布在南方某二三线城市，以加盟店为主总计30家，其中两家为老板亲戚开设直营店。

以实惠物美价廉应季款为主打走量，部分进口为高毛利款，加上部分利润款，旺铺日营业额超5000元，门店日均营业额超2000元，门店面积30-60平方左右。

门店主要开设在医院、中大规模小区、商业街附近，以社区门店为主。

因疫情人流持续下降，严重影响每日营收，积压部分货品，水果保存期较短，不新鲜的只能贱卖清仓。

在这个市场环境下，新店拓店计划严重受阻，加盟商投资信心受挫，旺铺营业额下降30%，其他门店下降20%-50%不等，部分门店也开通美团、饿了么等线上门店进行自救，因运营能力和系统问题，效果有限。同行的水果店也不好过，部分关店避免损失处理。

二、客户主要业务诉求

现在急需新的销售渠道，提高营业额，弥补线下人流缺失。通过系统方式降低门店管理成本和货品损耗，统一进行营销活动维护品牌和老顾客。

• 系统要能打通线下erp和线上销售渠道，统一管理商品、订单和库存。
• 门店自建微信小程序商城，让新老顾客都能进小程序下单，减少外部渠道依赖和成本。
• 打通线上新渠道，小程序，线下会员卡信息，统一管理会员信息，进行会员营销
• 实时数据报表，能统计门店营业额，热卖品
• 库存风险管理，新鲜度管理，备货订单管理等

剩下涉及商业机密，不再多说。

三、客户业务诉求分析

从市场情况和客户业务诉求得知，线下人流减少是核心问题，先要从销售端进行发力，首先建设多渠道包括美团外卖、饿了么外卖、京东到家等；提供到店自提，社区团购服务；建设小程序和社群运营，营销活动，会员营销等方式拉新和促活，同时加入充值管理绑定新老客消费能力。

打通新渠道和线下erp系统，减少新渠道商品管理和库存管理成本。

再优化改进供应端，加入数据中台和ai算法等能力，建设门店智能选品订货，库存风险管理，为门店店长减负，由系统智能管理库存，减少货品损耗。

四、客户行业top情况

百果园是国内最大水果品牌连锁门店，以加盟店为主，全国接近4000家门店。建设具备行业标杆一体化新零售体系，拥有从供应到销售整个链路能力。

打通线下门店、百果园app、外卖平台全渠道，最快支持30分钟到家上门和到店自提团购服务。

销售端提供商品、交易、配送、库存、售后、会员、拼团基础功能外，建设零售数字平台，支持营销平台、实时定价、商品推荐引擎、智能比价、销售预测、智能订货、商品计划预测等能力。

供应端提供仓储服务、物流服务、采购管理、品控质检能力、标准化种植平台、种植指导等。

水果产品主要面向中高端市场，高标准和高价是特点。

五、行业解决方案调研

行业内解决方案主要集中在多渠道、库存管理、会员统一、智慧门店、多端商城、大数据这几个方面

• 多渠道建设和管理：一键打通多渠道，解决商品、库存、价格、交易、售后、财务信息同步和管理；
• 会员统一：识别渠道顾客和会员，减少拉新和营销成本，建立顾客和会员画像，识别渠道价值，提升转化和留存，进行会员营销和充值营销；
• 数字化门店：交易管理数字化，线上线下融合打通，技术赋能，数据指导，降低运营和管理成本；
• 多端商城：建立小程序、app、h5自有商城，减少渠道依赖和风险，多端覆盖保持一致；
• 数据+ai：数据大屏，营业日报，销售报表，智能选品，智能订货补货，库存风险预测，损耗预测等
• 门店和供应链：加盟管理，加盟结算，门店管理，采销管理，供应商管理，订货管理等。

通过和老板、总部运营团队、加盟店店长讨论，以及行业解决方案分析，确定了项目建设愿景和预期，采用阶段迭代演进式思想建设开发。

六、项目战略目标

第一阶段战略目标：建设新的销售渠道，重点拉新，打通美团、饿百、京东到家和线下erp和收银台，统一商品、订单、库存、营销活动管理，来单提醒，来单打印等；建立门店运营台账和经营指导，辅助门店店长管理和运营（寻销路）。

第二阶段战略目标：减少库存和损耗，降低门店管理成本，建设数据中台引入ai算法，建设智能选品订货、备货库存管理，销售预测，损耗管理，新鲜度管理。（降成本）

第三阶段战略目标：留存新客维护老客，降低渠道成本，会员营销，运营绩效管理，会员充值管理，小程序营销，微信群营销；建立运营拉新留存绩效充分发挥门店积极性。（谋发展）

第四阶段战略目标：门店管理，加盟管理，费率管理，结算管理，运营管理，绩效考核，数据大屏，指标指导等。

第五阶段战略目标：供应链打通，供应商管理，库存盘点管理，订货备货管理等。

前三个阶段主要建设门店经营和运营能力，后面阶段建设和加强整体品牌和门店管理能力，供应链能力。

七、产品架构设计思路

线下实体店优势离顾客近，店员帮助顾客选购商品促进成交，具备一定执行能力，但缺少运营能力和营销能力；总部运营团队具备丰富运营能力和营销能力，充分发挥门店执行能力和总部运营能力，门店侧保持基础运营功能，强调执行能力，减少管理和运营成本，尽量依靠系统完成日常运营和管理工作。

总部侧建设统一管理能力，加强门店运营、渠道运营、营销运营能力，指导和辅助门店执行各项运营任务和工作。

整个产品架构分为销售渠道端、收银台、店长管理端、总部管理端，其中收银台是从店长管理端简化出来，只用于门店收银台。

销售渠道端属于to c部分，o2o电商系统非常成熟这里不过多介绍。

店长管理端定位是执行侧，产品设计上把运营部分和管理部分都上交给总部运营团队，门店只需要关心如何执行台账和服务顾客，不用参与选品定价备货，维护渠道门店，策划营销活动会员活动等复杂运营事务。

总部运营团队全局管控和包揽所有门店营销和运营事务。

八、功能规划

销售渠道：实体店、美团外卖、饿了么、京东到家、小程序商城

业务中台：门店、商品、库存、价格、订单、配送、履约、售后、营销、优惠券、折扣、满减、会员、权益、充值、财务、渠道、收银台、打印机、来单提醒、收益、erp管理、账号

数据中台：数据报表、营业日报、智能选品、智能订货、智能备货、新鲜度预警、销量预测、库存预警、损耗预警

九、店长管理端功能列表

十、总部管理端功能列表

十一、项目投资预期

采用系统定制模式，每家门店出资一万，品牌出资十万；出资门店第一年系统免费使用，以后每年5000技术服务费；非出资门店（包括新店）每年7000技术服务费。承诺出资门店永不涨技术服务费。

到此项目市场调研，行业解决方案调研，愿景和战略目标，产品架构设计完成，接来下进行第一阶段产品研发，在这个阶段遇到最大难题是美团外卖、饿了么、京东到家产品信息差异导致数据同步等问题，以及如何通过mvp模式快速迭代和验证此阶段产品价值。

附录：SaaS MVP 自查表

分享一个saas产品在mvp阶段下产品自查表，通过自查表补充和完善对saas前期调研和产品设计。

作者：徐小威

来源：徐小威

这里假设公司已经有一定规模用户，已经建立用户画像。

且已经做过需求论证，确定是我们的核心用户群体的需求。

一、确定关键指标——动手之前要先动脑

分析：这个需求的关键点是哪些？如何判断输出的产品方案是合适的？

所以要在产出之前制定针对结果的评判指标。

要最先摆出来关键指标，明确以下几点：

• 用户特征是什么？
• 在什么场景下用户有这个需求？
• 在该场景下，用户使用的关注点是什么？
• 在该场景下，用户的目标是什么？

关于1，不同公司/产品的用户群体不同，特征也不同，则对于产品好坏的评价标准会有差异；比如游戏公司的用户多为青少年、学生族、上班族。而古董、房产类电商产品用户多为中老年。

关于2，用户在什么场景中会有这个需求，不同场景下用户的操作行为和要求也会发生变化；比如打车产品，用户逛街逛累了、到陌生的地方旅游场景下会有这个需求；比如短视频类产品，用户在坐地铁、等车的场景下会有这个需求。

关于3，在不同场景，用户的关注点会有差别，关注点不同则产品设计的重点不同；比如在电商类产品中，用户在浏览商品的场景中，关注点是商品的质量、颜值、价格等信息，而在付款流程中，用户的关注点是地址信息、优惠信息、资金安全、消费风险等功能。

关于4，不同场景用户的目标不同（这里要明确区分用户目标和产品目标，是用户的心理预设目标）；比如电商产品中，在浏览商品的场景中，用户的目标是看到自己关注的、好看好玩、性价比高的产品；而在付款流程，用户的目标是流畅完成购买的操作，并确保资金安全。

在分析并解答这些问题后，对此次功能上线后的数据情况（用户量、日活、月活 ）会有初步的预测。

二、产品方案设计——不是无脑的抄抄

调研市面上是否已有该满足该需求的功能，在百度、贴吧等渠道寻找竞品。

如果已经有独角兽产品，则需要看该产品的用户评论和贴吧口碑。

最终选取口碑较好和独角兽的产品作为主要分析的竞品。

1.竞品分析

罗列竞品的产品关于该功能的产品结构，对比后梳理出共同的功能和差异的功能，即得到“基础功能”、“亮点功能”。

作为“基础功能“，我们的产品必然也要有。并且结合用户的负面评价进行优化。

而“亮点功能”则是各个产品的亮点，是运营宣传和吸引、留存用户的关键；所以我们也要想到自家产品的“亮点功能”。亮点功能的设计就要拿出前文的“关键绩效”，并结合公司已有资源来思考。

完成竞品分析后，脑中已经有了产品方案的雏形。

如果市场上没有该功能的竞品，那恭喜你，你可以做MVP，迭代优化后逐渐做大，充分展示产品经理的能力。

2. 输出业务流程图

工作中很多领导要求直接输出原型图，但是在我的经验中，这步操作很考验产品经理的逻辑能力，因为：

1）做原型图需要在脑中构建出业务流程图，产品结构图，还需要考虑交互设计、界面元素排布等事情；而原型图产出后，就会开会讨论，这个时候发现问题，就不只是产品经理复工，还会耽误大家时间。

2）业务流程图可以把流程展现出来，需要合并和缩短的流程一目了然，为后续功能模块的划分和相同页面的合并（关键页面）设计提供了便利；防止用户操作总是进入新页面，造成研发和设计团队工作量增大的问题。

3）业务流程图可以清晰的梳理、补全异常流程；异常流程的处理也很重要，上线初期会影响产品口碑，看微信的初期用户评价，有很多异常情况的负面反馈，这样就造成团队为了挽回用户快速迭代优化，大量加班。

所以建议产品经理谨慎的输出业务流程图，并反复琢磨；（建议分析竞品也采用这个方法，会受益良多）可以按照流程的层级输出多个业务流程图，某些自己闭环的功能可以另做一张图详细梳理，在主图中直接用模块替代。

3. 输出功能结构图

业务流程图梳理后，会很快产出功能结构图。

功能结构图的关键是各个模块应用边界清晰，防止之后迭代产生新功能时功能归属混乱，造成用户理解困难体验不好。

4. 关键数据指标的设计

在产品设计雏形出现后，需要思考：关键流程和页面埋点的设计。

当然需要先想到需要量化的指标，以及指标的计算方法，然后推理出需要埋点的位置和需要统计的字段。

1）关键节点的统计

根据文初的“关键点”设计数据指标。比如电商产品的成交量是一个关键节点，则该节点的pv、uv、订单量、付款量等数据是需要采集数据；最后根据采集到的数据进行用户质量、产品质量、ARPU等指标的计算。

2）关键流程的统计

比如学习平台的登录注册流程，是拉新指标的关键衡量流程，所以在用户操作的没一步都需要采集，之后做衰减图，分析定位造成用户流失的行为，来优化该位置。

数据量化是产品后续迭代重要的依据，可以量化的展示劣势和科学的提高关键指标，希望大家在产品设计时就开始规划。

5. 输出原型图

根据结构图，区分模块，根据流程图梳理出的关键页面，重点考虑交互的流畅度和元素排布的合理性；其中用户会从多条业务线进入关键页面，所以关键页面需要重点关注。

我的经验是，原型图设计有动态有静态，一般给客户展示（2B）需要做高保真动态原型图。

给团队研发同事看的需要具体沟通和公司的规定，有的研发会喜欢静态+描述的原型图。

6. 输出prd

prd的输出根据公司规定输出即可，有的公司做原型图+逻辑说明就可以，但是有的公司后台的逻辑比较多无法用界面描述，所以会需要prd。

三、产品方案论证——别着急找技术

产品经理拿着方案去找技术，这就走上了一条无法回头的战线，所以要慎重。

下面结合自己的经验，给出此阶段的自检方法。

自检问题：

• 设计的功能是否满足了需求？
• 这个设计是用户的首选方案吗？
• 用户选择使用这个功能有成本吗？
• 这个功能会给用户带来风险吗？

关于1，反思是否完成了设计的初衷。回头看最初的“关键点”中的需求，若解决了用户的需求问题，则通过。

关于2，需求是存在的，但是用户有很多解决办法，不一定要选择你提供的方法；如果用户有更加高效、优惠的方式，则你的用户量就会低于预期。

关于3，不少的解决方案是要求用户使用这个功能，但是没有考虑用户的成本；比如用户需要安装很多软件、插件等，这对于部分用户来说是需要考虑的成本。

关于4，对用户来说，是否有财务、心理、时间、社交的风险，这个时候就需要结合“关键点”中的用户画像来逐个分析风险的情况；相信大家都理解，这些问题对用户来说是会有负面的品牌印象。

四、对接研发——别用领导的态度

在工作到这一阶段，与研发同事沟通也是很多产品经理头大的一件事情。我的经验是：别用领导的态度和研发讲需求。

产品经理心里觉得：我忙乎半天终于搞出来产品方案了，直接输出给他们，他们赶紧干不就完了，为啥老是反问我，搞事情？

然鹅，研发的想法是：我们研发是公司的核心，你产品经理凭啥命令我们，我们为什么听你的？

这样就发现，研发同事并不是不认可你的产品方案（排除产品设计的确实很烂的情况），而是觉得产品经理的态度有问题。甚至有一些产品经理用某个领导说了要做什么来强制要求研发团队。所以团队中研发阻力很大的产品经理就要反观自己在与研发对接时的态度问题。

回到产品经理的初衷：希望产品完美的落地。奔着这个目标，我们可以更加友好的方式输出给研发。结合我的经验，方法如下：

1）讲故事的方式

通之以情晓之以理的声泪具下的描述用户的痛苦、用户的需求多么的迫切，让研发产生同感，由内心产生动力。

2）情商高的给研发展示的平台

产品经理拿着产品成果和领导汇报，而研发作为幕后人员，很少和大领导接触，所以如果产品经理在汇报时，增加篇幅表明研发同事的付出，自然而然的一点点建立与研发的友好关系；当然日常的邮件也要表明研发的配合工作并表示感谢。

当然，在开发过程中，异常情况也是产品经理与研发冲突的一个部分，这里就又要强调业务流程图的重要性了，请大家查看上文。

五、测试与上线前的把关——不要忽略细节

在研发完成后，需要产品经理在一线测试，除了要注意流程是否走通，还需要注意：

• 页面文字、提示语，是否有错别字。
• 冷启动资料是否准备充分。

有可能原型图没有错别字，但是设计师工作很多，没有注意到错别字；而研发直接用工具生成页面，则上线后这个错别字就会出现在用户面前，当然会影响产品的美誉度。

六、数据搜集——比对预期并反思

数据开始时不好也别着急，与运营部门一同发力，协作拉新、促活；数据特别好也别激动，有可能是运营活动做的好。

产品的数据在半年后才能显现，之前数据表现多是运营活动的效果，所以产品经理一定要稳住，多搜集用户评价、维护种子用户，多与第一批用户接触、做用户调研、搜集问题，快速迭代；等到半年到一年，数据表现的才是产品的优劣。

对比预测的数据，思考数据出现差别的原因，反思：

• 自己设计的功能是否有漏洞？
• 是否对用户群体特征的把握不够准确？
• 是否出现了强大的竞品？

到这里，落地的产品方案完成了，可谓路阻且长，行之将至。

产品方案的落地，并不是指产品经理的职责就完成了，建议大家多基于过程思考、基于结果思考，多提有目标指向的想法，自己发力，找到解决方案和优化方案。

如果大神路过，请过目我的思路，如若有激发您的灵感，欢迎留言评论。

作者：宇智波冰

来源：宇智波冰