Fit before scale

Software usually performs as specified. Adoption is where it fails. Most operating chiefs can name a system that did everything the contract promised and that almost nobody used: bought, installed, trained for, and quietly set aside once it met the texture of real work.

The risk a purchase order can’t manage

That risk isn’t the one procurement is built for. The buyer worries about picking the wrong supplier. The COO worries about something later and harder: whether the organisation will absorb the thing at all. A capable system dropped into a process that resists it is disruption with a licence fee attached. Even a pilot usually arrives after the supplier has been chosen, and it tests a finished product rather than the fit of something still being shaped.

A Fixathon moves the question earlier. Several teams build competing solutions to a real operational problem, with your data, in your context, and the people who will have to live with the result are in the room while it’s built. What’s being tested isn’t only whether the software works. It’s whether it fits.

Fit is decided at the interface

An operator put in front of a working front end learns in minutes what a requirements document can’t convey in fifty pages: whether the screen matches how the work is actually done, where the friction sits, which steps will be quietly worked around the moment the trainer leaves. The interface is the one thing a proposal can’t show, and it’s usually where adoption is won or lost.

Blufab, the Casais Group manufacturer behind one of the first-edition challenges, treated this as non-negotiable. Its brief made explainability a core requirement rather than a nice-to-have: whatever was built had to let its own people query a production-time estimate and see why the model reached it, which steps drove the number, where it was least certain, without needing technical expertise. The reasoning was operational rather than academic. An accurate black box that operators don’t trust doesn’t get used. An interface they can read and argue with has a chance.

The requirement had teeth because Blufab’s own people were there for the full 48 hours, answering the teams’ questions and giving feedback as the builds took shape. Whether an estimate was legible to the person who’d have to act on it got settled in the room, over and over, rather than assessed at a final demo.

The same logic applies to resistance more broadly. Operational change is hardest to sell while it’s still abstract, and a prototype operators can criticise while it can still be changed buys more than a mandate issued later. Here that isn’t a figure of speech: the criticism arrived early enough to alter what got built.

Demos are staged on tidy data

Operations aren’t. Watching a solution meet real volumes, real edge cases and the awkward exceptions that define how a factory actually runs answers the question a rehearsal can’t: whether it holds up on Monday morning. Much of operational risk lives in that gap, and a build event closes some of it before anything is committed.

Speed, and the habit underneath it

A validation that would otherwise take a quarter of specifications, workshops and circulated documents compresses into 48h of work you can watch. That’s worth having on its own. The more durable benefit is the practice: evaluating unfamiliar technology and deciding on evidence, quickly, is a capability you’ll need again and again in a market where the tools change faster than the procurement calendar.

None of this makes operations easy. It moves the moment of truth to where it costs least: before the training, before the process redesign, and before the settled conviction that the decision was right.