Features are easy to imagine. A button suggests another button. A simple page could have an account system. The account system could have a dashboard. Soon the original task needs a guided tour.
For this project, I want to use a plain question before adding something: what will a reader be able to do after this change? If the answer only describes the software, I probably have another sentence to write.
A fictional proposal
Suppose a checklist tool has a proposal for saved workspaces. “It will support workspaces” describes the implementation. “A reader can return to an unfinished checklist without starting again” describes a benefit. That benefit might be real, but it also raises questions about storage, deletion, and whether a downloadable file would be enough.
This is an example, not a report of user demand for our tool. The point is to compare ways to solve the same problem before choosing the most elaborate one.
A useful feature note
- Reader problem: describe the interruption or difficulty.
- Proposed change: explain what the reader can do afterward.
- Smallest test: name a complete example that would demonstrate the improvement.
- Tradeoff: say what gets slower, more complex, or more expensive.
- Decision: keep, revise, or remove after the test.
A rejected feature is not necessarily wasted work. A short test can tell us that a simpler tool already does the job. The useful result is the decision and its evidence, even when there is no new button to photograph.
The dashboard for deciding whether we need a dashboard remains unapproved.