第一位試用者要求特殊功能，該立刻做給他嗎？
先問這個要求要解決哪個具體任務，再區分可重用需求與單一情境。可以用小範圍人工協助了解問題，但不要一收到要求就承諾永久功能。
把功能名稱還原成任務
- 請對方描述最近一次遇到的情況。
- 找出缺少的結果。
- 確認你能提供哪種有限協助。例如想要十種匯出格式，可能只是需要把一份清單傳給使用不同工具的同事。
讓協助保留邊界
可以先提供一次通用文字匯出，觀察是否足以完成任務。記下這是否也出現在其他適合使用者身上，不把單次高熱情當市場規模。若不符合目前試辦目的，就解釋暫不提供，避免默默接下無限客製工作。
觀察到什麼，下一步怎麼做
| 觀察 | 下一步 |
|---|---|
| 一次替代就完成任務 | 保留觀察，暫不急著做永久功能。 |
| 多位適合使用者反覆卡住 | 進一步驗證共同需求與實作成本。 |
可直接使用的練習表
原始要求：＿＿；實際任務：＿＿；有限替代：＿＿；是否完成：＿＿；其他案例：＿＿；不承諾範圍：＿＿。
拒絕功能等於不重視使用者嗎？
不是。理解需求、說明限制與保留紀錄，也是一種認真回應。
依據與適用限制
本文是試辦決策建議，不保證功能取捨正確；Graham 的個案不能當普遍成效證明。
Graham 討論早期人工工作；本文流程為原創。 Paul Graham (2013) — Do Things that Don’t Scale