What I learned from two years of building in the async collaboration space

We experimented with five different product iterations with Acapela and each experiment taught me something valuable about the async collaboration space.

I started Acapela with my co-founder Roland back in October 2020 when the world was heading towards another COVID lockdown. All the knowledge workers had been forced to work remotely from home and that was a huge mental stressor for most of us. We started Acapela with a vision to build a better asynchronous collaboration tool to make remote work more delightful. We learnt a lot about people’s working habits and culture by going through many product iterations within the following two years. Here I want to summarize the most important takeaways to inspire others builders in this space.

To give a little bit of context to each lesson, we went through five major product iterations during our two years of building Acapela. In chronological order they were:

• Stand-alone threaded platform for having asynchronous meetings to replace repetitive video calls with your colleagues.

• Automated meeting agenda builder that would always ping the creator and/or participator of the meeting to create an agenda and summary of a video call.

• Slack competitor for having all of your company’s collaboration in spaces and rooms always dedicated to a specific conversation.

• Collaborative todo-app for Slack which makes sure that every request you make on Slack is always assigned to someone in the channel.

• Unified inbox for all your notifications.

Our first product was meant to offer companies a better way how to replace unproductive meetings with async collaboration spaces. While our value prop seemed to resonate with users just like Kitkat, we failed to realize how our new tool would fit into the existing meeting culture and tooling.

Your product has to fit into the existing workflows of your users.

Our very first lesson learned about meetings was that every meeting is useful for at least one person in the room. Even when everyone always complains about how unproductive their meetings are (this meeting should have been an email) there is always at least one person in the room, for whom the meeting is very valuable. They probably did not figure out a better way to make a decision within the organization and this is why they scheduled a meeting to force action by the end of it. Most people in meetings might feel like their time is being misused, but sometimes they find themselves on the opposite side of the table where they are the ones organizing a meeting just to force action by having a 30-minute slot. By the end of it, you need to come up with a decision. In such a working culture you end up in a situation where everyone complains about how many unnecessary meetings they have, but in reality, they are happy to put up with them, because you never know when you need to force action using a 30-minute blocker in everyone’s calendar. For example, I remember talking to a head of product at a famous fintech company which is known for its highly efficient working culture. He showed me his calendar on our user research call and it became clear that he was spending 40+ hours in calls during his week. When I asked him about getting work done outside of the meetings and how productive he felt the calls were, he was very satisfied with his time usage and productivity. He was also not bothered about how the meetings were affecting his colleague’s work since in his view work was getting done. The first lesson learned is don’t trust what the user is complaining about. Check whether they are actually trying to solve the problem they complain about.

Even though everyone one complains about meetings, switching to async rooms did not get teams excited.

Lesson number two - your product has to fit into the existing tooling amazingly well or completely replace them. Whenever you start building a product it should be totally clear whether it will live next to existing tools (such as Slack in our case) or whether you intend it to be an addition to current tools. That will very strongly influence your product decisions and how nice you want to play without tools (to integrate or not). That’s also a part I often saw many future-of-work startups get wrong where they did not have a strong stance on this and the product ended up having some integrations into existing tools, but then also building their own sources of knowledge. We decided to build a tool that should replace Slack and not build any integrations. Our solution was clearly not solving a big enough problem to justify introducing an extra silo of knowledge within an organization while keeping Slack around. Also during user feedback calls for our collaborative todo app, it became very clear that users wanted their todos to live in Slack. People did not care about our fancy web app which we had put so much effort into building. Even though the web app and the Slack integrations worked in perfect sync, every user told us during user feedback how we could improve the Slack integration, not what was missing from the web. Most future-of-work startups in some way or another compete with Slack and they have to figure out whether they want to compete or complement. For example, threads.com clearly decided to compete whereas Loom went out of its way to make the Loom experience within Slack as smooth as possible.

We built a stunning collaborative todo app experience that nobody wanted. All they wanted was a better Slack experience.

The third lesson stuck with me from every product iteration we tried to push to the market - it is not possible to solve bad culture with better tooling. A lot of the problems were the result of bad company culture. Often, managers and founders try to make their teams more productive by introducing more tooling to keep up good habits, but this rarely works if the company itself is not already trying to walk the talk. I remember talking to a CEO of a fully remote company that had only one weekly recap call within the company. She was so deliberate about the work culture at their company and this single weekly call was a great testament to that. She immediately understood the problem we were trying to solve with our async meeting platform, but she just did not have any meetings to replace. Another example about tools not fixing cultural problems is from companies deciding to install Clockwise for more efficient meeting coordination. It will have very little effect internally if the company actually does not care about respecting other people’s focus time more than always scheduling calls to discuss problems. The same experience stuck with me with every product iteration we had. Forcing people to fill in meeting agendas with tooling did not work if there is no culture of preparing meetings ahead of time in the entire company. Asking employees to make their Slack messages more actionable by always tagging at least one responsible person also does not make the team more productive if there is no habit of always having at least one person responsible for every initiative. This lesson applies to both leaders, but also builders. If you want to make your teams more productive, start with culture. And for founders, if you are planning to build productivity tools, make sure you are targeting customers that are already taking action which your tool will just make ten times simpler for them.

Next lesson is a short one and mostly applies to unit economics - it is very hard to build a venture backed business building a single-player tool that has no virality nor network effects. There are two different concepts in network-based tools: virality and network effects. Virality means that using the tool in its normal way will attract more users to the product. A great example would be document editing or video call tools where using the tool will naturally introduce the tool to more people potential users since they are by default collaborative. Network effects play out in products where more users using the tool with in the same subatomic network increase the value of the tool for other users. Great examples are Slack and Tinder, where respectively your colleagues or single people living around you increase the value of the tool for you. If your product has neither, it will be extremely hard to make the unit economics work for a venture-scale business. Both virality and network effects make sure that your long-term cost of customer acquisition has a chance to stay below customer lifetime value. We noticed it very clearly when building our last product iteration - a unified inbox for all your work notifications. The tool was a single-player tool and we quickly realized that by only charging single users while having to attract new users via paid marketing had negative unit economics from the very beginning. You can obviously hope for crazy word of mouth growth since your product is so much better, but in my opinion that should be a given for any startup. The word of mouth growth will help your unit economics, but it will not fix it.

Acapela was inherently a single player tool and no amount of bright CTA invite buttons would have fixed our unit economics.

The last lesson is a somewhat more complex beast - we experienced that adding network effects to a product retroactively is extremely hard to pull off if it is not a natural part of the product. In the B2B SaaS space that often means trying to turn a single-player tool into a collaborative tool used within a team. Our unified notification inbox was quite naturally a single-player tool and due to unit economics we had to try to make the tool collaborative. We considered introducing shared inboxes, creating more value for the users by cross-referencing files from your colleagues notifications and creating stateful notifications (sent, received, confirmed, done), but all of those efforts were rather far-fetched. I am sure we would have figured out a way how to provide more value to the user in case their colleagues were also using the product but the initial product experience would have suffered and it was clearly another zero-to-one effort, not just incremental improvements. I see the same thing play out now with a number of other originally single-player tools (for example Raycast) and it will be very interesting to see how they manage to introduce multiplayer features into a product that was started as a single-player tool.

We had a very exciting journey with Acapela and I am still rather bullish on the asynchronous collaboration space. There were many hard lessons learnt trying to find PMF in this space. I am sure many companies will be built in this space and I hope our learnings will help future founders avoid some of those mistakes. If you are actively building a related product, please reach out and I would be happy to provide more insights into our journey and how you could learn from that.