思考迭代的方向不是一件容易的事情，比较考验一个产品或者一个团队的长期规划能力和趋势预判能力。那我们在产品初期一穷二白什么数据都没有的情况下如何去判断迭代的方向呢？本文从6个步骤介绍如何做好产品迭代。

01、首先，搞清楚需求的一切

通过 6 部分，搞清楚需求。

1）背景：在什么样具体的业务场景中，我需要了解非常具体的、细节的业务场景、以及该场景的前提因素。

2）谁：是谁提出了这个需求，是直接提出还是间接转述。是需求直接人，还是非直接人。

3）需求规模：这个需求提出者的规模、类别、特征、等级，来界定需求的通用性和紧急度。

4）现有的解决方案：这个需求之所以产生，是否是因为使用某个产品、或者使用竞品的产品而附带产生，还是说现有解决方案没有解决好原生需求。

5）疼痛程度，是否这个需求是用户核心业务链路中的需求，还是相对来说无关紧要的、不痛不痒的需求。

6）核心诉求：用户在提这个需求的时候， 本质他是想解决什么问题，注重问题，而非用户需要“什么”，用户需要的往往带有主观因素。

当我搞明白这6点后，我就对这个需求有一个非常清晰的认知了。

02、接下来，我们就是想产品架构

1）先要确定主流程，即核心结构。

做任何东西都要先搭建主骨骼。一般来说，当我们迭代一个新功能，需要建立新的业务流程的时候，往往需要考虑，如何最合理的结合现有的业务模块或流程；而在老流程上做改造的时候，则需要考虑跟现有业务流程的延续性、兼容性、合理性关系。

2）完善分支流程和功能结构框架

这个没啥特别好说的，就是把需求转化成具体的业务分支流程，按照结构化思路把方案拆分成模块、功能点、页面、组件块。

这两步做正确，你的整体框架性方案就不会有太大的方向错误。

既然我们整个产品架构确定了，接下来就是要设计具体的功能了，主要是考量的是展现层、逻辑层、数据层。

03、再者，竞品调研

这个时间点，一般我会调研一些市面上做的比较好的竞品，当然这一步也可以在确定产品架构前去调研。

调研主要调研以下几方面：

1）竞品的业务背景、功能框架和流程

因为竞品的背景和自己的产品并不一样，所以有的时候我们在借鉴竞品功能的时候，其实是会被带偏的，需要搞清楚他们的业务背景，才能更好的理解他们的功能为什么这么设计，为什么这么搭建框架，为什么这么设计流程。

2）优点、亮点、创新点

有些同行真的做的很用心，做的很出色。那些出色的产品，往往会被用户传播。

从中吸收一些优质的点，并在此基础上做些微创新，其实就已经很棒了。但是依然，我们要充分考虑优点下的条件，在另一个条件下可能就不是优点了。

3）竞品背后的产品策略

比如微信加了一个”在看“的功能，表面上看类似于一个点赞的功能，背后其实是微信希望进一步打通好友之间的内容通道，从而增加内容的分发效率。

基于此，你再去判断这个功能到底好不好，是不是能真正增加分发效率，而非一个鸡肋功能。

04、接下来，就是产品方案设计了

这块没啥好说，把页面的作用定义清楚、把交互做的友好、把每个字段都定义的清清楚楚。最后整体串联起来，按照业务流程多走几遍，看下是否有问题。

05、客户验证

对于B端来说，我非常强调一点，就是客户验证。

那么在正式开发前，我们会跟每个层次的头部客户确定下产品方案，是否真正满足他们的需求，流程、功能点、字段是否是他们真正所需的。

确认了这一步，基本上不会出现太大的问题，我们经常看到有些产品上线后无人使用的尴尬境地。

绝大部分原因是产品无法满足需求，或是非常不好用。客户验证能大大降低此问题的几率。

06、最后，考虑的是技术实现

产品方案出来后，免不了评审和开发提出的一堆问题。

1）假如你有技术思维，在产品设计的时候就能规避掉很多技术无法实现、或是很难实现的问题。

2）假如你没有技术思维，那么在这一 part 你需要和技术一起讨论，确定最优的产品解决方案。

如果一个功能的价值不大，但是技术实现难度很大，这种投入产出比其实是非常低的，也是我们应该规避的。

我们最喜欢的应该是最小的开发成本，最有效的价值，就像微信的“拍一拍”。

本质上这也是一个产品方案更合理化的过程，我们不能只关注极致的用户体验，而忽略研发成本，在现在这个精细化运作的时代，投入产出比是每个产品经理都应该有的基础思维。

作为B端产品来说，只要遵照上述的路径来迭代需求，基本就不会出现太大的问题，而且在一次次不断的实践中，你也会不断修正路径，找到最适合自己的一条星光大道。