Can Coda bridge the gap from doc to app for good?

Posted on 5 mins read

Are we on the edge of a new paradigm for how we work together?

tl;dr: Coda is an innovative challenge to the status quo of workplace productivity and communication tools. As a “document” that can pull together live data and communication tools it offers something maybe lacking in our shift to hybrid and remote work. There’s something here worth exploring.

Are we seeing a paradigm shift beyond the office tools?

In a recent Stratechery interview, Coda founder Shishir Mehrotra describes Coda’s mission to redefine what the “document” is… and bridge the gaps toward us all building apps that start as documents.

Coda is a hybrid mix of a whole stack of things we work with

  • A document
  • A table/spreadsheet
  • Live connections in and out
  • Fully collaborative – across and even outside of the team

The “documentation stack”?

A key premise – organisations have a communication stack (Slack, email, etc) and a documentation stack (docs, spreadsheets)… but due to the latter being frozen in time – no real innovation in years – it’s time to double-down on, and extend the documentation stack.

we focus on the documentation stack, and actually the better that is, the less you use your communication stack, which is a good thing

Coda isn’t alone

Coda is one of several tools competing to be the new “one app to rule them all”. Three leading ones include:

  • Coda: the doc becomes an app
    • “Coda is a doc you’ll never outgrow.”
    • “One doc for all. And all in one doc.”
    • Start with a doc
    • Docs become templates that can be copied
    • Data/behaviour comes in via “Packs” (in from Google Calendar, Salesforce/HubSpot, Jira, out to Slack)
  • Notion – Confluence, but better?
    • The page/doc is central here too
    • “One workspace. Every team. We’re more than a doc. Or a table. Customize Notion to work the way you do.”
    • “Make Notion the central nervous system for all your tools. Automatically update other apps, take actions, and keep information consistent so you can work more efficiently.”
    • Lots of integrations that look and feel a lot like Coda… but from a play, it feels much less “app-like”
  • Airtable – the table that unifies everything
    • “Accelerate work and unlock potential with powerful apps that connect your data, workflows and teams”
    • starts with “table” as central concept…
    • far more app-like than the other two

For all of these…

  • Collaboration and sharing are a given
  • Data flows in, and, around are incredible – and can be augmented/extended with the integration platforms
  • They are a genuine threat/alternative to the low-code app tools – i.e. they have the potential to replace many of the standalone doc and/or spreadsheet tools that drive our businesses
  • They’re starting with small teams and trying to work their way up into “the enterprise” (more on this below).

Examples – Coda in action

It’s worth trying to see what this really looks like. Some case studies about Coda… available as Coda docs:

Some questions it prompts for me

💭 Has the move to hybrid work changed the game?

With teams now staying online/remote we need new tools and services to replace many of the physical artefacts that surrounded our teams. Tools like Miro have gone some way to bridging the gap but struggle to create the virtual “home” that many teams are searching for.

💭 Does Coda need to become a new doc ‘standard’ to work? to win?

Mehrotra breaks down apps into three types:

  1. Single player - 
  2. Multiplayer - ok for one, best when shared, value increases when more and more people use it
  3. All-player – Only really makes sense if the whole org is uses it… and not one where you want to have different teams using different tools

The assertion from Mehrotra is that Coda is in that middle category (multiplayer) – there’s value for just a single team; more value as it expands across the organisation and between organisations.

💭 Is there a certain type of environment where Coda can work, and another where it would just create more pain?

The examples above are all high-growth tech companies; all startups.

  • Should we use it just in our product/tech teams?
  • Is it ok for just a single team to use it?
  • Are we just too (something) for it to work?

I imagine there are some environments where it would be a real stretch, where the fluidity/informality would an issue.

Where to from here?

Coda is realistic about the way they can get into larger enterprises. They can’t go head-to-head with Microsoft Office or Google Docs. They don’t want to present themselves as an “all-player” (i.e. all or nothing) for all employees.

In a larger company… the question is: what enables a team in a company to experiment with tools without inviting SaaS sprawl?

It should surely be possible to imagine a legitimate/endorsed path to doing this without violating security, blowing budgets, etc.

Some suggestions

  1. Set up a lightweight program to support experimentation
  2. Do the initial due diligence on a couple of these platforms
  3. Try to figure out a way to build some rules of experimentation
    1. What data is appropriate to be used? e.g. yes to OKRs, no to customer PII, maybe to sales data.
    2. What integration patterns are supported (e.g. out-of-the-box integrations) and how?
    3. What is the minimum level of rigour – documentation and support?
    4. Work out how to support discovery of what exists – i.e. to not end up with 15 different OKR tools
  4. Build in cycles for reflection.

Coda and friends seem to offer a way to provide a huge productivity and collaboration to the company with rapid cycles of citizen-developed tools.

It’s really unclear whether the bold visions of the founders (i.e. replacing the MS Office/Google Docs paradigms) will be successful. Despite this, they seem to offer too much potential upside to be ignored.

I think it’s worth (purposefully, intentionally) going for it!