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:

• Low-code / no-code comes of age with announcements like Salesforce's Einstein Automate;
• The API Economy starts taking off;
• Look at AirTable's own list of user profiles: "Creators and creatives around the world use Airtable to do everything from cattle tracking to filmmaking";
• You can use the QUERY function in Google Sheets to run database queries directly from a spreadsheet.

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.

It’s not easy to hit the right balance between making thing easy for new or infrequent users and enabling power users to be very efficient. It’s even harder for a tool like Slack, which by definition has to be universally adopted in order to succeed.

This is why it’s particularly important to note the discussion about the recent changes to Slack’s editing functionality. The editor used to use Markdown, which is the sort of thing power users love, but others, eh, not so much.

Markdown was created as a a quicker and simple alternative to HTML, but with the aim of catering to the sort of people who would otherwise be crafting HTML by hand in a text editor window. I can pop open BBEdit or vi, start right from

`<html>
<head>
<title>This is my new document</title>`

and go from there, but it’s a bit of a faff. Markdown makes it easy for me, a power user, to be more productive.

The problem with Markdown, especially when it’s implemented inline like Slack did, is that it’s not particularly discoverable. Unless you already know what Markdown is and that it’s supported in whatever window you’re typing in, you’re unlikely to stumble across the functionality by accident.

This is why Slack built a rich text editor which shows all the functions – bold, italic, list, hyperlink, and so on – visually in a toolbar. This makes it much easier for people to add formatting to their messages who might never have done so in the past – and anecdotally, that is exactly what I have been seeing. This is known as a WYSIWYG editor, where the acronym stands for "What You See Is What You Get". Appropriately enough, I first became familiar with the concept when the first WYSIWYG editors for HTML started to come out. Those of us who were used to hand-crafting our HTML by hand in text editors scoffed at the inelegant HTML these tools produced, but they were quickly adopted by vast numbers of people who had been intimidated or were simply turned off by the blank stare of a new text editor window.

WYSIWYG tools are a major democratising force, opening up functionality to huge groups of users who would not otherwise have had access to them. However, as with many user-assistive functionalities, they need to be implemented with care so that they do not become obstacles for users who do not require (or prefer to do without) their assistance.

Uh oh, it looks like your embed code is broken.

The problem in Slack’s case is that the way the WYSIWYG editor is implemented breaks Markdown quite badly. In fact, the reaction got so bad that there is a Chrome plugin to disable the new editor.

To their credit, Slack are apparently walking back the changes and will rethink their approach:

Our recently introduced WYSIWYG formatting toolbar was developed with that broader customer community in mind. We thought we had nailed it, but we have seen an outpouring of feedback from customers who love using Slack with markup.

I don’t necessarily blame Slack for the original miss; it’s not easy to combine direct editing with WYSIWYG in the same window, and testing for all the edge cases of a markup language like Markdown is by definition a hard problem. It’s also worth noting that, in terms of percentage of user base, these Markdown issues will hit a very small number of people. The problem is that those are also the most passionate and dedicated users, so upsetting them will have disproportionate effects on user satisfaction overall. Also, kudos to Slack for listening to feedback and revisiting the changes.

This whole débacle does speak to a more general problem though. I liked early search engines, where you could type

"this phrase" AND "that phrase"

with a reasonable expectation of getting only matches that contained both of those phrases. Instead, search engines nowadays will "helpfully" try to work out what you really meant and return that instead, and it is frustratingly hard to persuade them to stop trying to help and get out of my way.

Providing assistive interfaces for those who need them is both a Good Thing in general, and good for product growth. Power users who are dedicated to learning something will jump through whatever hoops they need to jump through, but casual users will bounce off a learning curve that is too steep. The best match would seem to be a toggle somewhere that lets power users turn off the helpful interjections and talk directly to the machine (see also: autocorrect).

By giving both groups of users what they need, a user interface with this dual nature will both deliver easy onboarding of new users, and enable power users to work efficiently. I hope Slack figures it out quickly and becomes an example of Doing It Right.