For years we product managers have been stuck managing our most important decisions in spreadsheets and project management tools. We've lacked a way to visualize important prioritization criteria or get a holistic view of all our feature ideas.

That's about to change. 

Meet your new Features board. It's designed to offer the right balance of structure and flexibility so you can confidently decide what to build next:

  • Capture your feature ideas and organize them in a flexible product hierarchy
  • Surface the most promising ideas: sort & filter by criteria you choose
  • Prioritize around clear objectives that align with your product strategy
  • Plan your releases and decide what to deliver when
  • Monitor each feature's status as it progresses from discovery to launch

Here's how it works: 🎥

Organizing your feature ideas

Tame your unwieldy backlog of hundreds (or thousands) of feature ideas by adding them to your flexible product hierarchy.

We've found it best to organize features by the user needs they address. Doing so keeps everyone focused on the problems our solutions should address.

But what matters most is that the hierarchy is organized in a logical way that's easy for your team to navigate and find the right feature ideas – whether that's by user need, product area, or technical component. Whatever structure you decide, it should be around components that remain relatively stable over time, rather than short-term projects or initiatives that come and go.

At the least, your hierarchy's structure should map closely to the areas of responsibility for each product manager on your team. So start by considering how you divide responsibilities across product managers or product teams and use that as the foundation for your hierarchy. It's best to start with a simple, shallow structure and add more layers later as necessary.

Once your hierarchy is complete, you'll have an organized outline of your product with all the ideas you have for improving it, nested nearly within. PM bliss!

What do features represent?

Don't get hung up on the name "feature".

In reality, features can represent user needs or broad capabilities you're looking to unlock. They don't need to be specific solution ideas, and they often shouldn't be... unless you've done the necessary product discovery to arrive at the best possible solution idea.

Features will evolve as they progress through your prioritization process and you get a better sense for the solution they entail. It's ok to update their name and description as you go.

As for naming your features, we recommend keeping it short. This makes your boards easier to skim, and often makes features easier to find – not harder. So if you're using features to represent jobs-to-be-done or user scenarios, we recommend using shorthand for these concepts in the name and describing in more detail in the description field. 

The feature description field could also be a great place to add any other information on business objectives, key results, KPIs, and details on phasing/milestones, user scenarios, or acceptance criteria.

Managing features and subfeatures

In productboard, features are the most important ideas you're prioritizing. But it can often be helpful to break big ideas down into smaller subfeatures...

Or take several small, related ideas and roll them up as subfeatures under one big idea...

For now, it might help to think of features as big ideas (epics) and subfeatures as small ideas (user stories). But between you and me, that's not strictly the case. Down the road you may wish to prioritize a small-yet-critical enhancement directly against a big idea. And for this, it would make sense for them both to be features

That's why if you're pushing features from productboard into a development planning tool like Jira, you can decide whether a feature should be pushed as an epic, a story, or another smaller issue type.

A few more limitations of subfeatures:

  • Only features can span multiple releases
  • Only features can appear on the Features board matrix grouping
  • Only features can be scored by objective/driver and other prioritization criteria
  • Board groupings primarily serve to group features (underlying subfeatures are just along for the ride)

That's all you need to know for now! Your best bet is to start with features for now and begin adding subfeatures as needed down the road.

Next steps

✅  Set up a basic product hierarchy

Add a new product to your Features board and set up a simple hierarchy outlining the major areas (or user needs) of your product. Add some feature ideas to each area.

Wrap-up

That's your primer on organizing features on the Features board

Next up, we'll take a closer look at using data columns to prioritize what to build next and plan when it gets delivered.

See also

Did this answer your question?