Project Context
You are the program lead at GlucoPilot, a digital health company whose mobile app helps ~4.2M monthly active users manage Type 2 diabetes. The company is moving upmarket: three large US health systems (combined 1.1M covered lives) have signed LOIs contingent on GlucoPilot shipping a new feature called DoseAssist, which provides clinician-configurable insulin dosing recommendations. This feature changes the product classification from “wellness” to Software as a Medical Device (SaMD), requiring a more rigorous Quality Management System (QMS) aligned to ISO 13485 and FDA expectations.
Today, the company has strong engineering practices (CI/CD, code review, incident response) but no formal QMS. Documentation is inconsistent, risk management is ad hoc, and vendor controls are minimal. The CEO has committed to the board that DoseAssist will begin pilots by June 30 (16 weeks from now), and the Sales team has already promised a “regulatory-ready” posture to the health systems’ compliance offices.
Your mandate: stand up the key components of a QMS that are necessary to safely and compliantly ship DoseAssist without slipping the pilot date, while keeping the scope realistic for a 16-week runway.
Team & Operating Model
| Function | Headcount available | Notes |
|---|
| Backend Engineering | 6 | Owns dosing rules engine + APIs |
| Mobile Engineering | 4 | iOS/Android app changes |
| Data Science | 3 | Dose recommendation model + monitoring |
| QA / Test | 2 | Historically focused on manual regression |
| Product | 1 PM (you) | Owns roadmap + launch readiness |
| Clinical | 1 clinician | Part-time, reviews clinical logic |
| Regulatory/Quality | 1 contractor | 20 hrs/week, starts Week 3 |
| Security/Privacy | 1 lead | Shared across org, limited bandwidth |
Stakeholder Landscape (Competing Priorities)
- VP Sales: Wants pilots live by June 30 to avoid losing $8M ARR pipeline. Pushes for “minimum paperwork” and a narrow interpretation of compliance.
- Head of Clinical: Will not approve DoseAssist unless clinical risk controls and traceability are robust. Prefers delaying launch over patient safety risk.
- Engineering Director: Concerned about process overhead slowing delivery and increasing burnout. Wants lightweight workflows integrated into existing tools (Jira/GitHub).
- General Counsel / Privacy: Focused on HIPAA, vendor contracts, and audit defensibility. Wants clear document control and training records.
- Customer Compliance Officers (3 health systems): Require evidence of QMS elements (risk management, CAPA, change control, validation) before allowing pilots.
Constraints
- Timeline: 16 weeks to pilot start (June 30). No date slip is preferred; a slip beyond 2 weeks triggers LOI renegotiation.
- Budget: $180K total for external support (quality contractor, optional ISO consultant, tooling).
- Tooling: Must use existing stack where possible: Jira, Confluence, GitHub, Datadog. New QMS software requires Security review (4–6 weeks) and is risky.
- Regulatory posture: Not pursuing ISO certification before pilots, but must be “audit-ready” for customer diligence and future FDA submission.
- Parallel work: Engineering must still deliver DoseAssist; you cannot freeze development for process work.
What You Need to Deliver (Candidate Outputs)
Create a practical execution plan that answers: What are the key components of a QMS, and how would you implement them here under constraints? Your deliverables:
- QMS scope definition: Identify the minimum set of QMS components required for DoseAssist pilots (and what you explicitly defer).
- Process + artifact map: For each QMS component, specify the concrete artifacts (templates, logs, SOPs) and where they live (Confluence/Jira/GitHub).
- Integrated roadmap: A 16-week plan with milestones, owners, and dependencies that does not derail feature delivery.
- Trade-off decisions: At least 3 explicit trade-offs (e.g., validation depth vs. timeline, vendor qualification depth vs. risk).
- Launch readiness + monitoring: Define go/no-go criteria, rollback plan, and post-pilot CAPA intake.
Complications (Realistic Curveballs)
- Vendor change midstream: In Week 6, the team wants to swap the dosage rules engine library due to performance issues. This impacts validation and traceability.
- Staffing shock: In Week 8, one QA engineer goes on unexpected medical leave for 4 weeks.
- Customer diligence escalation: In Week 10, one health system requests evidence of design controls, including requirements traceability and verification/validation summaries, within 10 business days.
Success Criteria
Your plan should result in a QMS that is credible to enterprise healthcare customers and sets the company up for future regulatory submissions—while still shipping DoseAssist pilots on time. Be specific about:
- Which QMS components you implement first and why
- How you keep teams moving (templates, automation, “definition of done”)
- How you handle documentation control, training, and audit trails
- How you manage risks, CAPA, and change control without creating bureaucracy
