老铁，快帮我砍一刀 | 砍价项目复盘

对于「砍价」，相信各位并不陌生。你一定收到过这样的消息：

那么，对于产品经理而言，砍价究竟是怎么一回事呢？如何从 0 到 1 做一个砍价让用户参与呢？在这里，从产品执行层面来复盘和总结下砍价二三事。

为什么要做砍价？

• 砍价效率高
  砍价免费得这件事情对用户的吸引力永远比你想象的要大，用户会自发宣传，完成流量裂变。砍价可以理解为变相拉新，当你拉了足够多的用户时，恭喜你，这件商品归你了。
  举个简单的例子：不知道有多少朋友参与过拼多多的砍价。价值 398 元的行李箱，至少需要 300 名以上的好友帮忙砍价才能免费获得。

• 拥抱微信流量
  蘑菇街、京东、拼多多......甚至是前阵子在风口浪尖的抖音，无一不是微信流量中的获利者。作为月活跃用户破十亿的超级 App，熟人社交的主要场景，试问谁不想从中分一杯羹，享受微信带来的流量红利？

• 大家都在做
  唯品会、每日优鲜、享物说甚至是微信小游戏都在用砍价来吸引用户。微博搜索砍价，能看到无数个自发组建的砍价群。小程序开发者在模板消息后台应该都能看到如下图所示的数字，有多少人在尝试砍价这种形式已经不言而喻了。

  
  image.png

如何写砍价方案？

当我们做过市场调研，确定要做砍价之后，这时候产品同学的要开始写各种文档啦～主要由以下几部分组成：

• 砍价产品方案
  用户流程+原型说明。这是我们通常所理解的画原型过程。说清楚用户的操作流程，页面要素说明等。
• 砍价管理后台方案
  前后台产品不分家。砍价的商品从何而来，商品的如何排序，如何上下线商品......我们需要一个后台来进行管理。
• 风控策略
  前几年滴滴刷单的事情是众所周知。在补贴活动中，如何让真正的用户来参与活动，如何鉴别「坏人」，这些都是需要考虑的问题。
• 数值策略
  这是最核心的一部分。举个例子：我这个商品 599 元，好友来帮我砍价。那么这个好友能砍掉多少元？我需要多少好友帮我砍价呢？思路大体是：调研市面产品+结合公司业务实际需求
• 模板消息
  这是唤醒用户的途径。服务号一个月只能给用户发送四次消息，而小程序更是不能主动触达用户。模板消息为我们提供了一个很好的途径主动触达用户。我们可以在用户发起砍价、砍价成功等重要时间点给用户发送消息。但要注意千万不能滥用哦，被用户举报核实后，可是会封禁模板消息的使用呢～
• 数据统计需求
  活动上线后，我们如何判断这次活动是好是坏呢？因此我们需要数据埋点来检测活动效果～
• 客服同步
  任何一个运营活动／产品功能都要考虑客诉的处理情况。什么情况可能导致客诉，客诉进来之后应该如何处理？产品都需要事先考虑并提前周知客服同学。
• 数据效果
  每一个需求做完之后都建议检测其数据效果，并及时周知团队所有成员。

砍价其实是一个比较成熟的功能，市面上有成功的产品可以参照，基本上不会出太大差错。需要产品思考的是，如何设置更多细节去吸引和抓住用户，让用户对你「又爱又恨」。

以拼多多为例，砍价有很多细节设置的非常棒：

1. 分享之后可以再砍一刀
2. 砍价的好友若是一名拼多多新用户，可以帮你砍一大刀（即一下子砍掉很多钱）
3. 发起砍价后的 24 小时倒计时
4. 直接在页面显示可以帮砍的好友（若你和好友曾互砍过，拼多多会认为你们是好友，在下一次发起砍价的时候，引导你再去分享给该名好友）
5. ......

项目复盘

我踩过的坑，现在写出来，希望你们不要再去踩。

1. 产品需求的频繁变更和补充是一颗定时炸弹💣
   感恩项目组的研发哥哥们对我的宽容。在需求评审之后，我的各类文档至少改了有 200 次，有些是「趁火打劫」加需求，有些是考虑不周补充说明......但事后回想，如果这些细节能够在一开始就想清楚，大家在开发过程中都能轻松不少。特别是上线日期已确定的情况下，需求的频繁变更是一颗定时炸弹。
   需求变更如此频繁其中很重要的一点是在撰写产品方案时花了过多的时间考虑页面流程，没有仔细思考商品的后台逻辑（事实证明，后来的需求变更主要集中在后台）

2. 时刻关注微信的最新动态
   为什么会有这一点呢？是因为我们做的项目是基于微信环境的，搭建在小程序上面。微信爸爸的每一次调整，对于微信开发者都是一次新的机会和挑战。
   举个例子：微信在 4 月份时修改了客服会话逻辑，需要用户主动发送消息才可以进行回复。这个会直接影响到小程序中引导用户关注公众号的流程变动。产品需要去思考，在这种形式下，是否需要换种形式或舍弃这个功能。

3. 每一条数据都至关重要
   在项目刚开始时，我一直认为只需要关注几个关键指标即可。比如砍价参与人数、成功人数、分享人数...等等。但是后来发现，其实每一个指标都有至关重要。我们需要从多个维度来发生分析。尤其是在数据发生波动的时候，你会开始感激当时记录了每一个数据的自己。

4. 和运营同学充分沟通
   其实这是一个强运营的需求。无论是需求的开发、上线、迭代都需要运营同学的深度参与。开发时，需要运营同学一起设计页面文案。上线时，需要运营同学设计商品方案，运营同学更是会在迭代的时候提出早期商品设计中的缺陷。（尤其是给运营同学用的后台🙃）
   ps：我的小愿望是设计一个不被运营同学吐槽，打开就知道怎么用的后台。

5. 尽早建立报警机制
   我刚刚的文档结构里面没有提到这一点，的确我在产品设计时没有考虑到。一些核心并且存在变量的产品方案一定要建立数据异常时的报警机制，而不是等数据异常时，被动告知，才去查看问题。

6. 如何从被动通知到主动出击？
   这其实是我还没有想明白的一点。相信大部分初级产品都会有这个困惑。接到的需求都是老板让你去做的，而不是我觉得这件事情可以做，然后去做。关键是自己有时候还一头雾水，真让自己定一个方向去做，又定不下来，会觉得自己还没有考虑清楚，这件事好像还不适合现在做，逻辑不自洽。

结语

先简单写到这里。希望能对看文章的你有一点点帮助～

// 对了，你一定很好奇我做的是哪个砍价吧？但是我偏不告诉你😋