Shipping a 21 CFR Part 11 wearable platform

VivoSense supports clinical trials by analyzing wearable sensor data from multiple device vendors. The work is split across two teams: A research scientist team ingests sensor data from study participants, processes it through the proprietary analytics application, and delivers the final report to the pharma sponsor running each trial.

An engineering team builds and maintains the desktop application those scientists use, along with the data pipeline that imports raw sensor feeds from vendors and exports validated study artifacts to sponsors. My role at Vivosense was to manage the backlog, fill in the context, write, and prioritize the changes to the platform and trial data deliverables, and provide executive visibility. The whole platform operates under 21 CFR Part 11, a regulated software environment where every change has to be documented, validated, and traceable.

One of the complications that I dealt with where that multiple studies run concurrently, each on a slightly different validated build of the desktop software. Each study has its own data transfer agreement, validation expectations, and delivery cadence.

I was hired three months into the delayed release specifically to navigate a concurrent quality vendor migration from ETQ to ZenQMS. The migration was reshaping document approval queues and audit-trail conventions week to week, and the release schedule needed someone fluent in the regulated-release vocabulary who could keep development moving while the QMS ground was shifting underneath it.

Requirements documents lagged behind JIRA work that had already shipped. Acceptance criteria existed, but matching requirements and test coverage did not.

Multiple concurrent biotech sponsors had open incident tickets across the delivered trial data simultaneously, each thread carrying its own context that had to be reloaded each time it was discussed. Engineering requests from the research scientist team, namely monthly client data exports and per-client format tweaks, accumulated with no estimation discipline and no alerting on when work needed to start.

And underneath all of it, no shared mental model existed for how a new study moved through Engineering, QMS, and the research scientist team from sensor spec to first production export. Everyone knew their own slice, but nobody had the whole map.

• Product ownership: writing the requirements that should have already existed My first week was spent working backward from JIRA. Tickets had shipped without their requirements documented, so I reconstructed the requirements from the completed tickets and their acceptance criteria, then worked with QA to make sure test coverage matched each one and the test plan grouped requirements for efficient execution. The 4.0 baseline rollup added another layer: a numbering convention had drifted between several minor releases, and pulling those forward into the new baseline meant untangling the drift before requirements could be cleanly reconciled and signed off.
• Technical program management: single timeline for a three-discipline release The release needed a single timeline that surfaced dependencies across the three disciplines, not three timelines that each pretended the others weren't there. I started in Excel, moved to MS Project as the dependency tree got more layered, and finally landed in Notion, where the science, engineering, and QMS milestones could each carry their own context while staying linked to one another. From there, the cadence followed: sprint planning, reviews, and stand-ups all tied back to that plan, and stakeholders started seeing the whole release as one picture instead of three competing ones.
• Sponsor-facing PM: re-anchoring the recurring status The recurring sponsor status call had been running long and ending without decisions, so I took it over and rebuilt the format around a single deck with three sections: a Gantt for the current release, decisions needing sponsor input, and blockers we were carrying. With that structure in place, the half-hour ran tight and ended with a clear next-step list each time. The CPO's feedback after a few cycles: "much more concise, utilizing your ppt deck. Gantt chart looks really good as well."
• Process design: the artifacts, frameworks, and triage that scaled The other half of the role was building the durable artifacts and frameworks that meant the same problem didn't have to be re-solved every week. Six of those mattered most: When the CPO was out with COVID, I covered the role end-to-end for the duration.