Skip to Main Content
Status Unlikely to implement
Categories Features
Created by Guest
Created on Jun 20, 2019

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

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:

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!

    Jul 22, 2022

    Thanks for the idea!

    There are a couple standard ways that customers manage components in Aha! today:

    1. Components managed by custom fields

    2. Each component managed as its own product

    Here are a couple great articles to help further:

    At this time, we do not have plans to add a new record type in Aha! However, we continually monitor ideas for community feedback and alignment to our company goals. I hope you can understand.

  • Attach files
  • Guest
    Jun 20, 2019

    Thanks @julie and "admin."  Just got off a webniar with you guys that was equally as impressive as your response time, and thorough explanations here!  I also discussed with my fellow PM this afternoon making these "components" I described products themselves, glad to hear you are suggesting something similar. 

    I have probably evaluated closely about 40 - 50 productivity/CRM/Design/Product management apps the last 8 months in an effort to finalize my team's stack, and I think you guys are truly tops when it comes to support that I've seen, and I've only been on trial for a few days!

    Really looking forward to diving in deeper to Aha, and thanks again!

  • Admin
    Julie Price
    Jun 20, 2019

    Hi A! Thanks for taking the time to explain your use case and share your idea.

    There are a couple typical ways that you can manage components in Aha!


    Use case



    Components managed as a custom field

    Each component team want to work together on one features board

    Custom field steps in the article you shared: Manage product components


    Each component is its own product

    Each component team wants to manage their work on their own features board

    1. Create a product line

    2. Within that product line, create your components as products

    3. Create a master feature in one of the products

    4. Create a related feature in that same product

    5. Click on the [...[ menu in the feature > Copy feature

    6. Make copies for each of your components

    Another great article that may help: Best practices for managing product components

    There are many ways you can customize Aha! to match how your team works. Our customer success team is here to help! They have worked with thousands of customers and have a knowledge base of best practices that they'd love to share. Please feel free to reach out to them at to help further as needed.