# Write a PRD (/use-cases/rd-product/prd-writer)



Copy this prompt to start your first task:

<Prompt>
  Help me write a PRD for [paste your product idea or user problem]. Ask clarifying questions about target users, goals, and edge cases before drafting, then produce a full PRD covering scope, flows, and acceptance criteria I can share with the team.
</Prompt>

<LivePreview component="NewThread" scenario="{ draft: &#x22;Help me write a PRD for [paste your product idea or user problem]. Ask clarifying questions about target users, goals, and edge cases before drafting, then produce a full PRD covering scope, flows, and acceptance criteria I can share with the team.&#x22; }" />

## What is this workflow? [#what-is-this-workflow]

Writing a PRD means giving a teammate the problem and the goal, not the solution, and having it ask the clarifying questions a spec needs before it writes a word — success metric, edge cases, what's explicitly out of scope. It drafts a structured document, routes it for a feasibility read before calling it final, folds in review feedback point by point, and splits the finalized P0 requirements into tasks once everyone's aligned.

<Callout type="warn">
  This teammate doesn't decide scope or feasibility on its own. It asks the questions a PRD needs, drafts the structure, and revises against feedback, but whether a requirement is P0 or P1, whether a deadline is real, and whether something's technically buildable in the timeline are calls for you and the team, not something it resolves by itself. It flags a conflict between what's asked for and what's realistic; it doesn't quietly pick a side.
</Callout>

## PRD structure reference [#prd-structure-reference]

A PRD the teammate drafts usually covers:

1. Background and problem (why, current pain, data or feedback)
2. Goals and non-goals (what this version does, and explicitly doesn't)
3. Target users and scenarios (personas plus key user stories)
4. Success metrics (quantifiable acceptance or north-star metrics)
5. Detailed requirements (features, P0/P1/P2 priority, interaction notes)
6. Flows and edge cases (key flows, error handling)
7. Dependencies and risks (technical dependencies, compliance, mitigations)
8. Milestones and scope (phasing, MVP boundary)
9. Open questions (what's undecided, listed to drive decisions)

## How to use this workflow [#how-to-use-this-workflow]

<Steps>
  <Step>
    ### Hire a product manager, and write the bio around asking first [#hire-a-product-manager-and-write-the-bio-around-asking-first]

    Open **AI Teammates** in the sidebar, click **Hire AI Teammate**, and pick the **Product Manager** template. The default bio is generic product strategy. Replace it on the Profile step so it knows the job starts with questions, not a draft:

    <Prompt>
      You write PRDs. Given a problem and a goal, ask the clarifying questions a spec needs before writing a word: success metric, edge cases, what's explicitly out of scope. Don't fill gaps with plausible defaults, ask or flag them as open questions. Once a draft exists, treat review comments and feasibility pushback as required revisions, not optional feedback. Scope and priority calls (P0 vs P1, what's realistic in the timeline) are mine to make, not yours to decide alone.
    </Prompt>

    <LivePreview component="CreateAssistantPage" scenario="{ focus: &#x22;profile&#x22;, initialState: { start: &#x22;template&#x22;, templateRef: &#x22;@helio/product-manager&#x22;, name: &#x22;Product Manager&#x22;, bio: &#x22;You write PRDs. Given a problem and a goal, ask the clarifying questions a spec needs before writing a word: success metric, edge cases, what's explicitly out of scope. Don't fill gaps with plausible defaults, ask or flag them as open questions. Once a draft exists, treat review comments and feasibility pushback as required revisions, not optional feedback. Scope and priority calls (P0 vs P1, what's realistic in the timeline) are mine to make, not yours to decide alone.&#x22; } }" />

    [More on hiring →](/ai-teammates/hire-an-ai-teammate)
  </Step>

  <Step>
    ### Connect Notion [#connect-notion]

    The teammate stores and versions the PRD there as a living document. [Connect Notion →](/connect/connect-tools-to-ai-teammates)

    <LivePreview component="AssistantIntegrations" />
  </Step>

  <Step>
    ### Give it the problem, not the solution [#give-it-the-problem-not-the-solution]

    A good problem statement names the current pain, who's affected, and what success looks like — not a proposed fix:

    <Prompt>
      We need to support [feature] in [product]. Right now [current painful workaround]. Target users are [audience]. Success looks like [outcome]. Ask me what's missing before you start writing.
    </Prompt>

    For example:

    <LivePreview
      component="AssistantChat"
      scenario="{ assistantName: &#x22;Product Manager&#x22;, messages: [
    { author: &#x22;user&#x22;, text: &#x22;We need to support prescription withdrawal in the patient app. Right now patients call support to cancel a filled prescription, which takes 2 days. Target users are patients on chronic-med plans. Success looks like a self-serve cancel that still lets pharmacy staff verify eligibility. Ask me what's missing before you start writing.&#x22; },
    { author: &#x22;assistant&#x22;, text: &#x22;Before I start writing, is pharmacy-staff verification a hard requirement for every cancellation, or only above some threshold? And is 2-day cancel time the real failure mode, or do patients mostly not know self-cancel should even be possible? Those two answers change whether this is mainly a UX problem or a workflow-and-permissions problem, and the PRD looks different depending which one it is.&#x22; },
  ] }"
    />
  </Step>

  <Step>
    ### Route it for feasibility before calling the draft final [#route-it-for-feasibility-before-calling-the-draft-final]

    A PRD that hasn't been read by someone who'd actually build it is a wishlist with good formatting. Send the draft for a technical read before it goes to broader review. The handoff posts into the engineering channel, and a teammate can only post in channels it's a member of — add the Product Manager to that channel first:

    <Prompt>
      Draft's ready. Send it to engineering for a feasibility read before we open it up to the wider team.
    </Prompt>

    <LivePreview
      component="AssistantChat"
      scenario="{ assistantName: &#x22;Product Manager&#x22;, messages: [
    { author: &#x22;user&#x22;, text: &#x22;Draft's ready. Send it to engineering for a feasibility read before we open it up to the wider team.&#x22; },
    { author: &#x22;assistant&#x22;, text: &#x22;Sent to the engineering channel. One thing already flagged back: the requirement for real-time pharmacy-staff verification on every cancel isn't feasible with the current eligibility-check API, it's a nightly batch job, not a live call. I've added this as an open question rather than quietly changing the requirement myself, since whether we relax that to same-day verification or invest in a live API is a call for you and eng leads, not something I should resolve on my own.&#x22; },
  ] }"
    />
  </Step>

  <Step>
    ### Share it and revise point by point [#share-it-and-revise-point-by-point]

    Share the document link with reviewers. This happens inside Notion, not in a Helio chat: everyone reads, comments, and edits the same doc there, and the teammate follows up on open comments and revises the sections they touch, not the whole document. A comment like &#x2A;"this doesn't say what happens if the patient cancels after the prescription has already shipped"* gets a targeted fix (a new requirement, just the one section and its flow diagram updated) and a reply on that same comment thread, not a rewritten document.
  </Step>

  <Step>
    ### Finalize, then split into tasks [#finalize-then-split-into-tasks]

    Once open questions are resolved and review comments are closed, have the teammate split the finalized P0 requirements into tasks on your board:

    <Prompt>
      All open questions are resolved, mark the PRD final and split the P0 requirements into tasks.
    </Prompt>
  </Step>
</Steps>

**Nothing here needs your approval:** the document is collaborated on inside your workspace and sends nothing externally. See [Control](/ai-teammates/control) for what does pause for sign-off.

## Tips for Better Results [#tips-for-better-results]

| Tip                                              | Description                                                                                                 |
| ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------- |
| Give the problem, not the proposed fix           | A pre-picked solution skips the questions that would've caught a better one, or a hidden constraint.        |
| Route for a feasibility read before wider review | A draft nobody who'd build it has seen is a wishlist with good formatting.                                  |
| Keep P0/P1 and timeline calls with your team     | The teammate flags conflicts between what's asked for and what's realistic — it doesn't resolve them alone. |
| Reply on the same comment thread for a fix       | Point-by-point revisions stay scoped to the section that changed, not a full rewrite.                       |

## Common Questions [#common-questions]

<Accordions type="single">
  <Accordion title="Does the teammate decide what's P0 versus P1?">
    No. It asks the questions a PRD needs and drafts the structure, but priority and feasibility calls stay with you and the team.
  </Accordion>

  <Accordion title="What happens if a requirement turns out not to be feasible?">
    It's flagged as an open question, not quietly resolved. The teammate doesn't pick a side between what's asked for and what's realistic.
  </Accordion>

  <Accordion title="Where does review happen?">
    Inside Notion, not Helio chat. Reviewers comment and edit the same doc; the teammate follows up on open comments and revises just the sections they touch.
  </Accordion>

  <Accordion title="What happens once the PRD is final?">
    The finalized P0 requirements get split into tasks on your board.
  </Accordion>
</Accordions>

<Cards>
  <Card title="R&D & Product" href="/use-cases/rd-product" description="Back to the R&D & Product use case overview." />

  <Card title="Give instructions" href="/ai-teammates/give-instructions" description="Tell the teammate your PRD template and writing conventions." />

  <Card title="Memory" href="/ai-teammates/memory" description="Let the teammate remember your doc conventions and apply them automatically." />
</Cards>