The FDA regulatory framework creates a skills barrier that protects the salaries and career trajectories of people who understand it. Regulatory affairs specialists, quality engineers, and clinical PMs who understand IEC 62304, FDA 21 CFR Part 820, and human factors engineering requirements are in short supply because the knowledge takes years to accumulate. The same regulatory burden that makes MedTech move slowly is what makes experienced MedTech professionals valuable — you cannot quickly replace them with generalists from consumer tech. When a medical device company needs to file a 510(k) submission or prepare for an FDA audit, they need people who have done it before. That scarcity is structural, not cyclical. MedTech hiring does not have the same boom-and-bust pattern as consumer tech because the regulatory requirements do not go away in a downturn.
The human factors engineering requirement that creates UX demand
FDA requires that certain device classes undergo human factors validation — essentially usability testing with clinical users under controlled conditions documented for regulatory submission. This creates demand for UX researchers who understand both design research methodology and the FDA documentation requirements. Most UX researchers from consumer tech have never produced a human factors engineering report and do not know what an IEC 62366 summative usability evaluation looks like. MedTech companies actively recruit UX professionals willing to learn this framework because the combination of design research skills and regulatory literacy is genuinely rare. The career path for a UX researcher who develops this expertise runs significantly higher than the consumer tech equivalent — both in compensation and in the strategic weight of the role, because the usability evidence directly affects regulatory approval.
The digital health entry point that bypasses the steepest regulatory learning curve
Not all digital health products are FDA-regulated as medical devices. General wellness apps, administrative software, and clinical decision support tools that do not make diagnostic claims are often not regulated or are regulated at a lower risk classification. Breaking into digital health through these lower-regulatory products, then building toward more complex regulated software as you develop domain knowledge, is a viable path that does not require front-loading years of regulatory study. A PM at a healthcare SaaS company that builds scheduling and administrative software for hospitals is working in health tech, developing clinical workflow intuition, and building relationships in the industry — all without needing to understand 21 CFR Part 820 on day one. That foundation makes the eventual move toward regulated medical software significantly less steep than coming from consumer tech with no healthcare context at all.