对于产品经理来说非常关键的一点是如何识别、认知以及理解产品正位于哪个阶段，并且根据不同阶段的需求做好产品的迭代规划。本文通过参考产品的生命周期曲线将产品生命周期分解为：探索、成长、成熟、突破四个阶段，分别对每个阶段进行界定，并强调在各个阶段产品经理应当注意什么。

一、探索期

顾名思义，探索期就是一个产品从0到1探索的阶段。

在这个阶段，作为产品经理，最困扰的就是如何确定产品的定义？

在实际工作环境中，一般都是由老板提供一个大方向的的idea或者由客户提出需求。

由此确定产品的大方向，在确定完大方向之后，再通过市场调研、目标用户调研、竞品分析、盈利模式分析等方法验证产品的可行性。

在这个验证过程中，非常重要的一点就是要遵守一个原则——我将其称为4W1H原则，因为该原则是我个人于5W1H原则上加入了自己的理解后总结得出。

1. 4W1H原则

遵守这个原则的目的很简单，就是避免调查过程中偏离调查方向的偏离，在调查完成之后，可以再将调查结果总结为六个要素，我将其称为产品六要素。

2. 产品六要素

可以举个很简单的例子，就比如网易云音乐，它用产品六要素的办法总结就可以得出这么一个结论：网易云音乐是一款帮助音乐爱好者通过电脑或手机软件随时随地听歌，分享音乐评论的功能性产品。

用产品六要素总结可以很清晰地将产品的6个属性呈现出来，那么产品的定义就不会模糊。

本人曾经拥有一段在创业团队工作的经历，相信大家都经历过这样的难题：在初创公司，时间就等于金钱，BOSS天天都会牢牢盯着大家，并且不停地询问“产品什么时候能上线啊”，所以探索期的效率就会显得格外重要。

那么如何保证产品按时交付上线不会延期呢？

3. 如何提升探索期的工作效率呢？

其实这个问题，伟大的古人早就给出了答案：

《汉书·贾谊传》：“为人主计者，莫如先审取舍，取舍之极定于内，而安危之萌应于外矣。”

没错，关键就是“取舍”这个词。

探索期，团队的任务应该是尽快将产品开发出来先上线，而懂得取舍，才能快速地进行产品规划。

4. 怎么样才能做好“取舍”呢？

其实关键在于做好三点：

• 取大舍小：选择体量大的的用户，舍弃小用户；
• 取简舍繁：选择简单的流程，舍弃繁琐的流程；
• 取常舍异：选择常态的行为，舍弃奇葩的行为。

拿大家最熟悉的微信的1.0版本举个例子：

• 取大舍小：移动互联网发展爆发期，选择开发移动端，舍弃电脑端；
• 取简舍繁：针对一个核心业务“即时通讯”，集中精力开发；
• 取常舍异：选择类似短信的操作界面，贴合用户操作习惯，稍微进行微创新，而不是大幅改动。

5. 筛选需求，做需求的漏斗

在探索期，产品经理其实应该更多地去做一个需求的漏斗，将一大堆需求倒进漏斗里，再进行筛选；将最核心的需求过滤出来，再针对核心需求，设计出一个低保真的原型。

为什么要对需求进行筛选呢？

因为我们探索期的任务，就是快速地将产品开发出来迅速上线，整个过程是非常争分夺秒的；筛选出核心需求，可以将团队有限的资源集中起来，从而提高探索期的工作效率。

6. 那么如何对需求进行筛选呢？

可以通过六部分，搞清楚需求：

1. 背景：在什么样具体的业务场景中，我们需要了解非常具体的、细节的业务场景、以及该场景的前提因素。
2. 谁：是谁提出了这个需求、是直接提出还是间接转述、是需求直接人、还是非直接人。
3. 需求规模：这个需求提出者的规模、类别、特征、等级，来界定需求的通用性和紧急度。
4. 现有的解决方案：这个需求之所以产生，是否是因为使用某个产品、或者使用竞品的产品而附带产生，还是说现有解决方案没有解决好原生需求。
5. 疼痛程度：是否这个需求是用户核心业务链路中的需求，还是相对来说无关紧要的、不痛不痒的需求。
6. 核心诉求：用户在提这个需求的时候， 本质他是想解决什么问题，注重问题，而非用户需要“什么”，用户需要的往往带有主观因素。

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

二、成长期

当产品成功实现从0到1的开发之后，就进入了成长期，这也是我们大部分产品经理现在所处的产品阶段。

在这个阶段我们会发现，运营那里会不断地收到用户的反馈，运营本身也会不断地调整他们的运营策略，后台的节点也会越加越多，相对应的，他们也会不断地给我们提出新的需求。

那么，在成长期，我们该如何合理地从众多需求中挑选出合适的需求，从而进行顺畅的迭代呢？

1. 合理地挑选需求

其实这里又呼应了探索期时，产品经理所担任的需求的漏斗这一角色，因为同样的，这个时候产品经理需要做的依然是筛选需求。

只不过不同之处在于：探索期的时候，我们是去筛选出核心需求，而成长期，我们更多的是去挑选出合理的需求；根据这些需求开发出新的功能，去丰富我们的核心功能，从而达到让核心功能使用起来更加流畅方便，解决更多的用户痛点，使用户体验变好的这么一个目的。

2. 怎么样才能合理的挑选出需求呢？

那我们就要遵循“三个基于”原则。

• 基于核心业务提升；
• 基于用户运营效果；
• 基于战略方向调整；

我们拿淘宝举例：

• 淘宝通过后续添加了可以以视频展现方式充当商品封面图这个功能，将网购这个核心业务进行了提升。
• 淘宝双11购物节的成功是有目共睹的，并且在尝到了这个甜头之后，淘宝推出了一系列衍生的购物节活动，基于需要不断地举行营销活动，淘宝也会有针对性地进行迭代。
• 由于近来直播带货的大火，淘宝对自己的产品战略方向进行了轻微的调整，相对应的，为了加入直播带货这个功能，淘宝也进行了相应的产品迭代。

其实对于产品经理来说，添加功能并不难，难的地方其实在于如何保证添加的功能是正常合理的，是真正对产品有帮助的。

而如果遵循“三个基于”原则合理挑选需求，加上了限制，我相信应该很难出现那些天马行空的功能了。

三、成熟期

当产品到了成熟期，这时候，产品的核心功能都已经完善得差不多了，战略方向也已确定，流量也趋于稳点，运营节奏正常。

产品经理也将迎来非常尴尬的时期，经典的“产品与开发互砍撕逼桥段”往往也都发生在这个时期。

因为在成熟期，产品经理往往需要将之前成长期加的一些已经不符合当下环境的功能给删除；而这个行为，也往往会与开发发生矛盾：“当初不是你要加的这个功能么？现在又要删？”、“不是吧阿sir，你知不知道这个改动需要改多少东西呀？你现在要改的话，你当初为啥要加呢？”等等。

这个时候，我要为我们产品说句公道话，以前加上的功能现在要删除，不是真的只是我们产品无理取闹，给开发找事。

而是因为产品到了成熟期，通过采集了足够的数据，市场也验证了一些东西，用户的不断成长，整个趋势的变化会导致原本一些功能的不再适用或者不好用；基于这点，所以要对一些功能进行修改或者删除。

1. 怎么样才能做好功能修改更替呢？

同样有着以下4个原则：

1. 基于数据；
2. 忠于用户；
3. 遵循市场；
4. 跟随趋势；

当你基于这四个原则，有理有据地再去和开发谈时，我相信，你会能够说服他。

并且，往往每次地修改，都不仅要和开发谈，要和各个部门协调商量好；那么如果你条理清晰，思路正确，说服别人的难度也将大大降低。

2. 在这过程中，也有很多的注意事项

• 数据接口是否会导致旧版本出错？（旧版本兼容性）
• 更改后需要对用户进行通知
• 功能入口也要进行对应的更改或者清理，切记不要遗漏

四、突破期

怎么判断产品来到了突破期这个阶段呢？

就是像武侠小说中说的，当你的产品遇到了瓶颈时，你不知道如何继续发展的时候，产品自然就是到了突破期这个阶段。

1. 如何突破产品的瓶颈呢？

我们可以用武侠小说来便于自己理解，小说中的武林高手是如何突破自己极限的？

• 一个是量变：量变就像是你不断地练功，积累自己的内力，当内力的量积累到了一定程度时，自然就会挤破瓶颈；而当这个思路搬到产品身上来时，其实就是用户量的积累，当你的用户量积累到了一定程度时，自然地就会产生新的需求，从而完成产品的突破。这在社交类与内容类app上体现的尤为明显。
• 第二个是质变：质变就像是张无忌，当他获得了九阳真经之后，他的内力发生了质变的一个过程，由于质量的提升，本身的实力也会突破瓶颈；同样的，搬到产品身上来时，产品质变的实质就是定位的改变。例如当一个工具类app，加入了社交功能时，他就是一个质变的过程，例如支付宝从一开始的支付工具到后来加入了社交功能，这就是一个典型的质变。

而在突破的过程中，产品经理依然离不开“需求”两个字，因为我们需要分辨真需求与伪需求。

2. 如何判断伪需求？

对此，我判断伪需求主要是从两个方面：

1. 技术
2. 商业

简单地说，伪需求就是技术和商业上不合理的需求。

技术上，实现不了，or商业上，不划算；有些需求，现有的技术，无法通过实现功能对其进行解决，亦或者可以实现，但成本上并不划算。

这样的需求，在我眼里，他们就是伪需求。

• 假如你有技术思维，在产品设计的时候就能规避掉很多技术无法实现、或是很难实现的问题。
• 假如你没有技术思维，那么在这一 part 你需要和技术一起讨论，确定最优的产品解决方案。

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

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

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

五、总结

产品迭代是非常重要的过程，而做好产品迭代规划自然也是产品经理必不可少的技能；虽然有些公司的产品可能会经历上百年的生命周期，例如马爸爸给阿里巴巴定的目标就是活到102岁，但其实绝大多数产品并不会。

因为它们会被更加优秀、便宜、新颖的产品所取代。

而我们作为产品经理，我们的任务就是将产品从探索阶段引向成长阶段，尽可能久地维持产品的成长性，在成熟阶段尽可能多地获取利润，在最后的突破阶段为产品规划创新，焕发新的生命力。

当然，如果突破失败，那也就不会是突破期了，而是衰退期。

而为了适应不同的产品阶段，我们产品经理应该做的也是不断地拓宽自己知识面，持续地吸收新知识，转变自己的风格，应对不同时期地任务。

我觉得，“能人所不能”，这大概就是产品经理这个岗位的特殊性和重要性了。

免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！

思考迭代的方向不是一件容易的事情，比较考验一个产品或者一个团队的长期规划能力和趋势预判能力。那我们在产品初期一穷二白什么数据都没有的情况下如何去判断迭代的方向呢？本文从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端产品来说，只要遵照上述的路径来迭代需求，基本就不会出现太大的问题，而且在一次次不断的实践中，你也会不断修正路径，找到最适合自己的一条星光大道。

免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！