# 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 |
| --- | --- | --- | --- | --- | --- |
| native-feeling navigation | finish onboarding without confusion | MVP candidate | [DEPENDENCY] | asking for permissions too early | [TEST OR DEMO] |
| progressive onboarding | complete the core action in under one minute | MVP candidate | [DEPENDENCY] | data conflicts after offline use | [TEST OR DEMO] |
| account or guest mode | keep changes safe during weak or absent connectivity | MVP candidate | [DEPENDENCY] | platform-specific layout bugs | [TEST OR DEMO] |
| offline cache and sync queue | finish onboarding without confusion | MVP candidate | [DEPENDENCY] | store rejection | [TEST OR DEMO] |
| optional push notifications | complete the core action in under one minute | MVP candidate | [DEPENDENCY] | notification fatigue | [TEST OR DEMO] |
| permission education | keep changes safe during weak or absent connectivity | MVP candidate | [DEPENDENCY] | asking for permissions too early | [TEST OR DEMO] |
| touch and accessibility support | finish onboarding without confusion | MVP candidate | [DEPENDENCY] | data conflicts after offline use | [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 widgets before the first loop is proven.