原创： Kevin改变世界的点滴 Kevin改变世界的点滴
一款产品的诞生，都离不开有产品负责人从0到1进行规划。如果说做游戏的产品需要规划到5年左右的用户成长，那产品负责人需要考虑产品上线后的第一个版本与产品生命周期下业务的变现业务设计。
避免不了对产品各业务的需求进行排期与整合。产品生命周期规划，是高级产品经理与产品负责人后的基本工作。大体的规划需求计划后，接下来就是由各产品经理完成。
针对高级产品经理规划工作，有什么容易犯错的难点？还要产品经理如何学习规划产品生命周期进入高阶？
这里分：业务规划、优先级规划、模块拆分、产品结构4点描述
业务规划
提及业务规划，是需要产品来跟随的。不管是app还是web产品，都会包含公司的业务，为此业务一定会比产品先行，先出现。
就以电商系统来说，电商中存在的SKU（单个类型商品）是在业务规划下产生的。每个SKU的产品完善度、售后服务、供应链，以及最重要的系统打通都是影响产品生命周期。
我们在设计产品中要考虑每个模块的聚合复杂程度。这里的复杂程度是指接口与数据汇总。
以电商系统为例，每个SKU商品都代表一种流通的数据。比如智能手环的是链接在物联网平台（IOT平台），另外一个是链接第三方检测平台（生物实验室）。
上面一个SKU的商品就牵涉了2个平台，接口还不知道多少。并且还要产品经理前期调研各自的接口是否满足对方的需求。前期一定是在不增加接口的情况下，让公司内的开发与外部开发团队对接。
这里会有一些工作
需求文档对接
接口文档对接
新增需求设计
新增接口文档设计
所以，产品生命周期中这样的业务往往是比较重的。即需要花时间了解对方的业务，也需要开发工作。为此你可以看到很多产品第一版本是没有电商的。
模块的颗粒度
我们在做产品生命周期规划中，到底模块颗粒度应该多大？一个页面可能就会有3个按钮，但有一个按钮却是一个功能。另外只是一个操作
如何区别功能与操作？
功能是由操作与页面的集合，逻辑复杂切不单线
操作是由串行的单线组成，不涉及到页面集合
如下图，根据用户管理大模块，我们再进行颗粒化。每一个需求点都表示一个操作，操作的集合成了用户管理模块
不确定的需求
这一点是产品负责人会遇到的“尴尬问题”，在团队快速发展中，因为企业的合作方与优先级随时在调整。因此产品生命周期的需求也变得不确定。
但要注意的是，这里的改需求不是指这个页面的功能怎么减少。而是整个产品定位上的变化。
举个例子，产品本来是面向健康类普通用户。突然只针对孕妇类，其他类用户不接受。这样的产品变动，无意是产品设计还是产品团队的用户思考点都会调整。
所以需求调整不仅限于产品经理的工作中，产品团队负责人也会因为业务的调整进行变更。或许这将伴随着产品经理的一生职业发展中，但我们能做的是尽可能的选择靠谱团队与降低他出现的概率。
产品框架图
产品结构是产品最粗旷的信息框架图，但却是最基础的产品形态。在这个图下，产品整体的业务范围和产品结构包含在里面。
产品总监或产品团队负责人们，在做产品规划前都会使用这个信息框架图做产品集合。
既可以确定团队要输出的原型页面，也可确定整体功能是否有链接，承载公司业务。
没有业务的产品，是无法盈利的。就算留住了用户，比如你做了一个很好玩的app，但是没有任何业务的承载。你唯一的变现方式：广告。
相信没有产品团队只愿意做一个产品，仅仅是靠广告来盈利。产品总监在规划产品中，如何深度的理解业务知识将决定产品框架的设计。
好啦，今天的分享就在这里，我坚持每周原创工作的案例2篇给你～
推荐阅读：
