Tech and distribution

We are in the middle of an under-recognised moment of change in the way software is paid for and in what makes a software product successful or not. Let me lay out my reasoning for what this transition is, and what it will mean in the near future.

The Past

Once there was a market for software at all, the key to success was control of the distribution channels. This was the main chokepoint — or opportunity, depending on how you look at it — because most people accessed technology via their work, so controlling the corporate purchasing decision was crucial. Nobody was going to engage in BYOD, Shadow IT, or any of the other hobgoblins of command-and-control central IT departments in the days when you needed a forklift to bring your own device into the office, probably from a loading dock.

Today

The situation most people are familiar with these days is one in which the terms of the relationship I described above have everted, with platforms people chose for themselves becoming adopted as corporate standards. The breakout moment was probably when people started buying their own iPhones instead of corporate-issue Blackberries, or maybe it was MacBooks instead of boring Dells. The best current example would be Slack, which gets adopted for free by small teams, or perhaps even experienced first as the platform for a side project, in the same way that people might have used IRC a couple of decades ago.

In this market, developers are the new kingmakers, not purchasing departments that mainly work to get the thing developers already chose on better terms. The key to success if you want to sell to the enterprise therefore is controlling the hearts and minds of those developers.

The Future (Coming Fast)

While people are still fighting over the details of the present (and to be sure, while pockets of the past still exist here and there), the wave of the future is already building. Here’s the short version: democratisation of tech means line-of-business people can focus on the job to be done and route around developers who just want to play with the latest cool tech toys.

Some of the enabling technologies are out there already. Here are some signs and portents:

Another example would be Slack, a great success for the earlier model, but one whose inherent nature will prevent it from being successful in the same way in this future. The modular architecture that makes techies love Slack (the integrations! the bots! the custom emojis!) actually slows down the non-techies who just need to get their jobs done. By contrast, Teams’ integrated platform largely gets out of the way and lets them get on with it. The techies mutter and complain about the insufficient quality of each of the constituent modules, but the integrated platform is rapidly winning the market. In the words of Aaron Levie of Box, “Salesforce is blowing past traditional departmental boundaries” and selling directly to new users within their existing customer organisations.

In other words, Slack tried to kill email, but ended up becoming email — and as I wrote back in 2016, email has a long head start and is just generally much better at being email:

most would-be email killers are walled gardens, consisting of a service that is tightly integrated with its client app and does not allow third-party clients. This makes it much harder for innovation to happen, because there is only one provider, and they deliver only the functionality that they want and can build. If you want a feature to be added to Slack, you can’t build your own Slack client; you have to petition Slack to do it, and they choose whether to implement that feature or not.

In the end, Slack, like email, became a feature. This is why the real benefit for Salesforce in its acquisition of Slack is consolidation and the end of modular, piecemeal acquisitions of SaaS products by companies.

The Pendulum Swings

This change is part of a natural pendulum process, from integration to modularisation and back, but with the points of integration and modularisation changing. What is differentiating can be a module that is valuable in its own right, but once it becomes table stakes, the conversation moves up a level to the integrated platform that module is a part of.

Developers should not feel bad about no longer being in charge; the benefit is that they are also no longer on call to fix those things when they break. There will always be a role for developers, but in the same way that there is more to choosing a car than its horsepower or efficiency, other considerations come into play for business users when they are selecting a tool for their everyday use.

The new role for IT is to remain a part of the process, studying and advising, but ultimately it’s the users who decide — as it should be.