Connect Feedback to Your Custom Product Hierarchy [24/100]

We ❤️ customers’ feedback at Fibery (and we love our customers). We receive dozens of requests every day from many sources: Intercom chats, community forum discussions, review sites, customer calls, emails, and even messages on Twitter. We struggled with the feedback handling process, but now, I believe, we’ve nailed it. In this article, I’ll explore feedback processing evolution and show you a better process you can have right now.

Let’s check how product companies process qualitative feedback. They typically go through four phases of maturity:

Phase 1: Random notes 😌

Early-stage companies don’t have a lot of feedback or any process for feedback collection and processing. And this is OK since product development is mostly driven by the founder’s vision. Feedback lives in emails, recorded calls, and some random notes here and there. Everything is based on gut feelings and intuition.

Phase 2: Some repository or wiki 🙂

Eventually, feedback volume increases and a company receives dozens of feedback pieces daily. It still can be handled manually, but demands some formal process. At this stage, a company may decide to put all feedback into a wiki tool, like Notion, or a document repository like Google Docs. Feedback is manually copied from various sources and put into the wiki with minimal context.

Everything is manual, which means sometimes people forget to save feedback, miss context, add it in the wrong place, etc. Also, feedback quality is questionable, but at least you have something to work with.

Phase 3: Specialized feedback tool + tags 🤓

Success leads to a huge volume of feedback. Even a relatively small company can receive hundreds of feedback pieces daily, and at this point, manual feedback collection is no longer an option. This is when a specialized feedback collection tool steps in, like Dovetail or Cycle.

A specialized tool can aggregate a significant chunk of the feedback in a single place automatically, but you still need to process it to extract value. And here we have a problem. Almost all specialized feedback management tools promote tags. You have to create a tag hierarchy and link feedback to tags. It seems tags are applied by some leaders, like Tomer Sharon, and popularized with tools like Dovetail.

Linking feedback to tags gives you some ideas about high-level problematic areas of a product. Tags also help to find feedback related to some topics. However, this approach has some flaws.

Problems that Tags don’t address

It is relatively easy to tag incoming feedback, but this approach has some serious problems that prevent you from extracting more value from incoming feedback.

1. Feedback is disconnected from the product hierarchy. When you have a Feature in some tool like Jira or Productboard, and feedback in Dovetail or Cycle, there is no direct connection between feedback and feature. It may happen that feedback relevant to some Feature will be ignored.
2. Prioritization is harder. You don’t have any feedback volume info linked to a feature, and it is harder to understand what Feature is more important.
3. The feedback loop is broken. When you implement and release a feature, you have no idea what people want and whom you should contact.

Phase 4: Feedback connected to product hierarchy in your product development tool 🥹

In an ideal world, feedback is accumulated and connected to product hierarchy directly.

First, let’s define what product hierarchy is.

What is product hierarchy?

A product hierarchy models your product (or several products, but here we will focus on a single product). Some companies only have Features, some create complex structures. In my opinion, a baseline product hierarchy should include three types of entities: Product Area, Feature, and Insight.

Product Area

A Product Area is a significant part of a product, for example, Search or Whiteboard. Your product may contain other Product Areas like Integration → GitHub Sync, meaning Product Areas can be nested.

Product Area is a hub that collects everything related to an area of a product: Features, Bugs, Insights, and general feedback.

You may notice that some Tags that companies use to handle feedback represent Product Areas. In reality, real product areas and tags may diverge when you have them in two tools.

Feature

A Feature is a solution to a problem and a functional requirement for a Product Area. Features can also be nested.

Insight

In most cases, an Insight is a problem with the product. For example: People don’t understand the difference between data and views. It can also be an observation or an opportunity.

Product hierarchy transitions 🦐

The organization of entities in the Product hierarchy is not static. Features get added and get done. Insights lead to Features. Implemented Features lead to Product Areas. Here are the most frequent changes that are useful to know.

Insight → Feature.

An Insight is often a problem definition, but when you decide to solve a problem you create a Feature linked to the Insight and all feedback goes to this Feature. It’s like a movement from uncertain to a more certain product piece.

Feature → Product Area.

Sometimes features give birth to product areas. For example, Basic Search is a feature initially, but when you release this basic search, you get more and more search-related feedback, so it is good to create a Search Product Area and collect all feedback (and all relevant features and insights) in this Product Area.

Why connect feedback to product hierarchy?

The obvious reason is feedback discoverability. When you have features and feedback in a single tool, chances are that you will read the feedback and use it to make decisions. However, there are a few very concrete benefits on top of that.

Better feature specs

Connecting feedback to features helps in gaining a deeper understanding of user needs and problems. When feedback is visible in a feature, you will spot some use cases you might missed, and some requests that you might not have thought about. When you start a feature and read all the feedback attached to the feature, it helps to understand the problem better and scope the feature in the right way.

Prioritization

By linking feedback to specific features, you can better prioritize which areas of your product require attention based on customer input. Here is the list of product areas where the number of Recent Requests indicates customer feedback volume. You can dig deeper and see what features inside every area have more feedback attached. It really helps you to define a scope and set priorities.

On the image below we have some product areas and features with a number of linked feedback items. Search has 32 feedback items and this feedback was not linked to some exact features or insights. Search by Tag feature has 50 feedback items and it looks popular and important to implement.

Here is a real-life example. Our customers asked us to exclude some databases from Search. We collected all such feedback and connected it to a feature called Exclude databases from Search results. We accumulated 15 references and decided to implement it quickly (it is just a basic setting somewhere, right?). Having read all linked feedback it became clear that we have two use cases: static and dynamic. Some databases should never be visible in Search results, and here the solution is indeed a setting somewhere. But some use cases are per-user, like Teddy doesn’t want to see Features in Search, but Jerry does. As a result, we split this feature to three different features and decided to not implement any (so far), since feedback volume was low for any single one of them.

How to connect feedback to the product hierarchy 🤕

You should have a tool that can handle feedback and product hierarchy at the same time. There are not a lot of tools that can do it. To my knowledge, it’s a sleek list that contains only Productboard, Cycle and Fibery.

The linking part is technically easy: you have a piece of feedback as a text document, select some part of the text, and link it to some entity, like Feature or Product Area.

The main rule here is to link feedback to the deepest possible level in your product hierarchy. For example, we have this feedback text:

Yvette:
Hi guys, we have a lot of helper databases; I think it's >50% of all databases.
Was hoping that we could exclude them from search but just found out that it's in the icebox.

I can link it to Search Product Area, but we also have a feature called Exclude databases from Search results. It is required to link this feedback to this Feature instead of the Product Area.

Sometimes you don’t have an exact Feature (or don’t know whether a feature exists). In this case, it is OK to link the feedback to the Product Area. The Product Area Owner should process incoming feedback linked to their area and create new Features/Insights if some repetitive patterns appear.

It means that feedback accumulates in Product Areas and then re-links to exact Features or Insights: less known (PA) → more exact (Feature).

Problems (and solutions) with feedback connected to the product hierarchy 🦋

Let’s discuss potential challenges in connecting feedback to product hierarchy and how to overcome them.

Here are the best tools to handle feedback on my opinion.

Best Feedback Tools: a very brief overview

Dovetail

Dovetail a great tool to capture user research interviews, but not so good for feedback management. It doesn’t have a product hierarchy and prioritization is impossible.

Cycle

Cycle has a nice design, offering a pleasant experience; good for feedback capturing and insights creation. It has nice search functions, but Features and Backlog management are relatively weak since there is no way to sort by feedback quantity and no formulas to define priorities.

Fibery

Fibery has a flexible product hierarchy and feedback-based prioritization scoring. Not all popular feedback sources are supported so far and feedback processing is less pleasant than in Cycle. Still, this is the only choice right now if you want to make decisions based on feedback volume.

TL;DR

• The process of Feedback accumulation and processing evolves from a very basic and chaotic one to a structured one, which will demand specialized tools.
• Using tags in feedback processing has some shortcomings: Feedback is disconnected from product hierarchy, Prioritization is harder, and the Feedback loop is broken.
• It is far better to connect feedback to product hierarchy entities, like Features. Thus you can harness the full potential of feedback: prioritize better, write better specs, and more precisely define the scope.
• There are not so many tools that can do it now, but this is changing. Your best bet is to try Cycle, Dovetail, or Fibery.