One thing that stood out to me from ASU’s How do I gather and respond to customer feedback? module is that feedback should happen early and continuously, not only after a product is finished. The module emphasizes using insights from users, buyers, and other stakeholders to validate whether you are solving the right problem and whether people actually value the solution. ASU Entrepreneurship Training
For my own project, SceneSafe, I am exploring ways to reduce merge conflicts for student game-development teams. Instead of assuming I already know what features developers need, I want to talk with students, team leads, and instructors about where collaboration actually becomes difficult.
The biggest takeaway for me is that useful feedback is not just about hearing that an idea is good. It should help reveal what needs to change, what matters most to users, and whether the original idea needs to be improved.
Media: [How do I gather and respond to customer feedback? — ASU Entrepreneurship + Innovation]
Top comments (2)
This matches what I have seen building early products. It is very easy to hear feedback through the filter of what you already planned to build. One habit that helped me was writing down what I expected users to say before each conversation, then comparing it afterwards. The gaps were often the most useful part. It also made it easier to admit when a feature I liked was not landing.
Agree with the core point. The "confirm it" trap usually starts in how the questions are written: rating scales and yes/no questions can only confirm what you already believed. Open questions with one follow-up ("what were you trying to do when that happened?") are what produce the surprising answers. I work on chatform.in, which automates that follow-up in a form, but the principle holds with any tool, including a plain email.