Here is a list of Fibery Product Workspace Apps. You can install the one you need and build cross-apps relations, that will be helpful for your team.
Soon we will also add a link here to the whole workspace installation (that is still in progress).
This is interesting, I think the Product Team usecase is a great one and I feel like you guys will get great uptake on it, Fibery is very well suited for these types of teams - I am one of them!
I wanted to ask about one aspect of this: You guys have many relations to both parent and children, is there a reason you didn’t use LookUps?
For example, “Story” has a relation to Product Area, Product, and Feature. I would have thought it would be enough to have the relation to Feature, and use lookups to see up the hierarchy through Product and Product Area. All these extra relations means the Entity view gets clogged with additional fields, which are at a premium until we get Polymorphic.
Thanks in advance for any response you guys can provide!
This is actually, from what I can tell, a common theme in this set up. There are many instances where “up the hierarchy” you have direct relations to the same Type in each Type in that hierarchy, instead of using a LookUp. I have come across this situation in my Fibery Instance, and in some cases I would have a relationship with an Idea and Story that I’d like to use a lookup to see up to the “Product Area” for that Idea. So I have the lookup to pull that in, but also I can have a direct relation to the Product Area out of that Idea. The problem I find is I get every Idea with both these fields. This is also true in your “Bug” example.
So this leads to Field proliferation and I have always struggled with getting comfortable with this “multiple direct relations” to the same hierarchical group.
I have thought about two things I’m hoping to see one day in Fibery that could help solve this:
Some kind of better handling of a “subtype,” which would be a one-to-many relation within a Type, which could be used in “lighter” cases where you don’t want to create a full relation, perhaps something like “task/subtask”.
That latter need might also be handled by Polymorphic as well.
And in case it’s useful to share this, I also have an Idea Management set up in my Fibery, and sure enough I have seen the need for Ideas to be categorized around essentially the same stuff you guys are proposing: Work, Features, Goals, etc. What I did was use a dropdown to categorize them:
Then, I will try to limit the relations to this “Idea” Type to just those Types in my system, using the terminology of “promoted to” to describe the relation.
A great ability I’d like to see is then to have the status of the Idea “follow” the Entity it was converted to. Aha can do this. Here is my request about that:
Since you guys are building this set up for Product teams, perhaps you could look at this capability, or later provide some guidance on how to do it with Automations? I think it would be very useful for Product Teams to see how they are tracking with actual execution of the Ideas they have decided to work on.
Amazing real world new product startup app , very well built with easy to use templates too .
ther is an use similar use case for wiki content marketing too , where milestone related to OKR , issues related to wiki doc , roadmap to track wiki doc creations , integrated to real wiki builts dash boad. A special wiki doc viwes , for edition , readers reviews , comments conversion made possible .Thus this app user casee can be real alternative the notion user can migrate too as user of wiki doc , the creator integrate all doc too as report to the integrated app similar one well done too