PRD Template for Automotive Products
A product requirements template for automotive product managers. Covers connected vehicle features, OTA updates, ADAS safety validation, in-vehicle UX, and the functional safety standards (ISO 26262) that automotive software must meet.
Why automotive PRDs must prioritize functional safety
Automotive software development operates under the strictest safety requirements in consumer technology. A bug in a mobile app causes frustration; a bug in an automotive system can cause a fatal accident. ISO 26262 defines Automotive Safety Integrity Levels (ASIL A through D) that determine the rigor of your development, testing, and validation processes based on the severity of potential harm.
Connected vehicle features add complexity: OTA updates must be fail-safe, vehicle-to-cloud communication must be secure against cyber attacks, and in-vehicle UX must minimize driver distraction. Automotive product managers must specify requirements that satisfy both safety engineers and UX designers.
This template provides automotive-specific guidance including functional safety classification, OTA update architecture, cybersecurity requirements (ISO/SAE 21434), and the validation and verification processes that automotive certification demands.
The complete automotive PRD template
Ten sections tailored for automotive products with industry-specific guidance, realistic examples, and practical tips.
Problem Statement
Define the automotive problem in terms of safety incidents, driver experience gaps, vehicle downtime, or manufacturing inefficiency. Automotive problems have safety implications that must be explicitly assessed.
Example: "Infotainment system crashes occur in 8% of vehicles within 12 months, requiring dealer visits for software reset. Each dealer visit costs the OEM $180 in warranty claims. Driver-reported difficulty with navigation input while driving correlates with a 23% increase in distraction-related near-miss events in our telemetry data."
Tips
- Assess safety implications for every problem — even infotainment issues can cause driver distraction
- Quantify warranty costs, recall risk, and customer satisfaction impact
- Include field telemetry data to support problem severity assessment
- Reference NHTSA complaint data and industry safety benchmarks
Goals and Objectives
Automotive goals must include functional safety targets, cybersecurity requirements, and regulatory compliance alongside user experience and business metrics.
Example: "Primary: Reduce infotainment system crashes by 90% through OTA-updatable software architecture. Safety: All driver-facing features must achieve ASIL B classification per ISO 26262. Security: Zero critical cybersecurity vulnerabilities per ISO/SAE 21434 threat assessment. UX: Driver task completion in under 2 glances and 3 seconds per NHTSA distraction guidelines."
Tips
- Include ASIL classification targets for safety-relevant features
- Set cybersecurity goals per ISO/SAE 21434 threat and risk assessment
- Driver distraction targets must comply with NHTSA Visual-Manual Guidelines
- Define OTA update success metrics: update completion rate, rollback rate, zero-brick rate
User Stories
Automotive user stories must account for the driving context: limited attention, hands on the wheel, eyes on the road. Every interaction must be designed for minimal distraction.
Example: "As a driver navigating to an unfamiliar destination, I want the navigation system to provide timely lane guidance with audio instructions so that I can follow the route without looking at the screen for more than 2 seconds. Acceptance criteria: audio instruction given 500m before maneuver; lane guidance displayed on instrument cluster (not just center screen); route recalculation within 5 seconds of missed turn; works without cellular connectivity using cached maps."
Tips
- Design for driving context: 2-second maximum glance time per NHTSA guidelines
- Include stories for driver, passenger, and back-seat occupants (different interaction levels)
- Cover vehicle lifecycle stories: purchase, first setup, daily use, service, OTA updates, resale
- Address multi-modal interaction: voice, touch, physical controls, gesture
Functional Requirements
Automotive functional requirements must specify vehicle bus communication, sensor data processing, real-time constraints, and fail-safe behavior for every safety-relevant function.
Example: "FR-1: OTA update system must support A/B partition architecture ensuring rollback to known-good software within 30 seconds if update validation fails. FR-2: Navigation must function with offline map data for areas with no cellular coverage; map updates via WiFi at home. FR-3: Voice assistant must achieve 95% intent recognition accuracy in 75dB ambient noise environment (highway driving with windows open). FR-4: All safety-relevant functions must continue operating during infotainment system reboot — safety domain isolated from infotainment domain."
Tips
- Define fail-safe behavior for every feature: what happens when it fails during driving
- Specify real-time performance constraints for safety-relevant functions (latency budgets)
- Include environmental requirements: temperature range (-40C to 85C), vibration, EMC
- Address multi-ECU architecture: which functions run on which domain controller
Safety and Cybersecurity Standards
Automotive products must comply with ISO 26262 (functional safety), ISO/SAE 21434 (cybersecurity), UN R155/R156 (cybersecurity and OTA regulations), and regional type approval requirements.
Example: "CR-1: ISO 26262 — functional safety concept developed for all safety-relevant features; ASIL classification per hazard and risk assessment; safety requirements traceable to validation test cases. CR-2: ISO/SAE 21434 — cybersecurity management system; threat analysis and risk assessment (TARA) for all connected features; vulnerability management process. CR-3: UN R155 — cybersecurity management system certification required for type approval in EU, Japan, South Korea. CR-4: NHTSA Federal Motor Vehicle Safety Standards (FMVSS) compliance for all driver-facing displays."
Tips
- ISO 26262 ASIL classification determines your entire development and testing process
- UN R155/R156 compliance is mandatory for vehicle type approval in many markets
- Cybersecurity requirements affect both the vehicle and the backend cloud infrastructure
- Include homologation timelines: type approval processes vary by market and take months
Success Metrics
Automotive metrics span safety, reliability, user satisfaction, and OTA update effectiveness. Field quality data from connected vehicles enables continuous monitoring.
Example: "Safety: Zero safety-related incidents attributable to software defects. Reliability: Infotainment crash rate. Baseline: 8% within 12 months. Target: under 0.5%. OTA: Update completion rate. Target: 98% within 30 days of release. UX: Driver distraction metric — average glance time per interaction. Target: under 2 seconds. Satisfaction: JD Power IQS score improvement. Target: Top quartile in segment."
Tips
- Safety metrics must be zero-tolerance for critical safety incidents
- Track field quality through vehicle telemetry: crash rates, error logs, restart frequency
- OTA update metrics: download rate, installation success, rollback rate, time-to-fleet-penetration
- Include warranty cost reduction as a business metric for quality improvements
Timeline and Milestones
Automotive development timelines are measured in years, not weeks. Include safety validation, cybersecurity certification, type approval, and production launch milestones.
Example: "Phase 1 (Months 1-6): Feature development and unit testing. Phase 2 (Months 7-9): Integration testing on hardware-in-the-loop (HIL) bench. Phase 3 (Months 10-12): Vehicle-level validation testing. Milestone: Functional safety assessment complete. Phase 4 (Months 13-15): Cybersecurity certification per ISO/SAE 21434. Phase 5 (Months 16-18): Type approval testing and homologation. Phase 6 (Month 19): Start of production (SOP)."
Tips
- Automotive programs run 18-36 months from concept to SOP — plan accordingly
- Include hardware-in-the-loop (HIL) and software-in-the-loop (SIL) testing phases
- Type approval timelines vary by market: EU, US, China, Japan each have different processes
- OTA-updatable features may have shorter cycles post-SOP but still require safety validation
Risks and Mitigations
Automotive risks include safety incidents, cybersecurity breaches, recall costs, and the reputational damage of vehicle malfunctions.
Example: "Risk: OTA update bricks vehicle control units, stranding vehicles. Likelihood: Low. Impact: Critical (safety, recall). Mitigation: A/B partition architecture; update validation before commit; staged rollout (1% > 10% > 100%); remote rollback capability. Risk: Cyber attack exploits connected vehicle API to access vehicle controls. Likelihood: Medium. Impact: Critical (safety). Mitigation: Defense-in-depth architecture; vehicle-to-cloud mutual TLS authentication; intrusion detection system; security operations center monitoring."
Tips
- Vehicle-level failures can cause safety incidents, recalls, and massive financial liability
- OTA update failures must never brick a vehicle — A/B partitioning and rollback are mandatory
- Cybersecurity breaches in connected vehicles are a growing threat — defense in depth is essential
- Include supply chain risk: semiconductor shortages and component availability affect timelines
Integrations
Automotive products integrate with vehicle ECUs via CAN/Ethernet, cloud platforms, mobile companion apps, and dealer service tools.
Example: "Integration 1: Vehicle bus — CAN FD and Automotive Ethernet for ECU communication. Integration 2: Cloud platform (AWS IoT, Azure IoT) — vehicle telemetry upload and remote command execution. Integration 3: Mobile companion app — remote lock/unlock, climate pre-conditioning, charging status (EV). Integration 4: Dealer diagnostic tools — DTC reading, software version management, calibration data. Integration 5: Third-party services — Spotify, Google Maps, Apple CarPlay/Android Auto."
Tips
- CAN bus and Automotive Ethernet have strict timing and priority requirements
- Cloud integration must handle intermittent connectivity gracefully
- Mobile companion app must work across iOS and Android with platform-specific vehicle control APIs
- Apple CarPlay and Android Auto integration has specific UI and interaction guidelines
Open Questions
Document unresolved decisions about platform strategy, OTA scope, third-party ecosystem, and regional market prioritization.
Example: "Q1: Should OTA updates include safety-critical ECUs or only infotainment initially? Safety-critical OTA adds tremendous value but requires ISO 26262 compliance for the update mechanism itself. Decision owner: VP Engineering. Q2: Should we build our own cloud platform or use a managed vehicle cloud (AWS IoT FleetWise, Azure)? Decision owner: CTO. Q3: Which markets launch first? EU requires UN R155/R156; US does not yet mandate equivalent cybersecurity certification. Decision owner: Head of Product."
Tips
- Safety-critical OTA is the future but requires extensive certification — plan a phased approach
- Build vs managed cloud platform affects time-to-market and ongoing operational cost
- Regional market prioritization depends on regulatory requirements and sales volume
- EV vs ICE feature priorities may diverge significantly — define platform strategy early
Related templates
PRD Template
The universal PRD template with all ten core sections for any product team.
View template →PRD for Manufacturing Products
Production planning, quality control, and industrial IoT for manufacturing.
View template →PRD for Energy Products
Grid management, renewable integration, and utility regulatory compliance.
View template →Frequently asked questions
Generate an automotive PRD from your engineering data
Connect your tools, describe the feature, and get a PRD with safety standards, cybersecurity specs, and traced sources. Free to start.
Free to start. No credit card required.