Lerianstudio Ring Pre Dev Feature Map

Feature Map Creation - Understanding the Feature Landscape

Foundational Principle

Feature relationships and boundaries must be mapped before architectural decisions.

Jumping from PRD to TRD without mapping creates:

• Architectures that don't match feature interaction patterns
• Missing integration points discovered late
• Poor module boundaries that cross feature concerns

The Feature Map answers: How do features relate, group, and interact at a business level? The Feature Map never answers: How we'll technically implement those features (that's TRD).

Mandatory Workflow

Explicit Rules

✅ DO Include

Feature list (from PRD), categories (Core/Supporting/Enhancement/Integration), domain groupings (business areas), user journey maps, feature interactions, integration points, feature boundaries, priority levels, scope visualization

❌ NEVER Include

Technical architecture/components, technology choices/frameworks, database schemas/API specs, implementation approaches, infrastructure/deployment, code structure, protocols/data formats

Categorization Rules

• Core: Must have for MVP, blocks other features
• Supporting: Enables core features, medium priority
• Enhancement: Improves existing features, nice-to-have
• Integration: Connects to external systems

Domain Grouping Rules

• Group by business capability (not technical layer)
• Each domain = cohesive related features
• Minimize cross-domain dependencies
• Name by business function (User Management, Payment Processing)

Rationalization Table

Red Flags - STOP

If you catch yourself writing any of these in a Feature Map, STOP:

• Technology names (APIs, databases, frameworks)
• Component names (AuthService, PaymentProcessor)
• Technical terms (microservices, endpoints, schemas)
• Implementation details (how data flows technically)
• Architecture diagrams (system components)
• Code organization (packages, modules, files)
• Protocol specifications (REST, GraphQL, gRPC)

When you catch yourself: Remove the technical detail. Focus on WHAT features do and HOW they relate at a business level.

Gate 2 Validation Checklist

Gate Result: ✅ PASS → UX Design → TRD | ⚠️ CONDITIONAL (clarify boundaries) | ❌ FAIL (poor groupings/missing features)

Phase 4: UX Design (Large Track Only)

After Feature Map passes Gate 2 validation, dispatch product-designer for UX design:

Task(
  subagent_type="ring:product-designer",
  prompt="Create detailed UX design based on PRD, ux-criteria.md, and feature-map.md at docs/pre-dev/{feature}/. Mode: ux-design. Create: user-flows.md with Mermaid diagrams for all user journeys (happy path, error paths, edge cases), wireframes/ directory with YAML specs for all screens, UI state documentation for all interactive elements."
)

UX Design Outputs:

• docs/pre-dev/{feature}/user-flows.md - Detailed user flows with Mermaid diagrams
• docs/pre-dev/{feature}/wireframes/ - Directory with YAML wireframe specs per screen

UX Design Checklist:

If UX Design fails:

• Missing flow → Add flow for user journey
• Missing state → Add state definition
• Incomplete wireframe → Enhance spec with missing components
• Accessibility gaps → Add a11y requirements

Note: This phase is for Large Track only (2+ day features). Small Track skips to TRD directly.

Feature Map Template Structure

Output to docs/pre-dev/{feature-name}/feature-map.md with these sections:

Backend Integration Points (Fullstack Features)

⛔ MANDATORY: If topology.scope: fullstack, this section MUST be included.

When This Applies

Check research.md frontmatter:

topology:
  scope: fullstack  # ← This triggers backend integration documentation

Backend Integration Documentation

Add to feature-map.md under ## Backend Integration Points:

## Backend Integration Points

### Overview
- **Topology:** Fullstack
- **API Pattern:** [direct | bff]
- **Backend Services:** List of backend services this feature depends on

### Per-Feature API Dependencies

| Feature | Backend Dependency | Data Direction | Notes |
|---------|-------------------|----------------|-------|
| F-001: User Dashboard | User Service | Read | Profile data |
| F-001: User Dashboard | Order Service | Read | Recent orders |
| F-002: Create Order | Order Service | Write | New order |
| F-002: Create Order | Inventory Service | Read | Stock check |

### Data Flow Summary

| Frontend Component | → | BFF/API | → | Backend Service |
|-------------------|---|---------|---|-----------------|
| DashboardPage | → | /api/dashboard | → | User + Order Services |
| OrderForm | → | /api/orders | → | Order + Inventory Services |

### BFF Requirements Matrix

| Feature | Needs BFF? | Reason |
|---------|-----------|--------|
| F-001 | Yes | Aggregates 2 services |
| F-002 | Yes | Needs inventory validation |
| F-003 | No | Single service, simple read |

Integration Risk Identification

Document risks related to backend dependencies:

### Integration Risks

| Feature | Backend Dependency | Risk | Mitigation |
|---------|-------------------|------|------------|
| F-001 | Order Service | Service unavailable | Graceful degradation |
| F-002 | Inventory Service | Stale stock data | Real-time check before submit |

Rationalization Table for Backend Integration

Common Violations

Confidence Scoring

Action: 80+ proceed to TRD | 50-79 address gaps | <50 rework groupings

Output & After Approval

Outputs:

• docs/pre-dev/{feature-name}/feature-map.md - Feature relationship map
• docs/pre-dev/{feature-name}/user-flows.md - Detailed user flows (from product-designer, Large Track only)
• docs/pre-dev/{feature-name}/wireframes/ - Wireframe specifications (from product-designer, Large Track only)

1. ✅ Lock Feature Map - scope and relationships are now reference
2. ✅ Lock user-flows.md and wireframes/ - UX specs for implementation (Large Track)
3. 🎯 Use all as input for TRD (next phase)
4. 🚫 Never add technical architecture retroactively
5. 📋 Keep business features separate from technical components

The Bottom Line

If you wrote a Feature Map with technical architecture details, remove them.

The Feature Map is business-level feature relationships only. Period. No components. No APIs. No databases.

Technical architecture goes in TRD. That's the next phase. Wait for it.

Map the features. Understand relationships. Then architect in TRD.

Standards Loading (MANDATORY)

This skill is a business analysis skill and does NOT require WebFetch of language-specific standards.

Purpose: Feature Map defines business-level feature relationships and groupings. Technical standards are irrelevant at this stage—they apply during TRD (Gate 3) and implementation.

However, MUST load PRD (Gate 1) and ux-criteria.md to ensure feature map aligns with validated business requirements.

Blocker Criteria - STOP and Report

Cannot Be Overridden

These requirements are NON-NEGOTIABLE:

• MUST NOT include technical architecture or components
• MUST NOT include technology choices or frameworks
• MUST NOT include database schemas or API specifications
• MUST map ALL features from PRD (no missing features)
• MUST define feature categories (Core/Supporting/Enhancement/Integration)
• MUST define domain groupings with clear boundaries
• MUST document backend integration points for fullstack features
• MUST dispatch product-designer for UX Design (Large Track only)

Severity Calibration

Pressure Resistance

Anti-Rationalization

When This Skill Is Not Needed

• Small Track workflow (< 2 days) → skip to TRD
• Single simple feature → TRD directly
• PRD (Gate 1) not validated → complete Gate 1 first
• Feature Map already exists and is validated
• Bug fix with no feature relationship changes
• Documentation-only updates

Converted and distributed by TomeVault — claim your Tome and manage your conversions.