Components are like folders for organizing feature ideas. productboard is all about prioritizing and planning features and components play a helpful secondary role of keeping those features organized.

Some users think of components as different areas of their product. We like thinking of them as the core user needs our product addresses. (Ideally those different areas of the product each exist to solve some distinct user need, right?) This helps us stay focused on why we'd be building any of these feature ideas.

Above: Here's the top level of a sample product hierarchy for Zlack, a messaging app for teams. The first five top-level components represent key things Zlack helps users do. Adminsister your organization represents a tangential need. Capture customer value and Onboard new users represent needs that Zlack has to sustain their business. After all, some features must be built purely for business/strategic reasons (e.g. a new pricing/billing page).

Whether components represent each area of your product, or what user needs you're looking to address, they're unlikely to change in the shortrun. Unlike initiatives, which may serve as projects or milestones with start and end dates, components tend to persist over the long run. (That said, you may decide to reorganize your product hierarchy now and again as your product evolves, or as you decide to tackle different problems for your users.)

Did this answer your question?