Killing a weak hardware product idea at idea screening costs roughly $5,000 in analyst time. The same kill after mass production launch costs $5M to $50M in tooling, inventory, and brand exposure.
Walk into any portfolio review at a large hardware company, and the pattern shows up:
Programs with visible momentum and senior champions get the benefit of the doubt at every stage gate. Early-stage programs without sponsors get cut. Eighteen months later, those protected programs hit the same technical, market, or supply chain problems. Earlier-stage analysis would have surfaced them. The kill happens anyway, at 50 to 100 times the original cost.
This is not a tracking problem. New project management software does not fix it. Spreadsheets hide the cost curve entirely. Every program sits as one row of equal weight on the screen. The 28-month program, two months from mass production, looks identical to the 6-week concept in early validation.
What follows is the framework that hardware engineering teams use to move portfolio decisions earlier in the development process. It starts with the math of when programs should die. It ends with how to build that discipline into your stage-gate process without depending on individual judgment.
Why hardware product portfolios fail at the kill decision
Hardware product development has a cost asymmetry that software does not. A decision at idea generation costs roughly $5,000 in analyst time. The same decision at mass production costs $5M to $50M in tooling, inventory, and brand exposure.
This 1,000x cost curve should drive earlier and more aggressive kill decisions. In practice, it does the opposite. The further a hardware product moves through development, the harder it is to kill. Sunk cost protects programs that should die.
The cost-of-kill curve in hardware development
The math is unforgiving. At idea screening, an hour of analysis kills a weak idea at near-zero cost. At the design phase, killing requires writing off 6 to 12 months of engineering hours. At the testing phase, you add prototype tooling, regulatory submissions, and supplier commitments.
Each stage roughly 10x increases the cost of being wrong. Decision rigor stays roughly constant across stages. That mismatch is the root cause of most wasted spend in new product development.
Three signs your portfolio kills the wrong projects
If two of these are true, the portfolio is operating in late-kill mode. The fix is structural, not motivational.
Most kills happen at the testing phase or later, after $1M+ has been spent per program
Idea screening lasts 30 minutes per idea, with no documented scoring
The portfolio carries 3 or more programs that survived past two stage gates with the same unresolved technical or market risk
The stage-cost asymmetry in hardware product development
The development process in hardware product development moves through distinct stages, each with its own cost profile. Most teams know this in principle, whereas only a few build their portfolio process around it.
How costs compound from idea generation to mass production
A typical hardware product moves through a broader product development journey, with costs across six stages growing roughly as follows (Exhibit 1).
Exhibit 1: The different stages of costs
Concept-to-pilot timelines often range from 6 months to 2 years for low-certification products and 2 to 5 years for products needing extensive certifications. Concurrent engineering can reduce wasted time by running manufacturing processes, design, and marketing in parallel.
Why customer feedback arrives too late in new product development
In most engineering organizations, the first time customers see a hardware product is during alpha testing. By then, the design is largely frozen. Customer feedback at this stage produces minor refinements, not major redirects.
Strong product teams pull customer feedback forward. Lead user interviews in idea generation. Concept testing in idea screening. Functional prototype testing well before design freeze. The earlier user feedback enters the development process, the cheaper the corrections.
A consumer goods hardware maker that pulled customer concept testing from alpha back to idea screening cut its design-phase kill rate by 40%. The ideas that would have failed at alpha testing failed earlier, at one-tenth the cost.
The five kill rates of a healthy hardware product portfolio
A healthy hardware portfolio has a defined kill rate at each stage (Exhibit 2). The numbers below come from observed practice across consumer electronics, medical devices, and industrial hardware companies.
Exhibit 2: The five kill rates of a healthy hardware product portfolio
Across the portfolio, the cumulative math is: 100 ideas in, 11 to 12 launched products. That ratio is healthy for hardware innovations targeting new categories. For line extensions of existing products, the cumulative pass rate runs higher.
Three failures in new product development decision-making
Three failure patterns show up across hardware companies running new product development at scale. Each one inflates late-stage kill rates.
Building kill discipline into your hardware development process
The shift from late-kill to early-kill behavior is a governance change, not a tool change. The work runs in three stages.
Stage #1: Audit current kill rates by stage
Pull 24 months of portfolio data. For each program, record the stage where it was killed or where it currently sits. Calculate kill rates at the idea screening, design phase, testing phase, and post-launch.
Most teams discover the same pattern: idea screening kill rate under 50%, design phase kill rate under 15%, late-stage kills accounting for 70%+ of total kill cost. The numbers become the case for change. Without the audit, the conversation stays abstract.
Stage #2: Pre-commit kill criteria at each stage gate
For each stage gate, document the explicit kill triggers (Exhibit 3). Cost overrun thresholds. Timeline slip thresholds. Customer feedback thresholds. Technical risk thresholds.
Write the triggers before any program enters the gate. Once written, the discussion at portfolio review shifts from “should we kill” to “did the trigger fire.” The committee’s role becomes interpretation, not advocacy.
Pre-committed criteria also protect the program manager. Killing on documented triggers is policy. Killing on judgment is politics.
/Still%20images/Workflows%20Mockups%202025/capabilities-workflow-define-clear-approval-rules.webp){kind=spacer}
Exhibit 3: Define clear approval rules, log every decision, and prompt rework when needed
Stage #3: Separate the kill committee from the program champion
Stage-gate decisions are made by a committee of 3 to 5 named decision makers. None of them is the program champion. The committee meets monthly. Each program presents its stage-gate evidence in a standardized format.
The champion presents the case. The committee applies the pre-committed criteria. Decisions are dated, named, and logged. Reversal requires a documented new decision, not a quiet continuation.
This is the single largest behavior change for most engineering organizations. It is also the change that delivers the most measurable result. Companies that implement disciplined committee-based stage gates typically see late-stage kill costs drop 40 to 60% within two years.
How ITONICS supports disciplined hardware portfolio management
ITONICS provides the portfolio infrastructure that makes early-kill discipline practical at scale. The platform supports hardware product development from idea generation through mass production, with structured stage gates and portfolio-level visibility. A product requirements document carries validated objectives, specifications, and constraints into execution.
Three capabilities matter most for engineering teams building kill discipline.
Stage-gate workflows with pre-committed criteria. Each stage gate carries documented kill triggers, decision makers, and evidence requirements. The structure forces early-stage rigor without relying on individual judgment in the moment.
Portfolio-level kill rate visibility. Real-time dashboards show kill rates by stage across the full portfolio. Leadership sees where late kills cluster, which signals where earlier stages need to screen harder. Patterns become visible across different teams and product categories, and portfolio visibility should also connect launch readiness to downstream sales tracking when products are finally ready for market.
Decision logging and audit trail. Every stage-gate decision is dated, named, and tied to documented evidence (Exhibit 4). Programs cannot quietly survive past a gate where they should have been killed. Reversal requires a documented new decision. Audit-ready by design, which matters for regulatory compliance reviews.
/Still%20images/Workflows%20Mockups%202025/capabilities-workflows-set-required-tasks.webp)
Exhibit 4: Define what’s needed with custom fields and task forms for each phase
ITONICS supports engineering teams running 20 to 500 active hardware programs across the product lifecycle. The platform sits above existing project management tools and connects to product lifecycle management, ERP, and customer feedback systems to improve visibility into materials alongside supply chain decisions.
It does not replace the engineering work. It supports innovation with innovative solutions across the hardware product lifecycle by changing when and how portfolio decisions get made.
