We've recently made some enhancements to the product hierarchy to make it even more flexible for capturing feature ideas both large and small. If you're looking for more information what's new, you're in the right place!

Introducing subfeatures

Some ideas start out big, and you want to break them down...

Some ideas start out small, and you want to roll them up under one big idea...

To help you capture both big and small ideas we’re introducing a new entity – the subfeature.

Subfeature basics

Subfeatures sit beneath features.

You can create subfeatures in several ways:

  • Add new subfeatures directly to a feature.
  • Move existing features beneath another feature to convert them to subfeatures.
  • Create subfeatures when linking insights from the Insights board.

Note: At this time, it won’t be possible to convert a feature to a subfeature if it already contains subfeatures.

Subfeature data fields

Subfeatures are simpler than features, but share a number of data fields in common:

  • people
  • effort
  • tasks
  • custom fields
  • owners
  • followers
  • status (same values as features)

Subfeature actions

Subfeatures also support some of the same actions as features:

  • Use the hierarchy field to relocate a subfeature
  • Link insights to subfeatures
  • Multi-select to perform bulk actions (hierarchy, status, tag, owner, followers, delete)
  • Merge two subfeatures to dedupe them and combine their insights. (It’s not yet possible to merge a subfeature with a feature.) 
  • Convert subfeatures to features in multiple ways: 1. From menu available in its details. 2. By dragging and dropping the subfeature outside of its parent feature on the hierarchy. 3. Using the Hierarchy field to move a subfeature directly beneath a component.

Subfeature behavior

The order of subfeatures under a feature will be persistent in all views and feature details, except in the Sorted list grouping where subfeatures will be sorted under a feature accordingly. 

Subfeatures on the Roadmap

Subfeatures are displayed under their parent feature on the Roadmap if they have a release assigned to them.

You can choose whether or not to show subfeatures on the Roadmap and save this setting to a view.

Dragging a feature with subfeatures to another release on the roadmap will change the release assigned to the feature as well as underlying subfeatures.

Subfeature limitations

  • Subfeatures won’t appear on the Matrix.
  • Subfeatures must reside under a feature, not directly beneath a product or component.

Updates to features

With the addition of new subfeatures, productboard features can now be used to represent ideas for large pieces functionality. That's why features can now span multiple releases.

Assign features to multiple releases:

  • In the feature detail, select multiple releases in the release picker.
  • In the release columns, press shift while selecting two or more releases.
  • In the Features board By release grouping, press shift while dragging the feature to a different release bucket.

Each subfeature can be added to just one release.

Note that features still automatically span all releases assigned to underlying subfeatures. Assigning a subfeature to a release that its parent feature has not yet been added to will automatically add that feature to the release. 

Simplified components

Up until now, components have played several roles. They help you organize your Features board, but may also be used to cluster smaller feature ideas into bigger feature ideas. Now that you can use features and subfeatures to capture ideas both large and small, components can simply be used to keep things organized.

That means it will no longer be possible to apply many types of data directly to components, as this will be reserved for features and subfeatures.

Data no longer applicable to components:

  • Components will no longer have status.
  • Component will no longer have individual values for initiative, driver, effort, segment, competitor, task.
  • Users no longer will be able to convert a product to a component/feature and vice versa. 
  • Components will no longer be able to be pushed into integrated development planning tools.
  • If today you have the lowest level of components representing epics. Soon, you’ll use features to represent these ideas instead. Migration explained below.

Data aggregation at the component level

Rather than allowing data to be input directly at the component level, in many cases, components will aggregate data of their underlying features.

Data that is aggregated at the product and component levels:

  • User Impact score, Prioritization score, driver, company, effort
  • Calculation of the number of features that have some value type assigned: segments, initiatives, competitors, releases, tasks

Data that can still be input at the product/component level:

  • People, owner, tags, hierarchy (components only), custom fields

Component multi-select

To help you organize your components more effectively, we’ve added multi-select and bulk actions.

Bulk actions supported on components:

  • Archive
  • Move
  • Tag
  • Delete
  • Add/change owner
  • Add/change follower

Converting features to components

You can convert a feature to a component from a menu available in its details pane. Doing so will convert any underlying subfeatures to features.

Converting components to features

You can convert a component to a feature from a menu available in its details pane. Doing so will automatically convert underlying features to subfeatures.

Migrating to new components

Component status

You might previously have assigned a status like “done” to a component to filter it off of your views by default. Now that there’s no longer component status, these old components may reappear. Simply archive these components. You’ll always be able to use the filter menu to filter on all archived components if you ever need to access them again. (You can also filter components off your board temporarily using the Hierarchy filter.)

Component data values

Did you previously set data directly on the component level?

That data will now appear to be replaced by an aggregation of underlying feature data. But don’t worry. You can restore it by simply converting these components to features. Same thing if you have the components pushed to an integration you will be able to retrieve the link by converting them to a feature.

Jira Improvements

With the new flexible hierarchy and subfeature entity, we’re also improving how the Jira integration works.

Push both features and subfeatures to Jira

It will now be possible to push both features and underlying subfeatures to Jira. Components will no longer be able to be pushed as they represent folders for organizing features; features represent big feature ideas.

  • If you previously pushed your lowest level of components into Jira as epics (and features as stories), we recommend converting these to features. (Your previous features can be converted to subfeatures.)
  • If you previously pushed features into Jira as epics, you can leave your features as is. You now have the option to add subfeatures beneath your features and push them into Jira as smaller issue types (typically stories) as you see fit.

Flexible issue type mapping 

Each time you push a feature or subfeature to Jira, it will now be possible to decide what issue type it will become.

  • Features will typically be pushed as epics, but they can also be pushed as stories or other issue types like tasks.
  • Subfeatures will typically be pushed as stories, but can also be pushed as bugs, sub-tasks, or other issue types.

Note that in Jira, sub-tasks must have a parent. That means when pushing subfeatures as sub-tasks, their parent features in productboard will be pushed into Jira as well.

Other improvements:

  • For features pushed to Jira, you’ll now see both their issue ID and issue type displayed in productboard.
  • A feature spanning multiple releases in productboard will be assigned to multiple fix versions when pushed to Jira.

See also

Did this answer your question?