Brandon Hetherington, Editor of ManufacturingTomorrow.com interviewed Krunal Patel, Technical Program Manager to discuss how Hardware Program Managers can successfully scale innovative technologies.  

What are the biggest program management challenges companies face when trying to bring a new hardware product from concept to market, and how can teams get ahead of them early?

Product Development challenges are very dynamic across different stages of the product development lifecycle and may vary across industries. However, one of the common program management challenges is that uncertainty is highest in the beginning and gradually reduces; while decisions are cheaper in the beginning and becoming gradually expensive and difficult to reverse as the program progresses. In practice, combination of pressures of market requirement timings, supplier lead times, and especially in early phases where design may be only conceptually proven (or even not conceptually solidified) supported by limited data, and constrained by time of experimentation, create situations where key decisions need to get locked in before all technical and other program scalability risks are completely understood. Programs may not even get sufficient time to run all possible trials and may only get few iterations to converge into a direction, and at the same time program must continuously balance competing tradeoffs time-to-market vs technical risks, program cost vs product design flexibility, product spec vs manufacturability, component level optimization vs system level integration. Under these conditions, program decisions may be made with incomplete information to maintain momentum while ensuring the product will meet specs, scale to production, and stay within cost targets. These decisions become hard to change and very capital intensive gradually because the program starts building dependencies around them. (For eg: Once supplier engagement begins, long-lead components are ordered, tooling design starts, and manufacturing/test planning is underway, even small changes can cascade into rework across multiple functions impacting cost, schedule, and qualification timelines.). Teams can proactively get ahead by designing program program execution architecture aiming to focus on identifying high-impact dependencies early—such as tooling, suppliers, and long-lead components and ensuring these are only committed once key technical and scalability risks are sufficiently validated with data, and even exploring parallel path exploration with time-boxed convergence, so teams can evaluate options within limited DOE cycles before locking direction. Secondly, by tailoring program governance that can define stage-gate, agile, or hybrid gate model aligned to program complexity, where each decision point explicitly evaluates tradeoffs across time-to-market, cost, performance, manufacturability, and system-level integration before allowing the program to proceed or scale further.

How does hardware program management differ across industries like consumer electronics, EVs, semiconductors, and what can each sector learn from the others?

Hardware program management differs across consumer electronics, EVs, and semiconductors because each industry deals with a different mix of speed, complexity, and risk. Consumer electronics have the fastest cycles with strongest pressure on cost and launch timing. EV program management is evolving with battery technology at higher speed than traditional automotive, while maintaining a strong focus on quality, validation, and safety. Semiconductors have the highest technical uncertainty and deepest system complexity.

EVs can learn from consumer electronics about managing the reality that vehicles are increasingly becoming connected, feature-driven systems with integrated hardware and software (connectivity, UX, infotainment, sensors), much closer to consumer electronics or IoT systems. EV program management is traditionally stronger in later lifecycle stages validation, manufacturability, supplier readiness, compliance, and production ramp  because failure costs are extremely high due to safety, homologation, and integration risks. The transferable learning is to manage these consumer-electronics-like technologies differently across each stage, instead of treating them like mature automotive subsystems from day one. In proof of concept,  use short feasibility sprints to reduce the biggest unknowns while Product development, keeping parallel options open and in Development, place higher focus on system-level integration.

On the other hand, consumer electronics can learn from semiconductors how to operate under deeper technical uncertainty — semiconductor programs are accustomed to progressing with incomplete information, evolving requirements, and limited experimental cycles, while using structured risk reduction to guide decisions. The transferable learning: run risk-driven iterations where each cycle targets specific unknowns, use governance to make conditional decisions allowing progress while tracking remaining risks, and delay scaling until critical uncertainties are sufficiently reduced with evidence.

Semiconductor programs require handling deep technical uncertainty in early and middle lifecycle stages concept, feasibility, architecture tradeoffs, and qualification-driven development. But semiconductors programs can learn from EVs and consumer electronics in downstream productization that platform thinking, cost-down urgency, and speed-to-market are equally critical alongside technical success.
 

What role does cross-functional alignment play in successful hardware product development, and where do teams most often break down?

Cross-functional alignment in hardware is fundamentally about managing interfaces, not just people across all functions. With 2 people, you have 1 interface. But with N people, the number of interfaces grows quadratic as N(N−1)/2. So in a 50-person, multi-function, multi-geo program, you’re not managing 50 contributors, you're managing over a thousand interfaces. That’s where uncertainty and risk actually live. Delays, misalignment, and rework don’t come from individuals, they come from breakdowns across these interfaces (decision gaps, specs understanding gaps, late integration).

So, it becomes critical for program managers to architect the execution system end-to-end, accounting for technical development, cross-functional dependencies, supply chain, manufacturing, and change management while ensuring that short-term design decisions translate correctly into long-term scalability and production readiness.

How are rising supply chain pressures and component shortages changing the way hardware program managers plan for scale and resilience?

Supply chain has been very critical to scaling, especially in complex electro-mechanical systems where 1000s of parts (or sometimes 10s of thousands) come together from different geographies locally or globally. If even one component is late or not right, the volume mass production can stop; there's usually no buffer.

Rising supply chain pressures and component shortages have changed the level of unpredictability due to variability in lead times, geopolitical factors, more and more complex systems, and agility while still meeting time-to-market. Many of these issues don't originate at surface Tier-1 level, but deeper in the chain where visibility is limited.

That means in practice, supply chain resilience need to be built directly into the program execution architecture -  instead of treating as a downstream function, program managers now include contingency risk mitigation into baseline plan including identifying single-point failures, qualifying dual suppliers, one level deeper visibility of extending their focus beyond tier-1 suppliers by mapping dependencies across Tier 2 and 3 supplier levels and pre-validating alternate components so they can be used immediately when needed.

Another shift is in the planning approach which is changing from deterministic to probabilistic that accounts for variability of worst case and ideal case, and supplier performance, which helps to identify where uncertainty lies and have a mitigation plan in place.

Overall the shift is to designing programs which can manage uncertainty and still scale reliably. 

What does it take to successfully manage innovation programs in highly regulated or safety-critical hardware environments?

“Safety” is actually the most critical spec for any product. As a result, it is built into program governance from day 1 and throughout. Besides that, we need to enforce rigorous component and system-level validation, often beyond minimum requirements, validate continuously, and ensure every decision is traceable and safety/compliance defensible before scaling.

How is the convergence of hardware and software development changing the skill set required of today's technical program managers?

There’s not a definitive answer, but in my view, the convergence of hardware and software requires technical program managers increasingly need to adapt designing program execution architecture based on the level of program complexity. Skillset that will continue to be essential will be understanding of systems engineering, the ability to manage program changes, navigate R&D environments where outcomes are not guaranteed, scaling to commercialization, while balancing agility and time-to-market.