🚀Guide to HW PRDs: Step 2 of Product Making
How to define a physical product concept and get it ready for execution.
Hey Friends🖐️
What comes next after you’ve finalized a new product concept? Is there a document that we can hand off to engineering, factories, and marketing to build out our vision? How do we define a product? Today, we’ll discuss hardware product requirement documents. They’re arguably the most important artifact in your entire product development process.
What’s a HW PRD?
A product requirements document outlines characteristics that make a product successful. Earlier we discussed step 1 of product making where we conceptualize new ideas, strategies, and business cases with PRFAQs. PRDs (step 2) build on that to define the why, who, and most importantly, what. PRDs provide:
Product purpose, use cases, high-level business cases, and milestones.
Features and requirements with clear acceptance criteria.
A source of truth for design, engineering, GTM, legal, marketing, supply chain and more.
Clarity, constraints, alignment, and reduction in ambiguity.
Unlike software PRDs, hardware PRDs are not living documents. Ideally, they need to be locked before the development phase (EVT onwards), given the incremental cost and complexity of making changes to physical products as builds mature. HW PRDs also encompass a broader scope, including regulatory compliance, certifications, SKUs, warranties, supply chain implications, build regions, and more.
How to Write PRDs
Here are some general tips for writing good HW PRDs.
Anchor on user experience as a product manager, focusing on the what, why, and who. PRDs are not engineering spec sheets.
Keep them as concise as possible while highlighting key information. PRDs get long, and most stakeholders miss important information.
Major decisions need to be documented, with revisions. Provide rationale for why an important requirement has a certain acceptance criterion.
Don’t guess requirements, ask your technical teams for help. HW product making involves many domains (RF, electrical, mechanical, firwmware, app, and more) so it’s easy not to know everything, and that’s fine.
Ensure product vision, strategy, and user demand have been validated before entering the PRD phase.
Now that we've covered some basics, let’s see what this looks like in practice with an example. Imagine you’re a product manager at a smart thermostat company, tasked with defining the PRD for your next flagship product - the HeatSync Pro. Below is how your PRD could look.
1. Overview
This section should provide your stakeholders with a high-level summary of the program, including things like timing, the business case, regions, SKUs, and northstar success metrics, among other things. What’s also typically listed here is feedback, risks, and approvals from team leads but I’ve omitted that to keep things simple.
MSRP
The price at which customers buy the product. This is different from average selling price.
BOM
Bill of Materials or the cost of components needed to assemble the device.
LTV
Lifetime Value. An important financial metric used to determine the total return from a customer throughout their relationship with a company.
HW Financials are nuanced as there’s a lot that goes into calculating LTV other than BOM and build volumes such as tarriffs, shipping costs, tooling, assembly head count, R&D, material attrition, certifications, marketing, and more. We’ll cover this in a separate article.
SKUs
Stock Keeping Unit refers to how many variations of the device there are. This will help retailers and supply chain teams manage inventory.
CSAT
Measures how satisfied customers are with your product.
NPS
Net Promotor Score. Determines customer loyalty and the likelihood of them recommending a product to others.
Product Description
Next, include a compelling summary of the new product. For example:
The HeatSync Pro is a premium smart thermostat that combines climate intelligence with elegant design. Its edge-edge glass screen and machined aluminum housing compliment modern home interiors, while advanced features like multi-room sensing, air quality monitoring, and Siri voice control create a truly personalized comfort experience. Beyond maintaining ideal temperatures, the HeatSyncPro learns your preferences over time, automatically adjusting settings to maximize both comfort and energy efficiency throughout your home.
Concept Images
Include some early industrial design concepts to help contextualize the product to your team with varying angles and placement scenarios. These don’t need to be the final shape or finish.
2. Use Cases
List the target customers and their key use cases to help development teams stay focused on real problems, not just specs. Continually revalidate these use cases throughout all alpha and beta testing phases to ensure the product delivers value.
3. Features
A clean features list with rationale is a must for PRDs. Try to articulate why a feature is important and include any data to justify it such as user studies, satisfaction scores, market trends, or industry tech advancements.
It also helps to add a feature comparison table to provide background information. The table can be a mix of other products that your company or competitors offer. For example, the HeatSync Pro is a premium product but say your thermostat company also offers mid and entry-tier products. Laying options out like this can justify requirements or provide insight to engineering to use reference designs or modules.
4. Product Requirements
Product requirements will be used as an input by design, engineering, and maufacturing teams to develop the product. Let’s go over some definitions.
Requirement
Specific need, feature, or capability that the product must fulfill.
Description
An explanation of the requirement to add user context and clarify intent.
Acceptance Criteria
Specific conditions that must be met for a requirement to be ready for launch.
Constraints lead to great design. Requirements without criteria are just wishes.
Priority
P0: Critical, must have requirements that must be ready for product launch.
P1: High-priority requirements that are not blockers for launch.
Assume all requirements in the examples below are P0. A P1 requirement could be something like Alexa integration. It’s important for customers but not a showstopper for launch because we already have Siri.
4.1 Mechanical and Industrial Design
These define the physical structure, look, and feel of the device.
4.2 Electrical Design
I’ve decided to keep the device mains powered for simplicity. Consider that a battery adds layers of complexity such as meeting user battery life expectations, thermal considerations, safety, and layers of certifications. Despite this, if your device needs to be portable then battery power requirements are items such as capacity, energy density, charge/discharge rate, and more.
Another tip is to not specify how the technology should be executed. For example, I’ve listed an occupancy sensing requirement but didn’t list the type of sensor (PIR, radar, TMOS, etc.). That’s for engineering to recommend.
4.3 Reliability
I typically don’t like specifying Reliability requirements in a PRD because it often turns into a test plan, which as stated above, is not the point of this document. Things like long-term heat soak, vibration, temperature cycling, aging, and more should be captured by quality engineers. However, there are still some elements fundamental to a good, robust user experience that need to be made explicit. They are outlined below.
4.4 RF
This is how your device will connect to the internet, apps, and companion devices. RF is an important part of device design and has a notable impact on cost due to its relationship with SoC (system on chip/processor) selection.
Set requirements based on speeds, throughputs, and ranges for your use cases, not on the latest protocol. For example, if you have a portable battery-powered device consider that Wi-Fi is power intensive and it may be better to leverage low-power RF like Bluetooth whenever possible.
Another example is that you may not need dual-band Wi-Fi if it’s a device that just connects to the internet and doesn’t require high data transmission (such as video streaming). In these cases, 2.4 GHz would be fine, and simplifies things.
Lastly, while they’re not listed in this PRD, metrics should be defined such as target throughput, signal strength (RSSI), and % of devices falling offline.
4.5 Certifications
Certification planning is based on which region the device will be sold in as there may be different regulatory requirements for each country. These typically focus on safety (thermals, mechanical, electrical), RF interference, EM noise, hazardous substances, and much more. The table below is not a complete list but should serve as an intro to what types of certifications would be required for a premium smart thermostat. Always confirm these with your reliability, compliance, and test lab teams.
4.6 Packaging
Packaging is the first physical element a user interacts with. Attention to detail matters here as a frustrating unboxing experience, low-quality images, or flimsy structure may cause distrust in your brand.
4.7 Firmware
Firmware requirements are usually better served in an engineering spec sheet, because they are implicitly covered in other PRD sections such as electrical, RF, security, and app.
4.8 App
An app section on a PRD can get pretty long. Because this is building hardware and because so many other articles already cover software PRDs, I’m not going to list app requirements here. However on a high level look for user experience considerations, device setup flows, navigation, and integrations. For our smart thermostat that means requirements to define how customers will seamlessly be onboarded, how they can change temperatures, monitor energy usage, receive AI routines, get air quality updates, and interact with Siri.
4.9 Security
Look to define items like like encryption for customer account information and passwords, secure boot, memory access control, tamper protection, data collection policies, and more.
4.10 Warranty
List the length of warranty coverage (usually 1-2 years), start point (date of installation vs sale), conditions (proper usage, proof of purchase), and scope of coverage (manufacturing defects, performance issues, etc).
4.11 Lifecycle
Plan out when the device will become obsolete, what concessions need to be offered to customers (if any), inventory depletion, and next-gen roll-in timing. Milestones to consider are the end of manufacturing date, end of sale timeline, and end of official support as some devices may continue to function for a certain amount of years even after you officially stop selling them.
In Closing..
There are plenty of other sections we can include like legal requirements, user journeys, and performance metrics. However for now we’ll wrap it up here.
Over the years I’ve found that its important to stick to a template and hope this article helped clarify the core components of a hardware PRD. If you have your own tips, approaches, or best practices, feel free to share them in the comments below. I'd love to hear how others tackle this process.
Interested in more resources for HW PMing?
In addition to our articles on substack, we offer tailored services in HW PM career growth and HW product development from idea to launch.
Thanks for reading
Make sure you check out some other articles:
PS: I wish I had this before my first gig as a HW PM!!!
Really well-structured PRD! I’ve mostly worked on B2B hardware products and followed a similar format. One thing that proved especially helpful for the engineering team was including more detailed user stories