在产品迭代的过程中，肯定踩过不少坑。踩坑不要紧，重要的是踩坑之后能不能总结规划出一个套路，为以后的产品设计铺路搭桥。

最近两年来一直做一个电商平产品，自己负责整个产品从0到1策划并上线，后面又迭代了20多个版本。在做产品中自己从一个电商小白不断地成长，在项目中也踩了很多的坑。

今天借着有空给自己做个总结，同时也希望自己的经验可以分享给更多的人，让看到的人少犯错。

产品版本规划可以理解为是：对项目每个周期的计划。

一般我们会在7到15天这样去做一个版本的迭代，下面我会说明为何我们采用短周期的策略。

优势是用户可以在更短的时间内去使用到我们的功能，从而能够更快地满足用户的需求。如果换成大版本周期，例如：1一个月以上的话用户将会很久才能够使用到我们的功能，这样就导致我们在市场竞争中处于不利的地位；一个秒杀的活动如果对手先上了他们就可以提前去做营销赢取更好的口碑。

技术人员更容易集中精力去开发，从而提升开发效率；大版本开发的周期太长容易导致开发的时间难以去评估和把控。

小版本开发将大的任务细化拆分成小的任务去做，从而更清晰任务目标。

之前我们也尝试过大版本开发，但是后来发现每一次的任务太多，开发人员一个周期开发好几个功能经常会导致项目拖延严重，测试人员测试也会比较散漫最终导致整个版本的推荐效率不高。

更迅速地根据用户反馈做出调整：

当上线的功能出现问题，或没有很好地满足用户的需求时，我们可以快速地去响应。

例如：之前我们上线了一个我要找药的功能，后面发现这个功能的设计只是让他们提交了需要找的药，用户提交后并没有给用户反馈任何已经提交的记录。后面我们知道后就立马去完善这个功能，提升用户的使用体验。

更容易让产品人员集中精力去策划一个功能，如果一次策划太多功能容易导致调研不足，从而设计出来的功能不是用户想要的功能。

上面说到了规划一个版本的周期，下面我们就来谈谈：如何在这个开发周期内去选择要做的需求？

重要且紧急的功能我们通常会优先去做开发，但是在整合项目开发过程中，一个需求的重要和紧急程度会随着时间和项目的不同阶段而不同。

例如：客服系统在电商企业中是一个非常重要的系统，但是在平台早期，我们可以使用平台的客服通过微信，或电话的方式去解决客户的问题已经可以满足用户的需求。

然而，开发一个客服系统需要相当大的人力成本和时间成本，而且在早期公司都不知道能不能活下去却话那么大的成本去开发，一旦公司倒闭损失的会更大。

因此，客服系统在早期是重要但是不紧急的需求。但是，如果到了平台的中后期，随着客户的不断增大客服人员已经很难去服务那么多的客户。这个时候，客服系统就成为了一个重要且非常紧急的需求。

如何去分析一个需求的重要且紧急程度是一门大的学问。为了更好的去分析一个需求的重要和紧急程度我们会引入产品MVP的概念。

产品MVP即为：产品最小化模型，也可以理解为最基础且最乞丐版的产品。

通常来说，我们会把最小化产品的功能模块列为紧急且重要的需求，在优先级排期中我们也会排在前面。但是这个只是多数情况是这样，并不是绝对的。

例如：在电商平台中我们把订单系统列为重要的功能，此时有个用户提出在客户端订单列表中新增下单时间一个字段。但其次下单时间用户已经可以在订单详情页中去查看了。

假如老板提出要做一个抽奖的活动来提升平台的营销氛围从而让更多的用户去下单，我们就可以分析到：显示下单时间的需求虽然是属于订单中心的需求，但是我们并不会把他的优先级排的比抽奖的高，这个需求对用户下单并不能产生很大的响应。

账户体系：账户体系主要包括用户账户 商家账户 和平台管理员账户，账户主要是为了记录用户的身份，是平台产品必备的功能。

订单中心：订单中心是电商平台的核心模块，它记录了买卖双方的交易信息和状态流转。

财务中心：用于记录交易中的资金流转和用户以及商家对账。

商品中心：商家上架商品买家在前端可以浏览并下单。

因此，只要做好了这五个功能模块，就可以让买家进来“浏览商品-下单-支付-卖家发货”完成整个商品交易全流程。所以，我们可以将这五个模块的功能称之为最小化功能。

知道了电商产品最小化产品之后，我们在做产品版本迭代的时候，就有一定的套路去规划：哪些需求需要去优先做了？

相对来说，只要属于最小化产品里面的需求的，我们基本都会去优先考虑去开发迭代。把最核心的需求做好了，再去做其他附加的需求，这样更容易形成产品核心竞争力。

如果核心功能漏洞太多，用户使用的时候就会觉得连最重要的需求都没有满足这个产品太烂了，最终导致用户的流失。就比如当我们在一个平台购物时发现订单无法提交，此时就算其他功能做得再好也很难留住用户。

本文由@ADK 原创发布于人人都是产品经理，未经许可，禁止转载。