Crafting a Product Requirements Document (PRD) for Semiconductor Products: An Engineering Leader’s Journey

The Role of a PRD in Semiconductor Development

Example: PRD for a Low-Power IoT Microcontroller

Key Components of a Semiconductor PRD

1. What it is: A brief overview of the product and its significance, limited to 2–3 sentences.
2. Why it matters: Sets the stage for stakeholders, especially decision-makers, to grasp the product’s purpose quickly.
3. Semiconductor Example: “This low-power IoT microcontroller enables year-long battery life in smart sensors, targeting IoT device manufacturers to capture a $500M market opportunity.”
4. Do: Keep it concise and compelling, focusing on the product’s core value.
5. Don’t: Include technical details or vague statements like “build a great chip.”

1. What it is: A clear, focused description of the market or technical problem(s) the product addresses, without proposing solutions.
2. Why it matters: Grounds the project in a validated need, ensuring focus and minimizing scope creep.
3. Semiconductor Example: “IoT device manufacturers struggle with high power consumption in current MCUs (50 µA/MHz), limiting smart sensor battery life to 6 months. Customers demand <10 µA/MHz at 50 MHz to enable year-long operation, based on 2024 market research and feedback from 10 key OEMs.”
4. Do: Use data (e.g., customer feedback, market reports) to quantify the problem and keep the scope tight.
5. Don’t: Propose solutions (e.g., “use a 22nm process”) or address multiple unrelated problems.

1. What it is: Obligations to external stakeholders, such as promised features, timelines, or certifications.
2. Why it matters: Ensures transparency and alignment on non-negotiable deliverables.
3. Semiconductor Example:
   1. Commitment: “Deliver an MCU with BLE 5.2 and AEC-Q100 qualification by Q3 2026.”
   2. Who/Context: “Promised to key IoT OEM customer in a Q1 2025 contract.”
   3. Flexibility/Consequences: “Limited flexibility on timeline due to customer product launch; non-fulfillment risks losing $10M contract.”
   4. References: “Q1 2025 contract, Slack thread #iot-mcu-deals.”
4. Do: Specify who made the commitment, its context, and consequences of failure.
5. Don’t: Omit references or vaguely state “we promised something.”

1. What it is: Internal obligations, such as leadership directives or cross-team dependencies.
2. Why it matters: Clarifies internal expectations to prevent misalignment.
3. Semiconductor Example:
   1. Commitment: “Use TSMC 22nm process to leverage existing IP portfolio.”
   2. Who/Context: “Directed by VP of Engineering in Q4 2024 planning.”
   3. Flexibility/Consequences: “No flexibility due to IP compatibility; deviation requires re-licensing costing $2M.”
   4. References: “Q4 2024 engineering roadmap, email thread ‘IP Strategy.’”
4. Do: Mirror the structure of external commitments for consistency.
5. Don’t: Assume internal alignment without documenting commitments.

1. What it is: Broader benefits beyond solving the core problem, such as efficiency gains or strategic advantages.
2. Why it matters: Highlights the product’s value to the organization and future opportunities.
3. Semiconductor Example:
   1. Efficiency: “Reduces customer support queries for power issues by 50%.”
   2. Strategic: “Strengthens our position as a low-power MCU leader, deepening market moat.”
   3. Opportunities: “Enables future AI-enabled MCU variants for edge computing.”
4. Do: Tie impacts to business goals and future potential.
5. Don’t: Overpromise unvalidated benefits (e.g., “revolutionizes IoT”).

1. What it is: A rough estimate of time, resources, and complexity, often compared to past projects.
2. Why it matters: Informs resource allocation and feasibility.
3. Semiconductor Example: “Development requires 18 months and $10M, similar to Project X (12-month MCU) but larger due to BLE 5.2 integration and AEC-Q100 testing.”
4. Do: Use past projects as benchmarks and consult engineering for estimates.
5. Don’t: Provide overly precise estimates without validation.

1. What it is: A business case covering costs, revenue, and long-term viability.
2. Why it matters: Justifies investment and aligns with financial goals.
3. Semiconductor Example:
   1. Build Cost: “$10M for design, IP licensing, and tape-out.”
   2. Operating Cost: “$1M/year for support and updates.”
   3. Revenue: “$50M annual revenue from 10% IoT MCU market share.”
   4. Viability: “5-year product lifecycle, with potential for derivative products.”
4. Do: Acknowledge estimate uncertainty and justify figures with stakeholder input.
5. Don’t: Overlook indirect costs (e.g., support) or assume guaranteed revenue.

1. What it is: Brief descriptions of target users, their problems, and how the product helps.
2. Why it matters: Ensures the product is user-centric.
3. Semiconductor Example: “Embedded systems engineers at IoT device manufacturers need low-power MCUs with BLE 5.2 to build smart home sensors. OEMs require cost-effective chips (<$2/unit) for high-volume production.”
4. Do: Reference existing personas and focus on user-product interaction.
5. Don’t: Include full persona details or generic descriptions (e.g., “all engineers”).

1. What it is: A high-level statement of the product’s purpose and long-term impact.
2. Why it matters: Inspires teams and provides a guiding vision.
3. Semiconductor Example: “To empower IoT device manufacturers with a microcontroller that delivers industry-leading power efficiency and seamless connectivity, enabling smarter, longer-lasting smart home and healthcare devices.”
4. Do: Focus on user impact and market differentiation.
5. Don’t: Include specific features (e.g., “BLE 5.2 support”) or technical details.

1. What it is: High-level capabilities the product must have to solve the problem.
2. Why it matters: Defines what the product does to meet user needs.
3. Semiconductor Example:
   1. “Support BLE 5.2 for reliable smart home hub connectivity.”
   2. “Enable 50 MHz processing for real-time IoT applications.”
   3. “Provide configurable I/O for sensor integration.”
4. Do: Use user stories (e.g., “As an engineer, I need…”) and prioritize requirements.
5. Don’t: Specify implementation (e.g., “use ARM Cortex-M4”) or detailed feature lists.

1. What it is: Constraints on how the product operates, such as performance, reliability, or cost.
2. Why it matters: Defines the quality and boundaries of functionality.
3. Semiconductor Example:
   1. Performance: “<10 µA/MHz in active mode, <1 µA in sleep mode.”
   2. Reliability: “Meet AEC-Q100 qualification for automotive use.”
   3. Cost: “Production cost under $2/unit at 1M units.”
4. Do: Use measurable metrics and align with user needs.
5. Don’t: Include overly specific targets (e.g., “1.2V operating voltage”) that limit engineering.

1. What it is: Broad descriptions of how the product delivers functionality and how users interact with it.
2. Why it matters: Illustrates how requirements translate to user value, without overlapping with technical specs.
3. Semiconductor Example:
   1. Feature: “Low-power connectivity module.”
   2. Use Case: “An embedded engineer configures the MCU to connect a motion sensor to a smart home hub via BLE 5.2, enabling real-time alerts with minimal power draw.”
4. Do: Keep descriptions high-level (1–2 sentences) and tie to requirements.
5. Don’t: Include detailed UI or implementation (e.g., “firmware UI with three tabs”).

1. What it is: A clear boundary of what’s included and excluded in the product.
2. Why it matters: Prevents scope creep and maintains focus.
3. Semiconductor Example:
   1. In Scope: “Low-power MCU with BLE 5.2 and 50 MHz performance.”
   2. Out of Scope: “5G connectivity or AI acceleration, reserved for future revisions.”
4. Do: Explicitly list non-goals to avoid confusion.
5. Don’t: Leave scope ambiguous or include speculative features.

1. What it is: Relevant products, standards, tools, or regulations impacting the project.
2. Why it matters: Provides context for development and identifies opportunities or challenges.
3. Semiconductor Example:
   1. Help: “Existing BLE 5.2 IP library reduces development time.”
   2. Hindrances: “AEC-Q100 qualification requires additional testing; mitigated by early validation.”
   3. Peripheral: “Wi-Fi connectivity seems relevant but is out of scope due to power constraints.”
4. Do: Address competitors, standards, and mitigation strategies.
5. Don’t: Ignore regulations (e.g., RoHS compliance) or assume a clean slate.

1. What it is: Systems or tools the product will interact with programmatically.
2. Why it matters: Clarifies technical dependencies for engineering.
3. Semiconductor Example: “The MCU integrates with IAR Embedded Workbench for firmware development and connects to smart home hubs via BLE 5.2.”
4. Do: Summarize key integrations tied to “Help” items in Existing Environment.
5. Don’t: Include detailed APIs or protocols (e.g., “use specific BLE stack”).

1. What it is: External factors (e.g., IP licensing, fab capacity) and risks (e.g., supply chain delays).
2. Why it matters: Enables proactive planning and risk mitigation.
3. Semiconductor Example:
   1. Dependencies: “Requires BLE 5.2 IP licensing by Q1 2026.”
   2. Risks: “Potential TSMC 22nm fab delays due to high demand; risk of failing AEC-Q100 qualification.”
4. Do: Quantify risks and specify dependencies.
5. Don’t: Overlook supply chain or certification challenges.

1. What it is: A framework for defining and measuring success.
2. Why it matters: Aligns teams on goals and tracks progress.
3. Semiconductor Example:
   1. Objective: “Establish leadership in low-power IoT MCUs.”
   2. Key Results: “Achieve 10% market share by Q4 2027; secure 3 major OEM design wins by Q2 2027.”
4. Do: Use qualitative objectives with quantifiable key results.
5. Don’t: Set vague goals (e.g., “improve market position”).

1. What it is: Quantifiable metrics to monitor performance and support OKRs.
2. Why it matters: Provides operational insights and baselines for future goals.
3. Semiconductor Example:
   1. “Power consumption (µA/MHz),” “Customer acquisition cost,” “Design win conversion rate.”
   2. Baseline: “Current MCU power consumption: 50 µA/MHz; target: <10 µA/MHz.”
4. Do: Include metrics tied to OKRs and operational performance.
5. Don’t: Use engineering-only metrics (e.g., “gate count”).

1. What it is: A record of PRD updates, with version numbers and change summaries.
2. Why it matters: Ensures transparency as requirements evolve.
3. Semiconductor Example:
   1. “v1.0 (Jan 2025): Initial draft with problem statement and requirements.”
   2. “v1.1 (Mar 2025): Added BLE 5.2 and updated power targets.”
4. Do: Use clear versioning and summarize changes.
5. Don’t: Treat the PRD as static.

What a PRD Should Not Include

1. Implementation Details: Don’t specify how to meet requirements (e.g., “use TSMC 22nm” or “ARM Cortex-M4”). These belong in architectural specs.
2. Detailed Feature Lists: Avoid exhaustive breakdowns (e.g., “16 GPIO pins, 2 UARTs”). Focus on high-level needs (e.g., “flexible I/O”).
3. Unvalidated Assumptions: Don’t assume market needs (e.g., “customers want 20% better power”) without data.
4. Overly Prescriptive UX: Avoid dictating firmware UI details (e.g., “configuration tool with three tabs”). Focus on user needs (e.g., “easy configuration”).
5. Premature Optimization: Don’t lock in specific targets (e.g., “1.2V voltage”) that limit engineering flexibility.
6. Excessive Length: Keep the PRD to 5–10 pages, moving non-critical details to appendices or specs.

Relationship to Other Documents

1. Marketing Requirements Document (MRD):
   • Purpose: Defines market opportunity, customer demand, and competitive landscape.
   • Relationship to PRD: The MRD provides market context; the PRD translates it into product requirements. For example, an MRD might note “$500M IoT MCU opportunity,” and the PRD specifies “<10 µA/MHz.”
   • Key Difference: MRD is market-driven (external); PRD is product-driven (internal).
   • Semiconductor Example: MRD highlights “competitors lack BLE 5.2.” PRD requires “BLE 5.2 for smart home connectivity.”
2. Architectural Specification:
   • Purpose: Outlines system architecture (e.g., block diagrams, IP selection).
   • Relationship to PRD: PRD sets requirements (e.g., “50 MHz performance”); architectural spec proposes solutions (e.g., “Cortex-M4 on 22nm”).
   • Key Difference: PRD is solution-agnostic; architectural spec is solution-specific.
   • Semiconductor Example: PRD demands “real-time processing.” Architectural spec selects “Cortex-M4 with DVFS.”
3. Technical Specification:
   • Purpose: Details implementation (e.g., circuit designs, pin assignments).
   • Relationship to PRD: Translates PRD requirements into engineering deliverables.
   • Key Difference: PRD focuses on what and why; technical spec focuses on how.
   • Semiconductor Example: PRD requires “AEC-Q100 qualification.” Technical spec details “-40°C to 125°C testing.”
4. Test and Validation Plan:
   • Purpose: Defines how to verify requirements (e.g., performance, reliability tests).
   • Relationship to PRD: PRD success metrics (e.g., “<10 µA/MHz”) inform test criteria.
   • Key Difference: PRD defines success; test plan proves it.
   • Semiconductor Example: PRD requires “<1 µA sleep mode.” Test plan specifies “measure with Keithley 2450 SourceMeter.”
   • 
     

Structuring for the Audience

• For Decision-Makers: Prioritize Summary, Fundamental Problems, External/Internal Commitments, Additional Impact, Scale, Finance, OKRs, and KPIs to support go/no-go decisions.
• For Development Teams: Emphasize Functional/Non-Functional Requirements, Features and Use Cases, Integration Profiles, and Existing Environment, with Scale and Finance as context.
• 
  

Best Practices for Crafting a Semiconductor PRD

1. Collaborate Early: Engage product management, engineering, manufacturing, and marketing upfront. For example, confirm TSMC 22nm availability with the fab team.
2. Keep It Lean: Aim for 5–10 pages, using appendices for supporting data (e.g., market research).
3. Ground in Data: Use customer feedback, market reports, or benchmarks (e.g., “80% of IoT OEMs prioritize battery life, per 2024 survey”).
4. Prioritize and Iterate: Mark requirements as “must-have” or “nice-to-have” and update with version control.
5. Balance Flexibility and Structure: Set boundaries (e.g., “<1.5V operation”) but allow engineering creativity.
6. Use Collaborative Tools: Use Confluence or Notion for real-time updates, linking to Jira for traceability.
7. Avoid Pitfalls:
   • Scope Too Large: Break large problems into smaller projects (e.g., focus on BLE 5.2 now, AI later).
   • PRD Too Large/Detailed: Move details to specs or appendices.
   • Missing Information: Consult stakeholders to fill gaps (e.g., concurrent user requirements).
   • 
     

The PRD’s Role in the Semiconductor Lifecycle

• Pre-Development: Justifies investment (e.g., “$10M for $500M IoT MCU market”).
• Development: Guides architecture, design, and verification (e.g., power targets shape DVFS).
• Post-Launch: Evaluates success (e.g., “did we hit <10 µA/MHz?”) and informs iterations.
• 
  

Example PRD Outline for a Semiconductor Product

Product Requirements Document: Low-Power IoT Microcontroller
**Version**: 1.0 (Jan 2025)  
**Owner**: [Product Manager Name]  

1. Summary
This low-power IoT microcontroller enables year-long battery life in smart sensors, targeting IoT device manufacturers to capture a $500M market opportunity.

2. Fundamental Problem(s)
IoT device manufacturers face high power consumption (50 µA/MHz), limiting smart sensor battery life to 6 months. Customers demand <10 µA/MHz at 50 MHz for year-long operation, per 2024 OEM feedback.

3. External Commitments
- Commitment: Deliver MCU with BLE 5.2 and AEC-Q100 qualification by Q3 2026.
- Who/Context: Promised to key IoT OEM in Q1 2025 contract.
- Flexibility/Consequences: Limited flexibility; non-fulfillment risks $10M contract.
- References: Q1 2025 contract, Slack #iot-mcu-deals.

4. Internal Commitments
- Commitment: Use TSMC 22nm process for IP compatibility.
- Who/Context: Directed by VP of Engineering, Q4 2024.
- Flexibility/Consequences: No flexibility; deviation costs $2M in re-licensing.
- References: Q4 2024 roadmap, email ‘IP Strategy.’

5. Additional Impact
- Efficiency: Reduce power-related support queries by 50%.
- Strategic: Strengthen low-power MCU leadership.
- Opportunities: Enable AI-enabled MCU variants for edge computing.

6. Scale
18 months, $10M, similar to Project X but larger due to BLE 5.2 and AEC-Q100.

7. Finance
- Build Cost: $10M (design, IP, tape-out).
- Operating Cost: $1M/year (support, updates).
- Revenue: $50M/year from 10% market share.
- Viability: 5-year lifecycle, potential for derivatives.

8. User Profiles
Embedded engineers need low-power MCUs with BLE 5.2 for smart sensors. OEMs require cost-effective chips (<$2/unit) for high-volume production.

9. Product Vision
Empower IoT manufacturers with a microcontroller delivering unmatched power efficiency and connectivity for smarter, longer-lasting devices.

10. Functional Requirements
- Support BLE 5.2 for smart home connectivity.
- Enable 50 MHz processing for real-time IoT applications.
- Provide configurable I/O for sensor integration.

11. Non-Functional Requirements
- Performance: <10 µA/MHz active, <1 µA sleep mode.
- Reliability: Meet AEC-Q100 qualification.
- Cost: Production cost < $2/unit at 1M units.

12. Features and Use Cases
- Feature: Low-power connectivity module.
- Use Case: Engineer configures MCU to connect motion sensor to smart home hub via BLE 5.2, enabling real-time alerts with minimal power.

13. Scope and Non-Goals
- In Scope: Low-power MCU with BLE 5.2, 50 MHz.
- Out of Scope: 5G connectivity, AI acceleration.

14. Existing Environment
- Help: BLE 5.2 IP library reduces development time.
- Hindrances: AEC-Q100 requires testing; mitigated by early validation.
- Peripheral: Wi-Fi connectivity out of scope due to power constraints.

15. Integration Profiles
Integrates with IAR Embedded Workbench for firmware and smart home hubs via BLE 5.2.

16. Dependencies and Risks
- Dependencies: BLE 5.2 IP licensing by Q1 2026.
- Risks: TSMC 22nm fab delays, AEC-Q100 qualification issues.

17. OKRs
- Objective: Establish low-power IoT MCU leadership.
- Key Results: 10% market share by Q4 2027; 3 OEM design wins by Q2 2027.

18. KPIs
- Power consumption (µA/MHz), customer acquisition cost, design win conversion rate.
- Baseline: Current MCU at 50 µA/MHz; target <10 µA/MHz.

19. Change Log
- v1.0 (Jan 2025): Initial draft with problem statement and requirements.