01 · CONTEXT BEFORE FORMAT
Product thinking rarely arrives section by section.
You remember a user complaint, jump to a possible solution, correct the scope, then notice a dependency. Speaking lets you capture those connections before a template forces the idea into neat but premature boxes.
02 · THE BRIEF HAS TWO JOBS
Preserve the evidence. Expose the unknowns.
Who experiences the problem, what happens now, and why does it matter?
Describe the change in user behavior or product quality—not merely the feature shipped.
Keep the constraints and explicit out-of-scope decisions that protect the work from expanding.
Turn missing evidence into questions. Do not quietly convert assumptions into requirements.
03 · REVIEW THE CONTRACT
A convincing brief can still encode fiction.
- □Does every requirement trace back to something you actually said?
- □Are user evidence and team assumptions clearly distinguishable?
- □Did a possible solution accidentally become committed scope?
- □Are the success criteria measurable—or honestly marked unresolved?
- □Could engineering, design, and product disagree in the same document?
04 · MAKE THE FORMAT YOURS
Your product process can become a transform.
A startup brief, enterprise PRD, bug report, and experiment plan require different evidence. Store your sections, rules, examples, and writing style as a custom transform rather than relying on a generic template.
05 · COMMON QUESTIONS
Voice-to-product-brief FAQ
How do I turn a voice note into a product brief?
Record directly on this page or paste your product thinking, add optional product context, and choose Feature, Product bug, or Experiment. The tool returns an editable Markdown brief.
Is this the same as a PRD?
It can create the foundation of a concise PRD, but it will not pretend your initial explanation contains every implementation decision. Missing information becomes an open question for the team to resolve.
Will it invent requirements or research?
It is explicitly instructed not to invent research, quotes, metrics, deadlines, architecture, priorities, requirements, or consensus. Review the brief before treating it as a product decision.
Can I use it for bugs and experiments?
Yes. Product bug emphasizes current behavior, expected behavior, impact, evidence, and acceptance criteria. Experiment emphasizes the hypothesis, audience, measurement, guardrails, and decision rule.
Can I save my team’s brief format?
Yes. A custom AudioArcher transform can include your required sections, decision rules, examples, writing style, and Markdown skill files.