Mastering the Steps of Product Development for Complex Hardware

If you’re developing complex electronics, skipping straight to a prototype without a structured process is a recipe for disaster. This ad-hoc approach inevitably leads to spiraling rework costs, catastrophic schedule delays, and a product that’s impossible to manufacture at scale or sell at a profit. A haphazard process isn’t just risky; it’s a direct path to program failure.

This guide is for the engineering leaders, CTOs, and program managers accountable for shipping reliable hardware on time and on budget. It provides an operationally useful framework for navigating the steps of product development, from concept to production, specifically for complex systems like medical devices, robotics, or industrial IoT. This process is not for simple consumer gadgets or pure software projects where the cost of a mistake is low. Our focus is on mitigating risk early and designing for testability and manufacturability from day one.

You will learn:

• How to translate a concept into an actionable plan using deliverables like an SRD and risk map.
• How to execute EVT, DVT, and PVT builds to systematically de-risk your design and process.
• How to create a manufacturing-ready design that avoids common pitfalls in DFM and DFT.

As you can see, each phase builds directly on the last, systematically turning an initial idea into a validated, scalable product. Successfully moving from a prototype to a full product hinges on executing each of these stages with discipline. For a deeper dive into financing this journey, it’s also worth exploring the process of crowdfunding product development.

Step 1: De-Risking Your Foundation with Discovery and Architecture

The most critical work in any hardware program happens long before you order a single component. This is the discovery phase, where you de-risk the project by rigorously defining what you’re building, for whom, and under what constraints. Skimping here is a direct cause of scope creep, budget overruns, and late-stage pivots that jeopardize your launch. This isn’t about adding bureaucracy; it’s about building a stable foundation to move from a high-level idea to a concrete plan that aligns engineering, marketing, and finance. High-performing teams know this upfront clarity separates a chaotic, fire-drill-driven project from one that executes predictably.

From Idea to Actionable Plan

The first job is to translate market needs into cold, hard engineering terms. This culminates in the most important document in your program: the System Requirements Document (SRD). The SRD is the constitution for your product—a binding contract defining performance metrics, environmental conditions, regulatory hurdles, and target manufacturing costs.

A well-defined SRD acts as your program’s constitution. It forces difficult conversations and trade-offs early, preventing the team from building the wrong product, which is far more costly than building the product wrong. Every requirement should be unambiguous, testable, and traceable.

A requirement for “long battery life” is useless. A requirement for “a minimum of 16 hours of continuous operation at 25°C with a 70% duty cycle” is something you can design and test against. Explore our guide on how a structured discovery phase sets the stage for project success. This early work results in foundational documents that guide the program and mitigate risk before significant capital is spent.

Core Deliverables of the Discovery Phase

These deliverables are not just paperwork; they are the strategic artifacts that turn an idea into an executable plan, providing the guardrails needed for efficient development.

Creating Your First Risk Map

As you define requirements, you must actively hunt for what could go wrong. This begins with an initial risk map, where you catalog threats to your program’s success before they become crises. This is the start of a continuous process managed throughout the product’s lifecycle.

Common risks at this stage include:

• Technical Risks: Relying on unproven technologies, aggressive power or thermal constraints, complex sensor integration.
• Supply Chain Risks: Using single-source components, parts with long lead times, unvetted supplier quality.
• Regulatory Risks: Unclear compliance paths (e.g., for FCC, CE, or FDA), rapidly changing standards.
• Schedule Risks: Overly optimistic timelines, dependencies on other teams, complex system integration points.

For every risk, define its potential impact and likelihood, then assign an owner responsible for creating and executing a mitigation plan. This makes risk management an active, accountable process.

Real-World Scenario: De-Risking a Medical Device Architecture

A team developing a portable diagnostic device needed to meet stringent ISO 13485 quality standards. The initial concept called for a new, ultra-low-power microprocessor to achieve best-in-class battery life. During discovery, our process forced a critical question: “Does this new processor have a documented quality and reliability history sufficient for an FDA submission?”

The answer was no. Our risk map immediately flagged “FDA submission rejection due to unproven core component” as a high-impact, high-likelihood threat. The new chip was technically superior, but choosing it introduced massive regulatory and schedule risk.

The team pivoted to a slightly older but well-documented processor with a proven track record in other certified medical devices. This decision, made before a single schematic was drawn, prevented a catastrophic failure that would have otherwise surfaced a year later during regulatory review, saving an estimated $500,000 in rework and a nine-month delay. That’s the power of de-risking upfront.

Step 2: From Prototype to Production with EVT, DVT, and PVT Builds

Once your architecture is locked, theory meets reality. You move from digital blueprints to physical hardware across three crucial prototype builds: Engineering Validation Test (EVT), Design Validation Test (DVT), and Production Validation Test (PVT). Each is a distinct mission with its own goals and costly traps. I’ve seen too many leaders blur these stages—chasing PVT-level yields during an EVT build, burning cash and demoralizing the team. The real goal is to methodically kill risk and build confidence with each successive build.

The EVT Build: A Reality Check

The Engineering Validation Test (EVT) is your first shot at making the product real. You’re building a small batch, often 5-20 units, to answer one question: “Does the core architecture work?” The design is liquid; the BOM might have placeholders, and the firmware is skeletal. That’s okay. The focus is on validating core functionality.

Your primary mission during EVT is simple:

• Board Bring-Up: Can you power it on without letting out the magic smoke? This is your first gut check, verifying power rails, clock signals, and basic boot sequences.
• Architectural Validation: Is the main processor talking to the key peripherals? Are critical sensors sending data? This confirms your high-level design choices.
• Core Functionality: Does the product perform its most vital function from the SRD? For a medical device, that might mean taking a single sensor reading and printing it to a debug console. No fancy UI, no perfect accuracy—just proof of life.

EVT is not about perfection. It’s about finding bugs. You should expect to find them, make schematic changes (“redlines”), and grapple with buggy firmware. For the business, a successful EVT confirms your technical path is sound before you commit to more expensive tooling and larger build quantities.

The DVT Build: Freezing the Design for Verification

The Design Validation Test (DVT) build is where things get serious. Your goal here is to prove that a production-intent design meets every single specification in the SRD. This is where you freeze the design. Any change after this point requires a formal—and often painful—Engineering Change Order (ECO).

DVT builds are larger, usually 25-100 units. You should use production-intent parts and processes wherever possible. This means enclosures from soft tooling (not 3D printers) and PCBs from your intended volume manufacturer.

During DVT, you are testing the design, not the factory. The focus is on exhaustive verification. Every requirement—from functional performance and battery life to environmental testing and regulatory pre-screens—must be tested, passed, and documented before you exit this gate.

This is the phase for punishing tests:

• Full Functional Verification: Every single feature, button, and user-facing function gets tested against its spec. No exceptions.
• Environmental & Reliability Testing: Units are baked, frozen, shaken, and dropped to find weak points.
• Regulatory Pre-compliance: This is when you do preliminary scans for EMI/EMC. Finding a problem now is an inconvenience; finding it during formal certification is a catastrophe.

Exiting DVT successfully gives the business confidence that the product design is solid, reliable, and ready for mass production.

Real-World Scenario: A DVT Gate Failure

A robotics startup, feeling immense pressure from investors, decided to merge DVT and PVT into a single build. They skipped a formal DVT gate review and jumped to ordering a PVT build of 500 units, committing to expensive hard tooling for their custom plastic enclosures.

It was a disaster. They uncovered a signal integrity bug on a high-speed data bus that only appeared under certain thermal conditions, causing random data corruption that made their robot unreliable. The root cause was a layout mistake a proper DVT signal analysis would have flagged. Because they had already paid for hard tooling, the fix was financially brutal. They had to scrap the entire batch of main boards, pay for an expedited board re-spin, and pay again to modify the expensive injection molds. That single mistake cost them over $150,000 in NRE and scrap, delaying their launch by a full quarter—a painful lesson on the value of treating each validation stage as a non-negotiable gate.

The PVT Build: Validating the Factory

The final stage before mass production is the Production Validation Test (PVT). The focus shifts from validating the design to validating the manufacturing process. You’re using the final BOM, firmware, assembly line, and test fixtures. The question now is: “Can our contract manufacturer build this product consistently, at scale, and to our quality standards?” Build quantities are larger, typically in the hundreds or thousands, as this is your first official production run.

Key activities during PVT revolve around the factory floor:

• Yield Analysis: Obsessively track the first-pass yield at every station. Low yields are a massive red flag, pointing to a DFM issue or a problem with the manufacturing process.
• Manufacturing Test Validation: Confirm that every test fixture on the line is correctly identifying bad units and passing good ones. A faulty fixture is as costly as a faulty design.
• Assembly Process Refinement: Dial in the work instructions for line operators, fine-tune assembly jigs, and lock down quality control checkpoints.

A successful PVT run generates the data you need to confidently approve mass production, ensuring the business can scale predictably without hemorrhaging money.

Step 3: Ensuring Reliability Through Verification and Validation

Getting a prototype working on your lab bench is a milestone, not a destination. Now the discipline of Verification and Validation (V&V) begins. It’s how you prove you built the product right (Verification) and that you built the right product (Validation). Skipping this phase is how unreliable hardware ends up with customers, leading to brand damage and recalls that can sink a company. This is where you systematically prove the device meets every requirement you documented—a non-negotiable step for high-stakes products in aerospace or medical.

Building Your Verification Traceability Matrix

The entire V&V effort is governed by a Requirements Traceability Matrix (RTM). This matrix creates an unbreakable link from every single requirement in your SRD to a specific test case designed to prove it has been met. A well-maintained RTM is your insurance against gaps in test coverage, forcing you to answer for every feature: “How, exactly, are we going to prove this works?”

A missing link in your traceability matrix is a glaring red flag that a requirement is going untested. The best teams automate this matrix, generating it directly from their requirements and test management tools. This ensures it’s a living document, not a static spreadsheet that’s instantly obsolete.

This matrix becomes the ultimate scorecard for your DVT build. You cannot pass the DVT gate until every requirement has a “Pass” status next to it, backed by a formal test report with hard evidence.

Firmware and Hardware Testing Strategies

True V&V is a multi-layered campaign that starts at the code level and ends with a fully assembled system being pushed to its limits.

Firmware Testing Pyramid:

• Unit Tests: Testing individual functions and code modules in isolation, often using a mock hardware abstraction layer (HAL) to test logic without needing a physical board.
• Integration Tests: Confirming that different parts of your firmware play nicely together. Does your sensor driver correctly feed data to your processing algorithm?
• System-Level Tests: Validating the complete firmware running on the actual target hardware. These are “black-box” tests verifying the device’s behavior against the SRD.

Hardware Reliability Testing:

• Environmental Testing: Subjecting DVT units to the absolute extremes defined in your requirements—thermal cycling (hot/cold soaks), brutal humidity tests, and ingress protection (IP) testing.
• Mechanical Stress Testing: Simulating real-world abuse. Your product will be dropped, shaken, and vibrated according to industry standards to find weak solder joints, fragile connectors, and flaws in your enclosure design.

From personal experience, one of the most powerful things you can do is bake telemetry into your firmware from day one. Instrument your code to log critical state information, error codes, and performance metrics. This data is priceless for debugging failures in the lab and diagnosing mysterious failures that happen in the field post-launch. It’s the difference between guessing and knowing.

Formal Risk Management with FMEA

While a risk register tracks program-level threats, a Failure Modes and Effects Analysis (FMEA) is a more rigorous, bottom-up technique used to hunt for potential failures at the component and subsystem level. The process involves brainstorming how every part of your design could fail and what the consequences would be.

The core of the FMEA is calculating a Risk Priority Number (RPN) for every potential failure.

RPN = Severity (S) x Occurrence (O) x Detection (D)

• Severity (S): How catastrophic is the failure if it happens? (Scale of 1-10)
• Occurrence (O): How likely is this failure to happen? (Scale of 1-10)
• Detection (D): How likely are you to catch this failure before it ships? (Scale of 1-10, where 10 means it’s impossible to detect)

Your team’s job is to ruthlessly attack the highest RPNs. For instance, a failure mode like “battery shorts internally” would get a 10 for Severity. If your battery protection circuit has a design flaw (high Occurrence) and the fault is nearly impossible to spot in production testing (high Detection), you have a critical RPN that demands immediate redesign. This process creates a formal risk burn-down plan, where your team actively works to eliminate the biggest threats before mass production.

Step 4: Preparing for Scale with Manufacturing Readiness

I’ve seen it happen more times than I can count: a brilliant prototype that works perfectly on the bench completely falls apart when it’s time to build thousands. This is the moment where hardware startups implode, not from a lack of vision, but from a failure to plan for scale. Moving from a handful of units to mass production is a dedicated engineering phase where you rigorously prepare your design for the realities of the factory floor. Skipping this is signing up for crippling yield loss, sky-high costs, and schedule delays that can kill your company.

DFM and DFT: The Blueprint for a Scalable Product

This phase is governed by two critical disciplines: Design for Manufacturability (DFM) and Design for Testability (DFT). These aren’t just checkboxes. High-performing teams start thinking about DFM and DFT way back in the architecture phase. The goal is simple: make your product easy to build and even easier to test. DFM is about simplifying physical assembly, while DFT is about building testability directly into the hardware.

• DFM Best Practices:

  • Component Choices: Prioritize parts that are readily available from multiple suppliers and are packaged for automated pick-and-place machines. Avoid obscure or single-source components.
  • PCB Layout: Include fiducials for optical alignment, clear polarity markings, and enough space between parts to prevent assembly nightmares.
  • Mechanical Design: Use self-aligning features, minimize fasteners, and design parts that are impossible to assemble incorrectly (poka-yoke).

• DFT Essentials:

  • Test Points: Strategically place accessible test points on the PCB for critical voltage rails, clock signals, and data lines. They are your lifeline during production testing.
  • Programming Interfaces: You need a robust and fast interface (like SWD or JTAG) for flashing firmware and injecting device-specific data like serial numbers.
  • Boundary Scan: For complex ICs with hidden pins (like BGAs), JTAG boundary scan is the only way to test for bad solder joints without physical probing.

This upfront work pays for itself by directly lowering your Cost of Goods Sold (COGS) and preventing expensive rework. Learn more about how effective design for manufacturing can change your project’s financial outcome.

Orchestrating the Contract Manufacturer Relationship

Your Contract Manufacturer (CM) isn’t just a vendor; they are your most critical partner during scale-up. The relationship must be built on transparency and early collaboration. Bring your CM into the design process before the DVT design freeze. Their team will provide invaluable DFM feedback based on their specific factory equipment. Ignoring their input is a classic—and very expensive—rookie mistake.

Your CM lives and breathes manufacturing. They will spot potential yield-killers in your design that your engineering team might completely miss. A single half-day DFM review with your CM can easily save you hundreds of thousands of dollars and months of delays.

Choosing the right CM is about more than the lowest quote. Evaluate their technical capabilities, quality control systems (do they have ISO 13485 for medical devices?), communication, and expertise in international logistics, including understanding HS Codes to manage customs and tariffs.

The Manufacturing Test Plan and Fixture Strategy

Your manufacturing test plan is the definitive playbook for your CM’s test operators. It must detail every test to be performed on the production line with exact pass/fail criteria. This document drives the design of your test fixtures—the custom hardware that interfaces with your Device Under Test (DUT).

A smart, tiered fixture strategy is essential:

1. In-Circuit Test (ICT) / Flying Probe: The first line of defense on the bare printed circuit board assembly (PCA), checking for manufacturing defects like shorts and opens.
2. Board-Level Functional Test: Using a “bed-of-nails” fixture, this stage powers up the board, flashes test-specific firmware, and verifies core functions.
3. Final Assembly Test: After your device is fully assembled, this final “box-build” test validates all user-facing functions before it goes in the box.

A key part of this is secure flashing. You must have a bulletproof process to program each unit with its final production firmware, unique serial number, and any calibration data. This process must be fast, reliable, and secure from IP theft.

Managing Change with a Formal ECO Process

As you move from DVT to PVT, changes are inevitable. A DFM review will uncover a hard-to-place component. A test fixture will expose a new bug. Without a rigid process for managing these changes, you descend into chaos. This is what an Engineering Change Order (ECO) process is for. An ECO is a formal document that outlines a proposed change, why it’s necessary, its impact on cost and schedule, and the validation required. No change gets implemented without an approved ECO. This process is your single source of truth, ensuring every modification is documented, tested, and clearly communicated to the CM.

From Theory to the Factory Floor: Your Next Steps

Reading about the product development process is one thing; executing it is another. The real challenge is bridging the gap between theory and action. This starts with an honest, tactical assessment of where your program stands right now. This is where many teams stumble—they absorb the information but struggle to apply it. The key is to ask sharp questions that surface hidden risks before they blow up your budget and timeline.

What to Do Monday Morning: A Program Health Check

Get your lead engineers and program manager in a room and walk through this list. Be brutally honest. The answers will immediately point you to your biggest areas of risk.

• Requirements Traceability: Do we have one source of truth for all system requirements? Can we trace every requirement to a specific test case in our verification plan?
• Risk Documentation: Is our risk register a living document reviewed weekly, or is it gathering digital dust? Does every high-impact risk have a clear owner and a mitigation plan?
• Manufacturing Readiness: Have we sent our preliminary design to our contract manufacturer for a DFM review? Or is our test strategy still a vague “we’ll figure it out during PVT”?

If you answered “no” or “I’m not sure” to any of these, you’ve just found a major red flag. This signals a dangerous gap between day-to-day engineering work and disciplined program management. It’s exactly these kinds of gaps that lead to painful integration problems, blown budgets, and missed deadlines.

For leaders who want to bake these best practices into their team’s DNA, an outside perspective is a powerful tool. A third-party manufacturing readiness assessment can provide an unbiased, expert opinion on your DFM and DFT strategies, helping you spot critical risks before you commit to six-figure tooling costs.

Frequently Asked Questions About Product Development

Let’s tackle some of the tough questions that engineering leaders and program managers wrestle with as they navigate the hardware development lifecycle. The formal steps are a roadmap, but knowing how to adapt them to real-world constraints is what separates success from failure.

How Can a Startup Adapt These Steps with Limited Resources?

The principles of discovery, validation, and manufacturing prep don’t change, but the execution absolutely must. The discipline of each phase is what matters, not the page count of the documents you create.

• Instead of a 100-page System Requirements Document (SRD), you might have a prioritized feature list in a shared, living document that everyone on the team can see and update.
• Instead of a formal, heavyweight FMEA process, your team could maintain a simple risk matrix in a spreadsheet, focusing relentlessly on the top 10 threats to the project.

The key is maintaining the integrity of each phase. Trying to jump from a messy, benchtop prototype directly to a large production order is a classic, and costly, mistake. Lean execution is about being ruthlessly efficient, not cutting corners that you’ll pay for later.

What Is the Most Common Failure Point in This Process?

The transition from a functional, lab-proven prototype to a mass-producible product is, by far, where most projects fall apart. This is the chasm where great engineering goes to die.

Teams consistently underestimate the immense complexity of Design for Manufacturability (DFM), Design for Test (DFT), and rigorous supplier qualification. A prototype that works perfectly in your lab is utterly meaningless if you can’t build it reliably and cost-effectively at scale.

High-performing teams know this. They mitigate this risk by pulling the manufacturing and supply chain conversations much, much earlier into the design process. They’re engaging their contract manufacturer for DFM feedback during the architecture phase, not a week before they want to start the pilot run.

How Can We Better Manage Risk Throughout the Lifecycle?

Risk management can’t be a passive, check-the-box activity you do once and file away. It has to be an active, continuous process woven into the weekly pulse of the program. Start with a risk register during the initial discovery phase and treat it as a living document.

The goal isn’t just to list potential problems; it’s to actively burn them down. A simple but incredibly effective practice is to end every single team meeting by reviewing the top five risks and the current status of their mitigation plans.

Make sure to assign a specific owner to every significant risk. That person is responsible for defining the mitigation strategy and, more importantly, executing it. This creates accountability and ensures risks are being systematically retired, not just passively tracked until they erupt into full-blown crises.

At Sheridan Technologies, we specialize in guiding complex hardware projects through every stage of development, from architecture to production. If you’re facing challenges in your program or want to de-risk your next build, consider a Manufacturing Readiness Assessment.