# Feature Planning

Use this file to turn ideas into testable product behavior. A feature is ready to rank only when it has a user, trigger, expected outcome, dependencies, risk, and acceptance evidence.

[Kit README](README.md) · [Project Overview](Project%20Overview.md) · [PRD](Full%20PRD%20Template.md) · [Master Build Prompt](Master%20Build%20Prompt.md) · [Completion Checklist](Project%20Completion%20Checklist.md)

## Candidate Feature Map

| Feature | User Outcome | Release | Dependency | Main Risk | Acceptance Evidence |
| --- | --- | --- | --- | --- | --- |
| responsive header and navigation | understand the offer within ten seconds | MVP candidate | [DEPENDENCY] | unclear positioning | [TEST OR DEMO] |
| purpose-built page templates | reach any primary page in two navigation actions | MVP candidate | [DEPENDENCY] | oversized media | [TEST OR DEMO] |
| contact form with validation and spam controls | submit a contact request with clear confirmation | MVP candidate | [DEPENDENCY] | broken mobile navigation | [TEST OR DEMO] |
| SEO metadata and structured content | understand the offer within ten seconds | MVP candidate | [DEPENDENCY] | forms that silently fail | [TEST OR DEMO] |
| analytics with consent-aware events | reach any primary page in two navigation actions | MVP candidate | [DEPENDENCY] | missing page titles and alt text | [TEST OR DEMO] |
| accessible keyboard and screen-reader behavior | submit a contact request with clear confirmation | MVP candidate | [DEPENDENCY] | unclear positioning | [TEST OR DEMO] |

## Ranking Method

Score each candidate from 1–5:

- **Reach:** how many target users encounter the problem?
- **Impact:** how strongly does it improve the primary outcome?
- **Confidence:** how strong is the evidence?
- **Effort:** build, test, operate, support, and migration cost.
- **Risk reduction:** does it resolve a major safety, trust, or feasibility unknown?

Use: **Priority = (Reach × Impact × Confidence + Risk reduction) ÷ Effort**. The formula supports discussion; it does not replace judgment. Record the reasoning behind unusual scores.

## Feature Specification Card

~~~text
Feature: [FEATURE NAME]
Primary user: [USER]
Trigger: [WHEN IT IS NEEDED]
Behavior: [WHAT THE PRODUCT DOES]
User-visible states: default / loading / empty / success / error / offline / unauthorized
Data read: [FIELDS]
Data written: [FIELDS]
Permissions: [WHO MAY DO WHAT]
Dependencies: [SERVICE, DATA, OR PRIOR FEATURE]
Analytics event: [EVENT + ALLOWED PROPERTIES]
Acceptance criteria: [GIVEN / WHEN / THEN CONDITIONS]
Out of scope: [RELATED BEHAVIOR NOT INCLUDED]
~~~

## MVP Gate

A feature belongs in the MVP only when removing it would prevent the user from completing the central flow, create an unacceptable safety or trust gap, or make learning impossible. “Expected by users” is not enough without a concrete task.

## Common Mistakes

- Ranking screens instead of user outcomes.
- Ignoring operational work such as support, moderation, migrations, or content preparation.
- Treating an integration logo as completed functionality.
- Omitting recovery states and permissions.
- Adding CMS authoring before the first loop is proven.