Breaking up With a Term

Naming features may seem trivial, but it's definitely not an easy task. Getting the right name is hard but once you name a feature a certain way you end up with something that guides you in the future and affects your development decisions.

What we learned is that you should keep the name as generic as possible. Do that and it's likely the feature will remain simple as time goes by. For example, if you have something called "folder", there's not too much complexity to add and still be able to call it a folder. You may introduce a folder that shows content based on given criteria, but it's likely you will name that feature differently (Smart Folder for example).

On the other hand, name something a Kanban Board and you have to create a feature roadmap for several releases and great development effort just to be able to satisfy all the complexities this term brings to the table (swim lanes, capacity control, cross-project boards, full-screen mode with dark theme so it looks awesome on a TV in the dev room, and many more). Development complexities aside, by naming a feature Kanban Board you also got married to a particular methodology because your customer will expect you to continue development in that direction.

What specialized features do is that they lock down the potential of a feature to their own meaning. Generic terms can be a lot of things, but heavy, specialized terms usually mean only one thing (or two if you are lucky).

We learned this lesson when we liberated potential that was locked down by Milestones in Feather. Milestones are a general term but have a pretty specialized meaning when used in a project management setting. As such, they bring several implications to your workflow. I'll focus on major bad implications from ActiveCollab's history that proved to be limiting:

1. You use milestones for complex and long(ish) projects. There's no need for them in simple and straightforward projects so their utility is limited to big teams that work on big projects;
   
2. Milestones aren't disposable. They are important by definition, and therefore can't be trashed or canceled without a sense that you are doing something that should not be happening in the first place;
   
3. They lock tasks in. When a task is assigned to a milestone, an unwritten expectation has been set that task needs to be completed in the milestone's timeframe. If a task is not completed but needs to be moved to a different milestone, there's a sense that you're doing something that should not be happening;
   
4. Milestones need to have a date. If they don't, they are not milestones, but categories. You can either add a friction point where a date is required or make it optional and end up with a milestone that's not really a milestone.
   

Our team got so used to the term over the years that we never questioned it. When we discovered problems (like the need to have milestones without a date), we worked around it (we let users set milestone's due date "to be determined" even though it would never be determined because it wasn't needed) instead of fixing the name of the feature.

The name was finally challenged by a newcomer to our team who had a fresh perspective and wasn't attached to any name or feature in the software. Once that happened, things started to unfold really fast and milestones got replaced with a more general name - task lists. This enabled some really nice improvements to the Tasks tab (that we'll discuss in the next post), lifted off constraints from labels and made ActiveCollab task management less rigorous (and therefore more likely to be used by people who are not hard-core project managers).

Takeaway

They are instruments by which users understand how your software works on one side and can drive their expectations and future development on the other. As such, you should be careful when picking feature names. If you are in the business of making software that's not industry-specific, a good rule of thumb would be to go with a more general term instead of a specialized one whenever possible. That way you will leave more breathing room for the feature to grow (or not to) in the future.