Components are folders that organize your features.
Since components are the primary way of organizing features, they should be defined in a way that helps you and your colleagues gain a holistic view of your product and all the ideas you have for it, while also making it easy to retrieve specific features you're looking for.
That means it's best to define components so they'll rarely change. Name them after user needs, product areas, or technical product components, rather than after 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 called 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.
Comments
Article is closed for comments.