A Project Management Playbook for Healthtech Teams

A small team building software that touches patient-facing workflows

Picture a healthtech company of around fifty to eighty people, with an engineering group of twelve to eighteen building the parts of the product that touch clinician workflows or patient records, plus a smaller QA and regulatory-adjacent review function sitting alongside it. The features themselves aren't exotic: appointment scheduling, intake forms, a results dashboard. What makes the work different from a typical SaaS team's is that almost everything shipped in that area needs to be explainable later. Not just "does it work," but "who decided this, when, and what changed."

That requirement doesn't show up as a single big process. It shows up as a constant low-level tax on ordinary sprint work: a reviewer wants to see why a validation rule changed, a QA lead needs to confirm a fix actually addressed the reported issue before it ships, and six months later someone needs to reconstruct why a particular field became optional instead of required. None of that is dramatic. All of it depends on records existing somewhere findable.

This is the situation many healthtech engineering teams are in before they adopt a system built to keep a record next to the work, rather than a general tracker that assumes nobody will ever need to look back.

Before: work that shipped, but couldn't fully explain itself

The first problem is usually intake. A request to review a change before it ships, from QA, from a regulatory-adjacent reviewer, from a product lead who wants a second look at anything touching patient data, tends to arrive as a direct message to whichever reviewer is around. It's not that reviews don't happen. It's that they happen unevenly, based on who happened to be free, and there's no shared queue showing what's actually waiting on a look.

The second problem is reconstruction. Months after a change ships, someone asks why a particular workflow behaves the way it does, and the honest answer lives across three places: a Slack thread that's aged out of search, a comment on a closed ticket, and one person's memory of a call. None of it is written down in a place a new team member, or an external reviewer, could find on their own. Teams end up keeping a separate compliance spreadsheet just to have something durable, and that spreadsheet drifts out of date within a quarter because updating it is a second job nobody has time for.

The third problem is the gap between "the ticket says done" and "the code that actually shipped." A card gets marked complete, but there's no reliable link back to which pull request closed it, so tracing a shipped change to the review that approved it means digging through commit messages and hoping someone referenced the ticket number correctly.

After: a record that exists because it was part of the work

The realistic shift for a team like this involves no new compliance process bolted on top of engineering. The review queue becomes visible instead of ambient, and the explanation for a decision lives on a page instead of in someone's head. A change that touches patient-facing behavior sits in a column that won't let it through unreviewed, and the reasoning behind it is a link away from the card, not a search through old messages.

It's honest to say this doesn't replace a formal compliance program if the work genuinely needs one. A WIP limit is a capacity gate, not an approval workflow with named roles and legal sign-off, and a wiki page isn't a certified audit trail. What it does reliably fix is the ordinary version of the problem: a decision that was made but never written down anywhere findable, and a review that should have happened but got skipped because nobody was watching the queue. For most day-to-day engineering work in a healthtech product, that's the actual gap, and it's the one this closes.