MedTech · Discovery to scope lock
The requirements document was describing another product
A discovery review on a hospital computer-vision app that found a specification contaminated with a different product, an estimate with zeros in it, and a pilot reference for the wrong instrument set — before any of it became a commitment.
- Estimate withdrawn for rebuild instead of committed to
- 529hEstimate withdrawn for rebuild instead of committed to
- Vision features committed without evidence they were feasible
- 0Vision features committed without evidence they were feasible
- Open decisions given a named owner rather than an assumption
- 12Open decisions given a named owner rather than an assumption
The problem
A US medtech startup was preparing to build an iPad workstation assistant for hospital sterile processing departments: computer-vision-assisted identification of surgical instruments, checklists, placement guidance and an audit trail, first proving itself on one vendor instrument set at one hospital. The material handed over looked like a project ready to build — a draft requirements document, a backlog, a presale estimate, a clickable prototype, five recorded client calls. It was not. The working spec carried whole sections about parking enforcement and licence-plate recognition, pasted in from an unrelated product. The presale estimate totalled 529 hours with the front-end, back-end and QA rows sitting at zero. The pilot instrument set named in the summary did not match the surgical technique manual that had been supplied as its reference. And the computer-vision model everything depended on was to be delivered by the client, with no contract for its inputs, outputs or accuracy, and no test results.
What I did
I consolidated around thirty scattered documents into one delivery baseline and recorded every decision with the reliability of its source, so a passing remark in a call could not be quoted later as a settled requirement. The contaminated spec was quarantined rather than edited around: a document that cannot be trusted as a source of truth should not be feeding a backlog, acceptance criteria or an estimate. The estimate was withdrawn for rebuild after scope lock rather than defended. Then the scope itself: one narrow boundary statement covering a single pilot set at a single site, and an explicit four-way split — committed, conditional, future, out. Augmented reality, voice control, EHR integration and billing went out, voice for the concrete reason that the room is too loud for it to work. Every feature that depended on the unproven vision model was written with a manual fallback, so the product still functions if the model is late or wrong. The correctness checks that could not be evidenced stayed conditional.
How it ran
- 01
Consolidate the evidence
Around thirty documents, spreadsheets and call records reduced to one baseline, with each claim marked as verified, assumed or contradicted. Most of the project’s risk was visible only once the material sat in one place.
- 02
Quarantine what cannot be trusted
The requirements draft was taken out of use rather than patched: contaminated documents do their damage downstream, in the backlog and the acceptance criteria, where nobody remembers where the text came from.
- 03
Name the dependency
The recognition model belonged to the client, not the build team. That made its input and output contract the first thing to agree and the reason every dependent requirement needed a manual path underneath it.
- 04
Lock the boundary
One pilot set, one site, one workstation flow, written as a statement of what the release does and does not do. The alternative on the table — digitise the department’s workflows — was unbuildable as a first release.
- 05
Sort the wish list
Committed, conditional, future, out. Conditional items carried the condition that would promote them, so nothing sat in a permanent maybe.
- 06
Define what proof looks like
Success criteria a pilot can actually settle — completing the flow with no network, recovering from a wrong recognition, documenting a missing instrument with evidence — plus the metric that matters most on a vision product: how often users override what the model suggested.
Other work
All case studies →- Insurance
Sequencing the data foundation before anyone bought an AI agent
A financial group wanted AI scoring across five affiliates. I proposed one affiliate, eighteen weeks, and a data readiness report before a single model — because the alternative is an agent trained on data nobody has reconciled.
- Corporate banking
Winning back the last call after two meetings had failed
A long-standing account was one bad meeting from closing. I rebuilt the pitch around the client's own operating numbers and a working prototype, and cut every claim we could not source.
- Telecommunications
Every clause gets a human verdict
Contract review is the most demoed AI use case in the enterprise and the least trusted. I built the version where the model proposes a redline and a lawyer accepts, edits or rejects each one.
Something similar on your plate?
Thirty minutes, no deck. I will tell you whether it is worth doing at all.