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