Components act like folders for organizing feature ideas on the Features board.

You'll see features grouped by component whenever the Features board is set to group features by Hierarchy.

Since components are the primary way of organizing features, they should be defined in a way that helps you and your colleagues 1. Gain a holistic view of your product and all the ideas you have for it 2. Easily retrieve specific features you're looking for.

That means it's best to define them so they'll rarely change – based on user needs, product areas, technical product components – rather than around short-term projects or initiatives.

At productboard, our team likes organizing features by the user needs they address. Doing so keeps everyone focused on the purpose of each idea.

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 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!

Above: the top level of components for a sample product Zlack, a messaging app for teams. Each relates to a user need the product addresses, or to needs of the business (after all, some feature ideas relate solely to helping the business sustain itself and grow). Additional components further subdivide features beneath.

Did this answer your question?