A product requirements document does not need to be perfect before you speak to a delivery partner. It does, however, need to make the important unknowns visible.
The purpose of a PRD is not to predict every implementation detail. It is to create a shared understanding of the user, the problem, the desired outcome and the boundaries within which sensible decisions can be made.
Use these 15 questions as a readiness test. A missing answer is not automatically a failure. It is a signal that the question should be resolved before it becomes expensive code.
The problem and the user
1. Who experiences the problem?
Name the primary user precisely. “Businesses” is too broad. “The service adviser at a dealership handling inbound booking requests” is useful because it tells us whose workflow matters.
2. What happens today?
Describe the current process, including spreadsheets, inboxes, manual hand-offs and unofficial workarounds. The existing workflow contains constraints that a polished feature list often hides.
3. What is the cost of leaving the problem alone?
Quantify the consequence where possible: time lost, revenue missed, risk carried, customers delayed or decisions made without evidence. This helps determine whether custom software is justified.
4. What outcome should change?
Define success in observable terms. “Use AI to improve support” is an idea. “Resolve routine requests without increasing average handling time, while escalating uncertain cases to a person” is an outcome.
5. Who pays, who uses and who approves?
These may be three different people. A product that delights the user but cannot satisfy the buyer’s security or procurement needs still has a product problem.
The workflow and its boundaries
6. What is the smallest complete workflow?
Identify the narrowest journey that creates value from beginning to end. A thin but complete workflow is usually a better first release than fragments of five workflows.
7. What must the first release deliberately exclude?
A useful scope contains exclusions. Naming them prevents “small” additions from quietly changing the architecture, schedule and test surface.
8. Which decisions can the software make?
For AI products, define the line between recommendation, automated action and human approval. High-impact or irreversible actions generally need stronger controls.
9. What happens when the system is uncertain or unavailable?
Every important path needs a fallback. That may be a retry, a manual queue, a reduced service or a clear message. “The model will usually answer” is not a failure strategy.
10. Which systems must it connect to?
List the source of truth for customers, payments, inventory, identity, communications and reporting. Note whether APIs, test accounts and technical owners are available.
Data, risk and operation
11. What data enters, leaves and remains?
Describe personal data, commercially sensitive data, uploaded documents, model inputs and generated outputs. Include retention and deletion expectations.
12. What could cause real harm?
Consider incorrect advice, inappropriate access, leaked data, unwanted messages, financial actions and damage to customer trust. The answer determines the level of testing and control required.
13. How will we know the product is working?
Choose a small set of product and operational measures. Usage alone is rarely enough. Measure successful outcomes, exceptions, response quality, latency and unit cost where relevant.
14. Who will operate it after launch?
Decide who responds to alerts, approves releases, manages users, reviews AI failures and answers customer questions. If nobody owns operation, the product is not ready to be hosted.
15. What constraints are genuinely fixed?
State the budget envelope, desired launch window, regulatory obligations, required technologies and available team capacity. Separate hard constraints from preferences so trade-offs can be made honestly.
How to read your result
- 12–15 clear answers: the brief may be ready for architecture and delivery planning.
- 8–11 clear answers: a focused readiness sprint should resolve the remaining commercial and technical risks.
- Fewer than 8: start with product discovery rather than requesting a fixed delivery quote.
This is not a score of whether the idea is good. It is a measure of whether the team can make an accountable delivery decision with the information currently available.
What to send with the PRD
Include whatever reflects the current truth: workflow diagrams, customer notes, screenshots, prototype links, sample data, integration documentation and known constraints. Rough evidence is more useful than polished certainty.
Do not spend a month making the document look complete. Expose the gaps and let the readiness process resolve them.
Ready for a senior review?
AlanOps accepts complete PRDs, rough briefs and working prototypes. I will review the material personally, identify the decisions that control delivery, and tell you whether the right next step is discovery, a Build Readiness Sprint or implementation.