If you're setting up your product hierarchy for the first time, you're likely considering how best to name your feature ideas. You can take a deep breath here because it's not an exact science. You and the PM who sits next to you likely use different words to describe the same user need, which is abstract by nature. Still, a few tips may help assure you you're on the right track.
In this article:
- Needs vs. solutions
- Name features in shorthand
- Examples of how feature names appear in the UI
- Conventions for different feature types
Needs vs. solutions
At Productboard, we often talk about "needs" as the underlying user problems or opportunities we're aiming to address with features.
Some say you should only frame feature ideas as needs or the underlying jobs to be done by the feature in question. There's certainly some wisdom there. It prevents you from biasing the team (and yourself!) by locking onto a specific solution idea when another might better solve the real underlying need.
For example, you might create a feature called Export to CSV because many users are requesting it. But a bit of probing might uncover that the underlying need for exporting is to share data with their colleagues or boss on a weekly basis.
So should you name the feature Export to CSV or Share data with colleagues/boss?
Choose the name that best represents your current understanding of the need, and that will make it easy to find the feature when you search for it later.
That means it might start out as Export to CSV when that's what everyone is requesting. But as time progresses and you learn more about the underlying need, you can update it to Share data with colleagues/boss. And finally, when you decide to solve the need with Weekly summary emails, and that's how your team is referring to it, then update the name again.
You might even take a hybrid approach where you name the feature after a need or broad capability but accompany it with your solution name in parentheses. Here we've done that with an idea for creating your own personal inbox on the Insights board:
Name features in shorthand
Name features in shorthand. Or at least consider how valuable it is to be able to identify what feature you're looking for within the first few words.
A non-example here is writing out the full user scenario or job story in the feature title:
- ⛔️ As a boss, I want to be able to evaluate the progress of my direct reports on a weekly basis
We find this sort of lengthy explanation better to include in the feature description field instead.
When it comes to naming, it's better to abbreviate for skimmability:
- ✅ Evaluate the progress of direct reports (weekly)
Or if the role/segment/persona is important, you can prefix the feature name with this:
- ✅ Boss: Evaluate the progress of direct reports (weekly)
When feature ideas represent specific enhancements to existing functionality, we may also prefix the name with the part of the product it relates to:
- ✅ Chrome Extension: Allow highlighting in Google doc
Note: this may not be necessary if such context is captured in the name of the component, features are organized beneath.
One commonality you'll notice across all of these examples is that the needs/capabilities described begin with verbs. While not a strict rule, we find verb phrases tend to be more straightforward than abstract noun phrases, which leave more up for interpretation.
Finally, while Productboard supports feature names up to 255 characters long, only the first ~85 characters will show in key parts of the UI. Still, even names that get truncated in some parts of the UI may allow you to include more keywords that can be used to find these features with a search.
Examples of how feature names appear in the UI
The feature details sidebar shows only the first two lines of a feature's name by default (~85 characters). The example below contains 55 characters.
On boards with a main column, the main column's maximum width is about 85 characters. (The example below is 55 characters long.)
On insights boards, when linking insights to features, feature names may be truncated more than usual when nested deep in the product hierarchy, though you can hover over the feature to see its full name.
Conventions for different feature types
There are several different types of feature ideas, and it may be easier to distinguish between them by adopting a unique naming convention for each.
One way to do this is by preceding the names of each feature with an emoji, which allows you to effectively filter by feature type by entering emojis in the search bar.
Examples:
- Enhancement to existing functionality: 💡
- Bug fix: 🐛
- User confusion or pain point in today's product: ⛔️
Meanwhile, new needs/capabilities are the default and receive no emoji prefix. Or you can adopt a prefix for these too.
Comments
Article is closed for comments.