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