I understand the reasoning however the reverse is also true. For features that are equally owned by two people (something that happens very often in our projects), the fact that we can only list one name means there is less visibility and follow-up from all assignees on that issue. This means that it is more easily overlooked in our project. The requirements section is an option but doesn't have the visibililty that feature ownership has. 

I understand how Aha works (with sub requirements, etc), but that is not how the real world works. Not all companies using Aha work in an idealized Agile world, with perfect processess and workflows. The real world is messy, and in that world, assigning more than one person to be responsible for something is extremely common. This is a frustrating limitation.

Agreed with the other comments, we like Aha! and understand the rationale; however, Aha! needs to provide users the ability to customize their experience in certain ways. This is one of those ways, we have a team that has a feature that is arguably an Initiative but it won't be an Initiative. We pay for Aha! and expect to have an experience that fits our reality.

While we have adjusted our processes to match the tool, are great improvements, we still have other areas that will not change. Our expectation is that Aha! has a default setup, like this topic, but will allow the user or group to adjust that to fit their reality. 

Hi there. One additional option that has been introduced since this idea was originally submitted would be to add a custom user field to your features. This field will pull it's value options directly from your Aha! user list. The Aha! record relationships section in this article provides more details for setting this up. Thanks!