For most of the past decade, “product management” has been synonymous with building software products. We built apps or SaaS platforms, deployed code instantly to the cloud and measured success in digital engagement metrics.
But the agentic AI era is changing that assumption.
AI innovation is no longer confined to larger, cloud-based AI models or even viral orchestration frameworks like OpenClaw. A rapidly growing frontier is on-device or edge intelligence. This is privacy-preserving, low-latency AI embedded directly into smartphones, wearables (glasses, AI pins), robots and spatial computing platforms like Apple Vision Pro and Meta Orion. The most exciting AI products are no longer just chatbots living in a browser. Increasingly, they are physical agents living in our pockets, on our bodies and in our homes.
As AI products move beyond the screen and into the physical world, more AI product managers are asked to lead hardware programs for the first time. They’re often unprepared for this shift, however, lacking a mental model for how hardware development actually works. To a software native, hardware can feel like a different species — slow, rigid and fundamentally orthogonal to Agile.
This gap in intuition is dangerous.
This article is a practical playbook for AI product managers crossing that divide, decoding the hardware product development process called NPI (New Product Introduction) and translating familiar software instincts into the reality of building physical AI products at scale.
What Is the New Product Introduction (NPI) Process for Hardware?
The New Product Introduction (NPI) process is a rigid, phased waterfall framework used to transition a physical product from concept to mass commercialization. Unlike Agile software development, NPI uses strict Gates or Builds to manage the complexities of physics, supply chains and manufacturing costs.
- Stage 0: Definition — Define product vision What should we build, why, and at what cost?
- Stage 1: Proto — Prove the physics. Is the hardware design actually possible?
- Stage 2: Engineering Validation Test — Prove the function. Does the design meet all requirements?
- Stage 3: Design Validation Test — Prove the manufacturing. Can we build this consistently at scale?
- Stage 4: Production Validation Test — Prove the speed. Can we mass produce and ship?
Decoding the Process: Why Hardware Can’t Be Agile
In software, you live in a world of relatively immediate impact: code, deploy, measure, repeat. If something breaks, you roll it back. The development cycle is measured in weeks, and sometimes days. In hardware, timelines stretch into months or years, decisions feel irreversible and mistakes are measured in millions of dollars, not Jira tickets.
Hardware development isn’t slow because it’s inefficient; it’s slow because of a simple hardware truth: manipulating atoms is fundamentally different from coding bits. Whether it’s the H100 GPU training the model in the cloud or the smart glasses running it, physical products are bound by the unyielding principles of physics, material science and industrial design. Unlike code, you cannot simply refactor a molded plastic enclosure or an etched PCB. Key challenges include:
- Supply Chain: Raw materials, components and modules have tooling, manufacturing, and logistics lead times typically measured in weeks and months.
- Manufacturing: Finished goods must be assembled, rigorously tested to pass quality standards and regulatory certifications (FCC/CE) and be mass-produced.
- Forecasting: You must predict demand far in advance. Build too few, and you lose revenue; build too many, and you write off millions in inventory.
- Serviceability: You cannot hotfix a hardware defect. Correcting issues requires a robust infrastructure for repairs and returns (RMA).
Because of these constraints, hardware development cannot follow an Agile loop. Instead, it follows a rigid waterfall process known in the industry as NPI (New Product Introduction).
NPI is divided into phased “Gates” (often referred to as “Builds”). You cannot proceed to the next phase until you satisfy the strict exit criteria of the current one. This process design ensures that you can scale efficiently from prototype to mass commercialization while iterating on the product.
The NPI lifecycle is structured into five critical stages: Definition, Proto, EVT, DVT and PVT. Each stage acts as a filter, rigorously testing the design before committing to the next level of investment.
To navigate this transition, here’s a translation matrix to map your existing software intuition to the hardware world:
Translating Software Development Methods to Hardware
Stage 0: Definition — The Blueprint
- The Goal: Define the product’s vision and its features.
- The Question: What to build, why, and at what cost?
Before a single wire gets soldered, there is a chaotic, creative phase called the definition (or concept) phase. The product manager leads this phase, defining what is being built and why, closely collaborating with the UXR, design and engineering teams.
Crucially, this is where you collaborate with business teams to build the business case that justifies the investment. This includes analyzing market size, trends, and competition, setting a target price and estimating lifetime volumes. These financial targets create design constraints for the engineering teams. You cannot use a premium metal enclosure if your business model only supports a low-cost, plastic budget.
In software, requirements often evolve during development. In hardware, however, ambiguity is expensive. If you change the display bezels by just 0.5mm after the definition phase, you might trigger a redesign of the display panel, enclosure and battery, which would add cost and schedule delays in turn.
Therefore, the PRD in hardware acts more like a detailed specsheet than a backlog of user stories. Relevant cross-functional teams must sign off on it and lock it down early.
Finally, this phase typically concludes by awarding business to a contract manufacturer (CM). Unlike switching cloud providers, this is a long-term strategic marriage. This partner will build your product from the first prototype to the millionth unit and likely the next iterations of the product as well.
The Software PM Analogy
Think of this as a locked PRD or architectural blueprint stage. Unlike a standard Agile PRD, which serves as a living document, this is a fixed foundation. You cannot change the floorplan once you start pouring concrete.
Stage 1: Proto, or The Hackathon Build
- The Goal: Prove the Physics.
- The Question: Is the hardware design and functionality actually possible?
The first major phase in the development timeline is called proto, short for prototype. With the product defined on paper, it is time to build the first physical units that resemble the intended form factor.
The primary goal is to test if the design and features work together as expected. These early units are often ugly, featuring 3D-printed enclosures, loose wires and development boards. Engineering teams usually build multiple design variations in parallel. Testing results from this phase determine the necessary design changes for the next phase (EVT).
The Software PM Trap
In software, you often ship an MVP and promise to clean up the 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. BOM (Bill of Materials) costs can get out of control if not mitigated early on.
The Software PM Analogy
Think of this as a proof of concept (PoC). You aren’t trying to build something scalable; you’re just trying to prove that the core system actually works outside of a simulation.
Stage 2: EVT (Engineering Validation Test)
- The Goal: Prove the Function (“Looks like, works like”)
- The Question: Does the design meet the requirements?
EVT is where the product starts to look like a real device. You are fitting the components into the production-intent form factor built using the production-intent materials. The goal is to validate the design’s form factor, performance, reliability and manufacturability.
Key Constraints
The flexibility in design changes becomes highly limited at the end of this phase. Once you exit EVT, you are typically locking down the physical design. Why? Because cutting the steel molds for the next stage takes months and costs hundreds of thousands of dollars. The testing results of the EVT build inform the minor product changes that may be needed during the next phase (DVT).
The Software PM Analogy
Think of EVT as your alpha release. It has the features, but it’s buggy, fragile and definitely not ready for the public.
Stage 3: DVT (Design Validation Test)
- The Goal: Prove the Manufacturing (“Made on the Line”)
- The Question: Can we build this consistently at scale?
This is the stage that confuses software PMs the most. The product looks done, so why can’t we ship it?
In DVT, we don’t just test the product but also the process of manufacturing it at scale. The primary focus is testing the manufacturing process, optimizing it for yield (percentage of good units produced) and throughput (production speed). The DVT product is typically final production-intent, perfected through previous proto and EVT builds.
Pro Tip on Device Firmware
You might think, “Firmware is just software. We can update it anytime.” Incorrect. In DVT, the device firmware must be stable enough to support factory diagnostics. For example, if you push a firmware update that is incompatible with the factory test tool, you lose valuable test and diagnostics data needed for troubleshooting, making it impossible to identify and fix manufacturing defects.
The Software PM Analogy
Think of DVT as Staging/QA. You aren’t adding new features; you’re stress-testing the environment to ensure it won’t crash when traffic hits.
Stage 4: PVT (Production Validation Test)
- The Goal: Prove the Speed (“The Speed Run”)
- The Question: Can we mass produce and ship?
PVT is the final dress rehearsal. The primary focus is to validate the entire production process at scale, produce commercial units and verify the logistics setup.
The design is locked. The mass production tooling and equipment are locked. The line operators are fully trained. The assembly and packaging processes are fully established. Shipping and fulfillment setup is ready.
The only variable left is volume. We run the factory at full speed to ensure that building thousands of units doesn’t break the product quality, manufacturing line or processes. This is also when you are stressing the supply chain. If a component vendor fails to supply on time or meet your mass production quality standards, you cannot ship.
The Software PM Analogy
This is your release candidate or load testing. It’s the final “go/no-go” decision before you push to production.
The Finish Line: Mass Production (MP)
Once you successfully exit PVT, the NPI process officially ends, and Mass Production (MP) begins.
This transition is often marked by a phase called Ramp where the factory output increases exponentially, from hundreds of units per day to thousands. At this point, the product and engineering teams usually step back and the operations team takes over full control.
Why Hardware Fluency Will Define AI PMs
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. As a result, the definition of product leadership is expanding.
The most effective AI product managers won’t just understand models, prompts or orchestration frameworks. They’ll understand how intelligence becomes a reliable and scalable physical product, constrained by physics, manufacturing and supply chains.
Understanding the hardware 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, from the chaos of proto to the precision of PVT, you position yourself as a rare product leader who can speak both languages. You have the ability to 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.
