Ring Pre Dev Prd Creation

Explicit Rules

✅ DO Include in PRD

Problem definition and user pain points, user personas (demographics, goals, frustrations), user stories with acceptance criteria, feature requirements (WHAT not HOW), success metrics (adoption, satisfaction, KPIs), scope boundaries (in/out explicitly), go-to-market considerations

❌ NEVER Include in PRD

Architecture diagrams or component design, technology choices (languages, frameworks, databases), implementation approaches or algorithms, database schemas or API specifications, code examples or package dependencies, infrastructure needs or deployment strategies, system integration patterns

Separation Rules

1. If it's a technology name → Not in PRD (goes in Dependency Map)
2. If it's a "how to build" → Not in PRD (goes in TRD)
3. If it's implementation → Not in PRD (goes in Tasks/Subtasks)
4. If it describes system behavior → Not in PRD (goes in TRD)

Rationalization Table

Security Requirements Discovery (Business Level)

During PRD creation, identify if the feature requires access control:

What to include in PRD:

• ✅ "Only authenticated users can access this feature"
• ✅ "Users can only view/edit their own records"
• ✅ "Admin approval required for [action]"
• ✅ "Must track who performed each action"

What NOT to include in PRD:

• ❌ "Use JWT tokens" (technology choice → TRD)
• ❌ "Integrate with Access Manager" (architecture → TRD)
• ❌ "OAuth2 flow" (protocol choice → TRD)

Note: The TRD (Gate 3) will translate these business requirements into authentication/authorization architecture patterns. For Go services, refer to golang.md → Access Manager Integration section during TRD creation.

Operational Dashboard Discovery (Business Level)

During PRD creation, assess whether the feature/product requires business dashboard endpoints.

Not every product needs dashboard endpoints. The deciding factor is whether a human operator or business manager will need aggregated visibility to make decisions.

When to Ask

This discovery MUST be triggered when:

• Defining a new product or major feature
• The feature involves data that accumulates over time (transactions, events, operations)
• The feature is operated by end-users (not purely infrastructure)

Discovery Question

Use AskUserQuestion tool:

Question: "Will an operator or business manager need a consolidated view of this feature's data to make decisions (e.g., volumes, statuses, error rates, trends)?"

• Header: "Operational Dashboard"
• multiSelect: false
• Options:
  • "Yes - Business dashboard needed" (description: "Operators need aggregated metrics, trends, and status overviews to manage this feature day-to-day")
  • "No - Infrastructure/backend only" (description: "This feature runs silently — monitoring is handled by observability tooling, not business dashboards")
  • "Not sure - Needs discussion" (description: "Flag for product/business review before deciding")

If "Yes" Selected

Document in PRD under a "Dashboard Requirements" section:

Example PRD section:

## Dashboard Requirements

**Consumer:** Operations manager
**Decisions supported:** Health monitoring, SLA compliance, exception triage
**Key metrics:**
- Total volume processed (by period)
- Distribution by status (success/pending/failed)
- Error rate trends
- Aging of unresolved items
**Refresh:** Near real-time (< 5 min lag)

This section cascades into Feature Map (Gate 2) for UI components and API Design (Gate 4) for dashboard data endpoints.

If "No" Selected

Document explicitly in PRD scope:

## Out of Scope
- Business dashboard endpoints (infrastructure product — monitoring via observability stack)

This prevents the question from resurfacing in later gates.

If "Not Sure" Selected

Flag as open question in PRD:

## Open Questions
- [ ] Dashboard requirements TBD — needs product/business review before Gate 2

STOP Gate 1 validation for this item until resolved.

Guidance: When Dashboards Make Sense

Rationalization Table

Red Flags - STOP

If you catch yourself writing or thinking any of these in a PRD, STOP:

• Technology product names (PostgreSQL, Redis, Kafka, AWS, etc.)
• Framework or library names (React, Fiber, Express, etc.)
• Words like: "architecture", "component", "service", "endpoint", "schema"
• Phrases like: "we'll use X to do Y" or "the system will store data in Z"
• Code examples or API specifications
• "How we'll implement" or "Technical approach"
• Database table designs or data models
• Integration patterns or protocols

When you catch yourself: Move that content to a "technical notes" section to transfer to TRD later. Keep PRD pure business.

Data Source Discovery (Frontend-only Features)

⛔ MANDATORY: If feature is frontend-only (uses existing backend APIs), this section MUST be completed.

When to Apply

Check research.md frontmatter for topology: