I’m new to the community and recently read your post. While over a month since your request, offering my feedback in case it’s still helpful.
IMHO, hands down the best feature of the template gallery is the ability to demo before selecting a template. Instead of having to first create a new document, the user is provided a frictionless experience for determining whether a template meets the intended use case (i.e. try it, then save or discard). This is a superior approach!
Considering the templates themselves, the context for my feedback is as follows:
- I limited my examination to the eleven templates in the Project Management category, thinking these would be germane to nearly all businesses.
- While I’ve worked with many SMBs in my career, I tend to critique using an enterprise lens, assuming Coda’s GTM strategy will target organizations with more than a few hundred users.
There are a couple of templates that are creative gems, namely Meeting Timer and Simple Status Updates, which make the everyday tasks of running meetings and collecting status efficient and almost effortless. There is also good value to be found in the other templates, as well as some opportunities for improvement. Consider one example: Kanban project.
I realize a basic Kanban board has the three-step workflow you’re presenting, but the oversimplification and very thin sample data gave me the “slapped together” feeling. As the theme for the board is software development, in the next iteration you might consider expanding the swim lanes to include something like Develop, Test and Deploy. I also suggest creating a section at the top of the document to explain Kanban at a high level, and include a graphic representation of the physical Kanban card that you are modeling. Finally, since the goal of a Kanban system is to limit the amount of work in process so that work flowing through the system matches its capacity, demonstrating WIP limits through conditional formatting seems essential.
Stepping back to the forest view, I’m always more intrigued by templates which appear to contain real data. I’m not suggesting you expend the effort to create a fictional company à la MSFT’s Contoso (although you could evolve to something similar over time). Rather, since software development is a theme for many of these templates, a sanitization of a small portion of Coda’s own process steps and data would add a nice level of robustness.
I’ve saved the most important comment for last. This only applies if it is your intention to make Project Management a primary use case for Coda.
Collectively, the templates showcase powerful means of tracking and visualizing project status. In my experience, both as a program manager and working with others who are much smarter than I am, PMs and TPMs also need a method for measuring project velocity. For a software engineering project, measuring a team’s velocity is important to help understand what the team can build over a set period of time (e.g. a calendar quarter).
From my Google days, we used a bug tracking system to capture work for both resolving defects and building features. Since this is fairly standard practice, a TPM can use bugs fixed per time period as a proxy for velocity. Consider the illustration below, where the following three columns of data are imported once per week from a bug tracking system into a Coda table:
[# open P1 feature requests] [# open P1 defects] [# resolved P1 feature requests]
While this illustration is greatly simplified (e.g. a true velocity measurement would consider the size of each task), a weekly snapshot would enable a TPM to measure velocity over time and estimate a delivery date.
Apologies for this lengthy reply. Very much appreciate the team’s hard work and the opportunity to offer actionable feedback. Thank you!