Skip to content
GrowthOSGrowthOS Docs

PRD Studio

Overview

Section titled “Overview”

PRD Studio is where an Idea Lab draft becomes a real Product Requirements Document. Sections are organized and editable: problem statement, goals, non-goals, users, requirements, and success metrics, all in one structured view instead of a freeform chat.

You can edit any section directly, ask the assistant to expand or tighten a specific part, and reorder or remove sections that do not apply to this PRD. The document stays a draft, fully editable, until you explicitly finalize it.

Finalizing a PRD is the gate that unlocks backlog generation. Once finalized, the PRD becomes the source of truth that Product Backlog reads to build big rocks, epics, and stories; editing a finalized PRD later does not automatically regenerate the backlog.

What you can do here

Section titled “What you can do here”
  • Review and edit every section of a generated PRD in a structured layout.
  • Ask the assistant to rewrite, expand, or shorten a specific section.
  • Add, remove, or reorder sections to match how your team writes specs.
  • Share a read-only PRD link with stakeholders who do not have a workspace seat.
  • Finalize the PRD to unlock Product Backlog generation.

When to use

Section titled “When to use”
  • Immediately after generating a first PRD draft in Idea Lab.
  • Whenever a PRD needs a structural edit rather than a conversational one.
  • Before every backlog generation, since backlog quality depends on a finalized PRD.

Prerequisites

Section titled “Prerequisites”
  • A signed-in member account with product access.
  • A Planner seat to edit or finalize; Viewer seats can read shared PRDs only.

Where to find it

Section titled “Where to find it”
  • Sidebar: Product → PRD Studio
  • Direct route: /product/prd-studio

Step-by-step

Section titled “Step-by-step”
  1. Open Product → PRD Studio (/product/prd-studio) from an Idea Lab draft or the PRD list.
  2. Read through each section: problem, goals, non-goals, users, requirements, metrics.
  3. Edit any section directly or ask the assistant to revise it.
  4. Add missing sections or remove ones that do not apply.
  5. Share a read-only link with stakeholders if you need sign-off before finalizing.
  6. Address any open feedback or questions from reviewers.
  7. Click Finalize once the document is ready to drive backlog generation.
  8. Continue to Product Backlog to confirm the generated hierarchy.

What success looks like

Section titled “What success looks like”
  • Every section reads clearly enough that a new engineer could pick up the PRD unaided.
  • Stakeholders who needed to review have seen the shared link and raised no blocking concerns.
  • The PRD is marked finalized and the backlog has been generated from it.

Tips & best practices

Section titled “Tips & best practices”
  • Write non-goals as carefully as goals; they prevent scope creep once the backlog is built.
  • Only finalize once stakeholders roughly agree on scope, not once every sentence is perfect.
  • Keep one PRD per initiative rather than bundling unrelated features into a single document.

Common mistakes

Section titled “Common mistakes”
  • Finalizing before non-goals or success metrics are filled in, which weakens the generated backlog.
  • Editing a finalized PRD heavily and assuming the backlog updates automatically; it does not.
  • Sharing a PRD link too early, before the draft has any coherent structure to review.
Section titled “Related guides”