产品规划，既容易又复杂。
容易是每个人都会有深度使用的应用，看多猪跑会有错觉认为自己也能养猪。复杂是它不是我们看到的一个个推送更新的版本，透过表层，内里是需要从高层的战略到底层的表现、从核心板块迭代到板块间关系等多个层面去考虑。
既然复杂可能用一张图说清楚吗？当然可以。
有一定经验特别是参与规划过的话，就能明白图中概念及其关联。当然，可能基于产品发展阶段和资源限制，会有部分特别复杂又或会省略，都需要根据实际情况来调整的。这里，仅是我对以往经验的总结。
关于这个图，稍微解释一下几个概念和关键问题。最好是对照图一起理解。
首先是概念
|版本规划
版本规划，是针对产品目标，围绕产品路线在各个阶段所做的规划。
产品路线也叫roadmap，road和map。所谓road，就是通向某个地点的行走路径。而map，就是把要去的点、过程中会经过的点、点和点之间点关联、关系、路径标记出来而形成map。
所以，roadmap就是明确目标后，把达成目标的各个点标记出来，挑选出最合适的路线走过去。
|产品架构
产品架构，后面专门总结一下产品架构怎么画，怎么修正。这里先说下概念，这里的产品架构是说产品功能产品业务层面的架构，它由产品的目标和业务流程导出，非指技术架构和信息架构。
|产品规则
产品规则其实是对产品定位的显化，有了产品定位，就有了定位之下做产品的原则，这个原则就是去定义清楚产品是什么，不是什么，做什么，不做什么，以及去说明利益冲突的时候以谁的利益优先。有了它，我们在对产品模块进行梳理导出MVP版本时、梳理迭代版本时、对需求池需求整理为版本时，对版本中的功能需求的取舍、优先级，就会有明确的原则去指导。
|技术反馈
产品发展中，特别是产品前期，一定是产品思维主导的，但是对技术的反馈需要特别的重视，这里的反馈是指技术实现难度和技术对产品架构的反馈，这些反馈是否能达到理解一直将决定技术架构的搭建和完善，否则一定会导致技术重构。没有技术会想做架构重构。
|数据反馈
数据反馈非常重要，但在数据量不足和人力资源不足的情况下，无视它吧。
然后是注意事项
目标先行。大大小小的规划，一定要定位清楚目标，花多一些时间，自己把这个目标理解足够透彻，然后能做到能解释到足够清楚。
面向不同对象分享。一定一定一定要把版本规划针对不同的对象去分享。不同的部门人员关注的点不同，所以需要稍微调整下表达、表现方式。当然，时间不足的情况下，就一个版本多种讲法搞定吧，时间允许的情况下，尽可能去做。
版本数量要规划3个。不多也不少，就规划3个。太多会因为后续不确定因素导致变化，可能会浪费精力。太少没办法更好的统一不同部门的共识，一个版本需要不同部门做不同的事情，没有后续规划或后续规划太少会导致过多中间成本或时间来不及。
技术开发周期。这个虽然很多时间，技术不太愿意提供，但是没有这个，意味着进度管理必然失控。
大版本和小版本。大版本是基于产品架构和业务流程导出的板块，小版本是一个板块的优化迭代。一定要分清楚这两者，很多时候，这两者需要结合在一起去规划和实现。而他们的取舍和排序，就需要上面说到的产品规则。
架构是需要调整的。产品的架构是需要不断去调整的，不是设计好之后就再也不需要去理睬了。
最后说下认识
产品是演化出来的，不是规划出来的。所以版本规划的流程必须更加的抽象，抽象到只剩下流程和关键点。
敏捷是元素的迭代，不是功能的优化。譬如想做小程序的分销，迭代应该是：识别小程序-转发小程序-基于业务创建小程序。
