How to react to the feedback you get from your users?

Image for post
Image for post

You discovered a problem of a group of people, and deeply understood this problem and its context. You discovered what motivates people to solve it, and analyzed the opportunity in details in order to evaluate if is worth to build your software product. Finally, you developed the first version of your software product and launched it in the market following the recommendations of the many books about startup, innovation and software development.

Success! Not…

In fact, that was your first step of a very long journey, that we will approach in this and the following articles.

After the innovation stage, when you create and launch the first version of your software product, it comes the time you have to put more energy in understanding if your product in fact solves the problem of your clients. This is the time in which you either get into the growth stage or you cannot cross the chasm.

Actually, this is one of the most important moments in the lifecycle of your software product, the “moment of truth”, the moment in which your software meets the real world. You certainly provided a way for your users get in contact and now you are starting to get your feedbacks. These feedbacks are going to tell if you are in the right direction to solve their problem.

Dealing with user feedbacks

Answer quickly

Don’t make things up

Be polite

You must always be polite with your users, even with those who were not very kind. Your politeness while dealing with them can eventually help to erase the bad impression they had regarding your product.

Don’t implement every suggestion you get

In this beginning, the recommendation is not implementing anything: you are still getting to know your users and understanding if your product solves a real problem for them. If you implement every suggestion you get, you can ruin the solution you created and worse, you will start to complicate your product with many unnecessary features. In order to deal with all the suggestions, it is not necessary to create a system to write them down. After a while getting them you will remember which one are most popular.

If you want to implement a suggestion system, there is UserVoice, that you can try for free.

Feedback is not only way a user tells you something

To build you access statistics report, a good solution is Google Analytics. Using a little piece of JavaScript code in your website and your web application, Google Analytics collects several information from people who access them, such as: through what page they access it; the last page they visited; how long they stayed in each page; where are they from (city, state, country); if they are accessing it from a computer, tablet or smartphone; in addition, it gives you the numbers of visits and several other useful information, mainly in the beginning.

Another useful tool to check if how people are using your product is ClickTale, that also uses a small JavaScript in your page, and gives you information on clicks, as well as on mouse tracking of people when they are using your product. Seeing this can provide you many helpful information about your application.

Interact with your users through several media

You can also create a Facebook page to be the place where your users meet and share experiences. If you have the opportunity, do a live talk with people using your system. Live chats are very enriching for they allow more interaction and exchange of information.

Example of hurry to act due to feedback

I was getting organized to decide how to implement payment in the system but due to this feedback I decided to insert the feature of physical activity record on ContaCal two months after its launch. I did it because it was simple to implement and for thinking that it could help to increase the number of people that would continue to use the product after the first access.

I’ve announced the feature to existent users, highlighted it as one of the features of the system, and started to show this new feature to new users. A lot of people thought it was cool, but the curve of new users who registered to test the system, as well as users who decided to continue using it after the first contact didnít change at all!

To confirm this percept of too much effort with little utility, it was just a matter of looking to the database to see that only 2.4% of register come from activities. I ended up postponing the charging implementation for a month to implement this feature. Today I see that I didnít have to implement this feature and could have let ContaCal as an ingested calories record system only, without worrying with the calories spent in physical activities.

I got an email from a user complaining that the graphic I present as a report does not show the physical activities, considering that the goal is only to show the evolution of ingested calories. That is, I added one more complexity to the system that I have to deal up to today with practically zero gain, nor for user, nor for me, the software owner.

Be careful when implementing a new feature. Its creation creates complexity in the code, in the business rule and in the interface. If the positive outcome for users and owners are not very clear, maybe itís better to wait a little before investing.

Crossing the chasm

Although I have showed lots of information about this book, it is good to focus on some observations about it, considering this moment of product growth and feedback collection.

The first part of the book is very good; a recommended reading for anyone who works in technology. In it, Moore shows the technology adoption curve in details, the existence of the chasm in this curve and explains the reason why this chasm appears.

In the second and last part of the book, Moore suggests how to cross the chasm. The problem is that he uses war analogies for it; again, I emphasize that is not the most appropriate way to address business matters. The first chapter of the second part is called “The D-Day analogy” and the chapters that follow use the same kind of titles (“Aim for the attack point”, “Assemble your invasion force”, “Define the battle”, and “Release the battle”).

In spite of the horrible analogies, the ideas are good. In short, he recommends a profound understanding of the user to guarantee that your product is, in fact, solving a problem. He recommends focus on this single point for a group of users. It is better to be something really good for a group of people than try to be everything for everyone.

From the moment your product is a great solution for a problem of a small group, you will be able to look for more people who might have a similar or the same problem so you can adapt your product, and then reach for more market share.

Of course it is much more easy to talking than doing it, but donít forget: the good understanding of your user, of the problem, of the context in which it happens and the motivation the user has to get it solved are your best tools to cross the chasm, and avoid the premature death of your software product.

Lean Product Secrets

The thing is, two of these E-Books are in the way to their printed edition, so they won´t stay available as E-Books on LeanPub for much longer. So we decided to create a special bundle price to let you keep a copy of these E-Books.

We will keep updating the E-Books until they are officially released. This way you will have early access to their official first edition releases. Enjoy it:

Written by

Digital product development advisor, mentor, board member. And open water swimmer!

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store