积压事项的规模与我们与客户交谈的频率成反比

积压事项规模 vs. 与客户交谈

• 许多人不同意积压事项规模与客户接触频率成反比这一说法。
• 有人说：频繁与客户对话会产生 更多 请求和积压事项；好处在于更聪明的优先级排序，而不是让列表变短。
• 另一些人则认为：大型积压事项往往是充满假设的陈旧“墓地”；频繁与客户交谈会暴露出更多有价值的工作，并让旧工单明显过时。
• 结论：这种关系很大程度上取决于具体情境（早期初创公司 vs. 成熟产品、产品类型、团队纪律）。

积压事项里应该放什么？

• 一派观点：积压事项只应包含合理短期、可执行的工作；长期想法应放在更轻量的文档或单独工具中。
• 另一派观点：保留一个可搜索的单一系统；使用标签、问题类型、状态（例如“已搁置”）以及自动关闭来管理规模。
• 有些人明确把积压事项当作一种外交性的“是的，我们记下来了”工具；另一些人则称这是一种文化失调，并强调 PM 的职责是清楚地说“不”。
• 还有几位建议分开流程：
  • 原始反馈 / 客户问题。
  • 产品发现 / 机会树。
  • 真正会发生的工作的交付工单。

客户输入 vs. 功能请求

• 一个强烈主题是：客户应该告诉你问题，而不是规定 UI 或解决方案。
• 被指出的风险：对每个请求都反应式开发，会导致产品不连贯、功能堆砌。
• 建议做法：将多个请求综合为根本问题，并设计与产品愿景和业务目标一致的最小化、通用化解决方案。

工具与流程

• 提到的方法：Jira + Product Discovery、Productboard、专门的反馈聚合工具、公开的 GitHub issue 跟踪器、个人笔记。
• 积压事项卫生管理技巧：定期整理、让旧问题过期、WIP 限制、“仅短迭代”团队积压事项、T 恤尺码或价值/成本估算、优先级框架（例如 RICE、机会-解决方案树）。

组织与文化因素

• 大而不健康的积压事项通常与以下因素有关：薄弱的产品组织、PM 轮换、害怕说不，以及未加管理的销售/支持输入。
• 多条评论强调，销售、支持和 CS 是结构化客户洞察的丰富来源。
• 观察真实用户（有时冒充账户）被视为 UX 中极其宝贵的方法，但在某些领域，冒充会带来严重的安全、隐私和合规问题，因此需要强有力的审计与控制。