The feature list answers one question: what does the product do. Nothing else goes in it.
The list
- Three columns: code, feature, what it does. The code is short and stable so a conversation can point at it. What it does is one sentence about the user's result, not the screen.
- No phases, no owners, no dependencies. When it is built, who builds it and what it needs are three other documents and three other conversations. Mixed into the list, they dirty the only document the client sees.
- Group by what the person is doing, not by technical layer.
- Technical warnings and open decisions are said where the work is discussed, not written into the list.
Tracing
- Every feature traces back to the thesis. If it does not resolve part of what the research found, it is either a missing finding or a feature that does not belong.
- What the product will not do is said once, with its reason, so the boundary is a decision and not an oversight.
- A feature that needs something that does not exist yet stays on the list; the gap is noted in the plan, not here.
Names
Naming comes after the list is agreed, together with the direction, never before it.
- Product and feature names are conceptual, short and strong, with sound and identity. Short names win in stores and search; the exact length is the person's call.
- Names do not describe. A dictionary word buried among a thousand store results is not a brand. Discard any name already common in the category.
- Ask for the tone before proposing a batch.
Output
The list in docs/scope.md, next to the diagnosis, ready to show. From here the method continues with the direction and the references, at step 1 of the loop in kero-method.