Ship the thinnest slice: how to stop internal tools being abandoned

A healthcare group came to us having built two internal scheduling tools in eighteen months. Both had been specified thoroughly. Both had been built by competent teams. Both had been abandoned inside a year, and the clinics had gone back to a shared spreadsheet.

They wanted to know what we'd do differently. The honest answer was: mostly the order.

Why exhaustive specification fails

The two previous attempts followed the same pattern. Six to eight weeks of requirements gathering with clinic managers and leadership. A detailed document. Sign-off. Then four to seven months of building, and a launch.

The document was accurate. Everyone in the room agreed with it. And it still described a workflow that did not exist.

The problem is structural: the people available for requirements sessions are the people whose time is easiest to book. That is almost never the people doing the work. Clinic managers described the process as it is documented. Clinicians ran a different one, because the documented process didn't survive contact with a Tuesday afternoon.

No amount of additional specification detail closes that gap, because the gap isn't a missing requirement. It's a difference between what people say happens and what happens.

The thinnest slice

We shipped one workflow to production in three weeks: a single clinician booking a single patient into a single available slot.

Not a prototype. Not a clickable mockup. Real software, real database, real authentication, used by real people with real patients.

It did almost nothing. No waitlist, no recurring appointments, no cross-clinic visibility, no reporting. Roughly 4% of what the specification described.

Then we watched.

What we learned in the first fortnight

Within two weeks of watching people use the thin slice, we found something no specification round had surfaced in eighteen months.

Clinicians were deliberately double-booking a specific fifteen-minute window. Both previous systems treated this as a data-entry error and blocked it with a hard validation rule — which is precisely why both had been abandoned. The behaviour was a deliberate buffer for a category of appointment that routinely overran, and it was load-bearing for how the whole clinic day worked.

Every requirements document had recorded it as an error to be prevented. Two teams had built the prevention. Nobody had asked why it kept happening.

That single finding was worth more than the combined output of both previous specification phases.

What "thinnest" actually means

The slice has to be genuinely thin and genuinely end-to-end. Most teams get one of those and think they've done it.

Thin but not end-to-end is a prototype. A clickable Figma file, a UI with mocked data, a backend with no interface. People will tell you what they think of it, which is not the same as showing you how they'd use it.

End-to-end but not thin is a normal project with a shorter deadline. You still build most of the assumptions before finding out which ones are wrong.

Thin and end-to-end means: one user, one task, all the way through to a saved record in a real database, deployed where people work.

A useful test — can a real person complete one real instance of the job, with real consequences, without you standing next to them? If no, it isn't end-to-end yet.

The economics

Cutting scope by 96% for the first release sounds like it slows everything down. It does the opposite, for one reason: wrong work is more expensive than no work.

Building the double-booking prevention took one of the previous teams an estimated three weeks. Removing it — untangling it from the validation layer, the notification logic and the reporting — would have taken longer. It was cheaper to have never built it.

Across the full engagement, the thin-slice approach put us roughly four weeks behind a traditional plan at the twelve-week mark, and around two months ahead by month six, because none of the six months after the first slice was spent building things nobody wanted.

The result

94% of clinical staff were using the tool daily within six weeks. The previous system had reached 31% at the same point. Scheduling administration dropped from about eleven hours per clinic per week to three.

If you cannot name the one workflow you'd ship first, you do not yet understand the problem well enough to specify the other ninety-six percent.

---

The full engagement is written up in the Atlas Health case study. If you're on your second attempt at the same internal tool, that's a conversation worth having.