Comment by doix | Hacker News Reader

Comment by doix | Hacker News Reader

Parent Full thread

I totally agree. The worst thing is going directly from feedback -> ticket. Not only because of what you describe, but also because you end up with a product that is just a list of features without a coherent "idea". Especially when you've got eager developers that will see some slack in the schedule and just pick up a random ticket because it's "easy".

Usually when customers give feedback it's to address an immediate need they have, so they'll suggest adding a button/option/toggle/whatever. And that's fine, but if you do that for every piece of feedback, you'll end up with an unusable mess. Especially because it's usually very easy to add that one extra button/option/toggle.

You usually require someone to go through all the feedback and try to address the root cause of what they're asking for. Sometimes the extra option is unavoidable, sometimes it leads to redesigning some system to be more generic to support what the customer wants + more.

I do think the feedback needs to be linked to the work somehow, not hidden away in a separate PM tool or whatever. Ideally retaining the raw feedback, because sometimes when summarizing it, things get lost.

OTOH, evaluating feedback and determining whether it is actionable is itself work. So you need some sort of system to track the feedback you're getting, discuss it, make decisions about whether and how to implement anything in response to it, and then scope the downstream work you are going to do. And that sounds like the job of a ticketing system.

Maybe you don't want raw feedback dumped directly into your development board, so you might not just add extra columns to it, but another parallel board whose "done" column flows into the dev board's backlog seems like a reasonable approach.

Yeah, I agree with that. I should have been more specific in my comment. Going directly from feedback to _development ticket_ is (sometimes) bad. Sometimes when it's just "this is broken", it's fine.

I agree that you need some system to track feedback. I'm not convinced a board is the optimal choice, because (some?) feedback is kind of timeless. In my mind, it is never "done". Feedback can apply to future features that haven't been thought of yet when the feedback was originally processed, so it's valuable to keep it around in some sort of tag based system. You probably want a way to easily search it as well when designing new features.

The central paradox of product development: planning is work, and eventually planning is enough work that you need to plan to plan to plan to plan and the whole thing collapses because you try to systematize judgement too far up the value stream.

Pretty on point.

https://www.getcustomeriq.com/ is pretty much dedicated to "evaluating feedback and determining whether it is actionable" fwiw

I agree, but it's also important to note that the relationship 'customer request' <=> 'ticket' is often not one to one. A PM will have multiple customer requests that slightly overlap, but not fully, and requests that make more sense as multiple tickets.

In my experience it's really better to keep requests in a lightweight PM tool until they have garnered enough interest to write out as a ticket. The tool I use is Dynalist, really just a glorified todo app, where you can sort/collapse things that go together but there are a million tools like it. Only when there is some certainty it will ever be built does it get a proper ticket for the devs to look at.

Feedback is a good use case for custom issue types, though. We create feedback issues that are not actionable of themselves, but can be linked to tickets, so engineers get a feeling of what customers think.

Where do you keep those to avoid cluttering the "real" backlog? Separate Jira (if applicable) project?

There are products for those like https://www.productboard.com/ or https://harvestr.io/

And Atlassian’s own Jira Product Discovery (JPD) backlog management tool that integrates with Jira:

https://www.atlassian.com/software/jira/product-discovery

Product management tools typically handle this. Jira Product Discovery and tools like Kitemaker keeps that information close to where the rest of the team works :)

Even in jira you can filter your backlog by issue type. (Not saying it's the best approach, separate project and links might work better, because the workflow is different).

We have a ticket status in JIRA called "Parked". It allows us to capture the feedback so the stakeholder doesn't feel ignored. And if we get repeated requests, we can find it, bring it out of parked, and it starts to become a real thing.

There is the issue of dupes but it avoids the other issue, which is that if you hard decline too many requests from right after they are submitted, stakeholders may stop giving you feedback, which is a bad thing. So it is an unhappy middle ground (which is I feel the normal place which product management occupies. I could setup a small shop in the unhappy middle ground and sell souvenirs.)

Jira service desk to a separate backlog which is reviewed and filtered.

Tossing https://www.getcustomeriq.com/ in the mix - pretty much dedicated to this

Reply on news.ycombinator.com