What is a product requirements document?
The Harvard Chan AI Glossary
In our classes, we often pause to explain the ideas behind AI and the language used to describe it. These posts grew out of those conversations. They’re for anyone who would like to understand AI better, with no technical background assumed.
A product requirements document, or PRD, is a shared description of the problem a product should solve, the people it should serve and the behavior it must provide. It records decisions about purpose and scope so that designers, developers and other participants are working toward the same result.
Suppose a team wants to build a tool for organizing reading notes. “Use AI to make research easier” is an ambition, not a sufficient requirement. A useful PRD might identify the intended reader, explain the difficulty of finding earlier notes and specify that each summary must link back to the original material.
Scope defines what is included. Exclusions define what is deliberately not included. The first version might support a single person’s notes but not shared workspaces, automatic publication or access to private documents in other accounts. Explicit exclusions prevent a small project from quietly becoming a much larger one.
The document should also describe success and acceptance. Acceptance criteria are observable conditions used to decide whether an agreed requirement has been met. For the notes tool, one criterion might be that reopening a saved note preserves its text and source link. A separate measure of value might be whether people can find a relevant note more easily than before.
Those are different questions. Correctly saving a note establishes a tested behavior. It does not, by itself, prove that the product is useful. Requirements should connect to a real user need and a complete task, rather than becoming a list of features.
An AI assistant can help draft and critique a PRD, but fluent writing does not make its assumptions agreed facts. Someone must confirm the problem, resolve conflicting priorities and decide what is acceptable. The PRD should distinguish decisions from unanswered questions.
For the dental-care dashboard discussed in class, a PRD could specify the intended user, the stages from first attendance through treatment and follow-up, and how someone without a next step becomes visible. It should define the source of each stage and what the team will measure, not merely request a “live dashboard.” A first version might exclude automated patient contact. As staff test the workflow, the document should change with what is learned. Its purpose is shared decisions about a useful service, not a longer feature list.
If you would like to find out more about AI and improve your leadership skills, consider the AI in Health Care Certificate of Specialization from the Advanced Learning Academy at Harvard T.H. Chan School of Public Health. You can take an individual course or work toward the full certificate.
AI is a fast-moving field. This explanation reflects our class discussions and related material at the time of writing. Terminology, capabilities and tools may change.
For suggested additions or corrections, please email me at tpanch@hsph.harvard.edu.
Dr. Trishan Panch
Program Director, AI in Health Care
Harvard T.H. Chan School of Public Health — Advanced Learning Academy