We are all so used to phrases like “critical mass”, “scale up”, or ”volume benefits” that we don’t really question the underlying assumption that bigger is better. Ever since the days of Henry Ford we have grown up with the belief that more is merrier. Of course, in a world full of scale challenges, this was right: in order to get your product to a global audience, you needed a global team. To make a model T at a price for the masses, scale was needed to bring the unit costs down.
For as long as most products that were sold could be shrink wrapped, and the tools to make a noise about them were largely analogue, scale made sense, even when the drawbacks of size were obvious: latent processes, incoherent culture, big bureaucratic inflexibility. A nimble, smaller competitor could always be relied upon to grow to a size that destroyed their inbuilt advantage.
Slowly we are moving to a world of services, and a toolkit to come to market that is digital. So what? To move from analogue to digital is to move from challenges that are largely quantitative to ones that are largely qualitative. We are moving from the task of harvesting a field of fruit to a three-foot putt. The former does not need much skill, but much scale: the latter, the opposite. Indeed, scale would be disastrous: having 200 people size up the challenge would just confuse things and act against crisp execution of that putt.
So, let's bring it back to Supl’s world, that of enterprise software. It’s full of providers with immense scale: lots of sales people, pre-sales engineers, product specialists, accountants. All that scale includes the minimum cost of engaging with them: the beast needs feeding, even if such scale is unnecessary in the delivery of value-add services. We at Supl are frequently asked whether we have missed off a couple of zeroes when delivering a quote. It’s not that we are a charity, it’s simply that we don’t have scale, and nor do we need to. Stitching in a CRM service in between Xero and a subscription website (as we did for rightsnet, see the case study here) giving them a single view of their operations with automated processes was a three foot putt, not a fruit-picking expedition. Was there not a huge amount of data to to be normalised and reconciled? Yes, but some thought and some powerful software solved that.
The point that we’re making is not that we’re uniquely brilliant: actually there are plenty of people like us buried in large organisations. It’s just that they have to support the rest of the organisation, so their tariff has to be eye-watering. And remember, in enterprise software there is very little that can be classified as fruit picking. With cloud-based tools, the task of building and deploying a new service is one of pressing the right buttons, not deploying the largest number of people. You’ll save a few bob and more likely end up with a horse (a thoroughbred solution that coheres for the user) , rather than a camel (a collection of features agreed by committee).