公司产品团队论坛：Product Day 议程

产品团队论坛将产品组合、跨团队依赖关系和领导决策联系起来。我们解析 Product Day 的议程、角色、材料准备以及活动后的跟进工作。

公司的产品团队论坛，即内部 Product Day，用于解决无法在单个团队会议中容纳的问题。在论坛上，参与者共同梳理产品组合全貌，发现跨团队依赖关系，讨论限制条件并记录决策。此类活动的价值取决于工作成果：产品组合地图、依赖关系登记册、决策日志以及明确的后续行动。

我们 Aventura 负责论坛的活动架构：议程、脚本、参与者路线、场地、技术环境以及成果记录。产品数据、优先事项和决策权仍归客户所有。这种分工需要在选择演讲者和场地之前就确定下来。

公司什么时候需要产品团队论坛？

简而言之：当多个团队依赖共同的平台、数据、渠道、专家或管理决策时，就需要论坛。常规的同步会已经不够：每个团队只看到自己的一小块，而优先级和资源冲突仍留在各部门之间。

第一个迹象是：一个团队的决策会对其他团队产生影响。新版本发布需要平台改造、数据访问、法务审批、销售支持或调整共同的客户旅程。如果这些关联在不同的日程中讨论，整体图景就会支离破碎。

第二个迹象是：管理层不得不在接连的单独汇报之后去比对各项举措。各团队展示自己的路线图和指标，但使用的格式各不相同。结果，时间都花在了转换和澄清原始数据上。组合选择被推迟到一场闭门会议上，参与者事后才知道其背后的逻辑。

第三个迹象是：争议需要跨团队层面的权限。团队可以自行明确假设或任务顺序。而关于重新分配共享资源、叫停某项举措或变更承诺的问题，则应由负责的主管来决定。GOV.UK 的敏捷交付原则主张及时决策、在合适的层面决策，并让相关人员参与。对论坛来说，这是一条有用的边界：进入议程的，是那些无法通过常规团队会议解决的问题。

如果客户没有共同目标、选择标准和有决策权的人，那么论坛就为时过早。再大的会场也无法弥补未经准备的数据。首先需要收集分歧，并确定其中哪些需要共同协作来解决。

与 Demo Day、黑客松和战略会议的边界

要点：活动名称并不决定形式。Demo Day 展示已准备好的成果，黑客松为创造解决方案提供时间，战略会议选择方向，而论坛则把现有产品组合、团队、限制条件和后续步骤连接起来。

一个 Product Day 可以包含演示、工作会和负责人发言。但重心仍应只有一个。否则参与者会得到一份冗长、承诺各异的议程：一些人被要求展示工作，另一些人被要求构思新东西，还有一些人被要求协调资源。

在 Scrum 中，Sprint Review 被描述为一次用于检查成果并讨论后续调整的工作会。不建议将其限制为演示。这一原则对论坛同样有用：演示应当为提问或决策提供素材，否则就会沦为一场屏幕秀。

如果主要任务以展示已准备好的项目和针对每个项目做出决策而告终，最好采用单独的企业项目演示日。对于比较实践和文档的专业社群来说，了解企业技术专家论坛如何组织会很有帮助。产品论坛的不同之处在于其工作对象：它连接常设的跨职能团队、产品信号、路线图和共同限制条件。

当天结束前必须做出的决策

产出： 在拟定议程之前，需要记录团队会面所要达成的决策。对于每个问题，设定预期结果层级：最终选择、建议、缺失数据清单、指派行动或上报。

“同步团队”这一说法无法给脚本撰写者提供可执行的任务。应该把它拆解为具体问题。哪些举措需要共同资源？两个团队在哪里承诺了互不兼容的期限？哪些依赖关系会带来关键风险？管理层需要在哪些议题上确认选择？

我们从决策地图开始。其中包括讨论议题、筹备负责人、参与者、拥有批准权的人，以及论坛可接受的结果。如果无法在会场内做出决策，就需要如实确定论坛将为下一步准备什么。

可以方便地把问题分为四组：

1. 团队自行决定，并将结果告知其他人。
2. 多个团队就共同行动达成一致。
3. 负责人确认优先级或化解冲突。
4. 问题需要补充数据，并获得后续跟进的负责人。

并非每个争议都必须当天得到答案。有时，高质量的成果是明确缺少哪些数据、由谁收集，以及参与者何时会重新回到选择上。这比在缺乏成本、风险和承诺信息的情况下进行形式化投票更有用。

Atlassian 关于决策的材料描述了角色不明确时反复讨论的问题。对论坛而言，结论很直接：参与者必须知道自己在哪些环节提供贡献、在哪些环节形成建议，以及由谁批准最终结果。投票机制收集的是受众信号，但不能取代决策权。

参与者构成与角色

简要：参与者根据其对决策的贡献来选定。论坛需要产品背景、技术限制、用户数据、商业承诺和共享资源的负责人，以及能够确认下一步的管理者。

仅有产品经理参加的论坛会呈现不完整的图景。产品决策可能取决于架构、研究、分析、支持、销售、营销、运营、财务或法律限制。GOV.UK Service Manual 将数字服务工作与跨学科团队以及真正做出决策的人员的参与联系起来。

参与者构成取决于议程。没有通用的职位清单。我们建议逐一梳理每个议程模块，并回答三个问题：谁确认原始数据，谁看到决策的后果，谁有权决定下一步。

HR 和内部沟通团队帮助召集受众、解释目标，并将结果反馈给参与者。他们不应替代产品决策负责人。活动团队也不应为 CPO 或产品组合负责人决定优先级。

我们分别指定每个决策的负责人和论坛本身的负责人。前者对议题内容负责。后者统筹议程、材料版本、权限和变更。这种划分降低了组织任务与产品结论落在同一个超负荷角色上的风险。

我们将议程、主持和制作决策的解析发布在 Aventura 的 Telegram 频道。

论坛前需要向团队收集哪些内容？

工作原则：每个团队准备的是可对比的预读材料，而不是随意的演示文稿。其中需要包含问题或机会、目标受众、数据、预期结果、限制条件、依赖关系，以及对其他团队或管理层的一个具体请求。

材料应在带舞台调度的彩排之前收集。如果一支团队带来指标和备选方案，另一支带来发布历程，第三支带来广告片，它们就无法比较。最后一周的编辑修改无法弥补共同问题的缺失。

我们采用一页或多页简短的团队档案：

• 产品目标或问题；
• 用户或内部客户；
• 信号：指标、调研、反馈或承诺；
• 此前做出的决定及考虑过的替代方案；
• 预期结果；
• 风险或未知因素；
• 对团队、平台和公共职能的依赖；
• 对论坛的具体请求；
• 允许的材料披露级别。

在这样的材料包中，Roadmap 用于将目标、举措和预期结果联系起来。Product School 和 Aha! 将路线图描述为传达整体图景并将战略与工作联系起来的方式。对于论坛来说，发布日历是不够的。参与者需要理解下注依据、预期变化、限制条件和选择点。

可以提前阅读的事实材料，我们放入预读材料中。GitLab 的公开 handbook 描述了 live-doc meetings，以及同步对话与共享文档之间的联系。我们并不建议照搬某一家公司的流程。实用的原则是有益的：会场时间最好留给提问、冲突和修改方案。

材料、受众、流程和限制条件的清单，适合固定在企业论坛技术任务书中。在此基础上，我们规划议程、场地、设备、导视和团队构成。

Product Day 议程架构

简而言之：议程从整体框架推进到分组研讨，再到统一确认。参与者先了解目标与筛选标准，然后围绕自己的议题方向开展工作，最后看到决策、负责人以及后续安排。

我们 Aventura 围绕参与者的行动来构建论坛与研讨会的组织。首先弄清人们在何处聆听整体背景、比较各项倡议、梳理依赖关系、观看演示并做出决策。然后据此挑选会场、舞台、屏幕、网络以及转场时间表。

工作动线可能如下：

1. 管理层给出整体框架：目标、筛选标准、限制条件以及当日议题。
2. 简短的项目组合综述：各项倡议与关联的整体图谱。
3. 专题研讨：产品押注、用户信号、技术限制。
4. Dependency clinic：处理关键的跨团队依赖关系。
5. 针对那些需要现场演示来佐证论点的议题进行演示。
6. 如有必要，为敏感决策设置闭门环节。
7. 统一决策节点：哪些已决定、哪些需要更多数据、由谁继续推进。

主舞台用于传达每个人都应同样听到的统一背景。细节工作更适合在小会议室或工作台进行。最后环节再次将参与者聚在一起，但不是为了重复所有报告。主持人展示整体图景的变化并说明下一步行动。

并行分会场需要有明确的动线。每位参与者都应有清晰的选场逻辑，而组织者则需掌握房间容量、转场时间以及将结果汇入总记录的方式。如果某个小组的成果没有进入最终确认环节，它就只是一次局部讨论。

对于大型商务活动，我们将内容、物流与技术支持整合在商务活动的组织中。客户在此过程中始终掌握产品议程的内容主导权，并确认所有结论。

工作形式代替一系列报告

简要说明：当报告能快速建立共同语境时，它是合理的。而进行比较、风险分析和行动协调，则需要工作形式：圆桌会议、clinic、方案复盘、投资组合地图、failure review 或围绕文件的协同工作。

一连串演示便于安排日程，却很难改变团队的工作方式。每位演讲者讲述自己的故事，提问被压缩，而各场发言之间的联系只留在听众的笔记里。结果是论坛看起来内容充实，但决策往往在活动之后才出现。

我们根据所需的行动来选择形式：

错误复盘需要安全的主持。我们讨论决策和条件，分别审视决策时已知的信息，以及后来才明确的信息。我们不会把承认错误变成各部门的排名。

对于复杂案例，主持人会提前拿到问题、可用数据和讨论边界。他的任务是让对话保持在请求范围内。如果参与者在问题尚未达成一致前就深入到实施细节，主持人会把他们拉回最初的选择。

如何开展项目组合评审？

简而言之：项目组合评审用统一模板对各项举措进行比较。团队展示目标、预期成果、依据、限制条件、依赖关系和所需决策。幻灯片的精美程度和已发布功能的数量不应取代实质内容。

评审从全局地图开始。在地图上可以看到产品方向、各项举措、共享平台和重大依赖关系。随后，团队只展开那些需要其他参与者视角或管理层抉择的事项。

对于每一项押注，七个字段就够了：

1. 团队正在考虑什么问题或机会。
2. 它对谁重要。
3. 哪些数据证实其现实相关性。
4. 预期成果是什么。
5. 已知有哪些限制条件和替代方案。
6. 下一步取决于谁。
7. 论坛上需要做出什么决策。

主持人不会要求团队为整个路线图辩护。他会就争议环节提问。如果数据充分，由指定的负责人确认选择。如果依据薄弱，团队会收到一项核查任务。如果冲突涉及共享资源，该问题会转入由该资源负责人参与的决策窗口。

这种环节的反模式是“绿色状态大巡游”。参与者听到一切按计划进行，却看不到已停止的假设、延迟的代价以及向其他团队提出的请求。我们建议每次评审都以一个明确的结论收尾：继续、调整、停止、核查数据或上报。

决策记录人当场在屏幕或共享文档中写下结论。参与者能看到文本，并可在进入下一个议题之前消除歧义。最终记录应当让未在场的人也能看懂。

Dependency clinic 与跨团队联系图

答：只有当双方、负责人、所需行动、延迟后果和控制点都被指明时，依赖才变得可用于工作。两张卡片之间没有这些字段的连线只表明存在联系，但无法设定后续工作。

Atlassian 在 dependency mapping 方法论中建议提前识别依赖关系和风险、指定负责人、规划风险缓释并确定反馈节奏。对于论坛而言，这是单独工作环节的基础。

活动前，各团队将已知的联系录入统一登记册。在论坛上，参与者核查关键依赖，找出讨论中缺失的人，并明确行动。我们不承诺在会议室里解除每一个阻塞。如果没有权限或数据，结果就变成升级路径。

依赖卡片包括：

活动之后，这张图必须有负责人。墙面的照片不能替代登记册。所有卡片都要转入团队已经在开展产品工作的数字环境。工具的形式由客户选择。

在会议环节，最好把联系双方的人聚在一起。如果一方缺席，讨论很快就会变成对他人能力的猜测。此类问题应记录为未决问题，而不能当作已商定的计划。

领导层的角色与闭门会议

基准：领导层需要出现在那些其权限能改变结果的环节。开场致辞不能替代对优先级、资源和升级路径选择的参与。敏感问题可以放入闭门会议室讨论，但决策逻辑必须在允许的范围内回到团队。

论坛之前，我们会将决策者的日程与议程进行核对。如果 CPO、CTO 或业务负责人只出席开幕式，有争议的问题又会进入“待审批”。因此，决策窗口会安排在已确认的时间，并提前将预读材料发给负责人。

广泛的参会者可以讨论用户信号、依赖关系、执行方案和后果。关于人员、机密数据、投资限额或尚未公布的战略的问题，可能需要闭门讨论。边界由客户批准的访问矩阵决定。

闭门会议不应让整个论坛变成摆设。会后团队会得到明确的状态：决策已通过、问题推迟至数据齐备、另行安排会议或优先级已变更。细节可以受限，但参与者需要知道下一步做什么。

对每项决策，最好在允许的范围内保留依据。“领导层决定了”这句话很快就会失去上下文。记录下“因共同承诺确认优先级；团队 A 更新计划，团队 B 检查依赖关系”有助于执行并减少重复争议。

如何设计混合活动、演示和技术备份？

简而言之：远程参与者应能提问、处理文件并影响决策。每个 live demo 都需要经过确认的备份方案，而录制、路线图展示和资料访问的规则应在技术彩排之前确定。

混合形式的 Product Day 不能像一场只有被动聊天室的舞台直播那样来组织。W3C 建议提前考虑参与者的需求、音质、字幕或文字转录、重要视觉信息的描述以及资料的可访问性。现场提问必须对着麦克风重复，否则远程观众会错过部分对话。

对于分布式团队，我们建立统一的数字事实来源。其中包含会前阅读材料、工作模板、决策日志和已获准使用的资料。每个房间都需要有人负责远程环节，并将问题带回讨论中。

如果公司需要完整的混合活动组织，我们会分别搭建演播室和线下两条路线：连接、声音、屏幕展示、投票、小组工作和成果传递。单一平台无法自动解决这项任务。

我们将 live demo 作为一条生产链路来检查：环境访问、产品版本、账号、网络、线缆、信号源切换、界面缩放以及数据展示许可。备份可以采用经过确认的录制、截图或静态流程。替代方案必须能够支撑当初将演示纳入议程所要表达的核心论点。

衔接环节最好在活动技术彩排中进行演练。彩排会检查最终文件、各流程之间的切换、访问权限、备份、保密数据的显示以及将决策记入总日志。没有这些衔接环节的演讲排练无法体现论坛的准备就绪程度。

录制规则应提前确定。参与者会收到录制通知，并根据客户规则和适用法律取得必要同意。客户还规定访问权限、存储期限和资料的允许使用范围。在讨论敏感话题之前，参与者必须了解录制模式。

交付成果、指标与下一步

简要说明：论坛结束后，留下的是可用的文档和后续日程。应当评估的是决策的推进情况：是否指定了负责人、是否更新了依赖关系、是否补齐了缺失的数据、参与者是否回到了各控制节点。来宾的感受可以补充这一图景，但不能替代它。

Product Day 之后的最小交付包包括组合图、依赖关系登记表、决策日志、待解决问题清单以及已获授权的材料。日志中每条记录都要写明表述、依据、负责人、后续参与人员、缺失数据、访问权限和控制节点。

结果有四种状态：

1. 决策已记录并得到参与者确认。
2. 负责人已承接下一步行动。
3. 行动已在控制节点前完成或更新。
4. 产品成果或业务成果已由负责人在公司实际工作闭环内得到验证。

论坛可以高质量地完成前两步。其余的则取决于活动之后的常态化管理。因此，不能在没有客户数据的情况下，把产品上市提速、财务指标增长或参与度提升归功于这一天。

活动之后，不妨核查组织层面的指标：工作组是否达成了既定成果、时间是否足以做出决策、材料是否易于获取、音频、转场或访问权限方面在哪些环节出现了问题。这些观察有助于改进下一个周期，但不能证明产品层面的效果。

新一届论坛的筹备从简短的需求简报开始。其中需要包含业务任务、团队构成、争议问题清单、决策权限、访问权限以及预期交付的文档包。之后，我们会制定议程架构、场地、技术方案、角色分工和预算。

来源

• Scrum Guides: Scrum 官方指南
• Atlassian Team Playbook: dependency mapping
• Atlassian Team Playbook: 决策与角色
• GOV.UK Service Manual: 跨职能团队
• GOV.UK Service Manual: agile delivery 管理原则
• Product School: product roadmap
• Aha!: product roadmap 指南
• W3C Web Accessibility Initiative: 无障碍活动与演示
• GitLab Handbook: all-remote meetings