Prompt file imported from PauloHYBEX/Nexus-TCMS (.windsurf/workflows/templates/research-project/FEATURES.md). Copyright stays with the author.

Features Research Template

Name: FEATURES
Author: PauloHYBEX

Template for .planning/research/FEATURES.md — feature landscape for the project domain.

# Feature Research

**Domain:** [domain type]
**Researched:** [date]
**Confidence:** [HIGH/MEDIUM/LOW]

## Table Stakes

Features users expect by default. Missing these = product feels incomplete.

| Feature | Why Expected | Complexity | Notes |
|---------|--------------|------------|-------|
| [feature] | [user expectation] | LOW/MEDIUM/HIGH | [implementation notes] |
| [feature] | [user expectation] | LOW/MEDIUM/HIGH | [implementation notes] |
| [feature] | [user expectation] | LOW/MEDIUM/HIGH | [implementation notes] |

## Differentiators

Features that set the product apart. Not required for launch, but valuable.

| Feature | Value Proposition | Complexity | Notes |
|---------|-------------------|------------|-------|
| [feature] | [why it matters] | LOW/MEDIUM/HIGH | [implementation notes] |
| [feature] | [why it matters] | LOW/MEDIUM/HIGH | [implementation notes] |

## Anti-Features

Features that seem good but create problems. Prevent scope creep by documenting them.

| Feature | Why Requested | Why Problematic | Alternative |
|---------|---------------|-----------------|-------------|
| [feature] | [surface appeal] | [actual problems] | [better approach] |
| [feature] | [surface appeal] | [actual problems] | [better approach] |

## Feature Dependencies

[Feature A] └──requires──> [Feature B] └──requires──> [Feature C]

[Feature D] ──enhances──> [Feature A]

[Feature E] ──conflicts──> [Feature F]


### Dependency Notes

- **[Feature A] requires [Feature B]:** [why the dependency exists]
- **[Feature D] enhances [Feature A]:** [how they work together]
- **[Feature E] conflicts with [Feature F]:** [why they're incompatible]

## MVP Definition

### Launch With (v1)

Minimum viable product — what's needed to validate the concept.

- [ ] [Feature] — [why essential]
- [ ] [Feature] — [why essential]
- [ ] [Feature] — [why essential]

### Add After Validation (v1.x)

Features to add once core is working.

- [ ] [Feature] — [trigger for adding]
- [ ] [Feature] — [trigger for adding]

### Future Consideration (v2+)

Features to defer until product-market fit is established.

- [ ] [Feature] — [why defer]
- [ ] [Feature] — [why defer]

## Feature Prioritization Matrix

| Feature | User Value | Implementation Cost | Priority |
|---------|------------|---------------------|----------|
| [feature] | HIGH/MEDIUM/LOW | HIGH/MEDIUM/LOW | P1/P2/P3 |
| [feature] | HIGH/MEDIUM/LOW | HIGH/MEDIUM/LOW | P1/P2/P3 |

**Priority key:**
- P1: Must have for launch
- P2: Should have, add when possible
- P3: Nice to have, future consideration

---
*Feature research for: [domain]*
*Researched: [date]*

Table Stakes:

These are non-negotiable for launch
Users don't give credit for having them, but penalize for missing them
Example: A community platform without user profiles is broken

Differentiators:

These are where you compete
Should align with the Core Value from PROJECT.md
Don't try to differentiate on everything — pick 2-3

Anti-Features:

Prevent scope creep by documenting what seems good but isn't
Include the alternative approach
Example: "Real-time everything" often creates complexity without value

Feature Dependencies:

Critical for roadmap phase ordering
If A requires B, B must be in an earlier phase
Conflicts inform what NOT to combine in same phase

MVP Definition:

Be ruthless about what's truly minimum
"Nice to have" is not MVP
Launch with less, validate, then expand

# Features Research Template Template for `.planning/research/FEATURES.md` — feature landscape for the project domain. <template> ```markdown # Feature Research **Domain:** [domain type] **Researched:** [date] **Confidence:** [HIGH/MEDIUM/LOW] ## Table Stakes Features users expect by default. Missing these = product feels incomplete. | Feature | Why Expected | Complexity | Notes | |---------|--------------|------------|-------| | [feature] | [user expectation] | LOW/MEDIUM/HIGH | [implementation notes] | | [feature] | [user expectation] | LOW/MEDIUM/HIGH | [implementation notes] | | [feature] | [user expectation] | LOW/MEDIUM/HIGH | [implementation notes] | ## Differentiators Features that set the product apart. Not required for launch, but valuable. | Feature | Value Proposition | Complexity | Notes | |---------|-------------------|------------|-------| | [feature] | [why it matters] | LOW/MEDIUM/HIGH | [implementation notes] | | [feature] | [why it matters] | LOW/MEDIUM/HIGH | [implementation notes] | ## Anti-Features Features that seem good but create problems. Prevent scope creep by documenting them. | Feature | Why Requested | Why Problematic | Alternative | |---------|---------------|-----------------|-------------| | [feature] | [surface appeal] | [actual problems] | [better approach] | | [feature] | [surface appeal] | [actual problems] | [better approach] | ## Feature Dependencies ``` [Feature A] └──requires──> [Feature B] └──requires──> [Feature C] [Feature D] ──enhances──> [Feature A] [Feature E] ──conflicts──> [Feature F] ``` ### Dependency Notes - **[Feature A] requires [Feature B]:** [why the dependency exists] - **[Feature D] enhances [Feature A]:** [how they work together] - **[Feature E] conflicts with [Feature F]:** [why they're incompatible] ## MVP Definition ### Launch With (v1) Minimum viable product — what's needed to validate the concept. - [ ] [Feature] — [why essential] - [ ] [Feature] — [why essential] - [ ] [Feature] — [why essential] ### Add After Validation (v1.x) Features to add once core is working. - [ ] [Feature] — [trigger for adding] - [ ] [Feature] — [trigger for adding] ### Future Consideration (v2+) Features to defer until product-market fit is established. - [ ] [Feature] — [why defer] - [ ] [Feature] — [why defer] ## Feature Prioritization Matrix | Feature | User Value | Implementation Cost | Priority | |---------|------------|---------------------|----------| | [feature] | HIGH/MEDIUM/LOW | HIGH/MEDIUM/LOW | P1/P2/P3 | | [feature] | HIGH/MEDIUM/LOW | HIGH/MEDIUM/LOW | P1/P2/P3 | **Priority key:** - P1: Must have for launch - P2: Should have, add when possible - P3: Nice to have, future consideration --- *Feature research for: [domain]* *Researched: [date]* ``` </template> <guidelines> **Table Stakes:** - These are non-negotiable for launch - Users don't give credit for having them, but penalize for missing them - Example: A community platform without user profiles is broken **Differentiators:** - These are where you compete - Should align with the Core Value from PROJECT.md - Don't try to differentiate on everything — pick 2-3 **Anti-Features:** - Prevent scope creep by documenting what seems good but isn't - Include the alternative approach - Example: "Real-time everything" often creates complexity without value **Feature Dependencies:** - Critical for roadmap phase ordering - If A requires B, B must be in an earlier phase - Conflicts inform what NOT to combine in same phase **MVP Definition:** - Be ruthless about what's truly minimum - "Nice to have" is not MVP - Launch with less, validate, then expand </guidelines>

{ "prompt": "# Features Research Template\n\nTemplate for `.planning/research/FEATURES.md` — feature landscape for the project domain.\n\n<template>\n\n```markdown\n# Feature Research\n\n**Domain:** [domain type]\n**Researched:** [date]\n**Confidence:** [HIGH/MEDIUM/LOW]\n\n## Table Stakes\n\nFeatures users expect by default. Missing these = product feels incomplete.\n\n| Feature | Why Expected | Complexity | Notes |\n|---------|--------------|------------|-------|\n| [feature] | [user expectation] | LOW/MEDIUM/HIGH | [implementation notes] |\n| [feature] | [user expectation] | LOW/MEDIUM/HIGH | [implementation notes] |\n| [feature] | [user expectation] | LOW/MEDIUM/HIGH | [implementation notes] |\n\n## Differentiators\n\nFeatures that set the product apart. Not required for launch, but valuable.\n\n| Feature | Value Proposition | Complexity | Notes |\n|---------|-------------------|------------|-------|\n| [feature] | [why it matters] | LOW/MEDIUM/HIGH | [implementation notes] |\n| [feature] | [why it matters] | LOW/MEDIUM/HIGH | [implementation notes] |\n\n## Anti-Features\n\nFeatures that seem good but create problems. Prevent scope creep by documenting them.\n\n| Feature | Why Requested | Why Problematic | Alternative |\n|---------|---------------|-----------------|-------------|\n| [feature] | [surface appeal] | [actual problems] | [better approach] |\n| [feature] | [surface appeal] | [actual problems] | [better approach] |\n\n## Feature Dependencies\n\n```\n[Feature A]\n └──requires──> [Feature B]\n └──requires──> [Feature C]\n\n[Feature D] ──enhances──> [Feature A]\n\n[Feature E] ──conflicts──> [Feature F]\n```\n\n### Dependency Notes\n\n- **[Feature A] requires [Feature B]:** [why the dependency exists]\n- **[Feature D] enhances [Feature A]:** [how they work together]\n- **[Feature E] conflicts with [Feature F]:** [why they're incompatible]\n\n## MVP Definition\n\n### Launch With (v1)\n\nMinimum viable product — what's needed to validate the concept.\n\n- [ ] [Feature] — [why essential]\n- [ ] [Feature] — [why essential]\n- [ ] [Feature] — [why essential]\n\n### Add After Validation (v1.x)\n\nFeatures to add once core is working.\n\n- [ ] [Feature] — [trigger for adding]\n- [ ] [Feature] — [trigger for adding]\n\n### Future Consideration (v2+)\n\nFeatures to defer until product-market fit is established.\n\n- [ ] [Feature] — [why defer]\n- [ ] [Feature] — [why defer]\n\n## Feature Prioritization Matrix\n\n| Feature | User Value | Implementation Cost | Priority |\n|---------|------------|---------------------|----------|\n| [feature] | HIGH/MEDIUM/LOW | HIGH/MEDIUM/LOW | P1/P2/P3 |\n| [feature] | HIGH/MEDIUM/LOW | HIGH/MEDIUM/LOW | P1/P2/P3 |\n\n**Priority key:**\n- P1: Must have for launch\n- P2: Should have, add when possible\n- P3: Nice to have, future consideration\n\n---\n*Feature research for: [domain]*\n*Researched: [date]*\n```\n\n</template>\n\n<guidelines>\n\n**Table Stakes:**\n- These are non-negotiable for launch\n- Users don't give credit for having them, but penalize for missing them\n- Example: A community platform without user profiles is broken\n\n**Differentiators:**\n- These are where you compete\n- Should align with the Core Value from PROJECT.md\n- Don't try to differentiate on everything — pick 2-3\n\n**Anti-Features:**\n- Prevent scope creep by documenting what seems good but isn't\n- Include the alternative approach\n- Example: \"Real-time everything\" often creates complexity without value\n\n**Feature Dependencies:**\n- Critical for roadmap phase ordering\n- If A requires B, B must be in an earlier phase\n- Conflicts inform what NOT to combine in same phase\n\n**MVP Definition:**\n- Be ruthless about what's truly minimum\n- \"Nice to have\" is not MVP\n- Launch with less, validate, then expand\n\n</guidelines>", "variables": [], "notes": "Template for `.planning/research/FEATURES.md` — feature landscape for the project domain.", "metadata": { "source": { "provider": "github-windsurf-workflows", "repository": "https://github.com/PauloHYBEX/Nexus-TCMS", "path": ".windsurf/workflows/templates/research-project/FEATURES.md", "ref": "af66d4e66d7443d045e74bafc302cd998ceb5b99", "url": "https://github.com/PauloHYBEX/Nexus-TCMS/blob/af66d4e66d7443d045e74bafc302cd998ceb5b99/.windsurf/workflows/templates/research-project/FEATURES.md", "key": "PauloHYBEX/Nexus-TCMS/.windsurf/workflows/templates/research-project/FEATURES.md" } } }

FEATURES

About

Features Research Template

Use it

Manifest

Reviews