How to Dictate a Product Requirements Document (PRD) in One Sitting

Short answer: To dictate a product requirements document, speak the prose sections and type the values. Narrate the problem, goals, non-goals, and user stories right after a discovery call while context is fresh, then edit. Speech runs at 130 to 150 words per minute against roughly 40 typed.

Here is a pattern most product managers will recognise. An engineer stops by your desk and asks what the new feature is supposed to do. You explain it in about three minutes. You cover the problem, who has it, why it matters now, what the first version does, what it deliberately does not do, and the one edge case that worries you. The engineer nods and walks away with a clear picture.

Then you sit down to write the PRD, and it takes the rest of the afternoon.

The thinking was already finished. It was finished before the engineer walked over. What took the afternoon was not analysis, it was transcription of your own thoughts through a keyboard, and that is a very different problem from the one most PRD advice tries to solve.

The bottleneck is input, not rigor

PRD templates, frameworks, and "how to write a great spec" guides all assume the hard part is knowing what to write. Often it is not. The hard part is the mechanical cost of producing 1,200 to 2,000 words of structured prose when you already know all of it.

Run the arithmetic honestly. The average adult types around 40 words per minute. Even a strong professional typist runs 80 to 100. A 1,500-word PRD at 40 words per minute is roughly 35 minutes of pure keystrokes with zero pauses, zero rereading, and zero thinking. Nobody writes that way, so the real number is two to three times higher.

Speech runs at 130 to 150 words per minute, and it is the speed you already explained the feature at. The same 1,500 words spoken is around ten to twelve minutes of talking.

That gap is not a productivity trick. It changes which parts of the document get written at all. When prose is expensive, you unconsciously ration it. The sections that get cut are always the same ones: the context paragraph that explains why now, the non-goals, the edge cases, and the open questions. Those are exactly the sections that prevent an engineer from building the wrong thing, and they get dropped because they are long to type and feel optional at the moment you are tired.

Inventory: how much of a PRD is actually prose?

Before changing your process, look at what a PRD is made of. A typical one contains:

• Problem statement: prose
• Background and context: prose
• Goals: prose
• Non-goals: prose
• User stories or scenarios: prose
• Functional requirements: mostly prose with embedded values
• Edge cases and failure states: prose
• Open questions: prose
• Success metrics: numbers
• Dates, owners, links, ticket IDs: values

Eight of ten sections are things you would say out loud in a room. Two are things you would write on a whiteboard. That ratio is the whole argument for dictating a product requirements document rather than typing it, and it is also the source of the one rule that keeps this from going wrong.

The rule: speak the prose, type the values

Dictate the reasoning. Type anything where a small transcription error would be invisible.

This is not a hedge about accuracy. It is about a specific failure mode. If a transcription engine mishears a word in a sentence, you see it immediately, because the sentence reads wrong. If it mishears a number, the sentence still reads perfectly. A success metric of "reduce time to first action by 14 percent" that arrives as "40 percent" looks exactly as correct as the real thing. Nobody catches it in review. It gets quoted in a roadmap deck three weeks later, and by then it is a commitment.

So type, by hand, every time:

• Success metrics and target thresholds
• Dates, deadlines, and sprint numbers
• Ticket IDs, PR links, and document URLs
• Pricing, limits, quotas, and any figure with a unit
• Code identifiers, API field names, and anything camelCase

Speak everything else. The split is not a compromise, it is the reason the method holds up under review.

The timing change that matters more than the tool

Most PRDs are written at the wrong time. You have the discovery call on Tuesday, and you write the document on Thursday. By Thursday you are not writing, you are reconstructing: rereading your own shorthand notes, trying to remember what the customer actually meant, hunting through your calendar to work out who said the thing about the export flow.

Reconstruction is where the hours go, and it is also where fidelity is lost. The specific phrase the customer used, the one that would have made the problem statement land, is gone by Thursday.

The change is to move the capture earlier. In the ten minutes after the call, while the picture is still fully loaded in your head, dictate the problem statement and the context section straight into the document. Do not shape it. Do not worry about the heading structure. Just talk through what you now understand, the way you would explain it to a colleague who missed the call.

On Thursday you are no longer writing from nothing. You are editing a messy but complete draft that contains the real reasoning, in your own voice, with the customer's actual phrasing intact. Editing is faster than writing and it is a different kind of tired.

This is the same principle behind writing status reports from captures rather than memory, and it produces the same effect: Friday stops being archaeology.

Section by section

Problem statement

Speak the answer to one question: why does this matter, and why now? The "why now" half is the part that gets skipped when typing, and it is the part that stops a project from being deprioritised in month two, because it is the only section that explains the cost of waiting.

Say it as if the person listening is skeptical and busy. Skepticism in the room produces better prose than a blank page does.

Goals and non-goals

Non-goals are the highest-value, most-skipped section in any PRD. They are what stops an engineer from spending a week on something you never wanted, and they are cheap to say and tedious to type, which is precisely why they get dropped.

Speak them as a list of temptations you are declining. "We are not building the bulk version. We are not touching permissions. We are not solving the mobile case in v1, and here is why." Ninety seconds of talking produces a section that would have taken fifteen minutes to type and, more often than not, would simply not have been written.

User stories and scenarios

Narrate someone's actual day rather than filling in a template. Instead of writing "As a user, I want to export data so that I can analyse it," describe the person: what they were doing before they reached this screen, what they are trying to get done, what they do with the result afterward.

Narration is hard to fake. When you speak a scenario aloud and it turns out you cannot describe what the person does next, you have found a genuine gap in your understanding, and you have found it now rather than in sprint planning.

Functional requirements

Describe the happy path first as a continuous story, start to finish, without stopping to format. Then go back and speak the branches: what happens when the input is empty, when the network drops, when the user lacks permission, when the record was deleted while the form was open.

Conditionals are expensive to type and cheap to say, which is why edge cases are systematically under-documented across the whole industry. Speaking them is the single biggest quality gain in this method.

Type the values inside the requirements: the field limits, the timeout, the retry count. Speak the sentence around them.

Open questions

This section rarely gets written, and the reason is psychological rather than practical. Typing out a question you cannot answer feels like documenting your own ignorance, and the keyboard gives you plenty of time to talk yourself out of it.

Speaking is faster than that hesitation. Say the three things you are unsure about and who could resolve each one, and move on. An open question with an owner attached is a decision waiting to happen. An unwritten open question is a surprise in week three.

Success metrics and rollout

Type the numbers. Speak the reasoning around them: why this metric and not the obvious one, what would make you roll it back, what you expect to be true a month after launch.

Two passes, not one

Do not try to dictate a finished document. Trying to speak polished prose in final order is slower than typing, and it feels awful.

Pass one is capture. Talk through the whole thing in whatever order it comes out. Repeat yourself. Go on tangents. The output is messy and complete, which is a much better starting condition than tidy and half-finished.

Pass two is shaping. This is mostly deleting: cutting the repetition, moving the paragraph that belongs in context out of the requirements section, adding the headings. Deleting is the fastest kind of editing there is, and a good editing pass on a rambling draft is quicker than a first draft on a blank page.

The underlying trade is worth naming. Dictation converts a generation problem into a cutting problem, and cutting is easier.

Where PRDs live, and what to watch for

Every document tool has a few behaviours that will interrupt a dictation flow the first time you meet them. None are hard to work around once you know they exist.

• Return often does something. In block editors it starts a new block. In comment boxes and ticket fields it frequently submits. If you dictate "new paragraph" you may split one thought into four blocks, or post a half-finished comment.
• Auto-formatting fires on leading characters. A dictated hyphen or a sentence starting with a number can convert your paragraph into a list. Add structure with the keyboard after the text lands, not during.
• Slash and at-sign open menus. In Notion, Linear, Slack, and most modern editors, these characters open a command palette or a mention picker that then swallows the following words as a search query. This is the most common cause of "half my paragraph vanished."
• Selection is not insertion. A block highlighted as an object has no caret. Confirm a blinking cursor before you speak.
• Single-key shortcuts. Trackers like Linear and Jira bind bare letters to actions when focus is outside a text field. Move your dictation trigger to F13 through F19 so it never collides.

We have per-tool walkthroughs for the places PRDs usually live, including voice typing in Notion and dictating in Linear on Mac.

Teach it your product's vocabulary

Every product organisation runs on words that no general transcription has ever seen: the internal codename for the project, the two services that talk to each other, the acronym your company uses for a customer segment, the surname of the engineering lead.

Generic transcription will get these wrong, and it will get them wrong differently each time, which matters more than it sounds. PRDs get searched, not read. A project name spelled three ways across a quarter of documents silently halves what anyone can find later.

Voice Keyboard Pro's Smart Vocabulary is a personal dictionary with replacement rules, and the honest way to build it is not to sit down and brainstorm terms. Dictate normally for two days, notice what you correct by hand, and add those. Twenty entries drawn from real corrections outperform two hundred guessed ones.

One caveat specific to product work: keep the entries to things you would actually say aloud in a meeting. Do not add mixed-case code identifiers as replacement rules. Those belong in the type-them-by-hand category, and turning them into speech rules produces surprising substitutions in ordinary sentences.

Meeting Mode for discovery and spec review

Two meetings produce most of a PRD's raw material: the discovery conversation where you learn the problem, and the spec review where engineering pushes back on it.

Voice Keyboard Pro's Meeting Mode on Mac records with speaker detection and produces AI notes, which is useful for both. In discovery, the customer's exact phrasing survives to the moment you write the problem statement. In spec review, the objection an engineer raised in passing is still there when you update the document, and the reasoning behind a decision is preserved rather than reconstructed. Calendar meeting detection means it can start when the meeting does rather than three minutes in.

Two boundaries worth stating plainly. Tell people in the room that you are recording, out loud, before you start. And treat the output as raw material rather than a deliverable: a set of meeting notes is not a PRD, and pasting one in as if it were is how documents lose their argument.

Capture away from the desk

A good deal of product thinking does not happen at a keyboard. It happens walking between meetings, on the way home, or in the twenty seconds after a support conversation when you finally understand what the problem actually is.

On iPhone, Voice Keyboard Pro is a custom keyboard with a microphone button built in, so you can dictate into whatever app you already keep notes in. Voice Edit lets you speak a change to fix text, which is considerably easier than placing a cursor precisely on a phone. For teams that write in one language and discuss in another, two-way translation across 24 languages while dictating covers the case where the person who understands the requirement best is not fluent in the document's language. Treat translated requirements as a first draft that a fluent colleague reviews, since people implement specifications literally.

What this does not do

Being straight about the limits, because the method is stronger without overclaiming:

• It does not decide what to build. Prioritisation, trade-offs, and judgment are still yours. A faster way to write a bad spec produces a bad spec sooner.
• It does not structure the document. You still choose the sections and the order. Dictation produces text at your cursor, not an outline.
• It does not write code or schemas. Do not dictate identifiers, JSON, or SQL. Type them.
• It does not integrate with your tracker. There is no plugin and no ticket sync, by design. It types where your cursor is, which is why it works in every tool without any of them having to support it.
• It needs a connection. Transcription runs in the cloud, so an offline flight is a typing flight.
• It is audible. You are speaking out loud. In an open-plan office, some of this belongs in a room with a door, particularly anything touching headcount, pricing strategy, or a named customer.

On privacy, since PRDs are frequently the most sensitive document a company writes: our servers store only operational pings. No audio and no transcript content is retained, and your history stays on your device.

A realistic first week

Do not start by dictating a whole PRD. Start with the section you most often skip.

• Day 1: Dictate only the non-goals section of whatever you are working on. It is short, it is low-stakes, and it is the section that most reliably gets dropped.
• Day 2: After your next discovery call, spend ten minutes speaking the problem statement into the document before you do anything else.
• Day 3: Dictate the edge cases for one requirement. Notice how many you say aloud that you would not have typed.
• Day 4: Add the ten terms you have corrected by hand to Smart Vocabulary.
• Day 5: Do a full capture pass on a new document, then a shaping pass. Time both.

The test at the end of the week is not speed. Open the last PRD you typed and the first one you dictated, and compare the non-goals and edge-case sections. That is where the difference shows up.

Frequently asked questions

Will a dictated PRD sound unprofessional?

The opposite is the more common outcome. The stiff, passive, feature-list register that PRDs often fall into is largely an artifact of typing, where every sentence costs enough that you default to a formal template. Spoken explanation is usually clearer because it was aimed at a listener. The shaping pass removes the filler.

Can I dictate user stories in the standard format?

You can, but consider not doing it. The "as a user, I want, so that" template is quick to fill and easy to fill emptily. Narrating the scenario produces more useful text, and you can compress it into template form afterward if your team requires the format.

Does this replace writing skill?

No. It removes the input cost and leaves the thinking, the structure, and the editing exactly where they were. What changes is that the expensive sections stop being rationed.

What if I share a workspace?

Speaking is audible, and that is a real constraint. Most people end up with a hybrid: dictate the long prose sections when they can, type in the open office, and use a phone for capture on the move. Sensitive content should be in a room with a door regardless of how it is being written.

Does it work in Confluence, Google Docs, Word, and Jira?

Yes. It inserts text wherever your cursor is, so any tool with a text field works without needing to support anything. The tool-specific behaviour to watch is what Return does and which characters open menus.

How is this different from dictating other work documents?

The method is the same shape, but the sections and the traps differ by artifact. We have companion guides for pull request descriptions and for SOPs and procedures, both of which apply the same speak-the-prose rule to a different document.

You can explain the feature in three minutes. The document should not take the afternoon.

The thinking is the job. Getting it out of your head and onto the page is overhead, and it is overhead that quietly determines which sections of your specs get written. Voice Keyboard Pro has a free tier. Try it on the non-goals section of your next PRD and see whether it survives to the final draft.