Write a PRD
Give it the problem and the goal. It asks the clarifying questions a PRD needs, then produces a document your team can review and edit together in real time.
Copy this prompt to start your first task:
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.
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.
PRD structure reference
A PRD the teammate drafts usually covers:
- Background and problem (why, current pain, data or feedback)
- Goals and non-goals (what this version does, and explicitly doesn't)
- Target users and scenarios (personas plus key user stories)
- Success metrics (quantifiable acceptance or north-star metrics)
- Detailed requirements (features, P0/P1/P2 priority, interaction notes)
- Flows and edge cases (key flows, error handling)
- Dependencies and risks (technical dependencies, compliance, mitigations)
- Milestones and scope (phasing, MVP boundary)
- Open questions (what's undecided, listed to drive decisions)
How to use this workflow
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:
Connect Notion
The teammate stores and versions the PRD there as a living document. Connect Notion →
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:
For example:
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:
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 "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.
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:
Nothing here needs your approval: the document is collaborated on inside your workspace and sends nothing externally. See Control for what does pause for sign-off.
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
R&D & Product
Back to the R&D & Product use case overview.
Give instructions
Tell the teammate your PRD template and writing conventions.
Memory
Let the teammate remember your doc conventions and apply them automatically.
Monitor every deploy
A "deploy succeeded" notification isn't the same as a working site. Set up a teammate that checks the real thing after every release, quiet on success, first to shout on failure.
Organize your own tech team
Hire product, research, design, code-development, and code-review experts into one channel, then @-mention each role to break down and ship a real project together.