【人人译客】一问产品经理:有效的产品路标规划?

0 评论 29659 浏览 9 收藏 6 分钟

问题:

你用什么来创建和管理产品路标?以你的经验来看,有咩有比较好的资源如网站或书籍可以让我学到丰富的东西?

 

我搜罗了一番,找到了很多高大上的图形实例,但我并不确定那些是对的,抑或它们又是否可以更加细致一些呢?我想要找到一种可以更好理解并学习展现、管理数据的有效方法。

我的前雇主并不太在意这个东西,我都是自己学习。依照我们的开发计划,路标规划包含了很长的BUG列表和新功能。我一般使用Word来建立一张以季度为单位的表,把每个季度我想开发的主要功能(和要搞定的大BUG)列出来,我把它们称为“新发布”,我会基于我没有完成的开发和一些运营中的非理性决策去不断调整这张列表。(Chris Garby)

我了解你的痛苦!我也bug和新功能过载的路标规划。我花了很长时间才搞清楚为什么会这样。因为路标规划出错是不可避免的,原因是你不可能在一个文件中将未来18-24个月的事计划到一个非常细致的程度。

首先,不要把你的路标规划想象成一个甘特图。这是个很容易犯的错,因为大多数人喜欢用项目管理的工具或技巧去做路标规划。我的ProdPad联合创始人,SimonCast,曾经说过:切勿用项目管理的工具来做产品管理。

把你的路标规划看做是一个战略性的沟通文档。他的作用就是向你的股东和团队展示你的产品愿景是什么,以及其背后的原动力是什么。而不是一个你用来展示你狂拽酷炫的开发计划的工具,它不需要包含你的BUG列表也不需要你要发布的一些小功能。

更现实一点,作为一名产品经理,你在开发过程中也许确实有一串bug和小功能需要呈现。这无可厚非,但记住一点(当你帮开发团队把一个个小功能输入输出他们的Kanban/Sprint/Backlog或是什么其他计划),你是在做一个项目经理或是一个产品的直接拥有者,而不是一名产品经理。路标规划是产品管理的文档,是独立的。

别考虑日期。你根本无法预料几周后的某个交付日期确切是哪一天,比如一个sprint开发周期是多长,或者不管你的项目在你的团队面前多么清晰多么时间充裕,你都没必要去设定图一个日期。在路标规划中注明日期,如果是像”Q3 2013“这样模糊的日期,并不会帮助你建立产品交付的预期,还会导致股东的责难和非议。但理想情况下,如果你是个牛逼的产品经理,你会觉得你对一个产品会有一个大概的估计,并能够坚持执行,但是,你的估计真是糟透了(这是我推荐大家读的一本叫REWORK的书中讲的)。你根本不知道有什么BUG会冒出来并打乱你的计划,就算你按时完成了,在”Q3 2013“那个时间点你的产品策略也还是要根据市场、用户、竞品等因素去调整。

把你的路标规划当做一种指导,尽力保持每位成员在规划下工作,而不是一个严格的项目计划。就像Steven Johnson说的:我觉得可以分享我的路标规划……只要客户和销售人员明白这个路标规划只是个计划而不是个承诺就好。

 

对于其他的好资源,有些牛人可以关注一下:

>Steve Johnson刚出版了一部关于路标规划的电子书

>Marty Cagan在业内很有人气,我也经常读他的文章。这是他在roadmap上的一些产出

>Martin Eriksson(他给我介绍了没有日期节点的路标规划这一概念)为产品经理创办了ProductTank。他写过一篇关于优先级排序的经典文章

最后,在MindTheProduct.com有很多其他优秀产品经理的文章,这些是一些关于路标规划的

 

本文由人人都是产品经理@Tobbi翻译,转载请注明来源且保留本文链接。

原文地址:https://www.mindtheproduct.com/2013/06/ask-a-product-manager-effective-product-roadmaps/

 

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!