There’s more than one way to skin the cat but some ways tend to work slightly better than others. I’ll share a voice recording from a few years ago that I recorded to share a new feature (at the time): Checklists.

This was the very first recording that captured the idea and high level thoughts about this feature (which has now been in production for many years).

Typical Steps

• Record Voice Memo to capture initial thoughts about the new enhancement, feature or app/service.
• The number of such memos varies, ranging from a singular one for minor enhancements to tens of them for more complex features (or new apps/services altogether).
• Share memos with relevant team members (first, Product, then, Development).
• Meet with stakeholders quickly to get their feedback and iron out some details.
• Team starts to work on an initial version(s) making necessary assumptions.
• Team sets up time for a demo to collect initial feedback (this is an iterative effort).
• Work continues till it is completed (we keep most changes scoped to weeks, not months).
• A close-enough to Production version is deployed to lower environments for additional feedback and testing.
• Bugs are fixed, necessary code refactoring is done along with other polishing, where needed.
• New feature is pushed to production!

We have a number of products (B2B/B2C) and most, if not all, of them went through a process that isn’t very different from what I’ve shared above. Does it work? The proof is in the pudding, as they say, and the proof is in all our products that are in production & used by thousands of customers.

Checklist Feature

Check out the checklist functionality discussed above. It is implemented on our Mobile Apps as well.

Transcript

Hey there, I want to document the the next requirement. I know we've started doing custom forms But we've taken a Taking a break from it.

We've paused it momentarily at least so I think we need to Make a few changes and improvements or enhancements in lieu of that One of the things is checklist items.

Here's what I think we need to need we need to support a notion of checklist per For every block and pod maybe not necessary for for keys maybe you can add it for keys as well maybe there's not a if it doesn't hurt we should consider adding that for keys too but certainly for blocks and pods the relationship would be a single resource like a key block or pod can have any number of checklist any checklist can have

any number of checklist items right that's the relationship and you can add a checklist update the name of the checklist or more checklist and say more to check this the all of the checklist items will be removed as well similarly you can update add a checklist item update the title of the checklist item that that is it's more like a task but you can update the checklist item and delete or delete the checklist item

for now let's not worry about assigning checklists and all of that stuff we can deal with that later if you wanted to for now let's keep it as simple as possible and then I'm one of the places we could possibly render this shot would be right below comments on the web.

And yet we just have to think about a UI for mobile. I'm sure we can come up with something that's simple enough. So that's what we need to do. And in terms of security and authorization,

I don't think we, after when we still need to think about the teacher key and project key and students just to see if it brings any nuances, but I'll see you in a minute. comments or notes notes are private comments become part of what's shared and you collaborate your the collaborators also see your comments I think the checklist falls more in line with comments not not like notes they're not private to you so if

you share the block or the pod all your collaborators can see and modify or delete your checklist items right let's let's treat them the same way as though as how we would treat description for instance,

any other attribute. Now as far as project keys, console let me think, you create a, now before you go there, if you have right axis, even if you only have right axis on a block or a pod,

you can still delete checklist items, much like you can delete a description, so that's fine, you don't need admin axis. just to be clear and then when it comes to project keys let's say you share a project block it has a checklist and the permissioning is no different there but the part the project pod could also have checklist yeah and if the user has right access they can edit modify delete so maybe there is no

difference there we just have to be be, I'm not sure if I'm missing anything from a teacher key standpoint, but I think this probably should cover the basic use cases. Let's get started with implementing this.

And I think I did another wise move for due dates and due dates and stat date and end date. We can probably do them as part of the same PR or break it down,

but they are related items. We need to add stat date and end date to pods. and due date to blocks. If you did all of these and made these attributes hideable or at the resource level so users can choose to hide it or show all of them.

You can hide and show each one of them or you can hide and show all of them at the header level and when you hide all of them we will still show like the name.

attribute for instance. Maybe we'll still show some attributes, at least just the name, but we can hide all the other ones. If we supported the ability to show and hide and edit these attributes,

even short of supporting custom forms, which we probably will have to table for now, it's very complicated. Even though we made progress on the web, it's a lot to do. So, I think we should be in pretty good shape as far as customization.

of attribution is concerned. So that's basically it. Thanks.