面向目标 vs. 面向功能: 选择正确的Product Roadmap

编者注：本文来自romanpichler，中文版由天地会珠海分舵翻译。主要描述了我们作为产品经理编写我们的Product Roadmap的时候，我们应该如何选择我们Roadmap的类型，应该是面向功能呢，还是面向目标…

面向功能 vs 面向目标

众所周知，Product Roadmap这玩意儿的格式不一而足，且可大可小。而当前最流行的两个格式应该要数“面向功能”和“面向目标”的这两种Product Roadmap了。

前者是是基于产品的功能点的，比如注册功能，搜索功能，报告功能等，这些功能最终都会映射到一个时间轴上面。

面向目标的Roadmap 关注的是目标或者效益，并且明确指定要在什么时间完成什么样的目标。目标多种多样，比如可以是客户和用户获取，粘住用户，增加用户对产品的融合度(engagement)，开始获利，等等。功能点在这里会变成一个二等公民，他们源于目标，且通常一个大的功能点可能会跨多个目标。

以下的两张图片阐述了这两个不同的Roadmap格式，它们描述的是覆盖一个产品的两个版本发布m 和 n 的Roadmap。

跟你要采取的是那一种格式没有任何关系的是，你的Product Roadmap应该说的是一个实在的且前后要一致的描述你的产品是如何成长的故事。它应该执行的是你的产品战略，这样的话，前面的每一次发布都会把你往前向你的愿景推进。它不应该包含一些随机的目标或者一些松散的功能点。

面向目标的Product Roadmap示例

下图显示的就是我之前做的一个面向目标的Product Roadmap的模版，当然，你也可以通过这个连接 进行查看了。

以下是一个实例：

如何选择正确的Product Roadmap

在不同的情况下，你应该使用不同的Product Roadmap。为了找到最适合你的Roadmap格式，你应该要考虑的是你的产品的成熟度以及市场的稳定性。你的产品越年轻(比如还在产品开发的早期)，那么功能或者需求可能需要修改的地方就越多。那么这种情况下你就不应该使用面向功能的Roadmap而应该使用面向目标的Roadmap，否则你的Product Roadmap就需要经常随着功能的改变而改变了。

与之对应的是，越老的、越成熟的产品就越应该使用面向功能的Roadmap格式，道理很简单：当你的产品日催成熟之后，改变就相对比较少了，这个时候你就会处在一个很好的位置，通过在你的Roadmap中增加更清晰稳定的功能，来让你更准确的把控你的产品成长预期了。

除了产品成熟度会对你选择Product Roadmap格式有影响之外，市场的稳定性也会产生影响。所以就算你的产品已经很成熟了，但是市场却是非常的不稳定的话，比如竞争对手一直有新的功能的增加，或者说相关的关键技术发生了巨大的改变，那么你就需要频繁的更新你的产品以保卫你的市场份额了。结果就是，很多不确定的因素和功能会不停的走进你的Product Roadmap里面去。这就会让你很难周详的去提前计划一些细节性的东西以及预测那些功能点将是必须要要在下一版本进行发布的了。所以这种情况下，你更应该是采用面向目标的Roadmap格式。

下图描述了我们在综合考虑产品成熟度和市场稳定性之后，应该如何的选择Product Roadmap的格式。

总的来说，如果你的产品或者市场倾向于需要频繁改动的话，那么我建议你使用面向目标的Roadmap。你只有在你的产品已经很成熟且市场很稳定的情况下才应该使用面向功能的Roadmap。在现实中我曾经看到过很多企业的做法是相反的：它们在产品本身还非常不成熟，市场也很不稳定的情况下照样使用面向功能的Roadmap，最终做的一团糟。

需要谨记的是，就算是一个应很成熟的产品也有可能需要做大的改变。你也许需要，像苹果对它的iPod Nano一样，为你已成成熟的产品做出重大的改变，以使得你的产品重新精神焕发。为了让自2005年就已经发布的iPod Nano重获活力，苹果曾经为其动过相当大的手术，大大的缩减了它的大小，改变了它的形状，并且给它换了个触摸屏。所以这种情况下，你就应该需要从原来的面向功能的Product Roadmap转换成面成面向目标的Product Roadmap了！

提醒:更多文章请关注公众号:techgogogo。当然，也非常欢迎您直接私人微信(zhubaitian1)勾搭。
本作品采用[创作共用署名3.0中国大陆版许可证], 若非授权，转发时切勿删除联系信息，否则追究相应责任。本文首发虎嗅。