Ben Thompson interviews Shishir Mehrotra of Coda — I have Thoughts

Ben Thompson had a great interview (paywall) with Shishir Mehrotra, former VP of YouTube and current CEO at Coda. It touched on a bunch of topics that are near and dear to my heart (bundling, universal documents, Microsoft Office) and I had to add some commentary.

I’ll try to do a little better on the TL; DR front. Key points:

• In a discussion on bundling, Ben asks his recurring question of why has no one come up with a competitive productivity services bundle to Office 365? I offered an answer a while back in Office365 — Complexity and Strategy. To summarize, despite hand-waving around services-oriented-architecture or examples of surface-level integration between services, integrating services deeply is really, really hard. It’s significantly harder than integrating local applications like Word or Excel, which itself took decades of hard technical and organizational work. Basically, there is a deep moat of complexity around this market. I recognize this can be a frustrating argument because much of the complexity is hidden (although I give plenty of examples in the linked post) and one can try to argue “Can’t I just walk away from all this complexity? Isn’t this Microsoft just making things too complicated?”. This is the nature of moats — you’re always arguing what really fills the moat and how deep it is. The only thing that’s hard to argue with are the profits.
• Although Shishir talks about the “universal” aspects of Coda documents, I would claim that they are pretty clearly focused on a very rich and mature application market of business process automation tools. This is what Lotus Notes, Microsoft Access, and SharePoint (and related tools such as InfoPath) have long been focused on. And of course Trello, Jira, etc. Coda takes a very document-centric focus to this which offers good opportunity for differentiation from these other tools. They also built with a modern cloud architecture so naturally you have co-authoring, sharing and other social capabilities baked in.
• Coda’s gallery is a great idea but I’m not sure how profoundly innovative it is. Notes had its “nifty fifty” application templates and virtually every Microsoft Access application is built by starting from its heavily used template library. Every application that allows the creation of complex artifacts provides a rich “New from Template” experience.
• To the extent that Coda doubles-down on the “universal” aspects of their document canvas, they are going to run into two deep and related challenges that I discussed in The Math of Easy to Use and Containers are Hard. The richer you make any application data model, the harder it is to map any user gesture into a clear user intent and then to map that intent into a change in that richer data model. There are design strategies to mitigate, but the challenge is fundamental and faced by every application. Richer applications get harder to use. This makes them less appealing than a more limited (focused) application if you start with a focused intent.
• Additionally, as you try to bundle more capabilities into a single app (“container”), you inevitably run into the issues I discussed in Containers are Hard. In order to make it easier to add new capabilities, you want to reduce the requirements the container imposes on its contained primitives. But as you try to create a more integrated and consistent experience, you inevitably increase the requirements and depth of integration between the container and its primitives. This tension is inevitable. Additionally, as the primitives themselves interact (e.g. in Coda, when you want to allow a single data field in a table to be a rich container surface) complexity (both in implementation and user experience) starts to increase much faster than linear to the increase in capability. This makes it harder and harder to add new primitives over time as well as harder to add consistent new capabilities across all primitives. This is just the math of complexity — the only real mitigation is to be careful about exploding the set of low-value primitives early. They will only make all future development harder.
• Ben and Shishir start their discussion about Coda by asking an intriguing question. Why has the set of document types been frozen into the big three of word processing, spreadsheets and presentations? Is this just historical contingency (see Wonderful Life by Steven J Gould)? Or is there some deeper reason? Shishir has a very strong motivation to understand, since Coda is introducing a new document type.
• In fact, I would argue that we live in a golden age of document types (Cambrian explosion?). Practically every new Internet service defines a new document type. I just spent a couple years building a very specific document type that lets you build a redistricting plan for your state or locality. It serves as an interesting counterpoint to Coda’s more “universal” ambitions. The advantage of a very specific focus is that you can provide an approachable “easy-to-use” experience for what is actually a rather complex and technical activity. We have had both complete novices build valid, interesting plans as well as long-time professionals in the field sit down and build plans from scratch for the first time on their own because it is so easy. The point isn’t that we did something profound, the point is we did something obvious. The features did not make it easy to use, the lack of features did.
• Small nit — Ben and Shishir’s discussion of OpenDoc was a little confused. OpenDoc was really independent of Apple’s productivity applications Numbers, Pages and Keynote. Like OLE, it was created at a time people believed that these component models would be the future of application development. That effort was a dead end, in no small part because of the issues I discussed above.