Mastering the Art of Writing Effective Product Feedback: A Guide

Welcome to the third and final instalment of my Product Feedback series of posts. In case you missed the others, this blog series comprises three separate posts:

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

"The purpose of a storyteller is not to tell you how to think, but to give you questions to think upon." - Brandon Sanderson

In this post, I'll cover several thoughts on how you can take the information you've gathered and write a compelling and comprehensive brief on the impact of that feedback.

Introduction

So far, we've learned that product feedback is everyone's role in our organisation. Whether you're in product or engineering directly, front-line support, customer success, developer relations, pre-sales, post-sales, or beyond, the more we listen to our customers and community, the more we can help influence the direction of the product.

We also learned that it's essential to understand the specific context, knowing the underlying reason why we're receiving a given piece of feedback. What's the person's role? How are they using the platform today? What is it tangibly blocking them from achieving? This level of detail is often buried deeper and requires you to effectively use different types of questions to identify and capture the feedback.

This leads us to this final post on conveying the feedback we've understood into a cohesive, persuasive and relatable story so that the appropriate teams can prioritise this. Remember, you now have the context that the other teams don't. So it's essential to capture all of that context succinctly so that you can represent their needs well.

So let's cover some practical steps and techniques to take your context and notes and bring them into actionable product feedback.

The Power of Storytelling

Think back to your childhood. You probably remember being told an engrossing story that your imagination ran wild. Or, you had (or still have!) a favourite go-to book series where your imagination runs wild.

Stories have been proven?to help us learn, which is precisely what we're trying to achieve in this scenario. We aim to educate other teams in our organisation around the specific context we've encountered as we've worked with customers and our community.

So, much like any story, we need a narrative. We need a character. We need some form of 'adventure', whether encountering a 'villain' (e.g. a bug) or some kind of pitfall (e.g. feature blockers) to create tension along the journey.

So what are the key characteristics? We need to make the feedback?compelling,?actionable,?specific?and?constructive.

Recall the example feedback items that I wrote up in the second post:

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 additional documentation incorporating recommended API access practices or investigation/investment into increasing the API limits."

Do they match those characteristics? The third example is the closest, but there is still room for improvement. Who is providing this feedback? Why? What are they trying to achieve?

So, consider these questions as you write up your feedback:

• What is the scenario??Person X is trying to do Y to achieve Z. They cannot because of A, B and C.
• How does this impact them??This functionality is blocking their internal rollout, as they cannot perform {U Task}, a core workflow requirement. As a result, this will stop/slow the adoption of W users, and X projects, blocking Y revenue and impacting the Z community.
• What happens if it is not implemented??Organization A's project will not proceed, and the teams are already frustrated. They will likely investigate a competitive platform.
• Is there a competitive angle??Competitor already has this feature and has demoed it in several conference tracks / RFP processes.

While the examples above are not all-inclusive, you can see that by answering those questions, we can start painting a much richer story than the example of?"The API is too restrictive, and the customer cannot do what they need".

Ultimately, we capture the context in a rich narrative, which can be easily consumed by the relevant teams and help prioritise.

Communicating Context and Business Impact

There is a subtle but important aspect to clarify from the previous section. Rather than simply surfacing the 'what', we used those questions to help us specify the 'why' underlying the feedback.

Going back to the earlier API example. Suppose that the product team prioritised the feedback as a result and doubled the API limits. Is the solution good/bad? Does it solve the original problem?

We cannot be sure without understanding the "why" of the product feedback.

Similarly, a significant amount of engineering effort and re-architecture might be needed to increase those API limits. So, if it simply comes down to a misunderstanding of the API and clearer documentation was required, then not understanding the "why" could have been particularly dangerous, routing engineering resources to a problem that didn't necessarily need to be solved in that way.

You'll also notice that those questions didn't just point to the specifics of the technical challenges. It's about the direct customer impact and how they use the product/platform daily. We're not making technology because it's cool but to solve the real-world challenges of our customers and communities. So understanding and communicating the expected 'business impact' of implementing (or not) is vital.

I always consider Simon Sinek's Golden Circle when preparing my presentations, talks, blog posts. As you'll see, "why" is the most important question to answer, to help ground the purpose/cause, which is equally important in understanding the feedback.

Tying It All Together: Closing the Loop

So, this is it for my series on product feedback. To briefly recap the posts in the series:

1. Product feedback is everyone's responsibility, and it matters to your organisation, customers and community. It can originate from many sources, and it is vital to build a feedback culture.
2. Having the proper context is crucial to ensure you have actionable, specific and constructive feedback. By actively listening and then using open-ended, closed-ended, meta, leading questions and the five why's, you can capture the needed context for your write-up.
3. Tell a story with the information and context you have so that the relevant teams understand the need, prioritise appropriately and can help find the best solution.?

A centralised and effective feedback management system underpins these points, rather than ad-hoc messages via Slack, Teams, E-Mail or similar. Think of it as compound interest. It may not seem like a lot at first, but over time, diligently saving your product feedback will add up to a rich source of information.

I hope that you have found this series insightful, and I would love to learn from your comments!

So, I leave you with this final question: How are you applying these thoughts already, or how do you plan to use them in the future?