-
如何在软件产品中向客户征集反馈：时机、渠道与话术
想在软件产品里收到有用的反馈，就要在用户刚完成某个操作后，在他们工作的地方，只问一个具体的问题。本文按时机和渠道给出现成话术，并说明拿到答案后如何回复。
反馈闭环阅读约 1 分钟
-
产品路线图示例：六种格式，以及各自是怎样失效的
本文给出六个带真实条目的产品路线图示例：Now/Next/Later、季度时间线、主题式、结果式、公开路线图和发布路线图，说明各自适合的读者和失效之处。
反馈闭环阅读约 1 分钟
-
重复的功能请求：怎么合并但不丢失原来的声音
合并重复的功能请求能保住数字，但粗心合并会丢掉让某条请求真正有用的措辞。本文讲保留措辞的合并流程、如何识别误判、是否通知提出者，以及功劳记给谁。
反馈闭环阅读约 1 分钟
-
该怎样拒绝一个功能请求，又不失去这位客户
闭环通常意味着告诉某人她要的东西已经发布，真正难的是说不，还要不伤害和客户的关系。本文说明什么让拒绝特别糟糕，好的拒绝怎样开口，并给出可直接使用的话术。
反馈闭环阅读约 1 分钟
-
Feature flag 发布说明：该说什么，又该什么时候说
Feature flag 发布说明必须分清代码合并和真正发布，因为有 flag 时两者不再同时发生。时机不对就关闭反馈闭环，是在通知别人一个看不见的功能。本文讲如何判断时机。
反馈闭环阅读约 1 分钟
-
功能请求应该怎样追踪，才不会把它们弄丢掉
功能请求追踪通常只有两种失败方式：请求无处可去，或有了去处却没人回头看。本文说明能扛住这两种失败的机制、好用的分诊标签，以及如何决定优先级并做好闭环。
反馈闭环阅读约 1 分钟
-
支持工单对功能请求：你到底应该相信哪一个
支持工单和功能请求看板衡量的是两种不同的信号，来自两类不同的用户。把一个渠道的激增与另一个渠道的激增直接等同，只会得出自信却完全错误的优先级排序。
反馈闭环阅读约 1 分钟
-
一条功能请求，实际上很可能是一份缺陷报告
一张要求新增设置项的支持工单，很可能只是在绕开一个隐藏的缺陷。贴错标签会把它送到错的负责人和队列，浪费优先级信号，还拖慢真正的修复。本文讲如何分辨两者。
反馈闭环阅读约 1 分钟
-
功能请求越堆越多的时候，到底该怎样排优先级
功能请求都已跟踪、分组、打好标签后，仍有个更难的问题：该先做哪一个。本文讲几种管用的优先级框架、RICE 是否适合功能请求，以及原始投票数掩盖了什么。
反馈闭环阅读约 1 分钟
-
最终能够真正变成体验日志条目的功能请求模板
功能请求要有用，前提是功能上线时还能把它找出来。本文说明模板该长什么样、把请求分流到正确位置的标签有哪些，以及体验日志之后会读取哪些字段。
反馈闭环阅读约 1 分钟
-
用 issue 追踪系统打造三列式公开路线图
公开路线图归根到底是一份关于未来的承诺，所以要保持精简，直接从已在追踪的 issue 生成，并靠 issue 上的一个标签让项目在各列之间移动。本文说明整套机制。
反馈闭环阅读约 1 分钟
