"No battle plan ever survives contact with the enemy. "
——《Donnybrook : The Battle of Bull Run, 1861 》 by David Detzer
这篇文章我会继续聊聊产品规划。上篇文章的最后,我提到了在产品规划中要加入项目发布计划时,可以尽量写得模糊化,不要把项目内容和发布时间写得太精确。
这并不是叫你蒙混过关,模糊化其实有两个好处,一是出于尊重承诺的考虑,产品经理的影响力来自于交付承诺,所以不要轻易承诺做不到的事情,这个话题我以后会专门讲;二是可以通过这样的方式给产品规划适当留白,给自己和团队争取足够空间释放创造力,以及应对一些环境的变化。
产品规划的留白
产品规划的留白可以分成空间上的留白和时间上的留白。
Ruby on Rails 的创始人 DHH 曾经说,当你面前有艰巨而冗长的任务队列等待实施时,你的创造力将会被严重的抑制。
对于大部分人来说,当面前摆着一长串待办事项,而且待办事项上全都是具体的执行性工作任务时,我们会比较容易沉浸其中,就像在快餐店操作炸薯条的机器,照着一二三做就可以了,这时我们很少会有创造性的想法。
举个例子,如果规划文档中的项目任务是“支持 VISA 和 Master Card 信用卡支付,12 月 30 日之前发布”,我们脑子里想的一定是先去查接口文档、申请资质,以及整体的技术架构和页面流程。
这是一种本能反应,但是,我们其实更需要知道的是这个项目背后的动机。这种动机是有很多种可能性的。比如可能是为了增加支付渠道,也可能是为了提供跨境支付能力等。
当我们关注这些动机和目标时,我们的思考会上升一个维度,从研究“怎么做”转向“该做什么”。
比如,目标是为了增加支付渠道,那我们或许可以直接接入第三方的支付组件,一次性增加包括各种信用卡在内的多种支付渠道;如果目标是为了提供跨境支付能力,我们或许可以直接去接 PayPal。
关注这些动机和目标也可能会让我们考虑得更加周全,比如是否需要在境外增加服务器节点或缓存等相关基础设施。
所以,我们在做产品规划的时候,最好能把这些细节留白,到了具体操作实施的时候,让处在那个环境里的同事去决定具体的策略。
关于时间的留白,说起来挺文艺,其实就是指尽量别把时间点定得太精确。精确必须以具体为代价,而提前规划出来的具体十有八九都不靠谱。在这里,我建议最好先写成 X 月上旬 / 下旬这样的形式,到时候根据具体情况再决定怎样执行以及何时交付。