ad-prd

A PRD lifecycle can be maintained lazily by centralizing product scope at doc/product/PRD.md. This captures target users, goals, and success metrics while applying structured statuses like draft, accepted, or superseded to avoid unnecessary rewrites.

Multi-product PRDs are structured using individual files at doc/product/<product-slug>.md. This provides a single source of truth for each product's framing, capturing cross-feature constraints, non-goals, and success metrics to guide stakeholders.

Linking ADRs and feature specs to a roadmap requires a PRD that owns the product scope. By capturing decisions in an Open Questions log and applying lifecycle statuses, downstream specs and ADRs gain full traceability.

Yes, single-product PRDs are maintained at doc/product/PRD.md to capture cross-feature constraints. This centralizes target user definitions, problem statements, and MVP roadmap details into one stable source of truth.

A lazy PRD approach is used when centralizing product-level scope and stabilizing framing across teams is the priority. It applies defined lifecycle statuses and an explicit Open Questions log to capture uncertainties rather than writing exhaustive upfront documentation.

Tracking product decisions within a PRD is handled through an explicit Open Questions log. The PRD lifecycle captures uncertainties, owner information, and linked ADRs to ensure decisions are documented and accessible to stakeholders.