Every PRD starts from a blank page. The user research is in Dovetail, the related decisions are in a thread, the prior PRD is in a folder nobody remembers. The first hour is just gathering — and by the time the gathering is done, the part of the day with judgment in it is gone.
Drafting works. Synthesis doesn't. We didn't build another doc tool — we built the part the document can't do for itself: the part that gathers the interviews, the decisions, the prior specs, and the meeting notes before the cursor blinks. Some people will call this an AI PRD writer. We call it the missing function of the spec.
A PRD isn't really a document — it's a synthesis. The synthesis lives in scattered places. Customer interviews sit in one transcription tool, the prior PRD lives in a folder nobody remembers, the architectural decisions are in a Slack thread, the meeting where the team finally agreed on a metric is in someone's calendar three weeks back.
The "blank page" you're staring at on Monday morning isn't really blank — it's the bill for tools that don't talk to each other. The first hour of every PRD is the same hour: opening tabs, copying excerpts, remembering whose Loom held the answer to the question you're now trying to write down.
That's not a writing problem. It's a retrieval problem upstream of the writing. Generic AI writers will draft you a PRD from a description; what they can't do is draft from the evidence you actually have, because the evidence was never connected in the first place.
Knovya is the part of the system that does the synthesis — so by the time you open the PRD, the inputs are already gathered. Customer interviews land as notes with transcripts attached. Decision logs link backward to the meetings that produced them. Prior specs surface as precedents the moment you start a new one.
AI co-edit drafts the scaffold from that material — problem statement from the interview themes, user stories from the recurring jobs-to-be-done, success metrics from the decisions you've already made about what good looks like. You start the PRD by editing a synthesis, not by inventing one.
We don't call ourselves an AI PRD writer. We call it the missing function of the spec — the part the spec can't do for itself, because the synthesis has to happen before the first sentence.
The PRD that arrives already half-written, by you, two weeks ago.
Three moments in a typical product cycle. Pick one — the archive lights up the part of itself the PRD would actually use. No live data, no signup; the moves are real, the notes are illustrative.
The interview transcripts and prior PRDs are already in the archive. The competitor's changelog from Tuesday's research is linked.
Last quarter's auth-flow PRD surfaces as a precedent — the success metric you anchored on, the scope you cut, the decision Slack archived.
Open the new PRD on Wednesday. Problem statement, hypothesis, and three user stories are already drafted from the gathered material — you're editing, not inventing.
Friday: a public link to the PRD goes to stakeholders. Comments track in place; the version preserved.
Cagan called the document a PRD. We call these the four moves the document needs the archive to make for it.
Knovya doesn't ask you to write the PRD alone — the archive does the gathering, the framing, and most of the first draft. Here's which features carry which move, mapped to the elements you'll find on the periodic table at /features.
Pull every input the PRD needs into the archive — interviews, web research, conversations — before the writing starts.
A Claude or ChatGPT exploration becomes a real entry — exec brainstorms, problem framings, analyses.
Walk-and-talk debrief after the user interview, transcribed and structured.
A competitor's product page or changelog, clipped with source intact.
The archive surfaces the precedents — past PRDs, related decisions, recurring quotes — that frame the new one.
The PRDs you've already shipped surface alongside the one you're starting — the precedents do the talking.
Every decision the PRD references is visible from both sides — read the why before re-litigating it.
"What did the team say about onboarding friction?" — keyword and meaning, ranked together.
The scaffold writes itself from the gathered evidence — problem, hypothesis, user stories, success metrics.
Themes from interviews. User stories from JTBD patterns. Success metrics from prior decisions.
A relevant interview quote from six weeks ago appears next to the section it belongs in.
The most-connected research notes rise first — the strongest material lands in the draft.
Stakeholder review, engineering handoff, design pickup — the PRD travels through the tools your team already lives in.
A reviewable URL for stakeholders — comments tracked, version preserved, no Notion paywall.
Cursor, Claude, and ChatGPT read the PRD natively — engineering opens the spec inside the editor.
The PRD's connection density visible at a glance — every input that fed it, every spec it'll feed.
The PRD is one of the older artifacts in product management — older than agile, older than product management as a profession with that name. Its history is mostly a series of attempts to shrink it without losing it. Knovya is the latest answer to a very old question: how does the document arrive ready?
Horowitz and Weiden circulate the Good Product Manager / Bad Product Manager memo inside Netscape and Loudcloud. The PRD is treated as the central artifact — the product "Bible" for marketing, design, and engineering. The role gets its first widely-shared definition; the document gets its first widely-shared expectation.
Cagan publishes a 37-page paper through Silicon Valley Product Group, drawing on Horowitz's notes. The document codifies the structure most modern PRDs still echo: purpose, features, release criteria, rough timing. It travels by email between product leaders for the next decade — the kind of guide-by-forwarding that defines a profession's literature.
Cagan publishes Inspired; product management becomes a teachable discipline with a canonical book. The PRD enters PM curricula at every B-school and bootcamp. The artifact is now everywhere — and so is the version of it nobody on the team actually reads.
Cagan himself starts critiquing the artifact — Discovery vs. Documentation argues the spec works only when it follows real product discovery. One-pager PRDs spread through Silicon Valley. Linear, Notion, and Coda ship templates that compress the ten-step canon into four sections. The document gets shorter; the synthesis problem doesn't.
ChatPRD launches as the first AI dedicated to the artifact. NotebookLM lets PMs feed in transcripts and ask for outlines. Cursor brings AI drafting to the documents engineers actually open. The blank page stops being the bottleneck — but the AI is still drafting from a prompt, not from your archive. The synthesis is still the missing step.
We built the part Horowitz, Cagan, and the lean-PRD generation kept describing in the negative space: the synthesis layer underneath the document. Customer interviews, decision logs, prior specs, and meeting notes are linked before you start. AI co-edit drafts the scaffold from that material. MCP exposes the result to Cursor, Claude, and ChatGPT. The missing function, finally external.
Every tool in this category is wagering on a piece of the PRD workflow — the template, the editor, the AI, the handoff. The honest comparison isn't features. It's which piece each app decided to be best at, and which it's leaving to you.
The bet A library of structured templates. The PRD lives as a Notion page with the right sections waiting; the team can fill them in, link to other pages, embed designs.
What's left to you The synthesis. Templates give you the shape; the content still has to be gathered, paragraph by paragraph, from sources Notion doesn't reach.
The bet The PRD is a Linear document attached to the project, with engineering tickets, design files, and decisions linked from the same surface. The execution loop is tight.
What's left to you The discovery layer. Customer interviews, prior research, and the messy pre-decision context live outside Linear. The spec arrives clean; the why doesn't.
The bet The PRD is a live document that's also a database — structured fields, formulas, views. Status updates aren't a paragraph; they're a query.
What's left to you The first draft. Coda's AI fills cells well; it doesn't draft from your interview transcripts or prior specs because they were never in Coda to begin with.
The bet A model fine-tuned on the artifact. Type a problem description; receive a complete PRD scaffold in seconds. The category-defining AI PRD writer of the 2023–25 wave.
What's left to you The evidence. The AI drafts from your prompt — your description of the problem, not the interviews you did, the decisions you logged, the prior PRD nobody re-read. It's a confident first draft of what you can already articulate, not what you've already learned.
The bet The synthesis is the product. Customer interviews, decision logs, prior specs, and meeting notes belong in one archive — and the PRD draft should arrive built from them. MCP exposes the result to Cursor, Claude, and ChatGPT for the handoff.
What's left to you Picking what matters. The gathering is on the system. The judgment — which themes to lift, which decision to anchor on, which user story to lead with — is the only piece left for you.
We didn't pick a piece of the workflow to be best at. We picked the inputs.
A PRD doesn't get drafted at one desk in one sitting. The interview happens on a call. The debrief happens on a walk. The competitive note happens in a browser tab at midnight. The handoff happens inside Cursor. Knovya runs on every surface where a part of the document gets made.
Speak the debrief on the way back to your desk — the quote that mattered, the framing the customer used, the thing you almost missed. Lands as a structured note linked to the transcript.
A side panel shows the four inputs feeding the draft — interview, decision, prior PRD, meeting — each linked, each editable. The AI writes the first scaffold; you write the version that ships.
Highlight a sentence in any changelog or product page — the clip lands as a research note attached to the PRD it belongs to, with the source URL intact and the semantic neighbors already wired in.
Through MCP, the PRD is readable inside Cursor as the engineer opens the file, inside Claude as design pulls quotes, inside ChatGPT during the stand-up. No copy-paste, no version drift.
Not every spec is the same artifact. A feature PRD is a different document than an MVP brief is a different document than a technical spec. Knovya ships five starting points — pick the one that matches the moment, then let the archive fill the sections.
When the team's adding a capability to something that exists.
Before you've built anything — when the bet is the document.
When engineering writes the doc and the PM reviews it.
When you're rebuilding what shipped — and what you learned matters more than what you'll build.
When the team is small, the loop is fast, and the spec ships next week.
A PRD doesn't get written in isolation. It lives downstream of customer research, alongside decision logs, and upstream of design and engineering tickets. Here's the constellation around this page.
Themes from interviews, user stories from JTBD patterns, success metrics from past decisions — the scaffold writes itself.
See featureThe PRDs you've already shipped surface alongside the one you're starting — precedents do the talking.
See featureAn interview transcript or a Claude exploration becomes a real entry — searchable, linkable, draftable.
See featureCursor, Claude, and ChatGPT read the PRD natively — engineering opens the spec inside the editor.
See feature"We re-litigated the same architectural decision three times this year because nobody could find the original thread."
A decision log that surfaces the precedent — when the question comes up again, the answer is already attached.
See the workflow Problem 10 · Chapter II"Twelve customer interviews this quarter. The themes are in someone's head. The transcripts are in Dovetail. The PRD asks for both."
Interviews that turn into themes on their own — quotes cluster, jobs-to-be-done emerge, the PRD pulls from the synthesis.
See the workflowA PRD doesn't have to start blank. Open the archive — the synthesis is already half-done by you, two weeks ago, in the interviews and decisions and meetings the team has already had. The first draft is waiting.
Or scroll back to the diagnosis.
Eight questions we keep getting from product teams. If yours isn't here, the contact page reaches us directly.
A PRD — Product Requirements Document — describes what a team is building, why it matters, who it's for, and how the team will know it worked. The artifact comes out of late-1990s product management practice (Ben Horowitz and David Weiden's Good Product Manager / Bad Product Manager memo treated it as the central PM document) and was canonized by Marty Cagan's 2005 paper How to Write a Good PRD. Modern PRDs are shorter and more user-focused than the original 30-page Word documents, but the job is the same: align engineering, design, and leadership on a single source of truth.
PRD stands for Product Requirements Document. The acronym is interchangeable with product spec in some teams; some companies use MRD (Market Requirements Document) or BRD (Business Requirements Document) for adjacent artifacts.
A modern PRD usually has six parts: the problem (who is hurting and why), the hypothesis (what we believe will help), user stories or jobs-to-be-done, success metrics, scope and non-goals, and risks or open questions. The order matters less than the chain of reasoning — every section should answer a question the previous section raised. Knovya drafts a scaffold of all six from your existing archive (interviews, decisions, prior specs), so you start by editing instead of inventing.
In product management the PRD is the document a PM produces to align the build team. It sits downstream of discovery (research, interviews, opportunity assessment) and upstream of execution (design, engineering tickets, release). Marty Cagan has argued that PRDs work when they follow real product discovery and fail when they replace it; Knovya is built around that distinction — the archive holds the discovery, the PRD is the synthesis.
A brief states intent in a paragraph or two — what we're going to do and why, before scope is settled. A spec describes the implementation — what gets built, how it behaves, the edge cases. A PRD sits between them: it commits to a problem, a target user, a success metric, and a rough scope, but leaves the implementation open for engineering and design to shape. Many teams collapse two of these into one document; the names matter less than the order.
ChatPRD generates a PRD from a prompt — strong if you can describe the problem from memory, thinner if you can't. Notion templates give you the right sections — strong if you know what to put in them, blank if you don't. Knovya drafts the PRD from material that already exists in your archive: interview transcripts, decision logs, meeting notes, prior specs. The first draft arrives as synthesis, not invention.
Yes. Knovya Free includes 50 notes, 50 AI credits per month, and 50 MCP calls per month — enough to import a handful of interview transcripts, draft a PRD scaffold from them, and have Cursor or Claude read the result. Most one-PM teams can run a full PRD cycle on the free tier before deciding to upgrade.
Pro and Team plans include note-level end-to-end encryption (AES-256-GCM); encrypted notes are not searchable or embeddable on the server, which matters when interviews contain customer names, contract terms, or unreleased product details. The Free tier uses transport encryption. Login is hardened with 2FA, device fingerprinting, and anomaly detection.