业务需求老是变，产品到底怎么办？

业务需求老是变，产品到底怎么办？

话说年前接了运营组一个需求，希望有一套优惠券系统，可以在任何假期和任何不是假期的时间里，多一些噱头，跟用户多亲密接触几次……

组里的小朋友接到需求后，就热火朝天的干起来了。先拉了个会，请了运营组的所有同学参加，倾听他们的需求。而当时PDD优惠券刚出事，考虑产品的安全性，又请了运维组和基础架构组的同学开了另外一场会，认真讨论和反思了PDD。

这两件事，就用了两周时间。

业务需求老是变，产品到底怎么办？

过完年后上班，组里的小朋友开始哼哧哧的干活。又两周后，找到我，说老大找个时间聊聊？问问有关优惠券的事情，我说咋了，他说感觉东西忒多，做着做着就有一点做不动了，不知道方向在哪里？

我拿着他的需求看了看，发现他是这样做这件事的：

一、对优惠券下产品定义

定义了什么是优惠券，分为哪些类型，各种类型的触发规则是什么。非常多，此处略去。

二、描述了产品设计的边界

涉及了哪些终端，哪些是H5，哪些是原生。涉及了哪些系统，哪些是业务系统，哪些是账务系统。涉及了哪些流程，如生券流程、券激活流程、发放流程、生效流程、对账及容错流程（PDD的雷）等等。

三、制作原型

制作了用户领券页、使用页等一些交互，然后制作了一个后台交互，对的，你没看错，是个后台交互。怎么样在后台生成优惠券，怎么导出用户使用明细等等等等。

四、需求编写

写了大概三分之一，就死在这个流程上了……

这样做有什么问题么？

业务需求老是变，产品到底怎么办？

每个产品方案都有自己的优缺点，这个方案从一开始计划周密，准备详尽，虽然大骨头难啃，但多给点时间，没有吃不下的座头鲸。但缺点是什么呢？

第一，交付时间过长。这个需求全部交付给开发，怎么着也得一个月。想想老板的脸色~

第二，过长的交付时间，并不能保证开发速度就快。有些产品会琢磨，我万事俱备，一应俱全，开发起来就会快不少，所谓前面浪费的时间都补在后面去。实际上并不是这样的，东西越多开发吃透的就越慢，干扰项就越多，风险就越大。不符合快速迭代的要求。

那怎么做才能避免呢？

这个项目我作为产品负责人同时，我也是老板（需求提出人之一），正好说一下我对这个项目的做法和期望：

第一：老板视角：对优惠券的定义

我的痛点是指标，关于用户端到端转化的指标。目前产品手段已经穷尽（达成60%），仍距离目标有所差距（目标值65%），只能从产品运营角度考虑，因此我想到了优惠券。

那么转化率流失最高的是那一步呢？用什么样的优惠券才能消除差距？

用这个思路，想到的优惠券，才是当期迭代要试验的优惠券。想明白了目的，就能过滤掉99%的优惠券种类。

第二：老板视角的产品边界

快速上线，快速试验，快速优化。

因此可以没有后台，增删改查，可先通过硬编码实现。

可以没有可视化报表，但数据必须要入仓，可以通过sql的方式先看着。

可以没有成熟的防诈骗，防盗刷机制，但必须要做好开关（监控也可以酌量加上）。

第三：原型和交互、需求文档

定义了上面的第一和第二，这个需求就没有交互稿了。直接出围绕优惠券的若干视觉即可。

这个需求文档1000字内就搞定了。

总结：

偏业务的产品遇到业务需求时，99%的产品经理都会被业务方拐走，以致做出的需求背离产品本应有的特质：小、快和预留性。这样的结果往往是业务需求还没上线，业务就取消或者发生变更了（仔细想一想，有没有被业务放过鸽子的），或者产品哼哧哧三千弱水拿来了，业务方只喝了一瓢（有没有经常出力不讨好，实现的功能过剩的）。

所以我们在接产品需求时，一个好的产品经理，一要学会偷懒，二要学会藏拙。把业务本质弄清楚，业务需求的来源或目的是啥，这样就可以偷懒不用搞那么大的边界和范围了；藏拙是指管住自己天马行空的心，先实现最基本的，好想法往深处藏藏，用来做下一次，或下下次的迭代内容，时间是检验你的天马靠不靠谱的极佳武器。

上述总结是需要被多个大项目延期，误期，或频繁变更需求逼疯后才能有的。尝试下逆向思考，不妨在拿到项目时，倒着去拆解需求，一先控制量，14天的迭代（一般都是两周迭代一次）我只实现5个功能点；第二挑出这5个；第三把剩余的需求再分一次类，把好的想法、可扩展、便于扩展的项目藏起来。

你哪能知道，留余和藏拙，是产品经理生存的终极奥秘~

业务需求老是变，产品到底怎么办？

以上就是本期碎碎念，本人11年产品经理一枚，坐标上海。欢迎大家多赞多关注。不知各位对我的认知是否认同呢？不妨留个言，一起过过招吧。

业务需求老是变，产品到底怎么办？