The Graduation Point

TableTalk taught me this in real time. It began as a small response to a specific problem. Could I replace an expensive feedback service with something shaped around what the teams actually needed?

And then, without anybody formally deciding that it should, it grew.

Guest feedback became operational insight. Team recognition became visible locally and to global leadership. Voicemails began feeding into the same environment so restaurants could see potential sales opportunities that might otherwise disappear into an inbox. What had started as a lightweight feedback tool was quietly becoming part of how people saw and acted on the business.

There has been some lovely feedback from users since it went live, and plenty of little features and functions have been added along the way. One useful development was bringing executive reports into the tool itself, with reports generated there and automatically sent to the recipients. Previously, somebody had to sift through the data and create the report from scratch. That is less dramatic than announcing an AI transformation, but it is a very recognisable piece of work that no longer needs the same manual effort.

That, for me, is the graduation point, the moment the little thing you were experimenting with quietly becomes something people actually depend on.

Nobody rings a bell when you reach it. There is no helpful message saying, “Congratulations, your prototype is now important enough to cause a proper incident.” You notice because the questions change. Who owns this? Who can see this data? What happens if it is unavailable? Who supports it? What happens when the person who built it is on holiday, or gets bored, or is hit by the proverbial bus that IT governance people have been worrying about since approximately 1974?

The answer cannot be to wrap every experiment in enterprise governance on day one. That kills the economic advantage before you learn anything. But the answer cannot be to leave a successful prototype permanently pretending to be a hobby either.

So I think every small intervention needs a decision once it proves itself, kill it, keep it small, harden it, scale it or productise it.

Kill it when the evidence says it did not matter. Keep it small when it solves a small problem perfectly well. Harden it, making its security, reliability and support fit for everyday use, when people begin depending on it. Scale it when broader evidence justifies the investment. Turn it into a repeatable product only when the same friction appears often enough that reuse is more honest than pretending every customer is unique.

Success changes the standard, and that is not bureaucracy sneaking back in through the side door, it is simply responsibility catching up with value.

There is a temptation at that point to be proud of the growth and keep adding. Pride is not a governance model. The more useful response is to ask what new responsibility arrived with the new value. Does someone now rely on this before making a decision? Does it hold information we would care about losing? Would an outage merely be annoying or would it stop work? Those questions tell you more about maturity than the age of the application ever will.

I like the five possible decisions because they stop scale becoming the automatic prize. Killing something is allowed. Keeping it deliberately small is allowed. Hardening something without trying to sell it to the world is allowed. Scale is earned, not assumed. Productising is rarer still. It should happen because the same genuine friction keeps appearing, not because somebody has discovered the phrase recurring revenue.