I never understood why Slack won

I never really understood the popularity of Slack.

And I mean that quite literally.

When Slack appeared, instant messaging wasn't new. It wasn't even particularly exciting technology anymore.

We had ICQ in the 1990s. MSN Messenger. Yahoo Messenger. AIM. Skype.

By the time Slack launched publicly in 2014, people had already spent more than a decade sending instant messages, files and emojis, creating group chats, and making voice and video calls through applications sitting in the corner of their desktop.

Some of those products had enormous user bases. Skype had messaging, file transfers, voice calls and video. MSN Messenger had been part of everyday life for a generation. ICQ had been doing chat and file transfers years before that.

Then Slack appeared.

And everybody seemed to lose their minds over... chat.

Yes, Slack made messaging much more suitable for companies. Channels were useful. Persistent searchable history was useful. Having conversations organised around teams and projects instead of a giant contact list was useful.

Later, integrations became a huge part of the appeal.

I understand all of that.

But especially in the early days, I kept looking at it thinking:

Is that it?

Because fundamentally, the thing I wanted from a business messenger wasn't a slightly better place to send messages.

I wanted messages to actually do something.

If someone writes, "Can you fix this tomorrow?", why is that still just text? Why can't I click it and make it a task?

If somebody asks me a question while I'm busy, why should that question disappear into the chat history unless I remember to come back to it? Why can't I mark it as a question that remains unanswered until I answer it?

If someone posts an explanation we will need six months from now, why do I need to copy and paste it into a knowledge base? Why can't the message simply become knowledge?

That was the bit I couldn't understand.

We already knew how to build messengers.

What I wanted was a messenger that understood that a conversation at work is usually the beginning of something else.

About ten years ago I actually wanted to build one.

I called it Vigor.

Yes. Vigor.

I was very pleased with the name at the time.

The idea was simple: a message shouldn't always be treated as a message.

Sometimes it is information. Sometimes it is a request. Sometimes it is a question. Sometimes it is something you need to remember. Sometimes it is the beginning of a task. Sometimes it is a decision. Sometimes it should become permanent company knowledge.

So why does the software make me manually translate all of those things into other software?

I wanted to click on any message and be able to react, reply, forward or pin it, but also save it as a topic for discussion, create a sub-chat around it, save it directly into the knowledge base, turn it into a task, create a personal todo, assign that todo to somebody else, or turn it into a question for a particular person that remains outstanding until they answer it.

That distinction always seemed important to me.

Not "integrate chat with a task-management system."

The message becomes the task.

Not "copy this useful answer into the knowledge base."

The message becomes knowledge.

Not "I hope James remembers that I asked him this."

The message becomes an unanswered question assigned to James.

That is a very different way of thinking about chat.

But ten years ago, building all of this properly would have been a serious project. Authentication, realtime messaging, notifications, search, storage, permissions, tasks, knowledge management, mobile support, infrastructure, integrations, and then maintaining the whole thing forever.

So Vigor remained one of those ideas I occasionally thought about and never built.

Years passed.

Slack kept slacking.

Sorry. I had to.

To be fair, Slack evolved enormously.

It has apps, bots, workflows, reminders, Lists, AI summaries, translation and a huge integration ecosystem now. You can turn messages into tasks. You can automate actions. You can connect it to almost anything.

But that is also part of what still bothers me.

The basic model is still: here is your messenger, and then here are all the other systems you need to connect to it.

You have Slack.

Then project management.

Then a CRM.

Then a knowledge base.

Then automation.

Then your calendar.

Then email.

Then another app that connects Slack to your project-management app.

Then a workflow that takes something from the CRM and posts it into Slack.

Then another workflow that takes something somebody posted in Slack and puts it back into the CRM.

Eventually you have built a very sophisticated machine for transporting information between systems.

I always wanted the information to already be in the system where the work happens.

Recently I was building an internal tool for managing RightTech.

It wasn't supposed to be a messenger.

The goal was simply to stop running the business across so many disconnected systems.

So the tool gradually ended up covering requests, tasks, quotes, our knowledge base, CRM, mail, calendar and, eventually, chat.

At that point I realised I could finally build the messenger I wanted ten years ago.

Except now it wasn't really a messenger at all.

It was chat inside the same system where the rest of the work already lived.

And that turned out to be much more interesting.

Because if chat lives inside the same system as your tasks, CRM, knowledge base, requests, quotes, email and calendar, you don't really need integrations between them.

They are already connected.

More importantly, the conversations don't have to float around separately from the thing you are actually discussing.

Every request can have its own chat.

Every task can have its own chat.

Every quote can have its own chat.

Even a knowledge-base article can have a conversation attached to it.

That sounds almost trivial, but it fixes something that annoys me constantly in conventional messaging software: losing the connection between what you are discussing and where the discussion happened.

Imagine somebody writes in Slack:

"Can we increase the scope of the Smith quote to include the mobile app?"

Six weeks later, somebody opens the quote.

Where is that conversation?

Search Slack.

Which channel was it in?

Was it in a thread?

Was the customer's surname spelled correctly?

Did somebody discuss it privately afterwards?

Now compare that with opening the quote and seeing the conversation about that quote sitting right there.

The same applies to tasks.

Instead of having a task in one application and a Slack thread discussing the task somewhere else, the conversation belongs to the task.

When the task is finished six months later and somebody wants to understand why a particular decision was made, the context hasn't disappeared into chat history.

It is still attached to the work.

Email becomes much more useful this way too.

I can receive an email, click once, and start an internal chat about that exact email.

No forwarding it to somebody with "thoughts?"

No copying bits of it into Slack.

No screenshot.

No trying to explain which email I'm talking about.

The original email is the context for the conversation.

That's the model I wanted all along.

Not chat as a separate destination.

Chat as the discussion layer around everything else.

Once I had that, I added basically everything I had ever wanted on an individual message too.

One click on any message and I can react, reply, forward or pin it. I can save it as a topic to discuss later. I can create a sub-chat around it. I can save it to the knowledge base. I can create a task, create a todo for myself, assign a todo to somebody else, or create a question for a specific person.

The difference sounds small until you start using it.

Someone writes, "Can you check why this customer hasn't paid?"

Click. Task.

The original message, sender and conversation are already attached.

Someone asks, "Do we still support this old API?"

Click. Question.

It stays visible as an unanswered question instead of quietly disappearing into another few hundred messages.

Someone writes a really good explanation of how one of our systems works.

Click. Knowledge base.

Done.

And then, if we need to discuss or refine that knowledge-base article later, the discussion can live with the article itself.

No copying. No opening another application. No trying to remember where the information came from six months later.

And once I was already building the chat myself, I started fixing all the other little annoyances too.

Before sending a message, I can use AI to proofread it in three different ways. Or I can proofread and send in one click.

If I write in another language, the proofreading can automatically translate it to English at the same time.

Popup alerts don't just tell me that six messages arrived. AI summarises what those six messages are actually about.

Markdown tables are recognised automatically and rendered as proper tables. If I want to work with the data instead of just reading it, I can open the table as a spreadsheet with one click.

There are normal emojis, stickers and attachments, of course.

But sometimes you need to send something that really should not sit permanently in message history.

A password. A temporary credential. Sensitive customer information.

So sensitive messages can be encrypted and given a limited TTL. Once that time expires, they are gone.

None of these features is individually revolutionary.

That is almost the point.

They are just things I kept wishing the software would do.

For years, the answer to that kind of frustration was always something like, "Maybe there is a plugin."

Or, "You can probably automate it with Zapier."

Or, "Install this Slack app."

Or, "Maybe the vendor will add it eventually."

And that made complete sense when software was expensive to build.

General-purpose products have to work for millions of companies.

Your business doesn't.

Slack has to design a task feature that makes sense for an advertising agency, a hospital, a software company, an accountant and a 50,000-person multinational.

My internal software has to make sense for RightTech.

That is a much easier problem.

And this is the part of AI that I think people are still underestimating.

AI isn't only making existing software slightly cleverer.

It is making our tolerance for software that doesn't fit us properly much lower.

Ten years ago I had an idea called Vigor.

To build it properly, I probably would have needed to turn it into a startup. Build a team. Spend a year or two on it. Work out how to sell it. Compete with Slack, Teams and everyone else.

Today I can take the useful part of that idea and put it directly into the software my company already uses.

I don't need a million customers.

I need a handful of people to find it useful every day.

That completely changes the economics of software.

And, perhaps more importantly, it changes the psychology.

For most of the software era, we trained ourselves to adapt our businesses to applications.

The button isn't there.

The workflow doesn't quite fit.

The information is in the wrong place.

The conversation about the work lives somewhere completely different from the work itself.

The software needs seven clicks to do something that should take one.

That's just how the product works.

You get used to it.

I think AI gives us permission to stop getting used to it.

If something in your workflow annoys you every single day, write down what you actually wish happened.

Not which SaaS product comes closest.

Not which integration might connect two products.

Not which plugin has 60% of the functionality.

What should actually happen?

"When somebody sends me a request, I should be able to turn it into assigned work with one click."

Build that.

"When we're discussing a task, that conversation should live with the task forever."

Build that.

"When an email needs an internal discussion, I should be able to start one without forwarding or copying anything."

Build that.

"When somebody answers an important technical question, I should be able to preserve it as company knowledge without copying anything."

Build that.

"When somebody sends sensitive information, it should disappear automatically tomorrow."

Build that.

"When somebody asks me a question, the system shouldn't let that question disappear until I answer it."

Build that.

This is the really empowering part of where software is going.

You no longer have to wait for a product manager at a billion-dollar software company to decide that your problem is important enough to put on their roadmap.

You don't have to rearrange the way your company works because some SaaS product was designed for the average customer.

And you don't necessarily need to create a startup just because you want better software.

You can build the thing that fits your business.

The interesting question is no longer:

"Which software supports our workflow?"

It is increasingly:

"Why doesn't our software work exactly the way we work?"

Ten years ago that was mostly wishful thinking.

Today it is becoming a perfectly reasonable engineering question.

And I suspect the best business software of the next decade won't necessarily be the product with the biggest app marketplace.

It might be the software that doesn't need one.