Guide
Product hierarchy refers to the organizational structure and process through which a company manages the creation and improvement of its products.
What are the four levels of hierarchy
In the Product Team template, there is a four-level hierarchy:
Opportunity → Component → Feature → Subfeature
The top level is "Opportunity" which signifies the identification of potential areas or problems in the market. This level involves strategic decision-making to understand customer needs, market trends, and competitive landscapes.
The next level is the "Component" level, where the identified opportunities are broken down into components or modules. Components serve as the building blocks of the product and represent the key functional elements required to address the identified opportunity.
Then there is the "Feature" level, which involves the granular details of product development. This level includes the design, development, and implementation.
At the bottom level, there is "Subfeature" which refers to a specific aspect of a feature that offers additional functionality or detail.
How to extend product hierarchy
There are two ways of extension - upward in the hierarchy and downward.
To the top
Opportunities can be grouped according to high-level goals that your company is focused on. For example, the opportunity "Performance issues" could be part of the goal to "Create the fastest tool on the market."
Alternatively, opportunities could be grouped based on the specific market that the research was conducted for. For instance, the opportunity "Users don't like how drag and drop works" may be more relevant for RTL (right-to-left writing) markets.
Let's proceed with the first option.
It all begins with creating a Database. We can create it in the same Space as the rest of the hierarchy to avoid initial confusion. We will name it Goal.
Now let's connect it with the Opportunity Database. You can set Relations right from the Database setup screen, just click on Relations in the upper right corner.
Relations are many-to-one because of the initial requirement to add a higher level to the hierarchy. In this case, a Goal can contain multiple Opportunities, as Opportunities need to be grouped with a single Goal.
At the Goal level, you have access to all the discovered Opportunities and can visualize them in your preferred way.
For example, here is a List View:
To the bottom
This the case when you need an additional level of hierarchy for better decomposition.
Now we have Subfeatures at the bottom of the hierarchy. We can add an extra level and include Stories, small tasks to deliver.
How? Once again, it all begins with creating a Database. Let's create a Story database in the Product space.
You might want to add Fields such as Assignees or Workflow. Everything is up to you - nothing is hardcoded.
We need to connect the Story with the Subfeature Database. You can set Relations right from the Database setup screen, just click on Relations in the upper right corner.
Relations are many-to-one because of the initial requirement to add a bottom level to the hierarchy. So, now we will have to deliver many Stories to finish a single Subfeature. A single Subfeature can be decomposed into multiple Stories.
For visualization, we will use the Board Context Views. By opening any Subfeature, we can quickly access all the Stories and check the progress.
You can say that Story sounds more like a software development definition rather than product development one. Yes, Fibery can be used as a tool for software development as well. You may check this webinar if you are interested.
How to reduce the product hierarchy
As you remember, in the Product Team template, we use a four-level hierarchy.
Opportunity → Component → Feature → Subfeature
At the top or the bottom
If you want to get rid of Opportunities or Subfeatures, that's easy. You can just delete them with one click, and the hierarchy still remain stable. Just click on … next to the name of Database and choose Delete.
In the middle
But if we reduce something from the middle, the connection will be broken. Here is how Component, Feature, Subfeature and Opportunity are connected currently.
What if we get rid of the Feature?
The Relations between Databases will be lost.
What we need to do is to create new Relations that reflect the way we work. But how to understand the proper way of connecting Databases?
We recommend to map out your thoughts somewhere, for example, on the Whiteboards. Here is how we expect the final result to look:
Note that Database deletion may affect Formulas, Automations, and Views. Admins will be notified automatically about any broken Formulas or Automation rules.
Let's create new Relations right from the Workspace map. To access it, click on the Workspace name in the top left and then click Workspace Map (Admins only).
We want the Component to consist of multiple Subfeatures and Subfeature to be a part of a single Component (one-to-many relation). And we plan that Subfeature may affect multiple Opportunities, as well as a single Opportunity may be affected by multiple Subfeatures (many-to-many relation).
Here is how the final setup looks like.