Why is collaboration effective in some tools and not in others?

A framework for evaluating the effectiveness of collaboration in workflow tools.

Introduction

The recent years have seen a proliferation of products addressing functional jobs to be done within organizations. Since most work is not done independently, collaboration features are a fixture of these products. Some examples of functionally-specific products with collaboration built-in are Figma for design or PagerDuty for incident response. We find that products incorporate collaboration with varying levels of effectiveness. For example, Figma's multiplayer functionality enables designers, engineers, and other cross-functional stakeholders to collaborate seamlessly and richly around a design. On the contrary, other products' collaboration features are high friction to use, do not provide functional-workflow specific nuances, and feel bolted on as an afterthought.

One way to evaluate feature effectiveness is to analyze qualitative (user research) and quantitative (retention and usage metrics) signals post-release. However, it's difficult to gain a point of view on which collaboration features will be effective ahead of time. This post provides a simple, straightforward framework to evaluate the effectiveness of collaboration tools, and is addressed towards builders and investors focused on functional products.

In summary, we conclude that effective functional collaboration meets the following five criteria:

• No context-switching required for collaboration
• Atomic unit of work
• Unique collaboration vectors
• Real-time or greatly reduced waiting time between collaboration points
• Accommodates relevant stakeholders

How is the functional workflow under-addressed by incumbent collaboration tools?

Without collaboration features in functional workflows, users default to horizontal tools like Slack and email. These tools serve as a "catch-all" for collaboration use cases that are not addressed by functional workflow tools. This concept of the productivity meta-layer is previously discussed in Julian Lehr’s Superhuman & the Productivity Meta-Layer and Kevin Kwok's The Arc of Collaboration.

One way to uncover opportunities to build native collaboration features is to examine pain points that arise when horizontal collaboration tools are used for functional workflows.

Consider a situation where designers collaborate on a design file attached to an email thread. The individual contributor sends an email with the image attached to her design colleague, who opens up the file in an image editor. The colleague might make suggestions before sending the revised file back via email, typing up feedback in the email message. The designer opens up the file in an image editor and modifies the image according to feedback, and sends the updated image to their colleague, and so on and so forth until the image is finalized.

At first glance, the described workflow and incumbent solution are painful. Let's dig deeper to examine why:

• Context switching — creation occurs in the image editor, collaboration occurs via email. Both the individual contributor and the colleague must context switch between these two tools in the course of their workflow. The colleague thrashes between the image editor and the email as she looks at the design and gives comments. Similarly, the individual contributor goes back and forth between the two tools as she bakes the colleague's feedback into her designs. Context switching is expensive and taxing because one must remember information from one tool and apply it in another.
• Collaboration is not over an atomic unit of creation — it’s difficult to reference individual pixels and objects within the design when writing email feedback. Another way to frame this is that the collaboration is not over the atomic unit of creation in the workflow.
• Lack of expressive collaboration vectors — consider two designers collaborating together, in person, using a physical whiteboard. These designers will likely engage in complex collaborative actions; they might collaboratively sketch out designs, erase and modify each other's work or annotate the designs with sticky notes. When collaboration is limited to words on an email thread, there's a lot of richness that's lost.
• Non-real-time — in-person collaboration involves real-time, synchronous communication allowing for rapid iteration/team progress. Email doesn't provide for that — once an email is shot off, the other party must wait for a response.
• Doesn't accommodate all stakeholders/collaborators — in an ideal design process, there are cross-functional stakeholders like product managers, engineers and sales reps who should be involved. This workflow doesn't serve those cross-functional stakeholders well — for example, other stakeholders might not have the appropriate tool installed to open the files, or might want to be involved at different levels of granularity. As a consequence, these stakeholders are often left out of the workflow. We learned about this point from Why Figma Wins.

Applying the framework

We've identified pain-points that arise when functional collaboration work occurs on horizontal collaboration platforms. Another way to look at these pain points is that they serve as a framework for what a good solution should address. Next, we apply this framework to successful collaboration tools across a variety of verticals to see how they fare. The four tools we go over are as follows:

• Figma — a vector graphics prototyping tool for designers and their collaborators.
• Github — a productivity tool for engineers that helps with version control/source code management, testing, and deployment, amongst other workflows.
• Front — a universal inbox for individuals within a company to collaborate on interactions with external stakeholders like clients and partners.
• PagerDuty — a tool to manage IT incidents.

In conclusion, we created a framework that allows investors and operators to judge how effective a collaboration solution is. These are not hard and fast rules; they are neither necessary nor sufficient conditions for eventual business success. However, we believe that most successful "household" collaboration tools exhibit the majority of these traits.

George and Momo are operators and investors that are interested in thinking and learning more about how software products can improve workplace productivity. If you are building or thinking about building functional workflow products with a collaboration element, please reach out on Twitter at @g_xing and @momoeureka.