对于开发人员和产品经理来说，演示产品路线图可能会令其手足无措；一方需要努力提出一个愿景，而另一方则要等待将会影响其工作的未知事件的发生。
当我以开发人员的身份工作时，真的感受到了这种紧张，我经常发现自己对产品管理部门制定的路线图不满意。我不能完全认同这些决策，而且我经常会在规划会议结束时抱怨：“这对我来说毫无意义，但如果他们这么认为的话……”，更糟糕的时候，我会想：“我们必须自己弄清楚事情的来龙去脉，然后假装我们很适合这一路线图。”
您可能会争辩说问题是我可能患上了 NIH（非我发明症），您也许是对的。作为一名开发人员，我对怎样做才是正确的有着强烈的执念。但现在作为一名产品经理，我看到了造成这种脱节的原因，以及产品经理可以从这种脱节中汲取哪些常识，从而在路线图演示中大获全胜。毕竟，如果技术团队能够同意并理解大局，日常的设计和实现决策将在正确的背景下做出，您也由此可以获得您所预想的产品。
下面是我认为通过演示产品路线图赢得团队认可的十大途径。
1. 选择实质性内容而非流行语
虽然“大数据分析”、“机器学习”或“物联网计划 (IoT)”等流行词可能会作为高层锚点引起业务利益相关者的共鸣，但它们对技术团队没什么用，并且也不具有可操作性。工程部门需要确切了解自己在构建什么东西，这个东西与当前产品的关系，应该如何交付，最终由谁来使用，以及要用于什么用途。
设置高级别主题对于构建路线图和背景来说非常有用，但一定不能止步于此，而一定要对每个高级别项目背后的内容有良好的解答。例如，如果您以“智能服务”为主题，则一定要将其分解成为实现这一主题，需要执行的关键计划和战略举措。
2. 设置正确的背景
技术团队需要获取一些背景信息，了解您为什么要在路线图上构建某个东西。没有技术团队会说：“直接告诉我您需要什么，我去构建。”相反，工程师们需要看到您所发现的功能需求的证据。让数据说话，但也要从用户角度讲述有水说服力的故事。使用人物角色，谈谈您所排除的替代项及其原因。为帮助整个团队理解路线图，“为什么”和“是什么”同样重要。
3. 慎重对待承诺
如果某项功能似乎没有经过深思熟虑或者不现实，但仍出现在了路线图上，则应发出危险信号。您不希望让技术团队感觉，仅仅是因为您向他人做了某个承诺就导致他们必须构建某个东西。可能是对客户的承诺，也可能是因为“管理层想要这样”。因此，一定要理性承诺。即使您的身后有一股强制力量迫使您必须做出特定改变，您也一定要理解其理由，并将其传达给团队，然后自己做坚强的后盾。
4. 制定切合实际的计划
好的愿景很重要，但更重要的是要让每个人对实现愿景充满信心。计划不一定要很精确，但如果您的开发经理查看路线图时，首先看到的是巨大的瓶颈（比如，路线图看起来设计繁重且以前端为中心，但团队中只有一名设计师，并且过去几个月里一直在前端话题中举步维艰），那么在您接下来的所有演示当中，他或她都有可能很难接受这个路线图。
确保事先与团队一起核实现实情况，并做出假设。在寻求每个人的承诺之前，您需要对“如何实现”这一问题有自己的答案，有明确的行动计划并进行简明的考虑。
5. 从大处着眼，从小处着手
您需要非常清楚产品和团队技能当前处于怎样的水平，以及您希望其达到的水平。进入新领域固然很好，这可能需要团队运用新的技能而摒弃现有技术，但是不能一味地只写一年后您希望实现的梦想，还要思考在现实条件下如何实现。获取人才需要时间，采用新技术也需要时间，放弃现有产品则需要明确的承诺和过渡计划。
6. 构建商业案例
商业案例？是的。技术团队会非常关心商业案例。可能在程度上不同于高级管理层，但整个开发团队都会非常关心为什么某个东西对企业很重要，这个东西能否产生实际的效果，以及具体要如何衡量。一定要利用技术团队的商业实战经验。每个人都是企业取得整体成功的既得利益者，这一点可以成为获得反馈或其他想法的绝佳来源。
此外，清楚地了解业务影响并见证其发生可能也是个不错的激励因素；除了构建和发布一项功能外，推动结果的实现也总能给人以成就感。
7. 在平凡与激励之间取得平衡
工程师们都希望打造出其引以为豪的独创性产品。如果只是老生常谈，确实很难提起他们的兴趣。一定要做好研究，确认您的故事像您想象的一样具有创新性。除了提不起开发人员的兴趣外，缺乏创新性对商业的影响更为严重。
话虽如此，均衡的路线图始终要在激动人心的新功能与技术上没那么有趣，但必须要做的必需品之间做出平衡。尽量确保即使是平凡的事物也能在您的路线图上产生激励作用。
8. 超越 MVP 和 v1 进行思考
先创建最小可行产品，再创建版本 1 是一回事，发布后又是另一回事，因为会有很多事情发生：运营、维护、用户的功能请求、持续改进以及所集成的其他产品和/或平台的新版本。快速思考发布后可能存在的挑战和障碍，这样不费吹灰之力就能暴露出问题，工程师们也会非常感谢您没有忽视这些现实情况。据粗略估算，构建新功能的初始工作通常仅占该功能在整个生命周期内全部工作量的三分之一到一半。换句话说：后期工作比前期工作要付出更大的努力，所以从长远来看，一些“快而小的东西”也可能带来巨大代价。
9. 顺势而为
做好估算很重要。估算可以为您提供指导，并且都是在每个特定时间点根据产品经理掌握的所有情况的基础之上创建的。不过，您在开始实施或完善设计时会发现，估算时做出的很多假设可能存在严重错误。一定要做好准备并对应呈现路线图，以便其能够灵活应对变化。
10. 坦诚相见
制定路线图是为了提供指导，不能作为详细的行动计划，软件团队的所有人都很清楚这一点。没有必要超越其本质进行宣扬。所以，即使您还没有掌握关于某个主题的所有细节，也请保持心态开放。尽管去分享您已经掌握的信息、意图、尚未解答的问题以及还有待解决的最高风险。指出需要进行实验和加深研究以确定其“本质”的领域。只是要记得在规划中，需要将这段实验时间考虑在内。
底线？
您的团队需要一份既能清晰地描绘大局，又不忽略现实的路线图。您的团队还需要一份能够激发斗志、激动人心并且细节充分的路线图，以便整个软件团队清楚地知道接下来的 1-2 个冲刺该做些什么，并且有信心能够取得出色的业绩，并对业务产生重大影响。
是否需要其他帮助？请参阅 Jira Software 中的路线图功能以及 Jira 中的产品路线图模板。或者免费试用专为 PM 设计的 Jira Product Discovery。
