3 Types Of Feedback And How To Cope With Them

Here's what supermarkets taught me about feedback processes.

In major outlets, you often find different types of checkout counters:

1. Normal checkout with a cashier
2. Line for 10 items or less
3. Self-service kiosks

Doing your monthly grocery with tons of items? Go for option 1.

Got only a couple of items to buy? Skip the long queues and head for option 2.

Don't mind the extra effort & you're savvy enough? Scan the barcodes and swipe a credit card using Option 3.

-

When you're running a product, people around you will inevitably have feedback to share.

Some feedback will take the shape of heavy enhancement & feature requests coming from customers. You obviously need to capture more context here and get the business case. This might necessitate approvals, customer interviews, backlog gating discussions etc.

On the other hand, you will have receive lighter quick-fix items coming through as well.

Ex: Sales might catch a little bug on your search screen, marketing might pick up on a typo or two or something that is off-brand, customer success might have a cosmetic suggestion and so on.

Now, product & engineering teams don't want to entertain a high influx of such requests over email. And rightly so, as it becomes cumbersome to manage.

Instead, they redirect users to a ticketing system.

However, if the end-to-end process for a lightweight request

(a) turns out to be as complex as a feature suggestion

(b) takes a long time to acknowledge, then you'll end up discouraging users from filing that feedback in the first place.

Thus, you need a "10 items or less" kind of isle.

You could have a Slack channel where such cases are highlighted for POs and QAs to vet and log themselves OR have simplified ticketing forms based on the issue category.

Ex: there's no need to collect a business case when there's a typo on the main headline. Or if the problem is specific to a mobile device, simply have fields to capture device & browser specifications.

For functional bugs, you could just mandate a short Loom video to allow them to walk you through the issue.

Furthermore, if a certain person has authority and access to, say a CMS, they could "self-serve" by logging in and fixing the issue themselves.

I'd go as far as to say that filing such issues should be encouraged so that the product gets polished up collectively.

On the flipside, ticket authors make things a bit difficult by biasing the ticket urgency, especially if it's something to do with their client or department.

Ex: some ticket issuers have a tendency to mark everything as "Urgent" even when the issue is, in fact, trivial. This can create needless overheads for PMs during prioritization.

Such behavior needs to be curbed through internal training and education. Reduce the subjectivity by defining what constitutes as urgent and what doesn't.

‍

In summary, ease up feedback submission for issues that aren't that complex to fix.