Step 1: The Fundamental Tradeoff
The first step in deciding to build your own collaboration software is the standard tradeoff – what else won’t my team be able to deliver while we’re building collaborative features?
If you’ve got customers and a core product offering, you’ve certainly also got a product roadmap. Those customers want the features that they’re already paying you for. And they want more, new, better features, too. What features are you willing to put on hold while rolling out collaboration?
For many teams, this is the end of the conversation. Collaboration is a great set of add-on features, but clearly not the core product and clearly not the main focus of the product team. But this is a blog post about building it yourself, so let’s assume that from here forward you’ve done the tradeoff calculation and it’s definitely time to build it yourself.
Step 2: Pick your team
Building good collaboration actually starts with team selection. Let’s talk about the roster you’ll need to build good collaboration.
Who is your designer?
The hidden super power in teams at Figma, Facebook, and pretty much every team that builds great collaborative software is… drum roll please… Design! Oh yes. Turns out all those slick collaborative affordances like typing indicators and read receipts… yeah, those features require many, many passes of design iteration. Never in the history of the interactive internet has a company thrown the dart straight at the bullseye on the first pass. When I was working on Facebook’s Timeline feature, we went through 17 iterations of the product before we ever even shipped it to end users. We had massive design support the entire way. Our designer was literally embedded in the engineering team working right alongside the frontend engineers, backed engineers, and product manager. And it still took the better part of a year to get it right.
Your designer needs to know all the common patterns of collaboration out there right now. Users are smart and use lots of software already. The collaborative features you’re going to build for yourself have to adhere to all the same conventions. People know what chat messages look like. What reactions are. They know what replies look like. Your designer has to be able to design to the collective understanding of what collaboration looks like to your existing users. You don’t have much room to get creative or invent new design patterns. And don’t forget about real-time presence – who is on this page with me? Who is active somewhere else in the product? Users already know what to expect for things like this – your designer has to be ready to bring your product design into that existing shared understanding.
Who is your frontend engineer?
One of the most lynchpin members of your collaborative project team is your frontend engineer. You might even need two of them. This person will have to know your frontend product codebase well enough to extend the core UIs. This means they’ll need access to all the repositories of your application’s frontend. Maybe that’s just one repo… or maybe it’s a lot more than that. Good collaborative features are consistently available across your product, so cross-product remit is table stakes.
With access to everything and with the freedom to make significant changes to the application frontend, your UI engineer is off to the races. This engineer will have to work tightly with a server-side engineer to build the chat/commenting UIs using an agreed data model (more on this below). They’ll definitely have to implement some sort of client-side text editor. All good collaboration hinges on verbal communication of some sort. The days where a <textarea /> would pass as a user text input are loooong gone. People expect a message composer, which is a significant frontend task. Companies like Twitter and Facebook have entire teams devoted just to the message composer.
In addition to the basic stuff like rendering chat messages, accepting chat message input, and image thumbnails – the very minimum for some sort of collaborative features – your frontend engineer will also have to implement the client-side aspects of the operations work detailed below. This means WebSocket code (or an HTTP-only equivalent). They’ll also have to build the client side application state management for things like new messages that come in hot off the wire. And if you’re taking collaboration seriously, they’ll have to go a lot further than that. Real-time presence information requires a lot of thoughtful UI work, both in terms of client side state management and in terms of pixels‑on‑screen.
Your frontend engineer needs to work really closely with your designer. Getting this stuff right on the first pass is basically impossible. At least not a single tech company in living memory has built good collaboration on the first pass. So, think about it as a few quarters of investment for the team described so far.
Who is your operations engineer?
To build decent, modern collaboration, you need real-time infrastructure. If you don’t have a WebSocket open, you’re not really doing the thing. So you’re going to need an operations-savvy engineer to run your collaborative infrastructure. They’re going to have to sort out things like: deploying updates to your socket server while users are connected, load balancing socket connections, database locality, and so many other tasty operations challenges that come with real-time infrastructure. Your engineer will have access to all the repos and configuration and deployment infrastructure required to do all of this.
But maybe you don’t have an ops person. I mean, you could skip this and just do standard web development and just wait until the user refreshes the page to see new chat messages or page annotations or whatever collaboration affordances you’re building. You could. But your collaborative features won’t succeed if you do that. We’ve all used software that has half-finished comment boxes at the bottom of a key interface. We’ve used the software and not used the B-grade collaborative features.
It’s not just because we’re spoiled users. I mean, don’t get me wrong – we are spoiled users. We know what good collaboration feels like and we don’t want the cheap stuff any more. But that’s actually not the reason your collaborative features will fail without real-time infrastructure. The real reason is that you must build notifications. If you don’t build the infrastructure to pull people back into your product, the majority of the comments people leave will go unread. The questions will go unanswered. It only takes one or two unanswered chat messages before users stop believing in the collaboration. So, your operations engineer also needs to stay on top of email notifications at least. Ideally Slack notifications, too.
Who is your server-side engineer?
As I said in the last paragraph, you need for your users to be able to get back into your product from a notification. Nothing will kill user trust faster than getting a notification that doesn’t contain a link directly back to exactly where they should be taken. If you aren’t deep linking to your collaborative content, you’re not doing the thing. You need a server-side engineer who is able to sort out things like deep linking. Deep linking is actually a two-part problem. You have to deep link to the content and to the conversation. Your server-side engineer is going to have to sort out both of these things together. Otherwise users won’t understand where they’ve been taken to when they click a link.
But your server-side engineer isn’t done yet. This intrepid engineer has a much more daunting task to take on: data modelling. Building collaboration means dealing with human communication. Human communication on the internet has come a looong way in the last ten years. People expect every text box to support emojis, auto-linking, text formatting, file attachments, image uploads. When you build your own collaboration, it’s table stakes to have these things.
Turns out the infrastructure part is pretty tractable. I mean, assuming your operations engineer has some bandwidth to sort out things like S3 bucket URL signing and cross-domain image loading security. With the actual file handling sorted out, your backend engineer has to decide how to model the data of your collaboration. Even if you just go for basic chat, you have to decide how you’re going to structure the chat message data. A JSON tree? An array of text nodes? Plain text with magic strings in it? There’s lots of ways to solve this problem and they all come with tradeoffs and limitations. Your server-side engineer is going to have to be on top of these in order to build even basic chat.
The above is table stakes for data modelling of chat messages. But… if you want to build really useful collaboration, you also need Presence (i.e. who is on this page with me, who has been here before). Presence is constantly changing and requires real-time updates, too. Time to add some sort of server-side pub-sub system to the TODO-list for your operations engineer. Your server-side engineer is going to have to come up with a client-side communication mechanism for keeping all this stuff up-to-date, too.
Oh – and make sure that your engineer correctly handles things like multiple open browser windows and multiple browser tabs. It’s pretty easy to accidentally DOS yourself if two browsers are fighting to prove to the server who really has the user’s attention.
Who is your product manager / product lead?
Before I wrap up the team selection, we need to talk about the most important character in the story: the product lead. You can go pretty far with only a designer and a motivated frontend engineer, but you likely won’t build useful collaborative software. The reason for this is that collaboration is rooted in the actual human interaction. Coworkers trying to solve a problem together. A manager and their report discussing a project. Whatever your users do. This brings in all the complexity and nuance of human interaction. But you’re also working in an existing product. What features of that product are sufficiently complex or sufficiently multiplayer such that they need to become collaborative? That’s a tough product call that requires a very high level of decision making power and context.
Likewise, there are quite a few very tough tradeoffs you need to consider to build good collaboration. You need notification channels for it to even get off the ground. But… uh… what are you going to put into those emails or Slack messages? The title of the page? The text of the message from one user to their team? How about a screenshot of the page? That’s super handy for the user. It’s also an absurdly hard frontend coding problem. Just the browser security model alone makes it a 10/10 frontend challenge. But what about the content of that screenshot? Is it safe to fire it off as a slack message or email? What if someone wants to send it to someone who isn’t paying for your software? Do you still disclose details from within your product? How do you handle people landing on your login page when they click the link but have no way to actually get to the content? Or do you leave that feature out completely and dramatically decrease the utility of collaborative features?
Your product lead is going to have to wrestle with these kinds of questions and many more. Even more importantly, your product lead is going to have to keep an eye on your existing product roadmap and decide what else the team won’t build while they’re focused on collaboration. Do you invest the time in rich text formatting? What about @-mentions? Reactions? Where do you draw the line between valuable collaborative features that enrich the product experience vs. adding bread-and-butter value for the users in terms of core product features. Tough calls must be made here.
Next Step: Build It!
Now that you’ve got your all star team assembled, let’s talk through what it takes to actually build your collaborative features. Click here for Part 2 of this series!