一周的真实工作
典型的一周混着访谈、分层、写方案和内部演示。每类产出不同的东西，证明标准也不同。
访谈需要原话笔记，分层需要原因和频次，原型需要真实流程和“有没有帮上忙”的判断方式。
按原因给反馈分层
给每条请求标出背后的原因：缺数据、流程慢、职责不清，还是交接断了。功能名不是原因，而原因才是你能解决的东西。
十条请求指向同一个原因时，围绕原因做，而不是围绕声音最大的那条做。这也是最不伤人的拒绝方式。
做最小的可用版本
选一个原因，只做处理这一类情况的小工具。它可以不好看，但必须在这周内被真实任务用上，否则拿不到真实反馈。
把原型和产生它的反馈放在一起。有人问“为什么这样设计”，原因已经在那里。
留下决策记录
记下决定了什么、否掉了什么、什么证据会改变你的想法。产品决策失去理由之后，很快就会变得难以维护。
记录也保护团队：带理由的否定，比每季度都要重新争论一次的否定更容易回看。
该看什么指标
看工具是否被用在真实工作上，而不是看是否上线。然后看它省下的时间和避免的返工。
在反馈侧，记录有多少请求带上了原因。这个数字能预测下一轮优先级做得好不好。
在 Sigla 里怎么做
把反馈、决策记录和原型放在同一个工作区。描述重复出现的原因，做出最小版本，让同事在自己的任务里试用。修改时点名坏掉的那个场景。
想深入搭建过程，可以看「不写代码搭建内部工具」。如果反馈来自分析师团队，「给分析师的无代码应用搭建工具」更贴近。
常见问题
常见问题
这会替代路线图吗？
不会。它用一个小原型替代部分猜测性工作。更大的赌注仍然留在路线图上。
需要会写代码吗？
不需要。你需要一个清楚的原因和一个真实任务来测试。实现是你通过使用来验收的东西。
什么样的第一版算好？
一个原因、一个流程、一周时间。如果需要三个流程才有用，范围还是太大。
怎么让研发团队认可？
带着原型和证据去：谁用过、省了什么、不做什么。边界才是可信度的来源。