Mastering the Art of Product Feedback: From Identification to Action

This post is the second in a series of three posts on product feedback:

1. The Power of Product Feedback: Why it Matters to Everyone
2. Mastering the Art of Product Feedback: From Identification to Action
3. Mastering the Art of Writing Effective Product Feedback: A Guide

"Seek first to understand, then to be understood." - Stephen R. Covey

In my last post, we covered why product feedback is essential to an organisation and that it's everybody's responsibility. The industry has evolved, making feedback more critical than ever to continuously deliver services that delight our users. In this post, we'll build upon the foundations of the "why" and focus on practical steps for you to uncover and identify feedback. This post is important because feedback is more than what your users tell you. There are many channels of feedback (some broad, some 1:1). Some feedback will seem similar, but there may be different underlying requests at the root of the problem.

Finally, it's not always what is explicitly said. Suppose a user doesn't have confidence in navigating through your user interface, e.g. setting up the billing mechanism, deploying some infrastructure, or has several questions. In that case, it implies that improvement is needed. The documentation is either undiscoverable or needs clarification on the required steps.

Identifying Good Sources of Feedback

As we eluded to earlier, there are many routes for collecting feedback. These could include:

• Customer support tickets
• Interactions with your social media channel
• Community forums and discussion boards
• User satisfaction surveys (Including formal Net Promoter Surveys (NPS) or periodic 'pulse' surveys)
• Executive Briefing Sessions
• Conference Keynotes, Breakout Sessions, Roundtables
• Any customer meeting from the pre-sales stage through to deep implementation scenarios
• and many more! I'd love to learn in the comments; what are some of your best sources of feedback?

Hopefully, you're picking up on the point that any interaction with your users (community members or customers) is an opportunity to understand their experiences with your product. By engaging directly with them, you can determine whether their sentiment and feedback are positive, negative, or neutral, ideally constructive. Remember that sometimes emotions can come in (they're likely paying your company for a product or service, which in turn, their own company, community, or similar are depending on).

However, the first step is seeking to understand and not assuming that you have heard this feedback before and already know about it. There may be some nuance to this particular request, such as industry regulatory requirements, accessibility requirements or more. But, of course, there may be noise in the signals you receive. How do you reduce that so that you can focus on the quality feedback?

Identify your key stakeholders, and be aware of who they are

For example, engineering team leaders will likely understand the 'on the ground' impact of product friction. Individual engineers will be able to represent the challenges that they deal with daily. At the same time, senior business leaders, including the CIO and CTO, will see how the challenges affect the broader technology strategy.

Context is vital

As we've discussed above, the role and background of the person you're receiving feedback from will influence what they say. But, there is much more context we'll need to pick up about the company or community, how they're using our product, why they're using it that way, and their expectations. We are 'on the front line' with the rich opportunity to collect this feedback. Our product teams are the ones who consume the fruits of our work and will have a different context. Therefore, context is vital. We need to tell a story in our product feedback so that the product teams can genuinely understand the importance of each request and appropriately prioritise it against their backlog.

Recognising Good Feedback

Let's peel the onion layer a little more. When we say good feedback, what does that mean? Compare these examples:

1. "The API is too restrictive, and the customer cannot do what they need"
2. "The API does not expose everything available in the User Interface for programmatic consumption. The customer is building a dashboard to determine the number of investments made throughout the day, though only publicly available market data is available, not transaction information."
3. "The API provides all the required information for the customer's project. However, they are hitting API rate limitations daily. They would like to see either additional documentation incorporating recommended API access practices or investigation/investment into increasing the API limits."

Notice that there are a few key differences between these examples:

Actionable and non-actionable feedback.

• Example 1 is non-actionable feedback, as the exact problem or feedback request is unclear.
• Example 2 does better, highlighting the exact issue. Still, clarification is needed on the desired outcome (i.e. an extension to the existing API or a brand new API to call market data and transaction information separately).
• Example 3 does better again. The customer is having issues accessing the API. It is unclear whether it's their implementation (i.e., calling the API too much, in a suboptimal way) or a limitation on the API, not scaling to the needed levels to match customer expectations. Two clear routes of investigation can be divided between a field service or customer success team alongside the product team.

Specific and constructive feedback

• Again, example 1 is not specific or constructive. It comes across as a rant with no detail on how to solve the problem. This type of feedback is not valuable to the product team in prioritisation or building a solution.
• Example 2, again, is better. However, the feedback could be further improved. Which APIs are they using? How often are they calling those APIs? Are there other endpoints they have ruled out? Why? This line of questioning helps us determine if our documentation has been clear enough to help them arrive at the appropriate decision. After all, the endpoints could already exist, albeit poorly documented.
• Example 3 is good but also has room for improvement. Which endpoint is the customer calling? How often? If it's GraphQL, how much data are they requesting from the endpoint (i.e. are they saturating their requests quickly)? How did they arrive at that solution (e.g. Is their documentation which need to be updated to bring more clarity to solving this problem)?

Different types of feedback

Remember that feedback doesn't necessarily need to result in a direct product improvement. There are several areas, for example:

• Documentation improvements (e.g. discoverability, or whether the context exists)
• Content improvements (e.g. Helping to prioritise the DevRel team's backlog on content to enable specific scenarios)
• Sample improvements (e.g. Increase the complexity of the samples available for users to learn from and improve their scenarios)
• UI Improvements (e.g. The product works as expected, but arriving at the specific place in the UI to achieve that step was challenging)
• Product Improvements (e.g. The product has a current limitation, which blocks users from achieving a particular activity, or users would like to see additional enhancements).
• Bugs (e.g., something unexpected happening in the product, preventing the user from using the service as expected).

And once again, there are so many other examples we could pull out here. The critical point is that feedback comes in many different forms. It's not just about direct input to the product teams but how we collectively make our products accessible to users and improve their overall experience.

Actively listen, then pick your questions.

Let's take stock. As a group, we recognise the importance of product feedback. We realise that giving clear, targeted, and valuable feedback is crucial in helping determine which team should handle it and helps in backlog prioritisation.

But how do we get that actionable, specific and constructive feedback? Unfortunately, it's not always given to us directly - so it requires a bit of work to 'extract it' from the users we're working with. It all focuses on 'seeking to understand' and engaging in active listening. Ensure you are involved in the discussion, play back what you heard, and be open and curious about their experiences. Once we have that foundation, we can use different types of questions that can help us navigate their feedback.

Open-ended and closed-ended questions

• Open-ended questions typically start with "How, what, or Why". They usually require a complete answer rather than "Yes, or no" or one line. They help gather context and understand a broad scenario.
• Closed-ended questions typically result in a "yes/no" or direct answer. These questions are helpful if you're trying to establish a specific point rather than gathering context or broad information.

The five why's

The five-why's is a technique to get to the root of a scenario. Used well, it is an iterative approach to identifying the heart of a challenge. Used poorly, the person answering the questions may feel like they're in an interrogation. My tip here is to not "literally" use the word " why " five times over but carefully rephrase open-ended questions to gather the needed context and determine their underlying challenge.

Meta-questions

Meta-questions?are helpful to 'up-level' the question. If you're too much in the nitty-gritty details and want to understand the overall scenario, you likely want to bring in a meta-question.

Leading questions

Leading questions help you assess a scenario against an assumption you have. Be careful about using this, as you are implying the result you're looking for in the question, influencing the answer. This style of questioning can make people defensive if used formally, so it is likely best used in a relaxed style once you have gathered enough context and want to focus on the overall problem.

Properly managing feedback

Now that we've worked with our stakeholders to understand and capture their feedback, we must pass the feedback on to the appropriate teams. But how do we do that?

Centralising the feedback

Having some form of system, catalogue, or process to capture this is vital. Without that, there's no way of determining the scale and scope of a given feedback item. For example:

• Without a central source of feedback, how do we know if this has come from 1 customer or community group, or 100?
• How do we know if this has come from one of our top customers or someone who has just tried the service for the first time?
• How do we identify the seasonality and causality of feedback requests (e.g. has a recent change caused/fixed this)?
• Directing feedback to product teams over Slack, teams, direct messaging, or similar means the input might get lost. We're all busy and context-switching in our day-to-day roles. But what if that person goes out on vacation/sick? What if they change positions? Are they even the right person? Shouldn't that be routed to the docs team if it's more of a documentation piece of feedback? (Then rinse and repeat the questions in this bullet point)

As you can see, a well-designed feedback system enables teams across the company to come together and assess the priority and who best addresses the feedback. It also allows folks across the company to add to the input (think of it like an upvote, or +1), to aid in prioritisation, and add relevant context for other users, customers, or community members.

The feedback loop

Centralising the feedback has another, incredibly important benefit. It helps create an effective feedback loop.

To create and encourage a productive feedback community within your company, you must demonstrate that their input has been recognised and dealt with in some manner. The internal community interacts directly with your product's users, and it is essential to manage their expectations by demonstrating how their feedback has been received and acted upon.

• Establish some review process. Even a lightweight acknowledgement of the feedback can encourage folks across the company to know that their efforts have been recognised and impactful.
• Automate where possible.?Whether categorisation or associating metadata to the results raised, it will help increase the quality and discoverability of your centralised feedback.
• Provide updates.?Let your internal community know if the input has been prioritised on the backlog! Because inevitably, you'll be looking for some early adopters to trial the experience. Who better to trial the experience than the ones who brought you the feedback in the first place?

Conclusion

So let's recap what we've covered in this post:

• There are many routes to covering feedback. Context is vital on who is giving the feedback and why they may be providing it to us (e.g. are they a long-term user or a brand new user; how are they experiencing the product?)
• Feedback is not all about feature requests or product improvement. It could also include usability enhancements, documentation improvements and other content/samples to aid in adopting your platform.
• Feedback should be actionable, specific and constructive. We can use techniques like active listening, open-ended and closed-ended questioning, the five why's, meta-questioning and leading questions to gather the needed context and background.
• Having a robust process and system to capture feedback is vital to building the sense of community we covered in my first post. It helps trend input over time, group it to aid in prioritisation, and establish a feedback loop between our internal community and customers.

I hope this post has been helpful. This is the second in my three-part series on product feedback. I'd love to learn any additional methods that have worked well for you, so please comment below!