"In preparing for battle I have always found that plans are useless, but planning is indispensable."——Dwight D. Eisenhower
一.产品规划的目的;
二.自上而下和自下而上指定产品规划的两种方式，
建议你根据自己组织和业务的特点，选择做产品规划的方式；
三.产品规划和发布计划的异同，这里建议你不要用做发布计划的方式做产品规划。
产品规划
产品规划包括了年度规划、半年规划、季度规划甚至月度规划。
每个规划需要画产品路线图（Roadmap），做幻灯片，先逐级汇总，向上汇报，然后再向下分解落地。
刚做产品经理的时候，我很反感频繁地去做规划，感觉全世界的人都知道那是个谎言，但是还得一本正经地把谎说完。后来我逐渐意识到了规划的重要性，也在实践中总结出怎样做出有价值的规划。
今天，我就围绕这个话题来展开分享。
自上而下还是自下而上？
不同的公司有不同的产品规划方式。
有的公司是自上而下，从最高管理层制定战略开始，分解到各事业群，再向下细化到产品线，最后拆解到每个职能的头上。
还有一部分公司是由每个具体的组发起，汇总到产品线，不断向上传递，最终形成公司战略。
利：
前者更利于公司资源的战略安排和协调，也方便战略安排在组织内部的沟通和传递，
因为产品经理和开发都比较容易弄清楚自己做的事情跟公司方向有什么联系；
后者则能够给团队成员更多的发挥空间，能够激发主观能动性。
但是，这两者的弊端也显而易见。
自上而下的拆解导致一线员工的判断和认知很难融入公司战略，很难做到所谓的“让听见炮声的人做决定”，
这可能会导致公司错失机会。
自下而上又比较散乱，缺乏一致性，可能不同的部门想做不同的事情，互相之间又需要彼此的支持，
结果协调起来很困难，有种各自为战的感觉。
从这两种方式的利弊中，我们也可以看到产品规划的两个重要目的，
一是针对产品的愿景和公司的战略进行自上而下的沟通，让每个人清楚组织接下来一段时间的方向和重心，
并在公司战略和自己的工作之间建立清晰的联系。
二是激发大家的积极性和能动性，也可以给前线“可以听到炮声”的员工足够的话语和决策空间。
从这两个目的出发，我们或许可以尝试做一些结合。
我认为可以先自上而下，由公司管理层明确下一阶段战略方向，然后向具体的事业部拆解，但这个时候，不要下到太底层，只要有基本的框架就够了，再自下而上进行具体的策略填充。
举个例子，
比如某个面向 C 类市场的产品，公司管理层在某一阶段认为用户增量红利基本没有了，而且竞争对手该死的也都死了，没死的基本也都成气候了，一时半会儿打不死；
所以公司决定会在接下来的一段时间内，集中资源改进和完善用户体验，公司重心不再放在增加用户量上。
在这样的方向和战略下，
服务部门可能会确定关注服务质量而非服务数量的规划框架。
至此，自上而下结束，自下而上开始。
比如，
1.服务部门下属的呼叫中心会基于自己的职能范围确定自己部门的策略，让客服人员群策群力，讨论通过哪些方式可以提高整体的服务质量，并且明确哪些数据指标可以反映服务质量的提高。
2.产品和技术部门也是一样，先根据所在的事业群做自上而下的拆解，然后再根据职能特点进行自下而上的细化。
假设我是做支付的产品经理，基于用户体验的大方向，我可能会提出像“支持更多的支付手段”，或者“提高用户交易安全性”等具体的规划；
而对于工程师来说，他们或许会考虑提高产品的响应速度和可用性等。
在类似的过程中，我们能清楚地知道公司接下来的业务重心和希望达成的目标，同时又有自由的决策和发挥的空间，是一个自上而下和自下而上两者综合的过程。
当然，具体问题具体分析。公司的阶段、规模和迭代速度不同，都会大大地影响产品规划的方式和粒度。
比如在产品非常早期的阶段，我并不建议做太多规划；
对于复杂组织架构和成熟产品线，可能只选择自上而下的规划方式等。总之在做规划的时候要灵活，选择适合自己的流程。
产品规划不等于功能发布计划
很多的产品规划文档是由若干项目的简述和预计发布计划构成的。
这样的发布计划很重要，但它却不能算是好的产品规划，
它相当于跳过了为什么和怎么做，直接描述做什么和什么时候做。
当大家聚焦于具体的项目内容和发布时间时，很容易就会忽视产品规划最重要的目的。大家不太容易从一堆项目中去猜测背后的公司战略及部门阶段性目标， 而且在这样的沟通框架下，真正拥有第一手讯息和经验的同事会有一种“被告知”的感觉，这样就会对产品和公司没有参与感，失去主动性。
好的产品规划应该从更宏观的视角和判断入手，尽量避免过分关注具体的项目和特性列表。
所以，在做产品规划的时候给出准确的时间点是非常困难的。
有人会说：“既然大家都知道不靠谱，我随便说一个到时候再调整是不是就可以了？”
我的建议是：万万不可，宁可不给承诺，也不要承诺了却交付不了。
前者别人最多说你怂，后者可是会丧失信任的，
信任是产品经理的身家性命，一定要想办法守好。
我的经验是尽量打个提前量，
1.提前进行战略的沟通和团队群策群力的讨论，
2.在此基础上去做一些笼统的项目规划，
3.具体的特性能多模糊就多模糊，
4.交付时间范围能多大就多大。
我举个例子，比如我们的产品规划是增加用户支付手段，
不要去规划类似“支持微信、支付宝和银联支付，11 月 20 日前上线”这样的项目，
写成“支持 3 种以上主流支付方式，在 11 月下旬至 12 月上旬完成”，甚至“支持主流支付方式，Q4 完成”更好。
这样做不但会让团队聚焦于业务目标而不是项目列表，也可以为团队争取足够的空间。
网友评论