Ask HN: how do you store and organize product feedback?
9 comments
You need to go beyond just storing input, you have to process things as a team. That's hard to do well.
Try something like this:
1. Store feedback in a ticket system (or some other system). Try to store the detailed feedback/data, not your interpretation of it. In other words, don't write: "We need feature X for client Y", but write: "Client Y told me usecase Q and Z." Get the data. This is a different format than most bugs require. Try to get the story.
2. Plan roadmap sessions. They could last multiple days. Get multi-disciplinary teams in them. During the sessions, first, go over ALL feedback you got, write it down on sticky notes, and put things on the wall. (The wall part is important.) Then, discuss, review, prioritize, organize, and discuss some more.
Out of this, a roadmap will gell that's based on actual customer needs.
(Note: you will gather a mountain of data. That's good. Then use the process to go through it and make decisions based on data.)
(P.S.: look up "grounded theory" and "contextual inquiry" (the analysis part of it) for more ideas.)
* http://en.wikipedia.org/wiki/Grounded_theory * http://en.wikipedia.org/wiki/Contextual_inquiry
Try something like this:
1. Store feedback in a ticket system (or some other system). Try to store the detailed feedback/data, not your interpretation of it. In other words, don't write: "We need feature X for client Y", but write: "Client Y told me usecase Q and Z." Get the data. This is a different format than most bugs require. Try to get the story.
2. Plan roadmap sessions. They could last multiple days. Get multi-disciplinary teams in them. During the sessions, first, go over ALL feedback you got, write it down on sticky notes, and put things on the wall. (The wall part is important.) Then, discuss, review, prioritize, organize, and discuss some more.
Out of this, a roadmap will gell that's based on actual customer needs.
(Note: you will gather a mountain of data. That's good. Then use the process to go through it and make decisions based on data.)
(P.S.: look up "grounded theory" and "contextual inquiry" (the analysis part of it) for more ideas.)
* http://en.wikipedia.org/wiki/Grounded_theory * http://en.wikipedia.org/wiki/Contextual_inquiry
Thanks for this, Peter. One question: as we scale and grow our team, having a team-wide meeting is not possible. Is this something that eventually gets coordinated with a product manager + core team of "product people"? Wondering how you would scale this process across a team of 20-25 people, or more.
You don't need the entire company there, but you should have a multi-disciplinary group there, aka developers, designers, customer support, sales etc. So get perhaps the product design team (whatever that is), at least 1 senior developer, at least 1 customer support person etc.
Additionally, your product might have separate areas that could have their separate product-design teams and meetings (the backend, the sales site, ...).
(Feel free to email me at [email protected] if you'd like to discuss further.)
(Feel free to email me at [email protected] if you'd like to discuss further.)
Thanks Peter. I am sending an email right now.
We're getting to the point where we have tons of businesses giving us feedback -- sometimes it's directly to me, sometimes to our two sales reps, sometimes to others. We're storing a lot of the feedback as a mix of support tickets + notes in Excel.
Does anyone have advice on frameworks/software/processes they use for storing product feedback to determine what is important, what to build next, etc.?
Thank you!