Ready to get started with productboard? Great! The first thing you should do before anything else is to take a few minutes to create a feature hierarchy for your account. Doing this first ensures all your ideas have a place to live and makes future prioritization much easier. In this article, we'll cover:

  • What is a productboard hierarchy? 
  • What are the most common ways that product leaders set up their hierarchy?
  • Which hierarchy method is right for me?
  • Are there any common mistakes I should avoid?

What is a productboard hierarchy?

Depending on the system you've been using, your old organization system might have less in common with a filing cabinet and more in common with a junk drawer - we've all been there! Luckily, productboard makes it easy to create a simple organization structure:

Your productboard hierarchy is like a filing cabinet for all your feature ideas, big and small. Your hierarchy lives on your Features board, and organizes all of your feature ideas. The highest level item in your hierarchy is called a "product." A product can be organized into components, which are broad buckets for categorizing your different feature ideas. If you'd like a bit more structure, you can add subcomponents. 

Inside a component "bucket" are your features, which you may wish to break into smaller subfeatures. If this helps you familiarize yourself: when you're ready to push a feature from productboard into a development tool like Jira, a feature usually maps to an epic and a subfeature usually maps to a story. 

P.S. Changed your mind about how to categorize an idea? Just drag and drop!

Best practice: Limit the noise! Try to avoid adding subcomponents to subcomponents.

What are the most common ways that product leaders set up their hierarchy?

While productboard's hierarchy is completely flexible, our customers find the most success with one of two options:

Option 1: User need (a.k.a. "Jobs to be done")

Chances are, you're already familiar with the idea of organizing by a "Jobs to be done" framework - we're big fans. In this hierarchy, components address why a user is interacting with your product ("I want to communicate with my team") and features address how your product will help the user achieve that goal ("I want to communicate with my team using video calls").

Remember, user needs are relatively stable - not short-term initiatives or projects. For example, here at productboard one of our core user needs is Consolidate feedback. The core underlying user need isn't ever going away, even though feature ideas to help users meet this need will change frequently.
 

Option 2: Product area

Another popular option is to create a hierarchy which maps to the areas of responsibility for each product manager on your team. In this option, your components and subcomponents are based around core sections of your product

Remember, these areas should be fairly broad and stable. For example, here at productboard one of our core product areas is (you guessed it) the Features board. When the product team assigned to the Features board looks in our account, they can find their team's feature ideas right away.

Which hierarchy method is right for me?

There's no one correct answer - it depends on your team, your internal organization structure, and your needs. However, there are a few criteria we use to help customers decide:

1: Which version makes the most intuitive sense to us?

The most effective hierarchy is the one you and your team use. We prefer using a "jobs to be done" framework here - but if your colleagues would spend too much time hunting down features, stick with a more traditional product area framework instead. What matters most is choosing a framework and using it consistently, so everyone always knows where to find feature ideas in the hierarchy later on.

2: How do you need to organize your roadmap later on?

One of the most useful features of productboard is the ability to filter a roadmap by hierarchy, allowing product managers to zero in on their own work.

How would a product manager at your organization need to be able to filter if they only wanted to see their own work?

User need focused organization:

  • "I'm assigned to two core user needs and address them across every area of our product."
  • "I need to be able to track the progress we're making towards helping users connect with their community"

Product area focused organization:

  • "I'm assigned to work on mobile features only, regardless of what user need they address."
  • "I need to be able to track the progress we're making towards a more robust mobile experience."

3: Which features need to be prioritized by the same criteria?

Is it better to score a 70 on an exam or a C+? It's hard to know in an instant - you're comparing two different scales. In the same way, product managers being asked to prioritize certain features over others need to make sure that they're scoring features on the same criteria. For this reason, prioritization criteria are the same for all features in a single product, even those addressing different user needs or areas of the product:

However, there are times when product managers may use different prioritization criteria from one another. For example, the PM of a platform team may focus on compliance and stability, while another PM focuses on customer delight and competitive edge. It would make sense to create a separate product for platform features, so the team can prioritize according to the criteria that matter most to them.

Are there any common mistakes I should avoid?

Avoid the Big Flat List of Doom:

Say it with us now: "Aaaahhhh!"

You're missing out on the best parts of productboard if you don't use any kind of hierarchy! No way to summarize your feature ideas, no way to identify broad trends, no way to automatically organize your roadmap. Down with the junk drawer! Up with a new, organized and strategic hierarchy filing system!

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.

Join an upcoming webinar!

Learn best practices around organizing your product hierarchy during an upcoming webinar! A member of team productboard will explain key concepts, share tips, and answer all your questions so you feel prepared to hit the ground running.

👉Save your seat 👈

Did this answer your question?