How we got feedback for our product

How we got feedback for our product

Six months ago we started working on Feedgrip. As we have been working towards our beta release, I’d like to share how we got feedback for our project, making this a meta-post:

How we got feedback for our feedback platform

Some of the reasons that led to the Feedgrip idea are explained here. The main idea was:

Help Product Managers with user feedback tasks.

We had a hypothesis:

Product Managers struggle with utilising user feedback effectively and efficiently.

We had to learn more about it, thus we decided to join the best product manager communities. We joined the following Slack communities:

  • PMHQ
  • Product Coalition
  • MindTheProduct
  • Women In Product

We tried to get PMs to talk to us about their day to day regarding user feedback. We learned that these 30-40 minute chats are called User Interviews and we realised that we were nowhere near to doing them the right way. We found resources and tutorials on How to do User Interviews and compiled the following list of topics that would guide the discussion with the Product Managers:

  1. Feedback collection channels
  2. User Feedback importance for Product Decisions On a scale from 1 to 10, how important is customer feedback for your company’s product decisions?
  3. User Feedback reaches Product Development How do you incorporate your users’ needs into your product development? Suppose you have an Intercom conversation with a specific request from a customer. How do you pass this request through to the product team?
  4. Count of daily user feedback reports/requests Do you have a rough estimate of how many requests you get on a daily basis? Among all the requests you get, how do you choose what to do next?
  5. Magic Wand question If I gave you a black box that could process all your feedback, how could it make your life easier? e.g. Bug or feature, Topic clustering, Trends, Automated tagging
  6. Count of Product teams in the company
  7. Budget for user feedback collection/processing/exploration tools

By the way, this was our introduction:

First of all, thank you very much for accepting our invitation to have a chat with us. I just want to make clear that this is by no means a sales pitch. Let me briefly introduce you to what we do. We are building a new product and our vision is to help product teams build more user-centric products by utilising user feedback. We are still shaping our product and thus we are in the process of talking with product managers to identify their day to day pain points, so once again, thanks. I don’t want to spend much of your time so should we get started?

And this was our end line:

Once again I want to thank you for your time. Would you be interested in beta-testing our platform? Once again, this is not a sales pitch, feel free to say not interested.

We reached out to 100 PMs in the various communities, focusing mostly on PMHQ and Women In Product. We ended up conducting 25 user interviews, which constitutes an enormous C/R of 25%. To me, this means that the selection of people to talk to, as well as our human-friendly and not bot-like approach were both very good.

People know their problems, not the solution to their problems.

To our surprise, 19 of 25 PMs were eager to beta-test our platform. 15 of 25 said that the magic wand for user feedback would be a system that automatically groups reports and highlights the important ones. 12 of 25 have been using Zendesk and not Intercom / Drift for user feedback, which was a bit of surprise to us. Another interesting point that came out was that people were not interested in a system that differentiates between Bug reports or Feature requests. However, most of them tend to put Bug Reports pretty high in their priority list.

Do things that don’t scale. Again and again.

Reaching 100 people without using bots proved to fully materialise Paul Graham’s Do things that don’t scale We were happy but not able to continue finding good leads and having meaningful discussions with them. Thus, we decided to use a Google Form with a similar set of questions with the above and utilise the experience we gained from the face-to-face discussions with had with Product Managers.

Our Slack message regarding our Google Form:


And the outcome:

Indeed, we sent out 250 cookie packages! As you see, Google Form scaled much more than individual User Interviews. Questions and Aggregated Answers are listed below:

Do you use user feedback for product development at all?


In a scale from 1 to 10 how important is user feedback in product development?


Which channels/platforms do you use for external user feedback collection?


How do you organize user feedback items?


How often do you encounter duplicate or similar feedback reports?


How many user feedback reports do you receive per week?


Do you constantly monitor or study all user feedback you receive in order to improve your product?


I’d like to talk more about all this in a 20’ chat


As you see, people are busy!

The last question in our Google Form is whether the respondent is eager to subscribe to our “Coming Soon” mailing list and get early access to our platform. This led to a 33% conversion rate, which translates to 87 emails. Much more than any other channel. Concluding, I’d like to list three thoughts on the process we followed so far both for collecting feedback and for getting early access requests:

  1. Having One-on-One conversations with our potential users before using a publicly accessible anonymous questionnaire helped us a lot identifying the points we should focus on. Do things that don’t scale, as much as you can.

  2. Incentives for questionnaire completion don’t need to be very impressive. Many startups offer free subscription or extended trial periods. We did not go down that path since we thought that a subscription for something you do not know or may not need is not intriguing enough. We just offered cookies. Everybody loves cookies.

  3. People are busy! When introducing a new tool for work, people have to let go of their old habits and trusted methods even to just try your platform. Keeping them in the loop and trying to deeply understand their day-to-day problems is much more important than promising exotic technology, robots and A.I. These do not interest people, these interest your development team. Making their lives easier is what interests people.

Thanks for reading my article. As always, we are Feedgrip. Feel free to drop your email if you are interested in getting early access. We will not spam. If you want to learn more about how we work, feel free to drop me a line.

Dimitris Kotsakos
Authored by Dimitris Kotsakos
Software engineer, product guy and avid reader. Feedgrip is one of his side-hustles.