Provide more robust cross-product "Components" - Software Platform "Services" that are shared in Products

I have just discovered Aha and in a trial right now, but very impressed and likely to sign-on.  My use case is I'm running a website/software set of products, developing in Clubhouse - which I am going to try to integrate with Tray.io until Aha does a native integration.  

One very impressive feature of Aha is the hierarchy, and ability to link just about anything to anything - ideas to features, Initiatives, etc.  However, I have been hung up on the fact that Products are the main focus of the hierarchy, and I find this a bit too Flat and "one-dimensional."  There is a lot of development that is done around shared "Components," which can be called various things depending on the use case, such as "Services," "infrastructure," "Mid-tier," etc.  I was a previous Jira user, but moved to Clubhouse because it handles this multi-dimension of development projects better:  Jira forces everything into a Project.  In Agile terminology, "Project" generally refers to an open-ended set of work, it's like a container.  Things like "backend," "frontend" etc.  For the average person, and I think most PM's, "Project" is something that starts and ends.  So if you want to set up both types of categorization in Jira, you are stuck:  You should ideally have a container for things that are in, say, the backend of your stack, but which can be developed in tandem with Frontend and more typical "product" stuff via a "project" that would start, and end.  For example, "iOS app 2.1" would be a Project that is conceived, planned, developed, deployed, and closed.  It has a start and finish.  Clubhouse treats these "Projects" as "Epics" that are completely separate from issues.  Jira on the other hand has its Epics as types of issues.  So in essence, Jira is using a task-subtask set up to account for Projects.  This is awkward as the Epic in Jira has to both reside in a project - although it's allowed to take issues from various projects - and is treated like every other issue.  In Clubhouse, the epic is outside a project and can pull from any project, much more natural, and multi-dimensional.

As I move forward with Aha, I am wondering about how my team can account for components that are used across Products.  It's a similar situation as with the Jira/Clubhouse analogy above in that some of my stuff does not fit well into "Product."  For example, I have a tool that accepts feeds of content into many of my websites, call it the "Feed Ingester."   I plan to build part of that as part of a Product release of "Website X", which is within my Product line of "Website group XYZ." The release is v.2 of an interface on Website X  where my content partners can submit content feeds on said Website X. But the Feed Ingester component gets built and improved and the improvement affects other of my sites in the "Website group XYZ" product line.  I'd like to account for this within Aha.

I have read a good support article suggesting use of custom fields and calling them components:

https://support.aha.io/hc/en-us/articles/217204206-Manage-product-components

I think you guys have hit on the right approach here.  What I want to suggest however is that you develop further a specific type of record in Aha for this type of component.  Custom Fields are OK, but they are not robust enough I think to properly handle the big need here that I assume not just myself, but other product teams have who develop Software Products on a common platform.  I'm guessing that could be quite a few of your users.  With this extra thinking around Components, that could play well with Products and represent the true cadence for Software Teams, I think you'd solve one of the biggest pieces missing in Aha right now.  Here are some pieces that I think would be very useful:

- have some hierarchy within the Component records:  You could have a parent "Platform" and a child "infrastructure" and "hosting," or a team's services like my "feed ingester"

- It would be useful to be able to have initiatives about developing on these Components as initiatives, which might not be classic "Product' development, but would certainly need goals, personas even (of internal users), etc.  But in reality these are not going to be customer-facing in all likelihood, so much of what the typical Product Planning in Aha would not be relevant here.

I will use the custom field suggestion for now from the above article, thankfully its available so I can represent my needs here for the time being.

I also wanted to post a good article that explains in simple terms the relevance of components vs. features in Software and Agile:

https://innolution.com/blog/distinguishing-between-feature-component-teams

Really hopeful to see this developed guys, I think a ton of your users would find benefit from it, and it doesn't strike me as a huge endeavor!

Thanks for listening!