PRDs (Requirements)

A PRD — product requirements document — is where a piece of work begins in Scopingly. It's the source of truth that everything downstream (scope, schedule, epics) is generated from and traced back to.

What a PRD is

A PRD is a collaborative, versioned, approvable document. Each PRD has:

• Prose content — problem, goals, requirements, out-of-scope, non-functionals
• An owner and a three-tier permission model: owner, editor, viewer
• Reviewers, milestones, comments, and reviews
• Versions — an immutable history with an approval lifecycle

Under the hood, requirements are served by a dedicated service with real-time collaborative editing, so multiple people can edit the same PRD at once.

Creating a PRD

Create a PRD from the Requirements page. You can:

• Author it directly in the editor, or
• Import one from a .docx file or Notion, which Scopingly normalizes into a structured requirement you can edit and version like any other PRD.

You can attach reviewers at creation time or add them later.

Permissions

Role	Can
Owner	Everything: edit, manage collaborators, archive/delete, approve versions
Editor	Edit content, manage gaps, generate scope
Viewer	Read; may request edit access

Access is always scoped to your organization. Org admins can act across PRDs in the organization. See roles & permissions.

Requesting edit access

A viewer doesn't get handed a private copy — they request edit access, and the owner (or an org admin) approves or denies it. Approving upgrades them to an editor collaborator on the same PRD, so everyone stays on one canonical document. There is at most one pending request per person per PRD.

Reviewers

Reviewers are collaborators tagged for sign-off. Add them inline from the PRD view or when creating the PRD. A reviewer is a viewer-level collaborator with a role in the approval lifecycle — they sign off (or request changes); only the owner approves.

Private PRDs

Pro and above

By default a PRD is discoverable in your organization's search. Marking a PRD private hides it from the two org-wide search surfaces (full-text and semantic) for everyone except its owner, the people tagged on it (collaborators and reviewers), and org admins.

Privacy takes effect immediately — granting or revoking access changes visibility with no re-indexing. Private PRDs are a Pro+ feature; the toggle is hidden on Free (a single-seat org has no one to hide from) and is settable by editors and above.

The PRD lifecycle

A PRD moves through detection, review, and approval:

1. Assess for gaps. Scopingly flags gaps — a missing metric, no out-of-scope boundary — as advice, never a gate.
2. Summarize. Generate a one-page executive summary for stakeholders.
3. Review & approve. Move through the approval lifecycle: request review → reviewers sign off → owner approves. Approval creates an immutable version.
4. Generate scope. Turn the PRD into a scope document with provenance back to the approved version.

Housekeeping

• Archive (for history): archived PRDs leave the default list but stay readable and searchable. Approved PRDs are archived rather than deleted.
• Recycle bin (soft delete): a deleted PRD is hidden but restorable for 30 days before its organization's retention policy decides its fate.

See data management for the full retention model.