Hardware Development Has Its Own Rules. AI Product Managers Need to Learn Them.
AI is moving off the cloud and into physical devices - smartphones, glasses, robots, wearables. As a result, software-trained product managers are being asked to lead hardware programs for the first time, often without understanding how hardware development actually works.
The gap matters. Hardware follows a completely different process than software. Where Agile allows rapid iteration, hardware development follows a rigid, phased waterfall structure called NPI (New Product Introduction). The process exists because manipulating atoms is fundamentally different from coding bits.
Understanding NPI is essential for any product manager building physical AI products at scale.
Why Hardware Can't Be Agile
In software, you deploy code, measure results, and roll back if something breaks. Development cycles run in weeks or days. Hardware operates on a different timeline entirely.
A small design change - moving a display bezel by 0.5mm - can trigger a redesign of the display panel, enclosure, and battery. The cost and schedule impact ripple across months. Mistakes aren't measured in Jira tickets. They're measured in millions of dollars.
Hardware development is slow because of physics, material science, and manufacturing constraints, not inefficiency. Key challenges include:
- Supply Chain: Raw materials and components have lead times measured in weeks and months.
- Manufacturing: Finished goods must be assembled, tested, and certified (FCC/CE) before mass production.
- Forecasting: You must predict demand far in advance. Build too few, lose revenue. Build too many, write off millions in inventory.
- Serviceability: You cannot hotfix a hardware defect. Corrections require repair infrastructure and returns management.
Because of these constraints, hardware development follows NPI: a phased waterfall process divided into strict "Gates" or "Builds." You cannot proceed to the next phase until you satisfy the exit criteria of the current one.
The Five Stages of NPI
Stage 0: Definition - The Blueprint
Goal: Define the product vision and features.
Question: What to build, why, and at what cost?
This is where product managers lead the charge. You define what is being built and collaborate with design, engineering, and business teams to build the business case.
You analyze market size, set target pricing, and estimate lifetime volumes. These financial targets become design constraints. You cannot use a premium metal enclosure if your business model only supports a plastic budget.
In software, requirements evolve during development. In hardware, ambiguity is expensive. The PRD acts more like a detailed spec sheet than a living backlog. Relevant teams must sign off on it and lock it down early.
This phase typically concludes by selecting a contract manufacturer (CM). Unlike switching cloud providers, this is a long-term strategic partnership. This partner will build your product from the first prototype to the millionth unit.
Stage 1: Proto - The Proof of Concept
Goal: Prove the physics.
Question: Is the hardware design and functionality actually possible?
With the product defined on paper, engineering teams build the first physical units. These early prototypes are often rough - 3D-printed enclosures, loose wires, development boards. Teams typically build multiple design variations in parallel.
The primary goal is to test if the design and features work together as expected. Testing results determine what design changes are needed for the next phase.
A software PM trap: In software, you ship an MVP and promise to clean up code later. In hardware, technical debt is financial debt. If you choose an expensive component in the proto phase because it's convenient, that cost is likely locked in for the life of the product. Bill of Materials (BOM) costs spiral out of control if not managed early.
Stage 2: EVT (Engineering Validation Test)
Goal: Prove the function ("Looks like, works like").
Question: Does the design meet the requirements?
EVT is where the product starts to look like a real device. Components fit into the production-intent form factor, built using production-intent materials. The goal is to validate form factor, performance, reliability, and manufacturability.
Design flexibility becomes highly limited at the end of this phase. Once you exit EVT, you typically lock down the physical design. Why? Steel molds for the next stage take months to cut and cost hundreds of thousands of dollars.
Stage 3: DVT (Design Validation Test)
Goal: Prove the manufacturing ("Made on the line").
Question: Can we build this consistently at scale?
This stage confuses software PMs the most. The product looks done. Why can't you ship it?
In DVT, you test not just the product but the process of manufacturing it at scale. The focus is on testing manufacturing processes, optimizing yield (percentage of good units produced), and throughput (production speed).
One critical detail: device firmware must be stable enough to support factory diagnostics. If you push a firmware update incompatible with the factory test tool, you lose valuable diagnostic data needed to identify and fix manufacturing defects.
Stage 4: PVT (Production Validation Test)
Goal: Prove the speed ("The speed run").
Question: Can we mass produce and ship?
PVT is the final dress rehearsal. The design is locked. Mass production tooling is locked. Line operators are trained. Assembly and packaging processes are established. Shipping and fulfillment setup is ready.
The only variable left is volume. You run the factory at full speed to ensure building thousands of units doesn't break product quality, the manufacturing line, or processes. This is also when you stress-test the supply chain. If a component vendor fails to deliver on time or meet quality standards, you cannot ship.
After PVT: Mass Production
Once you successfully exit PVT, the NPI process officially ends and Mass Production (MP) begins. A phase called Ramp follows, where factory output increases exponentially from hundreds to thousands of units per day. The operations team takes over full control.
Why Hardware Fluency Matters for AI Product Managers
The most valuable AI products of the next decade will not live entirely in the cloud. They will operate in the real world, sensing, deciding, and acting through physical devices.
The most effective AI product managers won't just understand models, prompts, or orchestration frameworks. They'll understand how intelligence becomes a reliable, scalable physical product constrained by physics, manufacturing, and supply chains.
Understanding the NPI process is your passport to this physical layer. It bridges the gap between the infinite flexibility of code and the stubborn reality of atoms.
By mastering these NPI gates, you position yourself as a rare product leader who can speak both languages - software and hardware. You can make decisions that software-only PMs cannot: decisions that shape cost, quality, timelines, and trust at scale.
In the agentic AI era, building the brain will be table stakes. Building the body and knowing how to ship it will be the differentiator.
For product managers looking to strengthen their foundation in AI strategy and product development, the AI Learning Path for Product Managers covers the strategic and analytical skills needed to navigate both software and hardware product challenges.
Your membership also unlocks:
