How to use the Product Requirements Document Generator.
A PRD connects the user problem to observable product behavior. Keep requirements separate from proposed implementation details and unresolved decisions.
Make the workflow fit your task.
Translate the user problem into observable product behavior, defining inputs, outputs and acceptance conditions. Separate required behavior from implementation proposals and keep unresolved scale, permissions or error-handling decisions visible.
- What you provide
- Product problem, constraints and stakeholder notes.
- What you get
- PRD draft with goals, requirements and unresolved decisions.
See the input and the result.
Illustrative input and output · a teaching example, not a live WebAct run
Example input
Draft a small PRD for comparing two CSV supplier files before a catalog update. Required fields: SKU and Price. Match exact SKUs; show old and new prices; export a review list. Duplicate SKUs must be flagged. Volume limits and permissions are undecided.
Completed example
Problem: catalog managers need to inspect supplier price changes before an update. Inputs: two CSV files containing SKU and Price. Matching: exact SKU values; duplicate keys require review rather than automatic pairing. Result: a list containing SKU, old price, new price and change status. Export: the reviewed comparison is downloadable; the workflow does not update the live catalog. Acceptance example: A12 changes from 10 to 12 and appears as a price change. Open decisions: supported volume, permissions and treatment of missing prices.
Load this input into the prompt, then copy it to WebAct to try the task. Your result may differ from the illustration.
Decisions and troubleshooting.
Should a PRD prescribe the database or framework?
Include technical constraints only when they are established requirements. Otherwise describe the behavior and leave implementation choices for the appropriate design process.
Why can engineers interpret the same requirement differently?
Add concrete examples and acceptance conditions, including failure states. Broad wording such as easy to use does not define observable behavior.
Try it with your own source.
Replace the example with your material in the task prompt. Keep the requirements you need, then copy the task into WebAct.
Customize and copy the task ↑