The patterns that hold
innovation back

Team members have ideas. They share them in meetings, in Slack, in emails, in corridor conversations. Some get written down. Most do not. The ones that do get written down usually go into a document that nobody looks at again.

The problem is not the quantity of ideas. It is the absence of a system that captures them consistently and makes them visible to the people who could act on them.

Once a project starts, it often becomes a black box. The person running it knows what is happening. Nobody else does. Status updates happen in meetings that not everyone attends. Questions like "where is that project at?" require a conversation rather than a look at a shared system.

This creates coordination problems, duplicated effort, and a general sense that innovation activity is happening somewhere but nobody is quite sure where or at what stage.

Many project management and innovation tools are built with a certain type of user in mind. Someone comfortable with software, familiar with agile terminology, and willing to invest time in learning the system. This excludes a large portion of most teams.

When the tool requires technical confidence to use, participation becomes optional for most people and mandatory only for a few. The result is that the innovation process reflects the priorities of the people who can use the tool, not the whole team.

Projects launch. Sometimes they even finish. But the outcome is rarely measured against the original intent. Did it work? What changed? Was the hypothesis correct? These questions often go unanswered because the project moved on, the team moved on, and there was no mechanism to close the loop.

Without outcome measurement, organisations cannot learn from their innovation activity. They repeat the same types of projects, make the same types of mistakes, and have no evidence base for improving how they allocate resources to innovation.

Different parts of the team use different words for the same things. What marketing calls a "campaign test," product calls a "prototype," and operations calls a "pilot." There is no shared vocabulary, which means there is no shared understanding of where things stand.

This is not a trivial problem. Miscommunication about project stages leads to misaligned expectations, missed handoffs, and decisions made on the basis of incomplete information.