管理开源产品路线图

在本系列关于开源软件供应链的前四个部分中，我探讨了 开源作为供应链、什么是产品、产品经理做什么，以及 如何将开源软件产品与其上游项目区分开来。在本文中，我将讨论路线图的基本要素以及如何确定这些要素。

客户以及与他们交谈的销售和营销团队都喜欢路线图。 它让他们了解什么是现实的，什么是不现实的。 路线图也是产品的核心。 维护最新的产品路线图可使产品团队专注于客户，并围绕交付他们所需的产品保持一致。 路线图传达了产品的战略方向以及公司解决问题的视角。

专有产品的路线图和建立在开源供应链上的路线图之间有什么区别？ 差别不大。 产品经理与客户交谈、对他们的需求进行排名、制定路线图，然后弄清楚如何通过构建、购买和合作来交付功能。

将路线图视为产品的飞行计划。 飞行员可能需要根据天气、健康紧急情况或机械故障进行更改，但他们必须始终从飞行计划开始，否则他们无法起飞。 产品也是如此。

专注于市场问题

产品经理面临的最大诱惑之一是迷失在更大的图中，而专注于他们从客户那里听到的最后一个问题。 仅关注最新问题会导致目标的永久性变化，这将使工程团队和合作伙伴感到厌倦。 产品经理的影响力植根于信任，信任植根于一致的行为，而一致的行为植根于信心。

信心始于识别市场问题。 当一位客户告诉您某些事情时，这可能是一个侥幸。 当 100 个客户告诉您某些事情时，这是一个问题。 单个产品经理可能无法从 100 个客户那里获得反馈，因此他们需要一个系统来从他们可以获得的每个地方获取输入：客户、销售人员、其他产品经理、产品营销人员、会议上的用户以及相关来源。

客户有许多类型的问题，但市场问题是您的目标客户乐于付费解决的紧急挑战。 这是一个使人们更有可能购买您的产品或续订（如果是订阅）的问题。 解决由客户需求验证的市场问题可以推动您路线图的创建。 您的路线图永远不会让每个人都满意，但它可以帮助协调您的产品与购买它的客户之间的策略。

通过影响力进行管理

一旦您确定了您的产品可能解决的现实问题，您就必须弄清楚如何解决这些问题。 这些解决方案称为特性或在销售中称为功能。 一位优秀的产品经理意识到，特性远远超出了工程师构建的技术内容。 特性绝对可以是工程团队构建的一段代码，但它们同样可以是法律团队提供的某些内容，例如赔偿，甚至是服务团队提供的安装指导。 这些特性指导着产品路线图。

那么，产品经理如何实现他们的路线图呢？ 他们通常不编写代码——而且他们可能不应该——而且他们通常不控制预算或与合作伙伴签署交易。 事实上，他们无法直接控制任何人：客户、工程师、合作伙伴、记者、分析师，尤其不是竞争对手。 相反，他们必须通过影响力进行管理。

当产品团队拥有一组已通过客户验证的市场问题时，影响必要的人员来实施特性会容易得多。 无论该特性是由上游项目、下游工程师、服务团队还是法律团队交付的，情况都是如此。

建立影响力对于上游开源供应商尤其重要。 一些产品经理认为他们无法控制上游项目，因此他们认为更容易 分叉 项目并更改他们需要的内容。 不要分叉：它成本高昂、质量通常较低、更难维护，而且您会失去所有有价值的上游用户测试。 正如制造商影响其主要上游供应商一样，开源产品经理也应该参与上游项目，建立信任并利用他们的影响力。

客户与竞争对手

复制你的竞争对手总是一种诱惑。 关注竞争对手永远不是一个坏主意，但不要将其置于客户需求之上。 相反，通过直接与您的客户交谈并确定他们正在寻找的功能，来解决客户的业务问题。 如果您知道您比竞争对手更快，但你们都没有解决业务问题，那么客户不会为你们中的任何一个付费。

也就是说，请注意竞争对手对潜在客户的营销和信息传递，因为它会深刻影响客户沟通他们的问题以及他们对功能提出的请求的方式。 有时，竞争对手可以说服客户他们有一个问题，只有竞争对手优势之一的特性才能解决。 遵循竞争对手的领导并不是确定市场问题或解决它的最佳特性的方法。 将竞争对手的活动用作输入，但不要让它指导您的路线图。

承诺并展示路线图

一位优秀的产品经理非常了解他们的产品并且热爱它。 他们也了解并热爱他们的客户。 没有什么比在展示路线图时感到兴奋更能体现这一点了。 路线图既是产品经理的客户对话的输出，也是产品团队代表客户施加的影响力的输出。

产品经理只有在完成以下所有操作后才能提交路线图项

• 识别市场问题
• 通过多个客户和其他影响因素对其进行验证
• 与上游工程、法律、质量工程、性能工程和其他合作伙伴合作，以确定他们可以解决该问题
• 确定合理的成熟时间

就是这样。 这就是构建路线图所需的一切：市场需求和在一定时间内交付的承诺。

永远记住，您的产品不仅仅是其上游供应商。 将开源视为上游供应链，但将您的产品视为包含解决问题特性的超集的下游解决方案。 整体的总和应大于各个部分，而您的部分工作是将该总和与市场上的其他产品区分开来。 路线图应提供差异化的特性和功能，包括

• 特定于产品的功能——而不是供应商的功能
• 可供客户测试的功能（在 beta 测试或技术预览中）
• 可供客户在生产中使用的功能（通常可用并已启动）

优秀的路线图将被您的客户、销售人员、营销人员和其他产品经理使用。 此外，如果您的产品专注于技术用户，开发人员和架构师会依赖路线图将您的产品集成到他们的产品中。 如果您的产品是技术平台或服务（例如，基于 Linux、Kubernetes、Java 或虚拟机），您不仅从上游供应链消耗，而且还是您的客户创建的下游产品的供应链的一部分。 这使得可靠的路线图变得更加重要。

其他考虑因素

关于市场问题、特性以及产品团队应使用哪些工具，很可能会引发并进行几场圣战。 因此，我特意避免提及任何工具。 需要传达的重要部分是，路线图应以客户的需求和愿望为中心。 产品团队的工作是根据这些需求交付功能。 如何跟踪这一点未在本文中专门介绍。

本次对话中遗漏的另一个细微差别是上游项目路线图。 谁负责？ 上游项目不是产品，而且很少有人负责上游项目的长期路线图。 对于 OpenStack、Kubernetes 或 Linux 内核等大型项目，有一些开源项目经理和架构师专注于路线图。 这实际上使开源产品经理更容易，但大多数较小的项目（仍然可能是您的产品的关键供应商）没有超出下一次或两次发布的上游路线图。

路线图对客户、销售人员、营销人员和其他产品经理很有用。 此外，如果您的产品专注于技术用户，路线图对于依赖它们将您的产品集成到他们的产品中的开发人员和架构师非常重要。 如果您的产品是技术平台或服务（例如，基于 Linux、Kubernetes、Java、虚拟机等），您不仅从上游供应链消耗，而且还是您的客户创建的下游产品的供应链的一部分。 这使得可靠的路线图变得更加重要。

您的路线图永远不会让每个人都满意，但它可以帮助协调您的产品与购买它的客户之间的策略。 这与开源和专有软件产品一样重要。