Naming and defining feature ideas

If you're setting up your Features board 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 by nature abstract. Still, a few tips may help assure you you're on the right track.

In this article:

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 "Export to CSV" feature on your board because many users are requesting it. But a bit of probing uncovers 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 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 for 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 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. You can access the full name of a feature on the Features board or insight-linking popup by hovering over it.

Examples of how feature names appear in the UI

The feature details side pane shows only the first two lines of a feature's name by default (~85 characters). The example below contains 55 characters.


And the Features board itself, when the left column is resized to full width, shows about 85 characters. (The example below is 55 characters long.)


On the Insights board, when linking insights to features, feature names may be truncated more than usual when nested deep in the feature hierarchy, though you can hover over the feature to see its full name.


Conventions for different feature types

There are at least 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.

This even allows you to effectively filter by feature type by entering emojis in the search bar—on the Features board and when linking insights to features on the Insights board.


  • 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.

Would it help you to have an official way to distinguish these different feature types? Tell us what you think.

Was this article helpful?
27 out of 30 found this helpful



Article is closed for comments.

Articles in this section

See more
Our Support hours:
Monday to Friday from 9:00 am - 2:00 am CET. Monday to Friday from 0:00 am - 5:00 pm PST.
Productboard Academy
Become a Productboard expert with self-paced courses, quick tip videos, webinars and more.
Product Makers Community
Connect with product leaders, share and find product jobs, and learn how to approach similar challenges. Come join our Product Makers community.