A product requirements document for a voice assistant feature defines the natural language understanding (NLU) requirements, dialogue design specifications, multi-modal fallback behaviors, and acceptance criteria that the voice feature must meet — bridging the gap between conversational UX design and engineering implementation.
According to Lenny Rachitsky on Lenny's Podcast, voice as a product surface is fundamentally different from GUI: there is no visual hierarchy to guide users, which means the PM must specify the conversation design as rigorously as any UI spec.
According to Gibson Biddle on Lenny's Podcast, the hardest part of voice feature PRDs is defining what "success" looks like — because voice NLU accuracy alone doesn't predict user satisfaction. A feature that accurately understands 95% of commands but handles the 5% failure case poorly will fail in user testing.
According to Chandra Janakiraman on Lenny's Podcast, voice features in B2B products often fail because PMs spec them like chat features, not like voice features — overlooking ambient noise, hands-free contexts, and the user's inability to re-read instructions.
Voice Assistant Feature: A product capability that accepts spoken input, processes natural language to extract intent, and responds with synthesized speech or action — requiring distinct design and technical requirements from traditional GUI features.
Voice Assistant PRD Template
1. Feature Overview
Feature Name: [Voice Command: Feature Name] Platform: [Web / iOS / Android / Smart Speaker / Desktop] Voice Engine: [Whisper / Google Cloud Speech / Azure Speech / Amazon Transcribe] NLU Provider: [Dialogflow / Amazon Lex / Rasa / Custom LLM] Status: [Draft / Review / Approved]
One-Line Summary: Enables users to perform [core action] using natural voice commands, reducing the interaction time from [X clicks] to a single spoken command.
2. User Context and Constraints
Define when and where users will invoke this voice feature:
| Context | Description | Design Implication | |---------|-------------|-------------------| | Hands-free | User cannot use keyboard/mouse | Must work without any visual confirmation | | Ambient noise | User in noisy environment (kitchen, car) | Wake word must tolerate 60dB background noise | | Privacy-sensitive | User in shared workspace | Must support silent/text mode fallback | | Low-bandwidth | Mobile user on 3G | NLU response latency target <2s even on mobile |
3. Intent Library (Core Commands)
For each intent, define:
- Intent name: Canonical command category
- Sample utterances: 5-10 variations of how users might phrase the command
- Required slots: Entities that must be extracted (date, quantity, item name)
- Slot confirmation: When must the assistant confirm extracted slots before acting?
Example Intent: Create Task
| Slot | Required | Examples | Fallback if missing | |------|----------|----------|--------------------| | task_name | Yes | "write report", "review PR" | Ask: "What should I call this task?" | | due_date | No | "tomorrow", "Friday" | Default: no due date | | assignee | No | "for Sarah", "assigned to me" | Default: current user |
Sample utterances:
- "Add a task to write the quarterly report"
- "Create a new task called review the PR for tomorrow"
- "Remind me to call the client on Friday"
- "Add review mockups to my task list"
4. Conversation Flow Specifications
4.1 Happy Path
User: "Add a task to review the PR"
Assistant: "Done. I've added 'Review the PR' to your task list. Would you like to set a due date?"
User: "Yes, by tomorrow"
Assistant: "Got it. 'Review the PR' is due tomorrow."
4.2 Clarification Flow (Ambiguous Slot)
User: "Add a task for Sarah"
Assistant: "What should the task be called?"
User: "Design review"
Assistant: "Done. 'Design review' has been assigned to Sarah."
4.3 Error Recovery Flow
User: "[unintelligible]"
Assistant: "Sorry, I didn't catch that. You can say things like 'Add a task' or 'Show my tasks'."
User: [No response for 5 seconds]
Assistant: [Exits voice mode, shows visual prompt with suggested commands]
5. NLU Performance Requirements
| Metric | Target | Measurement Method | |--------|--------|-------------------| | Intent recognition accuracy | >92% on test set | Monthly evaluation against labeled corpus of 500+ utterances | | Slot extraction accuracy | >88% | Automated slot-level evaluation | | False wake word trigger rate | <1 per hour in typical use | Field test with 20 users | | End-to-end response latency | <1.5s at p90 | Synthetic load test | | Fallback trigger rate | <15% of sessions | Production monitoring |
6. Accessibility Requirements
- Text fallback: every voice-actionable command must also be executable via keyboard
- Visual confirmation: all actions taken via voice must show a visual confirmation toast
- Transcript availability: users can access a session transcript of voice commands and responses
- Screen reader compatibility: voice mode activation/deactivation must be accessible via keyboard shortcut
7. Privacy Requirements
- Audio data is NOT stored unless user explicitly opts in to "voice history"
- Wake word detection runs on-device (no audio streaming before wake word confirmed)
- NLU inference (post-wake-word) may use cloud processing — disclose in privacy policy
- User can delete voice interaction history at any time
8. Acceptance Criteria
- [ ] Intent recognition accuracy >92% on the 500-utterance evaluation set
- [ ] All core intents handle slot clarification without user frustration (usability test: <2 clarification turns per command on average)
- [ ] Error recovery flow exits gracefully to visual fallback within 5 seconds of failed recognition
- [ ] Text fallback available for all voice commands on all platforms
- [ ] Audio data deletion flow operational and tested
- [ ] Accessibility: all voice controls operable via keyboard
Common Pitfalls to Avoid
- Over-specifying sample utterances and under-specifying error recovery — error handling is where voice features succeed or fail
- Missing the multi-modal fallback — voice features without a text fallback fail users in environments where speech isn't appropriate
- No latency requirements — voice UX is latency-sensitive; a 3-second pause after a command feels like a broken product
Success Metrics
- Voice feature daily active users grows to 30%+ of eligible users within 60 days of launch
- Fallback trigger rate <15% (most commands are recognized correctly)
- User satisfaction with voice feature >4.0/5.0 in in-app rating prompt
For more, visit PM interview prep and daily PM tools.
Learn about voice and AI product UX at Lenny's Newsletter.
Frequently Asked Questions
What should a PRD for a voice assistant feature include?
Include user context and constraints (hands-free, noisy, privacy-sensitive scenarios), an intent library with sample utterances and slot definitions, conversation flow specs (happy path, clarification, error recovery), NLU performance requirements, privacy requirements, and acceptance criteria.
What is a good intent recognition accuracy target for a voice assistant?
Target >90% accuracy on a labeled test corpus of at least 500 utterances covering all core intents and common variations. Below 85%, user frustration drives abandonment. Test monthly as the NLU model is updated.
How do you handle voice feature privacy requirements in a PRD?
Specify on-device wake word detection (no audio streaming before wake word confirmed), no audio storage without explicit opt-in, cloud NLU disclosure in the privacy policy, and a user-accessible voice history deletion flow.
What is a voice feature fallback and why is it required?
A fallback is the behavior when voice recognition fails or the user is in an inappropriate context (noisy, silent office). Every voice feature must have a text/keyboard alternative — voice-only features exclude a significant portion of use cases.
How do you measure voice feature success?
Track intent recognition accuracy (NLU quality), fallback trigger rate (how often recognition fails), end-to-end latency, daily active users of the voice feature, and user satisfaction rating. Latency and fallback rate are the most user-experience-sensitive metrics.