Feature definition

# Feature definition

Use when a feature exists but the description is thin, fuzzy, too solution-led, or not yet ready for design and engineering handoff.

## Workflow

1. Read the feature record, including the current description and requirements.
2. Read linked goals, initiatives, release context, and persona if present.
3. Read linked ideas for direct customer evidence.
4. Review similar ideas elsewhere in the workspace when they could change scope or priority.
5. Review dependent or blocked records on the **Related** tab when they affect sequencing or feasibility.
6. Draft the description. If key context is missing and would materially change the draft, ask short follow-up questions. Otherwise proceed and call out the gaps in open questions.

## Rules

**Overview.** Write 3 to 5 sentences covering the core customer problem before the solution, why it matters now, how customers handle it today, who benefits most, the biggest customer and business gains, and how the feature supports linked goals and initiatives.

**Desired experience.** Describe observable behavior: what the user is trying to accomplish, what they see and choose and receive, the boundaries of the initial launch, and what makes the first release lovable rather than merely functional. Do not describe endpoints, internal architecture, or low-level UI mechanics unless they are essential constraints.

**MLP.** Define a minimum lovable product that is smaller than the full vision, valuable on its own, and clear enough to help product, design, and engineering decide what can wait. If the MLP matches the full desired experience, shrink it.

**Approaches.** Include an approaches table only when there are multiple credible paths. For each: name, effort of low, medium, or high, 3 to 5 pros, and 3 to 5 cons.

**Open questions.** List only questions that would change scope, sequencing, UX, or feasibility if answered differently. Prioritize customer evidence gaps, dependency risks, permissions or migration questions, rollout and measurement questions, and conflicts with adjacent work.

**General.** Synthesize rather than dumping record fields. Link cited ideas and dependent records by reference number and name. State when customer evidence is absent instead of implying certainty. Headers use sentence case. No em dashes, en dashes, or curly quotes.

## Output

```
### Overview  
<3 to 5 sentence synthesized narrative>  
  
### Desired experience  
- <behavioral description>  
- \*\*MLP:\*\* <smallest lovable version>  
  
<approaches table only when needed>  
  
### Open questions  
- <question>
```

## Quality checks

- The problem is clearer than the solution.
- The draft reflects evidence from linked records, or explicitly notes that evidence is missing.
- The MLP is meaningfully narrower than the full experience.
- Every open question could redirect the build.
- Dependencies are named when they affect delivery.