A product requirements documentresearch, requirements and open questions in one place

Method

1. 1

   Give your assistant the raw material

   Collect what you have: interview notes with customers already reduced to role and company size, the support tickets that started it, the roadmap goal and engineering’s questions. Attach them in Claude or ChatGPT, or point a local client at the folder, and ask your assistant to build a document called Multi-step purchase approvals on a Product specs shelf.

   Ask for a fixed shape: a draft overview; each requirement as a Suggestion titled with a stable label, R3. Approvers can delegate while on leave; each interview as Evidence; then every Risk and open Question it can find in the material. Tell it to quote, not paraphrase, and to invent no requirement the notes do not support.

2. 2

   Rewrite the overview as the problem, not the solution

   Press Edit and rewrite the overview yourself, whatever the draft says. It has four short parts: the problem in the customer’s terms, who has it, the goals and non-goals, and how you will know it worked (“Orders over the limit wait less than a day for a second approval”).

   Resist describing screens here. A stakeholder who reads only the overview should know why the feature exists and what it will not do. This is the part of the document that is your judgement, and it should read like it.

3. 3

   Fix up the requirements in the editor

   Read each requirement against the notes it came from. Keep the “R” label in the title, because finding numbers shift as you add evidence and questions, while R3 stays R3 in every meeting. Under each, the user story is a sentence and the acceptance criteria a check list.

   Drag the requirements into priority order, merge the ones the assistant split, and delete the ones that are really solutions in disguise. When the review approves the must-haves, mark them Key; the public view shows them as high importance.

4. 4

   Check the evidence and link to it

   Each interview or cluster of tickets should be an Evidence finding: “Interview: finance lead, 300-person manufacturer, 12 August”, describing the customer by role and size, never by name, with a quote or two and the link to the full notes in its sources, where your own access controls still apply.

   Ask your assistant to link each requirement to the evidence it rests on, then check the links. A requirement with no evidence is a hunch; say so in its body, and it becomes the next thing to test.

5. 5

   Keep risks and open questions in the open

   Risks read like “Delegation could let an approver approve their own order”; questions like “Do approval limits differ by currency?” Add engineering’s questions word for word.

   When a question is answered, add a Decision finding with the answer, the date and who decided (by role), and edit the question’s first line: “Answered by D2, 14 September”, with a link. The question stays, so the next person to ask it finds the answer and the reason.

6. 6

   Have your assistant research the landscape, then check it

   Ask your assistant to research how comparable products handle approvals, delegation and limits, from their public documentation and help pages only, and to file what it finds as a new document on the shelf, one finding per product, each with its source links. This needs an assistant with web search: Claude and ChatGPT have it; many local set-ups do not.

   Treat it as a first pass. Open every source, check that the page says what the finding says and when it was written, and delete what you cannot confirm. Then link the checked findings from the requirements they inform.

7. 7

   Share with stakeholders, and file what they say

   Press Share, copy the link when it appears, and set its expiry date to the day after the review. Keep anything a customer shared under NDA out of this document; put it in a private document and link to it. Stakeholders read the overview and findings with their types; they do not see your notes.

   Their feedback comes in the review or by email; file it as a new Question, a Risk or a note. Before the next review, ask your assistant to summarise each requirement’s Revisions since the last one, and open with that.

8. 8

   Turn the approved requirements into a plan

   Once the review approves the document, ask a coding assistant with the know.sh plugin, such as Claude Code, to build a campaign from it: an operation set per milestone, an operation per Key requirement linking back to its finding, and a blocks dependency wherever an open Question still stands in the way. The graph shows what cannot start until something is decided.

   The campaign is your view of sequence; there are no assignees, and engineering’s tickets stay in their tracker.