Should you immediately build a special feature requested by your first tester?
Ask which concrete task the request serves, then distinguish a reusable need from a particular situation. Bounded manual assistance may teach you something without committing to a permanent feature.
Translate the request into a task
- Ask about a recent occurrence.
- Identify the missing result.
- Define limited help you can provide. A request for ten export formats might really mean sending one list to a colleague using another tool.
Keep assistance bounded
Try a plain-text export once and observe whether it completes the task. Check whether other suitable users encounter the same issue; one enthusiastic request does not establish market size. If it lies outside the pilot's purpose, explain the limit rather than quietly accepting unlimited custom work.
What to do with your observation
| Observation | Next action |
|---|---|
| A one-off alternative completes the task | Keep the observation without rushing into a permanent feature. |
| Several suitable users encounter the blockage | Investigate the shared need and implementation cost further. |
A worksheet you can use
Request: __. Actual task: __. Bounded alternative: __. Result: __. Other cases: __. Excluded promises: __.
Does declining mean ignoring the user?
No. Understanding the task, explaining limits and retaining the observation can be a serious response.
Evidence and scope
This editorial decision aid cannot guarantee feature choices. Graham's cases are not universal outcome evidence.
Graham discusses early manual work. These procedures are original. Paul Graham (2013) — Do Things that Don’t Scale
Sources and further reading
This collection in Chinese and English · Life possibilities library