Is the best anchor a prototype?

When I worked in the tech industry, the common advice for when a group of stakeholders couldn’t agree on a solution was to just build something. The idea was that it would give you a starting point that you could iterate from, but also that once something is built, it’s a lot easier to go along with it than to come up with an alternative. In terms of my last post on forming consensus, the prototype you build becomes an anchor for the rest of the process.

It’s often tempting to try this tactic in other settings such as a biotech organization. But be careful: Bad software is a symptom, not a cause. The problems that we try to solve with data and software are often ingrained in the organization’s structure, processes and mental models. If your quick technical prototype requires a major change to any of those, it isn’t actually a quick project.

There will come a point where building a prototype can anchor the conversation by providing a tangible, ready-to-go solution. It will prove to stakeholders how good the idea is, and begin to shift their mental models in the right direction. But only if it fits a process model that’s reasonably close to what you already in place. Larger shifts are possible, but they take a lot more than a single prototype.