Crafting an Effective Product Requirements Document (PRD) for Chips

A Product Requirements Document (PRD) for a semiconductor product states what the chip is, why it matters, who it serves and how success will be measured, without saying how it will be built. It is the document that supports the go/no-go decision before a team commits millions to design and tape-out, and it stays the reference point through architecture, design, verification and launch. A good PRD is short, grounded in data, solution-agnostic and kept under version control.

A PRD empowers informed, effective product development decisions while serving as a goalpost, guide and reference point throughout the development lifecycle.

Key takeaways

• A PRD defines what and why; architecture and technical specifications define how.
• Its first job is to support the go/no-go decision before major resources are committed.
• Every requirement should be measurable, prioritised and traceable to a validated customer or business need.
• Commitments, scale, finance, risks and success metrics belong in the PRD as much as functional requirements do.
• Keep it to roughly 5 to 10 pages, version it, and move detail to appendices and specifications.

Why PRDs matter: a perspective from engineering leadership

A great Product Requirements Document is both powerful and essential, yet often difficult to define and even harder to craft well. In this article, I share my perspective on PRDs, shaped by years of experience as a designer, manager and director.

At its core, a PRD articulates what a product is and why it matters. It focuses on the problem being solved, the use cases, the target users, the business rationale and the broader product vision.

Unlike a product specification, which details features and functionality, the PRD provides strategic context: framing the problem space, defining the audience and aligning with business objectives.

A well-crafted PRD informs the critical go/no-go decision before significant resources are committed. It is a tool for clarity: refining and contextualising a product idea so stakeholders can make confident, informed decisions. Beyond that initial decision, the PRD serves as a guiding reference throughout development: a goalpost, a roadmap and a touchstone that keeps teams aligned and focused.

Crafting a PRD for semiconductor products: an engineering leader's journey

Back when I was a young engineer, hunched over a desk debugging RTL code at 2 a.m., I thought the hardest part of building a chip was getting the design right. Years later, as a leader herding teams through tight tape-out schedules, and now as a director wrestling with multi-million-dollar product decisions, I have learned the real challenge often starts before a single line of Verilog is written: it is crafting a PRD that actually works.

A great PRD is not just a document. It is a shared vision that keeps everyone, from designers to marketers, pulling in the same direction. I have seen PRDs that sparked brilliant chips and others that led to costly missteps and programme cancellations.

Drawing from those lessons, this article outlines how to create a PRD for semiconductor products, with a focus on clarity, structure and semiconductor-specific examples. It covers what a PRD must include, what it should avoid, and how it fits into the broader set of development documents. Please do leave your comments and let us engage more.

The role of a PRD in semiconductor development

A PRD is the heartbeat of a semiconductor project. It defines what the product is, why it matters and who it serves, without getting bogged down in how it will be built.

In an industry where a single tape-out can cost millions and take years, the PRD is the linchpin for the go/no-go decision, which ensures resources are committed only when the vision is clear and the market need is validated. It is also a guiding star throughout development, aligning product management, engineering, manufacturing and marketing teams through the long journey from concept to silicon.

Chips are unforgiving of late changes. A requirement changed after RTL freeze can mean redesign and re-verification; one changed after tape-out can mean a new mask set and a respin. That is why a semiconductor PRD has to be clearer, and more stable, than a typical software PRD.

Running example: a low-power IoT microcontroller

Imagine a PRD for a low-power microcontroller (MCU) for Internet of Things (IoT) devices. It would highlight the need for a chip that extends battery life in smart sensors, targeting IoT device makers. The PRD might specify 50 MHz performance at less than 10 µA/MHz but leave choices such as the Arm Cortex core or a 22 nm process node to the technical specifications.

All figures in this running example (market sizes, budgets, dates, percentages, contracts and named threads) are illustrative, chosen to show the shape of each section. They are not data about any real product or market.

Key components of a semiconductor PRD

A PRD must be comprehensive yet concise, balancing strategic vision with actionable requirements. Authored by a Product Manager with input from cross-functional stakeholders (for example engineering, design, client success and marketing), it should include the following sections, tailored for semiconductors.

1. Summary

• What it is: a brief overview of the product and its significance, limited to two or three sentences.
• Why it matters: sets the stage for stakeholders, especially decision-makers, to grasp the product's purpose quickly.
• Example: "This low-power IoT microcontroller enables year-long battery life in smart sensors, targeting IoT device manufacturers to capture a 500 million dollar market opportunity."
• Do: keep it concise and compelling, focusing on the product's core value.
• Don't: include technical details or vague statements like "build a great chip".

2. Fundamental problem(s)

• What it is: a clear, focused description of the market or technical problem the product addresses, without proposing solutions.
• Why it matters: grounds the project in a validated need, ensuring focus and minimising scope creep.
• 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 less than 10 µA/MHz at 50 MHz to enable year-long operation, based on 2024 market research and feedback from 10 key OEMs."
• Do: use data (customer feedback, market reports) to quantify the problem and keep the scope tight.
• Don't: propose solutions ("use a 22 nm process") or address several unrelated problems.

3. External commitments

• What it is: obligations to external stakeholders, such as promised features, timelines or certifications.
• Why it matters: ensures transparency and alignment on non-negotiable deliverables.
• Example:
  • Commitment: "Deliver an MCU with BLE 5.2 and AEC-Q100 qualification by Q3 2026."
  • Who and context: "Promised to a key IoT OEM customer in a Q1 2025 contract."
  • Flexibility and consequences: "Limited flexibility on timeline due to the customer's product launch; non-fulfilment risks losing a 10 million dollar contract."
  • References: "Q1 2025 contract, Slack thread #iot-mcu-deals."
• Do: specify who made the commitment, its context and the consequences of failure.
• Don't: omit references or vaguely state "we promised something".

4. Internal commitments

• What it is: internal obligations, such as leadership directives or cross-team dependencies.
• Why it matters: clarifies internal expectations to prevent misalignment.
• Example:
  • Commitment: "Use the TSMC 22 nm process to leverage the existing IP portfolio."
  • Who and context: "Directed by the VP of Engineering in Q4 2024 planning."
  • Flexibility and consequences: "No flexibility due to IP compatibility; deviation requires re-licensing costing 2 million dollars."
  • References: "Q4 2024 engineering roadmap, email thread IP Strategy."
• Do: mirror the structure of external commitments for consistency.
• Don't: assume internal alignment without documenting commitments.

Note the tension with the rule that a PRD avoids implementation: a process node is normally an architecture decision, but when leadership has already committed to it, the PRD records it here as a constraint, with its reason, rather than as a requirement.

5. Additional impact

• What it is: broader benefits beyond solving the core problem, such as efficiency gains or strategic advantages.
• Why it matters: highlights the product's value to the organisation and future opportunities.
• Example: efficiency, "reduces customer support queries for power issues by 50%"; strategic, "strengthens our position as a low-power MCU leader, deepening our market moat"; opportunities, "enables future AI-enabled MCU variants for edge computing".
• Do: tie impacts to business goals and future potential.
• Don't: overpromise unvalidated benefits ("revolutionises IoT").

6. Scale

• What it is: a rough estimate of time, resources and complexity, often compared with past projects.
• Why it matters: informs resource allocation and feasibility.
• Example: "Development requires 18 months and 10 million dollars, similar to Project X (a 12-month MCU) but larger due to BLE 5.2 integration and AEC-Q100 testing."
• Do: use past projects as benchmarks and consult engineering for estimates.
• Don't: give overly precise estimates without validation.

7. Finance

• What it is: a business case covering costs, revenue and long-term viability.
• Why it matters: justifies investment and aligns with financial goals.
• Example: build cost, "10 million dollars for design, IP licensing and tape-out"; operating cost, "1 million dollars a year for support and updates"; revenue, "50 million dollars a year from 10% IoT MCU market share"; viability, "5-year product lifecycle, with potential for derivative products".
• Do: acknowledge estimate uncertainty and justify figures with stakeholder input.
• Don't: overlook indirect costs (such as support) or assume guaranteed revenue.

A quick sanity check helps reviewers. In this illustrative case, 50 million dollars a year at a selling price under 2 dollars implies more than 25 million units a year, and 10% share of a 500 million dollar market is exactly 50 million dollars. If the volume looks implausible for the target customers, the finance section needs another look before the go/no-go meeting.

8. User profiles

• What it is: brief descriptions of target users, their problems and how the product helps.
• Why it matters: ensures the product is user-centred.
• 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 (under 2 dollars a unit) for high-volume production."
• Do: reference existing personas and focus on how users interact with the product.
• Don't: include full persona details or generic descriptions ("all engineers").

9. Product vision

• What it is: a high-level statement of the product's purpose and long-term impact.
• Why it matters: inspires teams and provides a guiding vision.
• 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."
• Do: focus on user impact and market differentiation.
• Don't: include specific features ("BLE 5.2 support") or technical details.

10. Functional requirements

• What it is: high-level capabilities the product must have to solve the problem.
• Why it matters: defines what the product does to meet user needs.
• Example: "Support BLE 5.2 for reliable smart home hub connectivity." "Enable 50 MHz processing for real-time IoT applications." "Provide configurable I/O for sensor integration."
• Do: use user stories ("As an engineer, I need...") and prioritise requirements.
• Don't: specify implementation ("use Arm Cortex-M4") or detailed feature lists.

11. Non-functional requirements

• What it is: constraints on how the product operates, such as performance, reliability or cost.
• Why it matters: defines the quality and boundaries of functionality.
• Example: performance, "less than 10 µA/MHz in active mode, less than 1 µA in sleep mode"; reliability, "meet AEC-Q100 qualification for automotive use"; cost, "production cost under 2 dollars a unit at 1 million units".
• Do: use measurable metrics and align with user needs.
• Don't: include overly specific targets ("1.2 V operating voltage") that limit engineering.

12. Features and use cases

• What it is: broad descriptions of how the product delivers functionality and how users interact with it.
• Why it matters: illustrates how requirements translate to user value, without overlapping with technical specs.
• Example: feature, "low-power connectivity module"; 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".
• Do: keep descriptions high-level (one or two sentences) and tie them to requirements.
• Don't: include detailed UI or implementation ("firmware UI with three tabs").

13. Scope and non-goals

• What it is: a clear boundary of what is included and excluded.
• Why it matters: prevents scope creep and maintains focus.
• Example: in scope, "low-power MCU with BLE 5.2 and 50 MHz performance"; out of scope, "5G connectivity or AI acceleration, reserved for future revisions".
• Do: explicitly list non-goals to avoid confusion.
• Don't: leave scope ambiguous or include speculative features.

14. Existing environment

• What it is: relevant products, standards, tools or regulations affecting the project.
• Why it matters: provides context for development and identifies opportunities or challenges.
• Example: helps, "an existing BLE 5.2 IP library reduces development time"; hindrances, "AEC-Q100 qualification requires additional testing, mitigated by early validation"; peripheral, "Wi-Fi connectivity seems relevant but is out of scope due to power constraints".
• Do: address competitors, standards and mitigation strategies.
• Don't: ignore regulations (such as RoHS compliance) or assume a clean slate.

15. Integration profiles

• What it is: systems or tools the product will interact with programmatically.
• Why it matters: clarifies technical dependencies for engineering.
• Example: "The MCU integrates with IAR Embedded Workbench for firmware development and connects to smart home hubs via BLE 5.2."
• Do: summarise key integrations tied to the "helps" items in Existing environment.
• Don't: include detailed APIs or protocols ("use a specific BLE stack").

16. Dependencies and risks

• What it is: external factors (IP licensing, fab capacity) and risks (supply chain delays).
• Why it matters: enables proactive planning and risk mitigation.
• Example: dependencies, "requires BLE 5.2 IP licensing by Q1 2026"; risks, "potential TSMC 22 nm fab delays due to high demand; risk of failing AEC-Q100 qualification".
• Do: quantify risks and specify dependencies.
• Don't: overlook supply chain or certification challenges.

17. OKRs (objectives and key results)

• What it is: a framework for defining and measuring success.
• Why it matters: aligns teams on goals and tracks progress.
• Example: objective, "establish leadership in low-power IoT MCUs"; key results, "achieve 10% market share by Q4 2027; secure 3 major OEM design wins by Q2 2027".
• Do: use qualitative objectives with quantifiable key results.
• Don't: set vague goals ("improve market position").

18. KPIs (key performance indicators)

• What it is: quantifiable metrics to monitor performance and support OKRs.
• Why it matters: provides operational insight and baselines for future goals.
• Example: "power consumption (µA/MHz)", "customer acquisition cost", "design win conversion rate"; baseline, "current MCU power consumption 50 µA/MHz, target less than 10 µA/MHz".
• Do: include metrics tied to OKRs and operational performance.
• Don't: use engineering-only metrics ("gate count").

19. Version control and change log

• What it is: a record of PRD updates, with version numbers and change summaries.
• Why it matters: ensures transparency as requirements evolve.
• Example: "v1.0 (Jan 2025): initial draft with problem statement and requirements." "v1.1 (Mar 2025): added BLE 5.2 and updated power targets."
• Do: use clear versioning and summarise changes.
• Don't: treat the PRD as static.

Writing requirements that can be verified

Every requirement in sections 10 and 11 will eventually be checked by someone in verification, validation or qualification. Requirements guides such as ISO/IEC/IEEE 29148 and the INCOSE Guide to Writing Requirements describe the qualities to aim for. In practice, five tests catch most problems:

Quality	Weak	Better
Measurable	Very low power	Active current below 10 µA/MHz at 50 MHz, 25 °C, typical silicon
Unambiguous	Fast wake-up	Wake from sleep to code execution in under 10 µs
Solution-free	Use a Cortex-M4	Run the reference sensor-fusion workload within the power budget
Prioritised	(no priority)	Must-have, should-have or nice-to-have, with a reason
Traceable	(no source)	Linked to the customer request, MRD item or commitment it comes from

The figures in the "Better" column are illustrative. Note that a power figure means little without its conditions: temperature, voltage, process corner, clock frequency and workload all change the answer, so the PRD should state the conditions or say they will be fixed in the specification.

What a PRD should not include

To maintain clarity, avoid these common pitfalls, especially in semiconductors:

1. Implementation details: don't specify how to meet requirements ("use TSMC 22 nm" or "Arm Cortex-M4"). These belong in architectural specs, unless they are recorded commitments as in section 4.
2. Detailed feature lists: avoid exhaustive breakdowns ("16 GPIO pins, 2 UARTs"). Focus on high-level needs ("flexible I/O").
3. Unvalidated assumptions: don't assume market needs ("customers want 20% better power") without data.
4. Overly prescriptive UX: avoid dictating firmware UI details ("configuration tool with three tabs"). Focus on user needs ("easy configuration").
5. Premature optimisation: don't lock in specific targets ("1.2 V") that limit engineering flexibility.
6. Excessive length: keep the PRD to 5 to 10 pages, moving non-critical details to appendices or specs.

Relationship to other documents

The PRD is part of a broader set of documents, each with a distinct role.

Document	Purpose	Relationship to the PRD	Example
Marketing Requirements Document (MRD)	Market opportunity, customer demand, competition	Market-driven (external); the PRD turns it into product requirements	MRD notes "competitors lack BLE 5.2" and a "500 million dollar IoT MCU opportunity"; PRD requires "BLE 5.2 for smart home connectivity" and "less than 10 µA/MHz"
Architectural specification	System architecture, block diagrams, IP selection	PRD is solution-agnostic; the architecture spec proposes the solution	PRD demands "real-time processing" and "50 MHz"; architecture selects "Cortex-M4 with DVFS on 22 nm"
Technical specification	Implementation detail: circuits, pin assignments, registers	Turns PRD requirements into engineering deliverables; PRD is what and why, the spec is how	PRD requires "AEC-Q100 qualification"; the spec details "-40 °C to 125 °C testing" (AEC-Q100 Grade 1)
Test and validation plan	How each requirement is verified	PRD success metrics become test criteria; the PRD defines success, the plan proves it	PRD requires "less than 1 µA in sleep mode"; the plan specifies "measure with a Keithley 2450 SourceMeter"

Structuring for the audience

• For decision-makers: prioritise Summary, Fundamental problems, External and internal commitments, Additional impact, Scale, Finance, OKRs and KPIs to support go/no-go decisions.
• For development teams: emphasise Functional and 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 up front. For example, confirm TSMC 22 nm availability with the fab team.
2. Keep it lean: aim for 5 to 10 pages, using appendices for supporting data such as market research.
3. Ground it in data: use customer feedback, market reports or benchmarks (for example, "80% of IoT OEMs prioritise battery life, per a 2024 survey", an illustrative citation; name the real survey in your own PRD).
4. Prioritise and iterate: mark requirements as must-have or nice-to-have and update them under version control.
5. Balance flexibility and structure: set boundaries ("operation below 1.5 V") 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 (focus on BLE 5.2 now, AI later).
   • PRD too large or detailed: move details to specs or appendices.
   • Missing information: consult stakeholders to fill gaps (for example, concurrent user requirements).

How reviewers probe a PRD

In a go/no-go or PRD review, expect questions like these. Answering them in the document saves a meeting.

• Where does each key number come from: a customer, a report, or an assumption?
• Which requirements are must-have, and what happens to the business case if one slips?
• Do the finance figures agree with the volumes, prices and market share?
• Is any requirement actually a design decision in disguise?
• Which commitments are already made to customers, and who made them?
• How will each non-functional requirement be measured, and under what conditions?

The PRD's role in the semiconductor lifecycle

• Pre-development: justifies investment ("10 million dollars for a 500 million dollar IoT MCU market").
• Development: guides architecture, design and verification (power targets shape DVFS and power-gating choices).
• Post-launch: evaluates success ("did we hit less than 10 µA/MHz?") and informs iterations.

Example PRD outline for a semiconductor product

The outline below pulls the running example together. As above, all figures are illustrative.

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-fulfilment 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.

FAQ

Who owns the PRD?

The Product Manager authors and owns it, with input from engineering, design, manufacturing, client success and marketing. Engineering leadership should sign off that it is feasible before the go/no-go decision.

How is a PRD different from an MRD?

The MRD describes the market opportunity and customer demand. The PRD turns that into product requirements the engineering team can design and verify against.

How long should a semiconductor PRD be?

Roughly 5 to 10 pages, with supporting data in appendices and detail in the architecture and technical specifications.

When should the PRD be frozen?

It should be stable before architecture is committed and well before RTL freeze. It is never fully static: changes continue under version control, but each late change should go through review with its cost in schedule and money stated.

A semiconductor PRD is more than paperwork. It is the foundation for turning a bold idea into a chip that powers the future. By clearly defining the problem, aligning with business goals and balancing stakeholder needs, it keeps teams focused through the complexities of chip design. With collaboration, data-driven clarity and iterative refinement, a PRD becomes the roadmap that turns vision into reality, one silicon wafer at a time.