Just chiming in here - that I believe this is a huge opportunity for Coda in order to place all workflow + knowledge in one tool.
Communications (Email, Slack, etc) and code/asset management (Github, AWS, Dropbox etc) can remain external and should have great interop with Coda.
There are missing features now in the areas of permissions, file attachment or external embedding, cross-doc syncing, markdown support etc, but most of these don’t concern me so much since they can be addressed in the future and there are a lot of benefits compared to the separate tool approach.
The scalability concerns are alarming though. My current layout puts each Project (Product) into its own doc, which could obviously grow to large numbers of rows. One of the main reasons I am looking for alternatives to things like Jira is the long delays between nearly all user actions. I think PM, CRM, and other workflow tools need to aim for text-editor like response times, to get out of the way of the real work. I can’t count the number of times I’ve spaced out while trying to do things in Jira.
Asana does this well and I’ve used tools in the past, like Hansoft, that were instant, and it really allowed me to enter a mental state of flow doing even PM work.
It’s possible there is some low hanging fruit for optimization, but the long delay times mentioned in this related thread, across various parts of the app, give me the sense fundamental architectural improvements are needed. This requires people that have a strong performance background and on an app this size, a big time investment.
Can any Codans comment on the goals here? My suggestion is that all mundane and common user actions - adding, removing, editing rows, editing doc content, should take less than a couple or few tenths of a second on a table with 1000 rows with 15 fields or so, or other similar complexity. Opening large docs should be under a second.
If Coda can do this, then the tool gets out of the way of interrupting the train of thought while jumping to Coda to update a task, enter something that needs to be done, get some info. This is super important.
@Johg_Ananda What’s this API limit? Is that even for Makers? A Maker can’t use the API on a doc that has combined more than 2000 rows? Would you recommend that a single Product that contains things like PM (backlog, dashboard, sprint-like stuff), Policy, Procedures, Visual Design, Technical Design, Meeting notes - be broken into a separate doc for each of those areas (as an example)? Even then - just the PM doc would eventually surpass 2000 rows even on a smaller project.