# A product requirements document — research, requirements and open questions in one place Recipe No. 36, Work and teams. From The know.sh Cookbook: https://know.sh/cookbook/product-spec - For: a product manager at a B2B software company writing the requirements for a new feature - You bring: notes from customer interviews, the support tickets that started it, a goal from the roadmap, and the questions engineering has already asked - You get: a requirements document whose overview states the problem and goals, with numbered requirements, evidence, risks, open questions and decisions, a link for stakeholders, and a build plan - Time: an hour for your assistant to draft it, a day for you to rewrite and check it, then fifteen minutes after each interview or review - Keep it: private while you work; share one document by a read-only link A requirements document usually starts as a page of good intentions and ends as three versions in three places: the one sales read, the one engineering built from, and the one with the answers to last week's questions. The evidence that justified each requirement is in someone's interview notes, and nobody can say which requirement it supports. This recipe keeps one document for the feature. The overview states the problem and the goals, and each finding is one thing a reader needs to see on its own: a requirement filed as a *Suggestion*, an interview filed as *Evidence*, a *Risk*, an open *Question*, and the *Decision* that settles it. Requirements link to the evidence they rest on, and every open question stays visible until a decision answers it. Your assistant builds the first draft from your interview notes and researches the competitive landscape; you rewrite and check it in the editor, stakeholders read it from a link, and once it is approved a coding assistant lays the build out as a campaign. Mock-ups stay in your design tool and tickets in your tracker. This is where the reasons live. ## What you will use - **Your AI assistant**: Claude, ChatGPT or a local model turns your interview notes and tickets into a first draft of the document, researches the landscape if it can search the web, and reports what changed before each review. - **The editor**: Where you rewrite the problem statement in your own words, fix each requirement, reorder, change types and mark the must-haves **Key**. - **Finding**: Requirements as *Suggestion*, interviews as *Evidence*, then *Risk*, *Question* and *Decision*. - **Links between documents**: Each requirement links to the evidence behind it, and each answered question to the decision that answered it. - **Public link**: A read-only link for stakeholders, expiring after the review, with anything under NDA kept in a separate private document. - **Revisions**: What changed in each requirement since the last review, and whether you or an assistant changed it. - **Campaigns**: A coding assistant with the know.sh plugin, such as Claude Code, turns the approved requirements into operations with dependencies. ## Method ### 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. 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. 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. 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. 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. 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. 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. 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. ## Prompts to try Your assistant, connected to know.sh (Claude, ChatGPT or a local model): > Research on the web how procurement tools for mid-sized companies handle multi-step purchase approvals, delegation and approval limits? Use public documentation, help centres and release notes only; no review sites or forums. One finding per product, quoting each claim with its link and saying when a page is undated, and a last finding comparing them. File it in know.sh as a new document on my Product specs shelf. Your assistant, connected to know.sh (Claude, ChatGPT or a local model): > Using know.sh, read the document Multi-step purchase approvals on my Product specs shelf. List every requirement that does not link to an Evidence finding, every Question that has no Decision answering it, and every Risk that no requirement addresses. Cite each finding by number. Do not change anything. Your assistant, connected to know.sh (Claude, ChatGPT or a local model): > Using know.sh, look at the revisions of every finding in the document “Multi-step purchase approvals” on my Product specs shelf since 1 September and write me a short list of what changed in each requirement and who made the change, so I can open the review with it. A coding assistant with the know.sh plugin, such as Claude Code: > Read my know.sh document “Multi-step purchase approvals”. Create a campaign called “Multi-step approvals: build plan” with an operation set per milestone and an operation per Key requirement, each linking back to its finding. Where an open Question blocks a requirement, add an operation for answering it with a blocks dependency. Leave everything as draft. ## Variations - For a small feature, write a one-page version: the overview and five findings, with no research document. - If you keep a [user research repository](/cookbook/research-repository), link its *Evidence* findings rather than copying interview quotes into each requirements document. - Decisions that outlive the feature, such as a new data model, belong in a *Decision* finding the team can find again, linked from here. - The competitive research doubles as the start of [battlecards](/cookbook/battlecards) for product marketing, once every claim is checked. ## Where it falls short - There is no approval workflow. Stakeholders cannot sign off in know.sh; record each approval as a *Decision* with its date. - Readers cannot comment on the link. Feedback arrives by meeting or email, and you file it. - No mock-ups or diagrams. Link to them in your design tool from the requirement’s sources. - Web research needs an assistant with web search, and any assistant can misread a page or a note. Revisions show everything it filed. - The campaign does not create tickets in your tracker or follow their status. It is a plan you keep up to date yourself. ## A note on customers, NDAs and competitors Describe interviewees by role and company size, not by name, and quote a customer on a shared link only if your agreement with them allows it. Anything a customer or partner shared under NDA, such as their roadmap, prices or internal process, stays out of shared documents entirely. Competitive research should use public sources only. Assistants can make mistakes; check every claim against the page it came from, and note the date you read it. Indexed under: Product requirements, Requirements, Stakeholder reviews, Competitive landscape, Open questions, Acceptance criteria, Build plans.