How Fibery uses Fibery for product development?
By: Michael Dubakov
Tags: Product Management, Product Development, Startup, Software Development

Note how we use emoji to indicate feedback importance. 🚨 indicates missing Fibery functionality, while 🙄 is a feature request. The number of emojis (from 1 to 3) describes the impact: from a 🚨 slight annoyance to a 🚨🚨🚨 showstopper.

Accumulated feedback → Better prioritization

The goal of these activities is to aggregate real feedback and understand what to work on next. How are we really doing it? We have a single product and we split it into Product Areas. Then we link Features and Ideas to Product Areas, sometimes we link direct feedback.

For example, we have feedback about Email integration but don’t have a Feature or Idea for this yet. In this case, we just link this feedback to Integrations Product Area. Here is Integrations Product Area with all linked entities:

Integrations Product Area has many Features, Ideas, Bugs, User Stories, and References inside.

Then we can count all references inside a Product Area and build a nice chart that shows the most frequently mentioned areas of Fibery. We have quite a lot of requests about Views, Integrations, and Permissions, so it seems we should focus on these things.

A number of references for Product Areas. Integrations are well developed, while permissions are not.

However, this is too high level to make concrete conclusions. For the repeating requests, we create Ideas or Features and link feedback to them. It enables us to clearly see the top requested things. Remember, this is aggregative feedback from all sources: Intercom, Calls, Community Forum.

Chart with top requests.

Indeed many people asking us about more granular permissions and entity changes history, so we have to take these into development ASAP.

We don’t use more advanced models, but definitely, you can create your own formula to calculate features' importance and use a number of references as a parameter. We want to keep it simple and rely on references more since the voice of users mixed with our own vision is the most important thing.

🤔 Why Tags don't work?

Many (all?) tools rely on tags to collect and categorize feedback. However, it doesn't work. Imagine you have meeting notes from a call. There are dozens of feature requests, problems, and other things. If you just add 5–10 tags to the conversation, how to find the exact part of the text that is relevant for Integrations, let’s say? You have to scan the whole text in the meeting notes document.

The ideal solution is to highlight a part of the text and link it to a Tag/Feature/Idea. Product Areas in Fibery are similar to Tags, but what makes it really work is text link granularity.

Notifying customers about done Features

When some Feature is completed, we notify all requesters via Intercom or Email. This is a manual process so far, but the good thing is that we have all requesters linked to a Feature.

Quite often requests are added via Intercom, in this case, it is very easy to contact customers. You just navigate to Intercom conversation imported into Fibery, then click the direct link to Intercom chat and reply in Intercom directly.

Notifying a customer about implemented Feature.

This video is a summary of feedback management and features prioritization in Fibery:

Product feedback management and features prioritization in Fibery.

Ideation

We have a simple ideation app with a list of ideas. Each idea can be described by words and pictures, so we use these things. Here is an example of a well-developed idea about new ways of information handling in Fibery. It has a detailed description and two linked whiteboards.