Hi, I'm Phil Freo

What makes a new feature or product update “done” versus what makes it “really done”? At  Close.io we developed our own process to answer this question, based on years of shipping new features for our sales communication platform. Today, we want to share this checklist with you.

As soon as a new feature you’ve built is running and working on your development server, there’s a strong temptation to think it’s “done”. You want to ship it. After all, the code is working, and you know many of your users would benefit immediately from the change.

It’s important to stop and ask yourself: What else should we do other than just making a new feature functional? How can I improve the experience for users or make this feature more accessible and maintainable?

We’ve learned that when you’ve only gotten a feature working, you are at most “80% done” and that the last 20% really makes all the difference. In fact, sometimes the “last 20%” of polishing a feature can take just as long to get right as the “first 80%”, however it also is what separates good from great.

Here’s our internal checklist that we use before launching significant new features or changes. Whether for launching a new reporting feature or migrating our database to a different cluster, we’ve found this list to be really helpful.

Performance

• Is it fast?
• Are the database queries optimized?
• Will it scale for a large number of records?

Code quality

• Is the code cleaned up, organized, and properly abstracted?
• Is it well commented / documented? Assume someone else will have to maintain it.
• Are there relevant unit tests?

Edge cases

• Do you consider and properly handle edge cases and invalid inputs?
• Did you test the first time experience / no-data-yet case?
• Is it localized? Consider timezones for anything date specific, and unicode.
• Did you test in all the supported browsers / platforms?
• Have you tested for potential security vulnerabilities?

Polish

• Does the UI look polished? Is it consistent or better than the rest of your application?
• Does the UI react to various edge cases properly?
• Is any written text as good as it can be? Did you check for typos?

Deployment

• Does it need any special deployment process, and is the process well documented? Any data or schema migrations necessary?
• Is everything backwards compatible? If not, did you communicate the change to users?
• Should it be deployed/visible to employees only to dogfood/test for a while?

Communication

• Are the relevant API docs complete?
• Do any FAQ docs need to be updated or written?
• Did you write a blog post announcement, if appropriate?

There you have it. Run through this list before shipping something new and you’re guaranteed to have a better launch.

Do you have anything to add to the list? Let me know!