If you use a lot of SaaS products, you’re probably familiar with giving feedback. Whether it’s feature requests, bug reports, or ideas—we’ve all been there. Most of us also like to think we give good feedback.
Feedback is a gift. Companies need it to improve their product and know what to build. Most importantly, with good feedback, they can learn about the value (or lack of it) for their end user (that’s you!).
Giving feedback is also good for you—you get your issues or ideas off your chest. Hopefully, things change for the better.
So, giving feedback is always good, and the effort is always appreciated.
However, there’s a big difference between quality feedback and “meh” feedback. This difference may also mean a difference in how fast things get done.
By learning to give high-quality, actionable feedback, you’ll speed up the process for both parties.
Plus, there are very few people who are truly exceptional feedback givers. Being amazing at giving feedback will earn you extra brownie points.
You’ll be everyone’s favorite user, and might even score some perks like being invited to beta test new features.
Today, we’re going to talk about the things to do to make sure your feedback is top-notch, useful, and truly appreciated.
Include visuals—right away
Many companies have the option to add images or other files to their feedback forms. Use this opportunity.
This is especially important for bug reports and other pressing issues that need fixing ASAP. It’s often hard for a support rep to understand the problem you’re running into just by reading a text description.
There are also nuances to errors that can change the perceived issue behind it.
For example, let’s say you don’t get a pop up notification for an action. There’s a big difference between the pop up not showing up at all, and it popping up, but not displaying text.
This interpretation issue means one of the following things:
- They get the wrong idea of what’s happening and go to development with the wrong information. A giant delay is caused in solving the real problem.
- They’re going to ask you to send visual material anyway.
Either way—wasted time, for both sides.
There’s no doubt any issue will be resolved eventually. However, there’s no reason to delay it by not giving enough visual information.
A screenshot is already good. When it comes to errors, a screencast is even better. A video can show exactly how an error occurs from beginning to end.
Even with simple feature requests or ideas, an image can add a lot. The problem is that people refer to elements and functions in the app differently.
So, you might call something a “post title”, whereas the company refers it to as “description”.
Adding a simple image pointing out exactly what you mean will make it a lot easier for everyone involved. Misunderstandings are no more.
Example of thorough feedback including a visual:
Hi there,
I was commenting on a feature request on the Canny board, replying to someone. When I finished typing the comment, the “post” button wasn’t functioning.
I was eventually able to post the comment by pressing enter, but the button itself did not work.
I was able to reproduce the issue with another comment and record a screen cast, attached below.
If you could look into this and let me know what’s going on, that’d be awesome.
Explain “why”—with real life examples
Bug reports never require a “why” explanation—they’re issues that need to be fixed.
However, if you’re asking for a new feature or have an idea, a “why” is the most valuable thing you can provide.
Here’s the thing—product owners are pretty much always looking for one thing—adding value. Other than that, they also care about reducing effort and obstacles.
If they’re not sure what you’re asking for adds value or reduces effort for you or other users, it’ll be hard to justify.
So, if you’re requesting something new, always explain why you need it.
Here are some prompts if you’re having trouble:
- How does this issue make things hard for you?
- How does it hinder your work?
- How would a fix make your life easier?
- How would it add more value for you?
- How would it save you time?
- Is there anyone else who has mentioned this to you?
The easiest way to make it more clear is to add real life examples from your own use case. This adds credibility and a layer of reality over just “I want this”.
Example of a well-explained ask:
Hi there,
There’s a feature ask we’ve been thinking about lately.
Basically, we’re struggling with the lack of being able to add owners to roadmap tasks.
We use our product roadmap internally, to communicate upcoming projects. It’s the single source of truth for all work being coordinated in the company, from development to marketing.
The issue is that since we can’t add owners to tasks, non-technical team members don’t know who to go to for questions or concerns.
This means that our lead PM is constantly being bombarded by questions about tasks she’s not responsible for.
We’ve resorted to creating a spreadsheet with all the roadmap items, and their respective owners. It’s time consuming to keep up with this. It’s also a pain to update two sources instead of one.
Being able to add owners to the roadmap would save us hours every day, and help us streamline our communication.
Let me know what you think!
Don’t leave anything out…
…because it’s “not important”.
It might seem awkward to write a novel as feedback. Don’t be scared. Honestly, in most cases—the more information, the better.
Granted, it needs to be relevant information. Nobody cares that you’re writing this during lunch while eating a turkey sandwich.
Details that you might find “unimportant” or “TMI” can be incredibly useful to the person receiving the feedback.
Adding as much detail as you can removes a lot of unnecessary back and forth between you and the support representative. This saves everyone time. Time is money.
Try to think about every aspect of an issue or a request that you’re sending off.
With bug reports:
- What happened
- When it happened
- Where it happened
- What did you do before and after
- Did you try any solutions yourself
- Did it happen again
- Has it ever happened before
- …etc.
With feature requests:
- What do you need
- Why you need it
- How it affects you
- Is there anyone else who has mentioned wanting this
- How you want it to work
- …etc.
Additional (and maybe useless, but maybe not) information is better than not enough information.
If you feel like your message is too long and winding, try to condense it down into simple lines or bullet points.
An example of a well-detailed bug report:
Hi there,
I ran into a bug while using Canny today. It seems like merging posts does not work. The command window works fine, but after it closes, the posts still haven’t been merged.
More details:
- This happened about an hour ago
- Our support agent uses Mac OS, the browser is Safari
- The user is X on Canny
- No console errors
- We tried it three times, and no luck
- We tried refreshing the page, logging out and in, no difference
Hopefully this is useful. Let me know if you need anything else.
Mastering the art of giving good feedback benefits everyone
Whether you’re submitting a bug report or requesting a feature, knowing how to give feedback well is a skill worth polishing.
You’re already an angel for even giving feedback, honestly. However, you have the power to make the whole process faster and more pleasant for everyone involved. Use it wisely.
What are your main principles when giving feedback to someone else’s product?
