如何规划产品路线图？

   <p style="text-align: center;"><img src="https://simg.open-open.com/show/0c8f305e20d14fda7fa8ff8678e5561a.jpg"></p>    <p>编者按：开发伟大产品很难。没有一个负责迭代、质控以及用户反馈的计划就想开发出伟大产品几乎是不可能的。所以我们才需要一幅精心打造的产品路线图，而这正是Janna Bastow在行的东西。身为产品经理的她与人一起创办了ProdPad，因为她根本找不到合适的工具来规划和管理自己的路线图和产品待办事宜。她还是 产品人全球社区Mind the Product的联合创始人。此文是她在接受Intercom访谈的 摘编 。</p>    <p>访谈内容的主要摘要如下：</p>    <ol>     <li> <p>一个合适的从路线图可以从两个角度实现：它实现了大目标，并按照公司愿景而打造，但它同时可以足够灵活，能适应市场的变化。</p> </li>     <li> <p>邀请公司内不同地方的利益攸关者一起讨论要开发什么，从而帮助你分析各种权衡和需求。为此，Janna推荐了一种被称为产品树的做法。</p> </li>     <li> <p>避免针对特定日期调整路线图；相反，要把你的路线图在更短的时间窗口和更长的时间范围之间进行拆分，这可以提供灵活性。</p> </li>     <li> <p>随着产品的发展，你将需要从列举功能的待办事宜清单的做法转移到按照正在解决的问题来组织路线图。</p> </li>     <li> <p>如果功能请求与公司的产品愿景和目标不一致，那产品经理完全可以拒绝，哪怕对方是自己的老板。在这里测试和数据和产品经理最好的伙伴。</p> </li>    </ol>    <p>问：产品管理相对于设计和工程等而言是一个相对年轻的领域——而且大家进入这个行当的途径也各不相同。你是怎么入行的？</p>    <p>答：我第一次从产品管理时实际上从未听说过这个词。我是一家技术公司的客户支持代表，他们喜欢我这个角色，因为我可以汇报bug并跟客户交谈。我的老板有一天把我找过来说：“我想让你当一名初级产品经理。”我的第一反应是，好的，我喜欢。但这是什么玩意儿？实际上我是Google之后才了解到我的发展路径是什么，怎么才能做好这一新角色的。尽管我之前学习过商业并事先涉猎了一些技术和设计方面的知识，但实际上从未听说过产品管理这个词。但现在已经不一样了。</p>    <p>问：你在为初创企业提供产品管理咨询的时候，你总是从这个简单的问题开始：你的产品要解决什么问题？那么是什么问题导致你要做ProdPad和Mind the Product？</p>    <p>答：两个截然不同的问题。其一是我是产品经理，所以我想想别的产品经理学习，但是网上根本没有多少资源。我的关系网络里面当然也没有太多的产品经理。于是我们几个决定找一些人进来一起举办项目经理的活动。最初它就是一个产品智库，大概有20人左右，然后慢慢地发展，最后就变成了Mind the Product。</p>    <p>至于ProdPad，我的出发点是身为产品经理我意识到手头没有做这件工作的工具。我得PowerPoint、电子表格等工具齐上阵。所以我和联合创始人最后决定做ProdPad，这原来只是一个黑客项目，为的是帮助自己完成工作。我们是在几年后才意识到这个东西值得分享给别的产品经理。</p>    <p>产品路线图从何而来？</p>    <p>问：ProdPad的用途之一是帮助构建产品路线图。对于要开发什么每一家公司都需要有计划，但创建产品路线图的办法实在是太多了。你们在ProdPad是用什么来作为产品路线图的输入的呢？</p>    <p>答：好的产品路线图从两个角度实现。一个可以是自顶向下的方案，先概括你的愿景，你的目标以及满足愿景需要采取的大步骤。你不能仅仅只进行自顶向下的产品管理，因为这意味着你没有注意到市场上发生了什么。</p>    <p>所以你需要跟自底向上法糅合在一起，这种办法会考察出现的所有机会：哪一个想法是你的团队想出来的？哪些反馈是客户提出的？你从观察市场或者新客户中学到了什么？通过融合这两个你就创建出来的路线图就既足够灵活看根据市场情况作出变化，同时又可确保你在朝着愿景而开发产品并实现对公司很重要的大目标。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/61c4a4cef8930187bc229e0c049e8690.jpg"></p>    <p>问：这些输入里面有没有哪些是更难管理或者平衡的？</p>    <p>答：大多数产品经理对于汇总客户的想法和反馈都会遇到问题。把所有东西都放到一个地方、形成闭环并确保你开发的东西跟客户相关并不容易。这是一个持续进行的循环，要不断地回头看，验证你在做的事情，哪怕这件事情你一直都在验证。你还是需要确保这是你要开发的合适的东西。</p>    <p>构建你的产品树</p>    <p>问：在确定开发的优先次序方面，你采用了一种叫做产品树游戏的做法。过程是怎么样的？这种做法是如何发挥作用的？</p>    <p>答：产品树游戏部分是受到了创新游戏背后那帮家伙的影响。您可以跟团队、公司内部不同的利益攸关者甚至客户一起玩这个游戏。你可以把团队集中起来，收集来自于销售、支持、开发等的不同观点，然后在白板上画出一棵大树来。</p>    <p>树的主干表示核心功能——这是绝对必备的功能，也是你手上现有的功能。树枝表示你可以进入的不同领域，而树根则表示开发这颗树所需的基础设施。让每个人头脑风暴一下，把想到的一切都写在便利贴上。然后让每个人把它贴到树上，一起协商这些具体功能或者想法应该怎么发展。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/9aa45976b6f71db630b8252852672e3f.jpg"></p>    <p>一些东西可能是绝对核心，需要成为树枝的核心基础。这些东西就得先开发。其他的一些可能就含糊点或者考虑得更远一点，这些就可以放到树枝更远一点的分支。作为根基的基础设施也很重要，因为这是开发者有发言权的地方。你可能有个销售说如果我们能够实现客户的这个视图的话就好了。但开发者这时候可以站出来说：“如果我们想实现这个那就得做这个才能支撑这棵树的发展。”然后解释为什么你需要一个好的基础设施。</p>    <p>你最后得到的就是一张树，也就是你的产品树的图， 这棵树是不是平衡马上就可以一目了然。每个人是不是都决定朝着一个特定的方向发展？你的基础设施是不是足以支撑众多新功能需求的实现？这是让大家参与到产品管理中来的一个很好的可视化方法，还可以看看在任何时候都在进行多少事情。</p>    <p><strong>问：团队多久需要做这么一次完整的流程？</strong></p>    <p>答：可能不会多于6个月一次。路线图的再思考我建议不要搞得比这还要频繁。如果你隔几个月就要更新一下路线图的话，那愿景变化就太频繁了。显然小一点的调整会有（也没问题），但我不建议频繁大改。这会让团队成员无法真正理解你究竟想要去哪里。</p>    <p><strong>问：画完一次产品树肯定会有很多东西要削掉。那谁来负责把这些概念放回路线图，在它完成后谁有权看路线图呢？</strong></p>    <p>答：产品经理本身应该拥有路线图。这个东西别人不应该随意增删，而管它的人也不应该随便换。他们应该拥有路线图，但他们还应该提供适当的透明度，要理解这是基于很多人的输入做出来的，而不是产品经理一个人说了算。</p>    <p>你应该把整个路线图展示给内部团队看。产品经理了解到的有关即将发生的一切都应该让未来要开发或者支持它的人提前知道。在向老板、董事会或者客户展示路线图版本时你可能会想削减一些东西。有时候是因为你不想泄露给竞争对手知道，因为你做的事情的确是很机密的。也可能是因为一些东西很普通，客户或者董事会并不感兴趣。路线图的展示内外有别（稍微不同的版本区别）是很正常的，只要讲述的故事基本一样就行。</p>    <p><strong>分配时间段而不是日期</strong></p>    <p><strong>问：你们的路线图上面看不到日期。你曾经说过产品经理应该关注范围更大的时间窗口。为什么要强调这一点？</strong></p>    <p>答：这把发生在发布计划中的可交付成果区分出来。也就是那些马上开发出来的东西。我们是按照日期开发但只会每隔2到4周推出一次，会进行若干次冲刺，除此以外的任何东西基于我们收到的反馈对变更都是开放的。还有根据竞争对手所做的事情、市场的变化情况，客户向我们提出的需求等了解到的新东西。这让我们可以更加灵活并根据我们看到的市场情况来做出变更。</p>    <p><strong>问：我们写了很多有关路线图结构方面的东西，我们（Intercom）会展望6周到6年的情况。你们的组织原则是什么？</strong></p>    <p>答：我们按照目前、近期、未来三个阶段来规划。一般而言，我们会展望2个月、6个月以及以后的事情。实际上这跟Intercom的做法没有太大的区别。我们听说别人的做法是分成现在、下一步以及未来三阶段，或者333格式。形式不拘，具体看哪种做法最合适自己。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/559d3a9174ee4e7f696292930c8ac5c8.jpg"></p>    <p>目前：特定范围、关注的颗粒度领域、规范与设计、不那么灵活</p>    <p>近期：关注范围广、有一定的灵活性</p>    <p>未来：顶层设计、宽泛的范围、灵活</p>    <p>有关路线图大家往往会按照历年去思考。他们看着路线图会说：“这是今年我们可以做的事情，”然后就把此后的事情切割掉了。在现实当中，一个规模小一点产品还没成熟的公司只能、也只需要看到未来3到6个月后的发生事情。他们没钱再看到更远的未来。他们还没有客户。而一家更成熟的公司可能会考虑2年、5年乃至10年后的事情。</p>    <p>路线图的幅度应该取决于产品本身以及公司的成熟度。但是时间分割按比例缩小，而时间范围按成熟度相应拉长的做法是很有意义的。</p>    <p><strong>问：着眼于短期可交付成果时，显然监控这个过程并了解什么样的交付成果比较现实会容易很多。而对于那些几年后的大图景目标，多久需要进行修订或者更新呢？</strong></p>    <p>答：如果你改变了基本愿景的话更长期的那些东西就应该修订。这个东西应该在公司层面去执行。3年后他们所设想的市场还存不存在？他们是不是还处在合适的位置？</p>    <p>一般而言随着公司发展，如果他们取得成功的话，实际上是会打开思考更遥远未来的能力的，这会让他们对于改变原先要追求的东西、拿下更大的市场拥有更开阔的愿景。对于任何公司来说修订自己的愿景都是很自然的事情，因此路线图大概每年调整一下也是正常的。</p>    <p><strong>衡量成功</strong></p>    <p><strong>问：在路线图的事情上你跟很多初创企业都打过交道，你发现有哪些东西是他们需要避免的？</strong></p>    <p>答：我发现产品经理或者小公司经常会犯的一个错误是一张路线图由完全不同的功能构成。如果公司还年轻，刚刚才把MVP（最小可行产品）做出来，只有一小部分客户提供给反馈的话，那么有一个小的待实现功能集一点问题都没有。但慢慢发展下去你就会看到路线图上黑压压的一大片功能堆积到一起，这时候你就开始需要把它们围绕着待解决问题的类型按照主题进行分组了。</p>    <p>如果你正在开发MVP可能接下来大概会有10件左右的待办事宜，但随着你开始搭建更大的路线图，你需要传达的是一个更大的故事而不仅仅是“我们准备要发布这些功能，让我们看看会发生干什么吧。”</p>    <p><strong>问：大家可能会沦为功能清单受害者的原因之一是往往会往路线图添加日期，以此作为展示成果的检查清单。如果去掉日期的话产品经理如何才能衡量自己的成功并向领导层证明自己呢？</strong></p>    <p>答：产品经理难以考核是出了名的。但是衡量产品的成功却很简单。产品流行与否有指标和目标——转化率、收入或者增长目标这几个尤其常见。</p>    <p>在这中间的产品经理并没有很容易跟踪的东西。跟开发团队不同，他们不能按照完成的工单数或者工作时长来衡量。也不想销售人员可以设定销售目标额。他们也没有支持人员的客户成功指标。产品经理往往是把这些东西糅合起来一并衡量的，同时还包括他们在团队当中工作得怎样。所以对他们可能要进行360°的考核。</p>    <p><strong>学会如何说“不”</strong></p>    <p><strong>问：你写过一篇很棒的文章：《你的老板有没有绑架你的路线图？》。我们讨论了很多产品经理必须对请求说不的事情。那他们究竟应该如何对老板说不呢？</strong></p>    <p>答：产品经理经常需要对老板说不的主要有两件事情。一是对指定日期说不。短期的预期是你要就这一日期给出一个范围，比方说大概一个月左右做出来。这是在你的团队能够洞悉所发生的事情基础上做出的。但从长期来看，需要指出的是像资源这类的东西是未知的。因此这两个都不能确定日期。</p>    <p>你可以对着老板说：“你要求的是一个一年半载后的时间点。我们不知道团队规模能有多大。我不知道我们是否拿到那笔钱或者找到合适的人。这种情况下我怎么能给出具体日期呢？”</p>    <p>另一件可能需要说不的未必就是功能方面的事情。利用像产品愿景、目标这样的东西去指出一个东西是否与之一致是很很重要的。如果你感觉不一致就要提出质疑。询问为什么他们认为某个东西很重要。你可能要指出你的HiPPO（拿钱最多的人的观点）愿景跟你的不一样，这种情况下这个问题要比特定功能方面的问题要根本性得多。</p>    <p>你还可以利用测试和数据来支撑自己。如果你只是用观点对抗HiPPO，你会输掉。但如果你可以测试和证实某个东西是否有效，或者以他们预期的方式推动事情进展，那你可以先做再致力于开发更加宏大的东西。</p>    <p><strong>问：无论是从领导还是客户的角度，你在ProdPad时什么时候会对功能请求说是？这些请求需要符合什么标准？</strong></p>    <p>答：最起码要有一个以上的客户提出了请求，然后这个东西必须符合我们的愿景。它还必须切合我们正在盯住的更广泛的主题。此外这里还有一些直觉的因素。我们会跟客户交谈，找出他们想做什么，然后提出“这个东西我们是不是也觉得对我们或者其他客户有用？这个东西是不是也应该符合我们做的别的东西？”这样的问题。</p>    <p>这可以启发很多的交流。只要我们从客户那里打听到了新东西，我们就会去找其他客户询问是否遇到类似问题。要找出困扰他人但我们可能此前从未听说过的问题。结果往往是一位客户请求的东西在其他客户那里也会有类似额度需求，这样的话路线图就值得为之留出一席之地。</p>    <p><strong>其他</strong></p>    <p><strong>问：你怎么知道什么时候该推出新版本而不是逐步发布许多的改进？</strong></p>    <p>答：当我们意识到原有架构不足以支撑新的客户规模、在性能上难以实现更加稳定更快时，我们觉得最好的办法还是搭建新的平台然后互补迭代前端。</p>    <p><strong>问：产品管理方面最近有哪些观点和哪些人值得留意？</strong></p>    <p>答：随着产品管理的演进最近我们看到对产品管理的领导艺术情调得很多——也就是产品管理当中的人的管理方面，要有一支产品人团队。大家可以关注一下Pluralsight的CXO Nate Walkingshaw。实际上他写过一本有关产品领导力的书。我在Mind the Product的联合创始人Martin Eriksson也值得留意。</p>    <p><strong>问：你怎么看AI未来几年对产品管理的影响？</strong></p>    <p>答：这是个好问题。我们曾经讨论过人工智能会如何取代产品经理的事情。争论的焦点是产品管理是否天生就是一个需要创意的领域，所以一直都需要有人的参与，还是从理论上来说这个东西可以被机器人替代。实际上我们并没有得出结论，但我认为随着时间转移我们将看到产品管理很多简单乏味的工作会被取代。产品经理大量时间将花在简化规范或者针对此前产品经理做过的同样事情设计实验上面。现有产品人和产品团队可用的工具比以前多多了，这可以帮助他们把更多精力聚焦到提出更大的问题解决真正问题上面而不是整天写规范。</p>    <p> </p>    <p> </p>    <p>来自：http://36kr.com/p/5064475.html</p>    <p> </p>