Coda as a Product Management Tool

Hi all,

I’ve been using Coda with my development team for about a month now. As you can imagine we have a master table of tasks that are related to specific stories we are working on.

As the task list grows (and the team) is there a best practice to handle this growing database of tasks? We also have other master tables that are quickly growing.

To note, we often work quarter to quarter, perhaps to keep things lighter we could duplicate the Coda doc at beginning of each quarter and start afresh while keeping all the neat little tools we’ve create within the doc.

Any thoughts on this would help a great deal.

Best,
Nat

Disclaimer: I’m not on Coda team; perhaps someone from the team will chime in with better suggestions.

I don’t think it’s a problem if you have a large master table. In fact, it’s better to have one big table than try to shard it. Unless you need to make lots of changes to the rows that are quite old and have lots of rows depending on those rows (and hence would incur costly recalculations), that is.

My advice would be to:

  • Structure the data in such way that new data won’t depend on old data
  • Structure lookups and aggregation in such fashion that value changes will not require calculations on the whole table
  • Hide the master table away (e.g. in a separate folder where Coda doc users won’t need to look), and instead use Views to project your data. You can then filter those views to show only the relevant subset at any time.

However, if you don’t need historical data that often, making doc copies quarter to quarter is also a viable solution.

Wondering what Coda team’s input would be on this.

1 Like

These are great suggestions @Paul_Danyliuk! To get to the crux of your question @Nathaniel_Daudrich, is performance of the doc something that may be a concern as the master tables grow? If it’s just a matter of tables getting too “big,” as Paul suggested tucking away the master tables in a “Do not touch” folder is a good first step to preventing teammates from poking around the master tables.

We recently announced performance improvements which may be worth checking out if you are interested in optimizing your doc. These tips are some practical ways of making your doc quicker as your doc grows.

Hi both,

Thanks for the excellent advice.

I have been following these practices up until now. And for now the performance has been good.

Thanks @Al_Chen_Coda for pointing me back to the performance improvements doc.

Have a good one,
Nat

1 Like

@Nathaniel_Daudrich good information and let me explore the product